--- title: "Stellen Sie einen lokalen Connector-Host bereit" slug: "deploy-an-on-premise-connector-host" status: "new" updated: 2026-10-22T14:48:31Z published: 2026-10-22T14:48:31Z canonical: "support.tulip.co/deploy-an-on-premise-connector-host" --- > ## Documentation Index > Fetch the complete documentation index at: https://support.tulip.co/llms.txt > Use this file to discover all available pages before exploring further. # 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*](https://support.tulip.co/docs/introduction-to-tulip-connector-hosts) [On-Premise-Connector-Hosts](/r230/docs/overview-of-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](https://support.tulip.co/docs/networking-requirements-for-a-tulip-cloud-deployment) zum Dienst zulässt, häufig mithilfe von Portweiterleitungsregeln auf dem WAN-Router bzw. der Firewall. ## Einen On-Premise-Connector-Host bereitstellen Update to Support and Troubleshooting Starting with LTS16+, OPCH includes two environment variables to help with troubleshooting and support: TULIP_LOGGING_TO_TULIP (logging) and TULIP_TELEMETRY_TO_TULIP (metric reporting). To explicitly opt out, you can comment out the above environment variables. ### Technische Standards OPCH performance 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. 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](https://www.docker.com/resources/what-container). 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](https://support.tulip.co/docs/networking-requirements-for-a-tulip-cloud-deployment) aufgeführt) - Ausgehender Zugriff auf das Docker-Repository [hier](http://bckca2dh98.execute-api.us-east-1.amazonaws.com/) - Ausgehender Zugriff auf alle relevanten externen Systeme über die angegebenen Ports Die vollständige Liste der Netzwerkanforderungen finden Sie [hier](https://support.tulip.co/docs/networking-requirements-for-a-tulip-cloud-deployment) ### 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/](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 Version compatibility OPCH must be kept up-to-date with the Tulip product. Learn more about [connector](/r230/docs/on-prem-OPCH version support. Recommended upgrade procedure for OPCH Tulip recommends proactively confirming the upgrade by successfully running a test OPCH connection to the development environment and/or development instance. Once this verification is complete, the production environment can be confidently upgraded. Details on how can be found below. :::(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](/r230/docs/how-to-run-a-connector-function-in-multiple-environments) “. Alternativ können Sie Ihren OPCH auf Ihrer Entwicklungsinstanz aktualisieren und anschließend die Produktionsumgebung sicher aktualisieren. ## Protokollierung in externe Protokollverwaltungstools Availability This capability is available for LTS15+ OPCH. 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/](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/](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: | **Typ** | **Rate** | **Beschreibung** | | --- | --- | --- | | **Heartbeat** | 6 Anfragen/Minute | Bestätigt, dass das OPCH online und verbunden ist. | | **Abfrage der Datenquelle** | 20 Anfragen/Minute | Regelmäßige | | nach Aktualisierungen der konfigurierten Datenquellen. | | | ### 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. | **Typ** | **Typische Rate** | | --- | --- | | **Änderungen des Online-Status der Maschinendatenquelle** | 1 Anfrage pro Änderung (bis zu 60 Anfragen/Minute) | | **Connector-Aufrufe** | 1 ausgehende Anfrage pro HTTP-Connector-Aufruf | ### 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` Note The configurations and online statuses typically change rarely. Also, the OPCH optimizes the number of HTTP requests to the Tulip cloud by batching multiple requests together when needed. As a result, the average rate for the above setup will likely be around `200-270 requests/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](https://support.tulip.co/docs/enabling-log-rotations-for-existing-on-premise-connector-host-container) 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?}}