:::(Attenzione) (Modifiche alla rete OPCH in LTS12+) Con LTS12 è stato modificato il modo in cui OPCH comunica con Tulip Cloud. Queste modifiche erano necessarie per garantire che l'OPCH potesse supportare distribuzioni massicce di connettori e macchine.
Con questa modifica, l'OPCH è passato dal mantenere una connessione websocket continua con il cloud a essere stateless. Questo porterà a un aumento delle chiamate RESTful tra OPCH e Tulip Cloud. Durante gli aggiornamenti dell'OPCH, i clienti sono tenuti a garantire che i proxy e i firewall siano in grado di supportare questo carico aggiuntivo.
:::
Scopo
Imparare a sfruttare gli Host Connector On-Premise per le proprie integrazioni.
Prerequisiti
Per conoscere gli Host Connector in Tulip, leggere prima questo articolo
Panoramica
Questo articolo vuole essere un punto di riferimento per i Connector Host On-Premise (OPCH) in Tulip. Il Connector Host è un servizio utilizzato per facilitare le connessioni da Tulip a servizi web esterni, database e server OPC UA. Tutte le istanze di Tulip hanno un Cloud Connector Host per impostazione predefinita.
Ci sono diverse considerazioni da fare per determinare se un Connector Host On-Premise è l'architettura corretta.
Considerazioni chiave per l'host connettore On-Premise
Le considerazioni per un Host Connector On-Premise possono essere suddivise in alcune categorie:
1. Rete2. Gestione dell'infrastruttura3. Prestazioni
Rete
La motivazione più comune per l'implementazione di un Host Connector On-Premise è il vantaggio che offre per la connessione a sistemi ospitati all'interno di una rete locale. Con l'offerta on-premise, tutte le connessioni da Tulip ai sistemi esterni partono dalla rete locale. Tutte le connessioni dalla vostra rete sono in uscita verso Tulip tramite un WebSocket sicuro.
Ciò contrasta con i Cloud Connector Host, che richiedono un accesso in entrata ai servizi. In genere si tratta di una decisione IT per consentire connessioni WebSocket sicure in entrata dal cloud di Tulip al servizio, spesso utilizzando regole di port forwarding sul router/firewall WAN.
Gestione dell'infrastruttura
Per implementare un Host Connector On-Premise, ci sono diversi componenti dell'infrastruttura di cui il cliente è responsabile. Di seguito è riportata una matrice di ruoli e responsabilità di base:
| Tulipano | Cliente | |
|---|---|---|
| Fornire risorse tecniche su OPCH | X | |
| Hosting e distribuzione di macchine virtuali | X | |
| Monitoraggio e aggiornamenti della macchina virtuale | X | |
| Generazione di credenziali OPCH | X | |
| Test dell'OPCH | X | |
| Distribuzione dell'OPCH | X | |
| Aggiornamento dell'OPCH | X | |
| Monitoraggio dell'OPCH | X | |
| Risoluzione dei problemi dell'OPCH | X | X |
Il cliente dovrà idealmente essere a proprio agio con le tecnologie utilizzate per l'implementazione di Connector Host e con l'uso di tecnologie come Docker per la gestione dei container.
Distribuzione di un host connettore on-Premise
Standard tecnici
The amount of resources needed to run OPCH will increase as its usage increases. If you consistently use it beyond 250Hz of throughput, we strongly advise allocating more resources to your virtual machines to ensure optimal performance.
Quando si decide di implementare una soluzione on-premise, Tulip raccomanda un percorso self-service utilizzando un'immagine Docker distribuita. Il modo più semplice per farlo è utilizzare una macchina virtuale con una distribuzione di Linux (preferibilmente Ubuntu).
Tulip consiglia inoltre di ospitare un solo On-Premise Connector Host per macchina virtuale per evitare un singolo punto di guasto per i siti.
Requisiti della macchina virtuale:
- RAM - 4 GB
- ROM - 8-16 GB di disco
- CPU - 2 core
- Versione Docker - 20.10+
Per quanto riguarda i requisiti di rete, l'Host Connector On-Premise ha i seguenti requisiti:
- Un indirizzo IP
- Risoluzione DNS per
- Accesso in uscita sulla porta 443 a Tulip (IP elencati qui)
- Accesso in uscita al repository Docker qui
- Accesso in uscita a tutti i sistemi esterni rilevanti con le relative porte
Esaminare l'elenco completo dei requisiti di rete qui
Richiesta di credenziali
Contattare il Supporto Tulip(support@tulip.co) per richiedere le credenziali del Connettore Host On-Premise utilizzando il seguente modello, inserendo tutti i dettagli racchiusi tra parentesi:
``Ciao,
Questa è una richiesta di creazione di un nuovo Host Connector On-Premise.
Istanza Tulip:
Tulip creerà e condividerà le credenziali attraverso un collegamento sicuro e temporaneo alla password. I dettagli devono essere trasferiti a un archivio di credenziali gestito internamente e includere quanto segue:
- Fabbrica
- UUID
- Segreto della macchina
On-Premise Connector Host credentials should not be used to create more than one Connector Host - this would result in connectivity problems for all hosts sharing credentials.
Versioni disponibili dell'Host Connector On-Premise (tag)
OPCH must be kept up-to-date with the Tulip product. More information.
Tulip utilizza i tag dell'immagine Docker per versionare le immagini dell'host del connettore. Di seguito è riportato un elenco dei tag dell'host del connettore attivamente supportati che possono essere utilizzati insieme ai comandi Docker run e pull.
| Versione LTS | Versione bisettimanale | Tag OPCH più recente |
|---|---|---|
| LTS11 | r262 - r274 | lts11.7 |
| LTS12 | r275-r287 | lts12.10 |
| LTS13 | r288-r307 | lts13.4 |
| LTS14 | r308+ | lts14 |
Distribuzione
La seguente sezione illustra come distribuire un host Connector On-Premise in diversi ambienti. AWS e Azure offrono entrambi servizi di container in grado di eseguire l'immagine Docker.
-
AWS:
- Utilizzare l'interfaccia Web e questo set di istruzioni: https://aws.amazon.com/getting-started/hands-on/deploy-docker-containers/.
Prior to LTS12, the environment variables CONNECTORS_HTTPS_PROXY and CONNECTORS_HTTP_PROXY must be replaced with HTTPS_PROXY and HTTP_PROXY, respectively
- Azure:
az container create \ -g <NOME DEL GRUPPO DI RISORSE IN AZURE> \ --name <NOME DEL CONTENITORE> \ --cpu 2 \ --memory 3 \ --restart-policy Always \ --image bckca2dh98.execute-api.us-east-1.amazonaws.com/public/connector-host:<TAG> \ -e TULIP_UUID='<UUID>' \ TULIP_FACTORY='https://<YOUR SITE>.tulip.co' \ TULIP_MACHINE_SECRET='<SECRET>' \ TULIP_DEVICE_TYPE='onprem' \ CONNECTORS_HTTP_PROXY='' \ CONNECTORS_HTTPS_PROXY=''
- VM Linux: :::(Warning) (Pre-LTS12 OPCH)
Prior to LTS12, the environment variables CONNECTORS_HTTPS_PROXY and CONNECTORS_HTTP_PROXY must be replaced with HTTPS_PROXY and HTTP_PROXY, respectively
:::
docker run -d \
Aggiornamento di un host del connettore on-premise
OPCH must be kept up-to-date with the Tulip product. More information.
Tulip recommends proactively confirming the upgrade by successfully running a test OPCH connection to the development environment and/or developement instance. Once this verification is complete, the production environment can be confidently upgraded. Details on how can be found below.
Tulip rilascia gli aggiornamenti del Connector Host On-Premise in base al programma di rilascio del supporto a lungo termine (LTS). Per aggiornare il servizio, seguire le istruzioni riportate di seguito:
Il processo di aggiornamento di un OPCH comporterà un tempo di inattività durante l'arresto e la ricreazione del pod.
- Ottenere l'ultima versione dell'immagine Docker di On-Premise Connector Host.
docker pull bckca2dh98.execute-api.us-east-1.amazonaws.com/public/connector-host:<TAG>2. Eseguire il comando seguente per ottenere l'ID del contenitore Docker.
docker ps3. Se si ha accesso ai dati TULIP_FACTORY, TULIP_UUID e TULIP_MACHINE_SECRET, passare al punto 4. In caso contrario, eseguire il comando seguente e memorizzare l'output del comando in un luogo sicuro.
docker exec <container-id> env4. Fermare il contenitore Docker esistente.
docker stop <container-id>5. Rimuovere il contenitore Docker esistente.
docker rm <container-id>6. Eseguire il comando standard Docker run sfruttando l'insieme delle credenziali memorizzate.
Prior to LTS12, the environment variables CONNECTORS_HTTPS_PROXY and CONNECTORS_HTTP_PROXY must be replaced with HTTPS_PROXY and HTTP_PROXY, respectively
docker run -d \ --name tulip-connector-host \ -e TULIP_FACTORY='https://<FACTORY>.tulip.co' \ -e TULIP_UUID='<UUID>' \ -e TULIP_MACHINE_SECRET='<SECRET>' \ -e TULIP_DEVICE_TYPE='onprem' \ -e CONNECTORS_HTTP_PROXY='' \ -e CONNECTORS_HTTPS_PROXY='' \ -e EXIT_ON_DISCONNECT=true \ --restart=always \ --net=host \ --mount type=volume,source=tuliplog,target=/log \ bckca2dh98.execute-api.us-east-1.amazonaws.com/public/connector-host:<TAG>
- Confermare che il nuovo contenitore Docker è attivo.
docker ps
Usare gli ambienti del connettore per testare l'aggiornamento
Ogni connettore ha tre ambienti diversi (produzione, pre-produzione e sviluppo) e ognuno di questi ambienti può avere il proprio host del connettore e possono essere di versioni diverse.A seconda dello stato dell'applicazione (versione di sviluppo, in attesa di approvazione, pubblicata) si può usare un ambiente diverso.Il processo previsto per fare la convalida dell'host del connettore dovrebbe essere:1. Aggiornare l'OPCH di sviluppo2. Aggiornare l'host del connettore di convalida (l'ambiente di pre-produzione punta qui a dev) 1. Testare il connettore nella pagina dei connettori. Testare il connettore nella pagina dei connettori o nella modalità di sviluppo dell'applicazione3. Al termine dei test di convalida, aggiornare l'host del connettore di produzione.
Per ulteriori informazioni, vedere Come eseguire una funzione di connettore in più ambienti.
In alternativa, è possibile aggiornare l'OPCH sull'istanza di sviluppo e poi aggiornare con sicurezza l'ambiente di produzione.
Ulteriori riferimenti
Abilitazione delle rotazioni dei registri per Docker
Per gli host On-Premise Connector esistenti che non utilizzano le rotazioni dei registri di Docker, seguite le istruzioni documentate qui per garantire che lo spazio su disco sia mantenuto correttamente.
Avete trovato quello che cercavate?
Potete anche andare su community.tulip.co per porre la vostra domanda o vedere se altri hanno affrontato una questione simile!