Déployez un hôte de connecteur sur site

Découvrez les étapes techniques de déploiement, de configuration et de maintenance des hôtes de connecteurs sur site (OPCH) pour vos intégrations Tulip.

Cet article est un guide de référence technique destiné aux personnes chargées du déploiement physique et de la gestion du cycle de vie des OPCH. L’hôte de connecteur est un service utilisé pour faciliter les connexions depuis

des services Web externes, des bases de données et des serveurs OPC UA. Toutes les instances Tulip disposent par défaut d’un hôte de connecteur cloud.

Plusieurs éléments doivent être pris en compte pour déterminer si un hôte de connecteur sur site constitue la solution architecturale la plus adaptée.

Prérequis

Avant de poursuivre, assurez-vous d’avoir pris connaissance des notions de base relatives aux hôtes de connecteurs Tulip :* Hôtes de connecteurs* Hôtes de connecteurs sur site

Réseau

La raison la plus courante justifiant le déploiement d’un hôte de connecteur sur site réside dans 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 entre Tulip et les systèmes externes s’effectuent à partir de votre réseau local. Toutes les connexions sortantes de votre réseau vers Tulip s’effectuent via un WebSocket sécurisé.

Cela contraste avec les hôtes de connecteurs cloud, qui nécessitent un accès entrant vers les services. Il s’agit généralement d’une décision informatique visant à autoriser les connexions WebSocket sécurisées entrantes depuis le cloud de Tulip vers le service, souvent à l’aide de règles de redirection de ports sur le routeur/pare-feu WAN.

Déployer un hôte de connecteur sur site

Normes techniques

Lorsque la décision est prise de déployer une solution sur site, Tulip recommande une approche en libre-service utilisant une image Docker distribuée. Le moyen le plus simple d’y parvenir consiste à utiliser une machine virtuelle équipée d’une distribution Linux.

Tulip recommande également de n’héberger qu’un seul hôte de connecteur sur site par machine virtuelle afin d’éviter un point de défaillance unique pour les sites.

Configuration requise pour la machine virtuelle :

• Mémoire vive (RAM) : 4 Go
• Espace disque : 8 à 16 Go
• Processeur : 2 cœurs
• Version de Docker : 20.10 ou supérieure

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

• Une adresse IP
• Une résolution DNS vers
• Un accès sortant sur le port 443 vers Tulip (adresses IP répertoriées ici)
• Un accès sortant au référentiel Docker indiqué ici
• Un accès sortant vers tous les systèmes externes concernés via les ports

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

Déploiement

La section suivante décrit 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.

AWS

Utilisez l'interface utilisateur Web et ce guide : https://aws.amazon.com/getting-started/hands-on/deploy-docker-containers/

Azure (Bash) : LTS16+ OPCH

az container create `-g <NOM DU GROUPE DE RESSOURCES DANS AZURE> `--name <NOM DU CONTENEUR> `--cpu 2 `--memory 3 `--restart-policy Always `--public.ecr.aws/tulip/connector-host :<TAG>--os-type Linux `-e TULIP_UUID='<UUID>' `TULIP_FACTORY='https://<VOTRE SITE>.tulip.co' `TULIP_MACHINE_SECRET='<SECRET>' `TULIP_DEVICE_TYPE='onprem' `TULIP_LOGGING_TO_TULIP=true`TULIP_TELEMETRY_TO_TULIP=true`TULIP_CONNECTORS_HTTP_PROXY='' `TULIP_CONNECTORS_HTTPS_PROXY=''

Azure (Bash) : OPCH antérieur à LTS16

az container create `-g <NOM DU GROUPE DE RESSOURCES DANS AZURE> `--name <NOM DU CONTENEUR> `--cpu 2 `--memory 3 `--restart-policy Always `--public.ecr.aws/tulip/connector-host :<TAG> `--os-type Linux `-e TULIP_UUID='<UUID>' `TULIP_FACTORY='https://<VOTRE SITE>.tulip.co' `TULIP_MACHINE_SECRET='<SECRET>' `TULIP_DEVICE_TYPE='onprem' `CONNECTORS_HTTP_PROXY='' `CONNECTORS_HTTPS_PROXY=''

VM Linux : LTS16+ OPCH

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 TULIP_LOGGING_TO_TULIP=true \ -e TULIP_TELEMETRY_TO_TULIP=true \ -e TULIP_CONNECTORS_HTTP_PROXY='' \ -e TULIP_CONNECTORS_HTTPS_PROXY='' \ --restart=always \ --net=host \ public.ecr.aws/tulip/connector-host:<TAG>

VM Linux : OPCH antérieure à LTS16

 --name tulip-connector-host \  
 -e TULIP\_FACTORY='https://.tulip.co' \  
 -e TULIP\_UUID='' \  
 -e TULIP\_MACHINE\_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 \  
 public.ecr.aws/tulip/connector-host :

Windows (PowerShell) : LTS16+ OPCH

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 TULIP_LOGGING_TO_TULIP=true -e TULIP_TELEMETRY_TO_TULIP=true -e TULIP_CONNECTORS_HTTP_PROXY='' -e TULIP_CONNECTORS_HTTPS_PROXY='' --restart=always --net=host public.ecr.aws/tulip/connector-host:<TAG>

Windows (PowerShell) : OPCH antérieur à LTS16

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 HTTP_PROXY='' -e HTTPS_PROXY='' -e EXIT_ON_DISCONNECT=true --restart=always --net=host --mount type=volume,source=tuliplog,target=/log public.ecr.aws/tulip/connector-host:<TAG>

Dépannage des erreurs de certificat

Si OPCH ne parvient pas à démarrer et affiche des erreurs du type « certificat auto-signé dans la chaîne de certificats », la cause principale pourrait être qu’un proxy ou un pare-feu d’entreprise utilisant des certificats personnalisés empêche les connexions sécurisées vers Tulip Cloud.

Symptômes : - OPCH affiche le statut « Never seen » - Le processus s'arrête lors du démarrage - Erreurs de chaîne de certificats SSL dans les journaux

Pour résoudre ce problème, vous pouvez spécifier des autorités de certification supplémentaires à référencer lors du démarrage d’OPCH à l’aide de la variable d’environnement suivante, comme indiqué ci-dessous. Notez que le fichier doit être présent dans le conteneur Docker.

Pour les versions d’OPCH antérieures à LTS16: -e CONNECTORS_EXTRA_TRUSTED_CAS_FROM_FILES='["/etc/tulipCa/ca.pem"]'

Pour OPCH LTS16 et versions ultérieures: -e TULIP_CONNECTORS_EXTRA_TRUSTED_CAS_FROM_FILES='["/etc/tulipCa/ca.pem"]'

Mise à niveau d’un hôte de connecteur sur site

:::(Avertissement) (Votre Edge IO peut également nécessiter une mise à niveau)
OPCH peut fonctionner sur des appareils Edge IO. Si la mise à niveau automatique n’est pas activée sur votre appareil, vous devez effectuer la mise à niveau manuellement.

Si cette bannière d’avertissement s’affiche toujours après avoir effectué toutes les mises à jour de l’OPCH, veuillez vous assurer que votre Edge IO a également été mis à jour.
:::

Tulip publie des mises à jour pour l’On-Premise Connector Host conformément à notre calendrier de publication LTS (support à long terme). Pour mettre à niveau le service, suivez les instructions ci-dessous :

Le processus de mise à niveau d’un OPCH entraînera une interruption de service pendant que le pod est arrêté puis recréé.

1. Procurez-vous la dernière version de l’image Docker de l’hôte du connecteur sur site.

   docker pull public.ecr.aws/tulip/connector-host:<TAG>2. Exécutez la commande ci-dessous pour obtenir l’ID du conteneur Docker.

   docker ps3. Si vous avez accès aux variables TULIP_FACTORY, TULIP_UUID et TULIP_MACHINE_SECRET, passez à l’étape 4. Sinon, exécutez la commande suivante et conservez le résultat de cette commande dans un emplacement sécurisé.

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

   docker stop <id-du-conteneur>5. Supprimez le conteneur Docker existant.

   docker rm <identifiant-du-conteneur>6. Exécutez la commande standard docker run en utilisant les informations d’identification enregistrées.

Pour OPCH LTS 16 et versions ultérieures : 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 TULIP_LOGGING_TO_TULIP=true \ -e TULIP_TELEMETRY_TO_TULIP=true \ -e TULIP_CONNECTORS_HTTP_PROXY='' \ -e TULIP_CONNECTORS_HTTPS_PROXY='' \ --restart=always \ --net=host \ public.ecr.aws/tulip/connector-host :<TAG>Pour les versions d'OPCH antérieures à LTS16 : 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 \ public.ecr.aws/tulip/connector-host:<TAG>

1. Vérifiez que le nouveau conteneur Docker est actif.

   docker ps

Utilisez les environnements des connecteurs pour tester votre mise à niveau

Chaque connecteur dispose de trois environnements différents (production, pré-production et développement) ; chacun de ces environnements peut avoir son propre hôte de connecteur et utiliser des versions différentes. En fonction de l’état de l’application (version de développement, en attente de validation, publiée), un environnement différent peut être utilisé.La procédure recommandée pour valider l’hôte du connecteur est la suivante :1. Mettez à jour votre OPCH de développement2. Mettez à jour l’hôte de votre connecteur de validation (ici, l’environnement de pré-production pointe vers le développement) 1. Testez votre connecteur sur la page des connecteurs ou en mode développement de votre application3. Une fois les tests de validation terminés, mettez à jour l’hôte du connecteur de production

Consultez la section « Environnements de connecteurs » pour plus d’informations.

Vous pouvez également mettre à niveau votre OPCH sur votre instance de développement, puis mettre à niveau l’environnement de production en toute confiance.

Enregistrement dans des outils externes de gestion des journaux

Vous pouvez transférer les journaux de l’hôte du connecteur sur site vers des outils tiers pour une surveillance et un dépannage centralisés. L’OPCH prend en charge Datadog, Grafana Loki et Splunk via des variables d’environnement. Les types de journaux disponibles concernent l’état de santé de votre OPCH (notamment en ce qui concerne sa connexion à Factory), l’exécution des appels de connecteur et les journaux d’abonnement. Dans le cadre du processus de démarrage de l’OPCH, les utilisateurs peuvent configurer l’outil de journalisation externe vers lequel ils souhaitent acheminer les journaux. Si des identifiants pour plusieurs services sont ajoutés, les journaux sont envoyés à tous ces services

1. Choisissez votre destination
2. Datadog: point de terminaison global ; seule une clé API est requise.
3. Grafana Loki: Loki hébergé par le client ; l’URL peut inclure une authentification de base.
4. Splunk (HEC): multi-instances ; nécessite à la fois une URL et un jeton.
5. Ajouter des variables d’environnement : ajoutez les variables ci-dessous à l’environnement de l’hôte du connecteur. N’utilisez que celles correspondant à la destination choisie.

Datadog

• TULIP_LOGGING_DATADOG_API_KEY=<votre_clé_API_Datadog>

Grafana Loki

• TULIP_LOGGING_LOKI_URL=https://<utilisateur>:<mot_de_passe>@loki.votre-domaine.com/loki/api/v1/push
  (L'authentification de base est prise en charge en intégrant « utilisateur:mot_de_passe » dans l'URL — facultatif.)

Splunk (HEC)

• TULIP_LOGGING_SPLUNK_URL=https://splunk.your-domain.com:8088/services/collector
• TULIP_LOGGING_SPLUNK_TOKEN=<votre_jeton_splunk_hec>

1. Redémarrez l’hôte du connecteur

Redémarrez le service pour que les nouvelles variables d’environnement prennent effet.

1. Vérifiez la transmission

Générez de l'activité (par exemple, exécutez une fonction du connecteur) et vérifiez que les logs apparaissent dans votre destination :

• Datadog: vérifiez les journaux récents pour votre nom d’hôte/de service.
• Loki: effectuez une requête par étiquette d'hôte ou par sous-chaîne de message connue dans Grafana Explore.
• Splunk: recherchez les événements récents provenant de votre hôte (par exemple, index=<votre_index> source="tulip-connector-host").
• Modifier ou désactiver la journalisation
• Pour changer de destination, mettez à jour les variables en indiquant le nouveau fournisseur (et supprimez les anciennes).
• Pour désactiver la journalisation, supprimez les variables de journalisation et redémarrez le service.

Informations supplémentaires

Implémentation basée sur les exportateurs Grafana Alloy :

Exportateur Datadog :https://grafana.com/docs/alloy/next/reference/components/otelcol/otelcol.exporter.datadog/

Exportateur Splunk HEC : https://grafana.com/docs/alloy/next/reference/components/otelcol/otelcol.exporter.splunkhec/

Charge des appels entrants et sortants

Cette section explique le nombre de requêtes HTTP que l’OPCH envoie au Tulip Cloud. Ces requêtes peuvent être regroupées en requêtes à débit fixe (toujours actives) et en requêtes à débit variable (en fonction de votre configuration et de votre activité).

Requêtes à débit fixe

Ces requêtes sont émises à un rythme régulier et prévisible :

Fréquence variable des requêtes

Ces requêtes dépendent de votre configuration et de votre activité.
Plus il y a de modifications ou d’événements, plus le taux de requêtes est élevé.

Exemple de calcul

Considérons une configuration comprenant : - 1 source de données machine - 500 attributs de machine, chacun transmettant des données à 1 Hz (une fois par seconde)

Taux de requêtes dans le pire des cas :`Taux (pire cas) = (6 + 1 + 20) + 40 + 60 + 240 = 367 requêtes/minute

Références supplémentaires

Activer la rotation des journaux pour Docker

Pour les installations existantes sur site ( Connector Hosts ) qui n’utilisent pas la rotation des journaux Docker, suivez les instructions décrites ici afin de garantir une gestion adéquate de l’espace disque.

Vérifier l’état de santé de votre OPCH

Pour intégrer l’OPCH à votre orchestrateur de services basé sur Azure ou Kubernetes, vous pouvez utiliser la configuration suivante :

Pour OPCH LTS16+ :

Pour intégrer l’OPCH à votre orchestrateur de services basé sur Azure ou Kubernetes, vous pouvez utiliser la configuration suivante : le point de terminaison de vérification de l’état est attribué de manière aléatoire sur un port et exposé au chemin racine /health-check. Vous pouvez éventuellement remplacer le port attribué en définissant TULIP_HEALTH_HTTP_PORT sur le port spécifié. Par exemple : TULIP_HEALTH_HTTP_PORT = 80. Une réponse réussie renverra un code d’état HTTP 204, indiquant que le service OPCH est en bon état et opérationnel.

Pour les versions d’OPCH antérieures à LTS16 :

Pour intégrer OPCH à votre orchestrateur de services basé sur Azure ou Kubernetes, vous pouvez utiliser la configuration suivante : le point de terminaison de vérification de l'état doit être activé en définissant la variable d'environnement CONNECTORS_HEALTHZ_SERVER_ENABLED sur true.Le point de terminaison est disponible sur le port 9223 et accessible à la racine /. Vous pouvez éventuellement remplacer le port par défaut 9223 en définissant CONNECTORS_PORT sur le port de votre choix. Par exemple : CONNECTORS_PORT = 80

Une réponse réussie renverra un code d'état HTTP 200 (OK), indiquant que le service OPCH est en bon état et opérationnel.
Il est possible de remplacer le port par défaut 9223 en définissant CONNECTORS_PORT sur le port souhaité. Par exemple : CONNECTORS_PORT = 80

Une réponse réussie renverra un code d'état HTTP 200 (OK), indiquant que le service OPCH est en bon état et opérationnel.

{{snippet.Avez-vous trouvé ce que vous cherchiez ?}}