Vue d'ensemble des hôtes de connecteurs sur site
  • 22 Oct 2024
  • 6 Minutes à lire
  • Contributeurs

Vue d'ensemble des hôtes de connecteurs sur site


Résumé de l’article

Objectif

Apprendre à tirer parti des hôtes de connecteur sur site pour vos intégrations.

Pré-requis

Pour en savoir plus sur les Connector Hosts dans Tulip, lisez d'abord cet article

Vue d'ensemble

Cet article a pour but de servir de point de référence pour les On-Premise Connector Hosts (OPCH) dans Tulip. Le Connector Host est un service utilisé pour faciliter les connexions de Tulip aux services web externes, aux bases de données et aux serveurs OPC UA. Toutes les instances de Tulip ont un Cloud Connector Host par défaut.

Il y a plusieurs considérations à prendre en compte pour déterminer si un Connector Host sur site est le bon choix d'architecture.

Considérations clés pour un Connector Host sur site

Les considérations pour un Connector Host sur site peuvent être divisées en quelques catégories :

1. Mise en réseau2. Gestion de l'infrastructure3. Performances

Mise en réseau

La raison la plus commune pour déployer un Connecteur sur site est pour les avantages qu'il offre lors de la connexion à des systèmes hébergés au sein d'un réseau local. Avec l'offre sur site, toutes les connexions de Tulip à des systèmes externes commencent à l'intérieur de votre réseau local. Toutes les connexions de votre réseau sont envoyées à Tulip via un WebSocket sécurisé.

Ceci contraste avec les Cloud Connector Hosts, qui requièrent un accès entrant aux services. C'est typiquement une décision informatique d'autoriser les connexions WebSocket sécurisées entrantes depuis le nuage de Tulip vers le service, souvent en utilisant des règles de transfert de port sur le routeur/pare-feu WAN.

Gestion de l'infrastructure

Pour déployer un On-Premise Connector Host, il y a plusieurs composants d'infrastructure dont le client est responsable. Vous trouverez ci-dessous une matrice de base des rôles et des responsabilités :

TulipeClient
Fournir des ressources techniques sur l'OPCHX
Hébergement et déploiement de machines virtuellesX
Surveillance et mise à jour de la machine virtuelleX
Génération d'informations d'identification OPCHX
Déploiement de l'OPCHX
Mise à jour de l'OPCHX
Suivi de l'OPCHX
Dépannage de l'OPCHXX

Le client devrait idéalement être à l'aise avec les technologies qu'il utilise pour déployer le Connector Host, ainsi qu'avec des technologies telles que Docker pour la gestion des conteneurs.

Performance

Tulip recommande d'utiliser également un Connector Host sur site lors de la connexion d'un serveur OPC UA. Bien qu'il soit possible d'utiliser la solution cloud, il peut y avoir une demande importante de bande passante sur le réseau au fur et à mesure que le nombre de tags OPC UA souscrits augmente.

Déploiement d'un hôte de connexion sur site

Normes techniques

Lorsque la décision est prise de déployer une solution sur site, Tulip recommande un itinéraire en libre-service utilisant une image Docker distribuée. La manière la plus simple d'y parvenir serait d'utiliser une machine virtuelle avec une distribution de Linux (Ubuntu est préférable).

Tulip recommande également de n'héberger qu'un seul On-Premise Connector Host par machine virtuelle afin d'éviter un point de défaillance unique pour les sites.

Configuration requise pour la machine virtuelle :

  • RAM - 4 GB
  • ROM - 8-16GB de taille de disque
  • CPU - 2 cœurs
  • Version de Docker - 20.10+

En ce qui concerne les exigences en matière de réseau, l'hôte du connecteur sur site dispose des éléments suivants :

  • Une adresse IP
  • Résolution DNS vers
  • Un accès sortant sur le port 443 vers Tulip (IPs listées ici)
  • Un accès sortant au dépôt Docker ici
  • Accès sortant à tous les systèmes externes pertinents avec des ports

Consultez la liste complète des exigences réseau ici

Demande d'informations d'identification

Contactez le support Tulip(support@tulip.co) pour demander les informations d'identification de l'hôte du connecteur sur site en utilisant le modèle suivant, en remplissant tous les détails entre parenthèses.. :

``Bonjour,

Ceci est une demande de création d'un nouvel hôte du connecteur sur site.

Instance Tulip :
OPCH nom : ---CH````

Tulip créera et partagera les informations d'identification par le biais d'un lien de mot de passe temporaire et sécurisé. Les détails doivent être transférés vers un stockage d'informations d'identification géré en interne et inclure les éléments suivants :

  • Usine
  • UUID
  • Secret de la machine

:::(Info) (NOTE**) Les informations d'identification de l'hôte du connecteur sur site ne doivent pas être utilisées pour créer plus d'un hôte du connecteur - cela entraînerait des problèmes de connectivité pour tous les hôtes partageant les informations d'identification**::: :

Versions disponibles de l'hôte du connecteur sur site (balises)

Tulip utilise les tags d'image Docker pour versionner les images de Connector Host. Vous trouverez ci-dessous une liste des balises On-Premise Connector Host activement supportées qui peuvent être utilisées en conjonction avec les commandes Docker run et pull.

:::(Warning) (ATTENTION) Pour de meilleures performances, la version de votre Instance Tulip et la version de l'Hôte du Connecteur sur site doivent correspondre. L'hôte du connecteur n'est pas garanti d'être compatible avec les versions de l'instance (c'est-à-dire une version de l'hôte du connecteur LTS8 sur une instance LTS7) ::: :

ÉtiquetteVersion LTSVersion bihebdomadaire
lts7LTS7r222 - r232
lts8LTS8r233 - r237
lts9LTS9r238 - r248
lts10LTS10r249 - r261
lts11LTS11r262 - r274
lts12LTS12r275-r287
lts13LTS13r288+

:::(Warning) (Dépréciation de la balise Prod)Historiquement, la balise prod pouvait être utilisée pour indiquer la version la plus récente de l'OPCH. Cette pratique a été abandonnée. Dorénavant, la balise prod pointera vers la version LTS11.3 de l'OPCH :: :

Déploiement

La section suivante explique comment déployer un hôte de connecteur sur site dans divers environnements. AWS et Azure proposent tous deux des services de conteneurs capables d'exécuter l'image Docker.

:::(Warning) (OPCH pré-LTS12)Avant LTS12, les variables d'environnement CONNECTORS_HTTPS_PROXY et CONNECTORS_HTTP_PROXY doivent être remplacées par HTTPS_PROXY et HTTP_PROXY, respectivement:: :

  • Azure :

az container create \N -g <NOM DU GROUPE DE RESSOURCES DANS AZURE> \N --name <NOM DU CONTENEUR> \N --cpu 2 \N --memory 3 \N --restart-policy Always \N --image bckca2dh98.execute-api.us-east-1.amazonaws.com/public/connector-host:<TAG> \N-e TULIP_UUID='<UUID>' \N-TULIP_FACTORY='https://<Votre SITE>.tulip.co' \N-TULIP_MACHINE_SECRET='<SECRET>' \N-TULIP_DEVICE_TYPE='onprem' \N- CONNECTORS_HTTP_PROXY='' \N- CONNECTORS_HTTPS_PROXY=''

  • VM Linux : :::(Warning) (Pre-LTS12 OPCH)Avant LTS12, les variables d'environnement CONNECTORS_HTTPS_PROXY et CONNECTORS_HTTP_PROXY doivent être remplacées par HTTPS_PROXY et HTTP_PROXY, respectivement :: :

docker run -d \N --name tulip-connector-host \N -e TULIP_FACTORY='https://<FACTORY>.tulip.co' \N-e TULIP_UUID='<UUID>' \N-e TULIP_MACHINE_SECRET='<SECRET>' \N-e TULIP_DEVICE_TYPE='onprem' \N-e CONNECTORS_HTTP_PROXY='' \e CONNECTEURS_HTTPS_PROXY='' \e -e CONNECTEURS_HTTPS_PROXY='' \e -e EXIT_ON_DISCONNECT=true \e --restart=always \e --net=host \e --mount type=volume,source=tuliplog,target=/log \e bckca2dh98.execute-api.us-east-1.amazonaws.com/public/connector-host:<TAG>

Mise à jour d'un hôte de connecteur sur site

Tulip publie des mises à jour de l'hôte du connecteur sur site conformément à notre calendrier de mise à jour du support à long terme (LTS). Pour mettre à jour le service, suivez les instructions ci-dessous :

:::(Info) (NOTE**) Le processus de mise à niveau d'un OPCH entraînera un temps d'arrêt pendant que le pod est arrêté et recréé**::: :

  1. Obtenez la dernière version de l'image Docker On-Premise Connector Host.

docker pull bckca2dh98.execute-api.us-east-1.amazonaws.com/public/connector-host:<TAG>2. Exécutez la commande ci-dessous pour obtenir l'ID du conteneur Docker.

docker ps3. Si vous avez accès à TULIP_FACTORY, TULIP_UUID et TULIP_MACHINE_SECRET, passez à l'étape 4. Sinon, exécutez la commande suivante et stockez la sortie de cette commande dans un emplacement sécurisé.

docker exec <container-id> env4. Arrêtez le conteneur Docker existant.

docker stop <container-id> 5. Supprimer le conteneur Docker existant.

docker rm <container-id>6. Exécutez la commande Docker run standard en utilisant l'ensemble des informations d'identification stockées.

:::(Warning) (OPCH pré-LTS12)Avant LTS12, les variables d'environnement CONNECTORS_HTTPS_PROXY et CONNECTORS_HTTP_PROXY doivent être remplacées par HTTPS_PROXY et HTTP_PROXY, respectivement :: : docker run -d \N --name tulip-connector-host \N -e TULIP_FACTORY='https://<FACTORY>.tulip.co' \N-e TULIP_UUID='<UUID>' \N-e TULIP_MACHINE_SECRET='<SECRET>' \N-e TULIP_DEVICE_TYPE='onprem' \N-e CONNECTORS_HTTP_PROXY='' \e CONNECTEURS_HTTPS_PROXY='' \e -e CONNECTEURS_HTTPS_PROXY=''\e -e EXIT_ON_DISCONNECT=true \e --restart=always \e --net=host \e --mount type=volume,source=tuliplog,target=/log \e bckca2dh98.execute-api.us-east-1.amazonaws.com/public/connecteur-hôte:<TAG>7. Confirmez que le nouveau conteneur Docker est actif.

``docker ps````.

Références supplémentaires

Activation des rotations de journaux pour Docker

Pour les On-Premise Connector Hosts existants qui n'utilisent pas les rotations de journaux Docker, suivez les instructions documentées ici pour vous assurer que l'espace disque est correctement maintenu.


Vous avez trouvé ce que vous cherchiez ?

Vous pouvez également vous rendre sur community.tulip.co pour poser votre question ou voir si d'autres personnes ont rencontré une question similaire !


Cet article vous a-t-il été utile ?