Stellen Sie einen lokalen Connector-Host bereit

Erfahren Sie mehr über die technischen Schritte zur Bereitstellung, Konfiguration und Wartung von On-Premise Connector Hosts (OPCH) für Ihre Tulip-Integrationen.

Dieser Artikel ist ein technisches Nachschlagewerk für Personen, die für die physische Bereitstellung und das Lebenszyklusmanagement des OPCH verantwortlich sind. Der Connector Host ist ein Dienst, der Verbindungen von

externen Webdiensten, Datenbanken und OPC-UA-Servern zu ermöglichen. Alle Tulip-Instanzen verfügen standardmäßig über einen Cloud-Connector-Host.

Bei der Entscheidung, ob ein On-Premise-Connector-Host die richtige architektonische Lösung ist, sind mehrere Aspekte zu berücksichtigen.

Voraussetzungen

Bevor Sie fortfahren, sollten Sie sich mit den Grundlagen der Tulip-Connector-Hosts vertraut machen:* Connector-Hosts* On-Premise-Connector-Hosts

Netzwerk

Der häufigste Grund für die Bereitstellung eines On-Premise-Connector-Hosts sind die Vorteile, die er bei der Verbindung zu Systemen bietet, die innerhalb eines lokalen Netzwerks gehostet werden. Bei der On-Premise-Lösung beginnen alle Verbindungen von Tulip zu externen Systemen innerhalb Ihres lokalen Netzwerks. Alle Verbindungen aus Ihrem Netzwerk erfolgen ausgehend über einen sicheren WebSocket zu Tulip.

Im Gegensatz dazu erfordern Cloud-Connector-Hosts eingehenden Zugriff auf die Dienste. Dies ist in der Regel eine Entscheidung der IT-Abteilung, die sichere eingehende WebSocket-Verbindungen von der Tulip-Cloud zum Dienst zulässt, häufig mithilfe von Portweiterleitungsregeln auf dem WAN-Router bzw. der Firewall.

Einen On-Premise-Connector-Host bereitstellen

Technische Standards

Wenn die Entscheidung für die Bereitstellung einer On-Premise-Lösung getroffen wird, empfiehlt Tulip einen Self-Service-Ansatz unter Verwendung eines verteilten Docker-Images. Der einfachste Weg, dies zu erreichen, wäre die Verwendung einer virtuellen Maschine mit einer Linux-Distribution.

Tulip empfiehlt außerdem, nur einen On-Premise-Connector-Host pro virtueller Maschine zu hosten, um einen Single Point of Failure für Standorte zu vermeiden.

Anforderungen an die virtuelle Maschine:

• RAM – 4 GB
• Festplattenkapazität: 8–16 GB
• CPU – 2 Kerne
• Docker-Version – 20.10+

Was die Netzwerkanforderungen betrifft, verfügt der On-Premise-Connector-Host über Folgendes:

• Eine IP-Adresse
• DNS-Auflösung zu
• Ausgehenden Zugriff über Port 443 auf Tulip (IP-Adressen sind hier aufgeführt)
• Ausgehender Zugriff auf das Docker-Repository hier
• Ausgehender Zugriff auf alle relevanten externen Systeme über die angegebenen Ports

Die vollständige Liste der Netzwerkanforderungen finden Sie hier

Bereitstellung

Im folgenden Abschnitt wird beschrieben, wie ein On-Premise-Connector-Host in verschiedenen Umgebungen bereitgestellt wird. Sowohl AWS als auch Azure bieten Containerdienste an, auf denen das Docker-Image ausgeführt werden kann.

AWS

Verwenden Sie die Web-Benutzeroberfläche und diese Anleitung: https://aws.amazon.com/getting-started/hands-on/deploy-docker-containers/

Azure (Bash): LTS16+ OPCH

az container create `-g <NAME DER RESSOURCENGRUPPE IN AZURE> `--name <NAME FÜR DEN CONTAINER> `--cpu 2 `--memory 3 `--restart-policy Always `--public.ecr.aws/tulip/connector-host:<TAG>--os-type Linux `-e TULIP_UUID='<UUID>' `TULIP_FACTORY='https://<IHRE WEBSITE>.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 vor LTS16

az container create `-g <NAME DER RESSOURCENGRUPPE IN AZURE> `--name <NAME FÜR DEN CONTAINER> `--cpu 2 `--memory 3 `--restart-policy Always `--public.ecr.aws/tulip/connector-host:<TAG> `--os-type Linux `-e TULIP_UUID='<UUID>' `TULIP_FACTORY='https://<IHRE WEBSITE>.tulip.co' `TULIP_MACHINE_SECRET='<GEHEIMNIS>' `TULIP_DEVICE_TYPE='onprem' `CONNECTORS_HTTP_PROXY='' `CONNECTORS_HTTPS_PROXY=''

Linux-VM: 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>

Linux-VM: vor LTS16 OPCH

 --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 vor 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>

Fehlerbehebung bei Zertifikatsfehlern

Wenn OPCH mit Fehlern wie „Selbstsigniertes Zertifikat in der Zertifikatskette“ nicht gestartet werden kann, könnte die Ursache darin liegen, dass ein Unternehmensproxy oder eine Firewall mit benutzerdefinierten Zertifikaten sichere Verbindungen zur Tulip Cloud verhindert.

Symptome: – OPCH zeigt den Status „Never seen“ an – Der Prozess wird beim Start beendet – Fehler in der SSL-Zertifikatskette in den Protokollen

Um dieses Problem zu beheben, können beim Start von OPCH zusätzliche Zertifizierungsstellen über die folgende Umgebungsvariable wie unten beschrieben referenziert werden. Beachten Sie, dass die Datei im Docker-Container vorhanden sein muss.

Für OPCH vor LTS16: -e CONNECTORS_EXTRA_TRUSTED_CAS_FROM_FILES='["/etc/tulipCa/ca.pem"]'

Für OPCH ab LTS16: -e TULIP_CONNECTORS_EXTRA_TRUSTED_CAS_FROM_FILES='["/etc/tulipCa/ca.pem"]'

Aktualisieren eines On-Premise-Connector-Hosts

:::(Warnung) (Möglicherweise muss auch Ihr Edge-IO aktualisiert werden)
OPCH kann auf Geräten von „ Edge IO “ ausgeführt werden. Wenn auf Ihrem Gerät die automatische Aktualisierung nicht aktiviert ist, muss es manuell aktualisiert werden.

Sollte dieser Warnhinweis auch nach Abschluss aller OPCH-Upgrades weiterhin angezeigt werden, stellen Sie bitte sicher, dass Ihr „ Edge IO “ ebenfalls aktualisiert wurde.
:::

Tulip veröffentlicht Updates für den On-Premise Connector Host gemäß unserem Release-Zeitplan für Long-Term-Support (LTS). Befolgen Sie die nachstehenden Anweisungen, um den Dienst zu aktualisieren:

Der Aktualisierungsprozess für einen OPCH führt zu Ausfallzeiten, während der Pod angehalten und neu erstellt wird.

1. Beziehen Sie die neueste Version des Docker-Images für den On-Premise Connector Host.

   docker pull public.ecr.aws/tulip/connector-host:<TAG>2. Führen Sie den folgenden Befehl aus, um die Docker-Container-ID abzurufen.

   docker ps3. Wenn Sie Zugriff auf TULIP_FACTORY, TULIP_UUID und TULIP_MACHINE_SECRET haben, fahren Sie mit Schritt 4 fort. Ist dies nicht der Fall, führen Sie den folgenden Befehl aus und speichern Sie die Ausgabe dieses Befehls an einem sicheren Ort.

   docker exec <container-id> env4. Beenden Sie den bestehenden Docker-Container.

   docker stop <container-id>5. Entfernen Sie den bestehenden Docker-Container.

   docker rm <container-id>6. Führen Sie den Standardbefehl „docker run“ unter Verwendung der gespeicherten Anmeldedaten aus.

Für 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>Für OPCH vor 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. Überprüfen Sie, ob der neue Docker-Container aktiv ist.

   docker ps

Verwenden Sie Connector-Umgebungen, um Ihr Upgrade zu testen

Jeder Connector verfügt über drei verschiedene Umgebungen (Produktion, Vorproduktion und Entwicklung), und jede dieser Umgebungen kann einen eigenen Connector-Host haben, wobei diese Hosts unterschiedliche Versionen aufweisen können. Je nach Status der Anwendung (Entwicklungsversion, zur Freigabe anstehend, veröffentlicht) kann eine andere Umgebung verwendet werden.Der erwartete Ablauf für die Validierung des Connector-Hosts sollte wie folgt sein:1. Führen Sie ein Upgrade Ihres Entwicklungs-OPCH durch.2. Führen Sie ein Upgrade Ihres Validierungs-Connector-Hosts durch (die Vorproduktionsumgebung verweist hier auf „dev“). 1. Testen Sie Ihren Connector auf der Connector-Seite oder im Entwicklungsmodus Ihrer Anwendung.3. Wenn die Validierungstests abgeschlossen sind, führen Sie ein Upgrade des Produktions-Connector-Hosts durch.

Weitere Informationen finden Sie unter „Connector-Umgebungen “.

Alternativ können Sie Ihren OPCH auf Ihrer Entwicklungsinstanz aktualisieren und anschließend die Produktionsumgebung sicher aktualisieren.

Protokollierung in externe Protokollverwaltungstools

Sie können die Protokolle des On-Premise-Connector-Hosts zur zentralen Überwachung und Fehlerbehebung an Tools von Drittanbietern weiterleiten. OPCH unterstützt Datadog, Grafana Loki und Splunk über Umgebungsvariablen. Die verfügbaren Protokolltypen beziehen sich auf den Zustand Ihres OPCH (insbesondere hinsichtlich seiner Verbindung zu Factory), die Ausführung von Connector-Aufrufen sowie Abonnementprotokolle. Im Rahmen des OPCH-Startvorgangs können Benutzer Konfigurationen für externe Protokollierungstools angeben, an die die Protokolle weitergeleitet werden sollen. Wenn Anmeldedaten für mehrere Dienste hinzugefügt werden, werden die Protokolle an alle Dienste gesendet

1. Wählen Sie Ihr Ziel
2. Datadog: Globaler Endpunkt; es ist lediglich ein API-Schlüssel erforderlich.
3. Grafana Loki: Vom Kunden gehostetes Loki; die URL kann eine Basic-Auth-Anmeldung enthalten.
4. Splunk (HEC): Mehrere Instanzen; erfordert sowohl URL als auch Token.
5. Umgebungsvariablen hinzufügen Fügen Sie die folgenden Variablen zur Umgebung des Connector-Hosts hinzu. Verwenden Sie nur diejenigen, die für das von Ihnen gewählte Ziel relevant sind.

Datadog

• TULIP_LOGGING_DATADOG_API_KEY=<Ihr_Datadog-API-Schlüssel>

Grafana Loki

• TULIP_LOGGING_LOKI_URL=https://<Benutzer>:<Passwort>@loki.your-domain.com/loki/api/v1/push
  (Basic-Authentifizierung wird durch Einbettung von „user:password“ in die URL unterstützt – optional.)

Splunk (HEC)

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

1. Starten Sie den Connector-Host neu

Starten Sie den Dienst neu, damit die neuen Umgebungsvariablen wirksam werden.

1. Überprüfen Sie die Übertragung

Lösen Sie eine Aktivität aus (z. B. durch Ausführen einer Connector-Funktion) und vergewissern Sie sich, dass die Protokolle an Ihrem Zielort erscheinen:

• Datadog: Überprüfen Sie die aktuellen Protokolle auf Ihren Host-/Dienstnamen.
• Loki: Führen Sie in Grafana Explore eine Abfrage nach dem Host-Label oder einem bekannten Teilstring der Meldung durch.
• Splunk: Durchsuchen Sie die aktuellen Ereignisse Ihres Hosts (z. B. index=<Ihr_Index> source="tulip-connector-host").
• Protokollierung ändern oder deaktivieren
• Um das Ziel zu wechseln, passen Sie die Variablen an den neuen Anbieter an (und entfernen Sie die alten).
• Um die Protokollierung zu deaktivieren, entfernen Sie die Protokollierungsvariablen und starten Sie den Dienst neu.

Weitere Informationen

Implementierung basierend auf Grafana Alloy-Exportern:

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

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

Last durch eingehende und ausgehende Aufrufe

In diesem Abschnitt wird erläutert, wie viele HTTP-Anfragen der OPCH an die Tulip Cloud sendet. Diese Anfragen lassen sich in Anfragen mit fester Rate (laufen ständig) und Anfragen mit variabler Rate (abhängig von Ihrer Konfiguration und Aktivität) unterteilen.

Anfragen mit fester Rate

Diese Anfragen erfolgen mit einer konstanten, vorhersehbaren Rate:

Anfragen mit variabler Häufigkeit

Diese Anfragen hängen von Ihrer Konfiguration und der Aktivität ab.
Je mehr Änderungen oder Ereignisse stattfinden, desto höher ist die Anfragerate.

Beispielberechnung

Betrachten wir eine Konfiguration mit:- 1 Maschinendatenquelle- 500 Maschinenattribute, die jeweils Daten mit einer Frequenz von 1 Hz (einmal pro Sekunde) melden

Anfragefrequenz im ungünstigsten Fall:`Frequenz (ungünstigster Fall) = (6 + 1 + 20) + 40 + 60 + 240 = 367 Anfragen/Minute

Weitere Hinweise

Log-Rotation für Docker aktivieren

Für bestehende On-Premise- Connector Hosts, die keine Docker-Protokollrotation verwenden, befolgen Sie die hier dokumentierten Anweisungen, um sicherzustellen, dass der Speicherplatz ordnungsgemäß verwaltet wird.

Überprüfen Sie den Zustand Ihres OPCH

Um den OPCH in Ihren Azure- oder Kubernetes-basierten Service-Orchestrator zu integrieren, können Sie die folgende Konfiguration verwenden:

Für OPCH ab LTS16:

Um den OPCH in Ihren Azure- oder Kubernetes-basierten Service-Orchestrator zu integrieren, können Sie die folgende Konfiguration verwenden: Der Endpunkt für den Zustandscheck wird zufällig einem Port zugewiesen und unter dem Stammpfad /health-check verfügbar gemacht. Optional kann der zugewiesene Port überschrieben werden, indem TULIP_HEALTH_HTTP_PORT auf den angegebenen Port gesetzt wird. Beispiel: TULIP_HEALTH_HTTP_PORT = 80. Eine erfolgreiche Antwort gibt den HTTP-Statuscode 204 zurück, was anzeigt, dass der OPCH-Dienst fehlerfrei und betriebsbereit ist.

Für OPCH vor LTS16:

Um den OPCH in Ihren Azure- oder Kubernetes-basierten Service-Orchestrator zu integrieren, können Sie die folgende Konfiguration verwenden: Der Endpunkt für den Health Check muss durch Setzen der Umgebungsvariable CONNECTORS_HEALTHZ_SERVER_ENABLED auf „true“ aktiviert werden.Der Endpunkt ist auf Port 9223 verfügbar und unter dem Stammpfad „/“ erreichbar. Optional kann der Standardport 9223 überschrieben werden, indem „CONNECTORS_PORT“ auf den gewünschten Port gesetzt wird. Beispiel: CONNECTORS_PORT = 80

Eine erfolgreiche Antwort gibt den HTTP-Statuscode 200 (OK) zurück, was anzeigt, dass der OPCH-Dienst fehlerfrei und betriebsbereit ist.
Optional kann der Standardport 9223 überschrieben werden, indem CONNECTORS_PORT auf den gewünschten Port gesetzt wird. Beispiel: CONNECTORS_PORT = 80

Eine erfolgreiche Antwort gibt den HTTP-Statuscode 200 (OK) zurück, was bedeutet, dass der OPCH-Dienst fehlerfrei und betriebsbereit ist.

{{snippet.Haben Sie gefunden, wonach Sie gesucht haben?}}