Bereitstellen des Relay-Clients als Container

Stellen Sie den UiPath Relay-Client als Container-Image mithilfe von Podman, Docker oder Kubernetes bereit, um sichere ausgehende Tunnels in containerisierten Umgebungen einzurichten.

Führen Sie den Relay-Client als Container-Image aus, um sichere ausgehende Tunnel zu Test Cloud aus containerisierten Umgebungen aufzubauen. Bevor Sie beginnen, konfigurieren Sie eine Relay-Gruppe und halten Sie den Client-Konfigurationsstring aus der Relay-UI bereit.

Voraussetzungen

• Container-Runtime: Podman, Docker oder ein Kubernetes-Cluster.
• Container-Image des Relay-Clients: registry.uipath.com/relay-client:<tag>. Ersetzen Sie <tag> durch eine Relay-Version von der Downloadseite des UiPath Customer Portal . Die mindestens unterstützte Version ist 26.4.1 oder 26.4.3 für TCP-basierte Verbindungen wie SAP BAPI.
• Eine base64-codierte Konfigurationsdatei, die von der Relay-Benutzeroberfläche generiert wurde.
• Lizenzannahmevereinbarung: Legen Sie LICENSE_AGREEMENT=accept als Umgebungsvariable fest, oder fügen Sie --accept-license-agreement an den Startbefehl an.
• (Optional) Ein benutzerdefiniertes Zertifizierungsstellenzertifikat, wenn Ihre Organisation Enterprise-PKI verwendet.

Hardwareanforderungen und versionsspezifische Netzwerkvoraussetzungen finden Sie unter Bereitstellen des Relay-Clients.

Wichtig:

Für unterstützte TCP-basierte Verbindungen, wie SAP BAPI, stellen Sie den Relay-Client zusammen mit einem zweiten Container, dem lokalen Executor, bereit. Wenn Sie eine benötigen, überspringen Sie Schritt 3 und folgen Sie stattdessen SAP BAPI und anderen TCP-basierten Verbindungen . Dieser Abschnitt behandelt Docker und Podman.

Schritt 1: Abrufen der Konfiguration

1. Öffnen Sie das Dashboard Relay-UI.
2. Erstellen oder kopieren Sie Ihre Relay-Konfiguration.
3. Erstellen Sie auf dem Host ein Verzeichnis für die Konfigurationsdatei. Jedes Verzeichnis funktioniert; Diese Seite verwendet /opt/uipath/relay/config als Beispiel. Verwenden Sie unter Windows einen Windows-Pfad wie beispielsweise C:\uipath\relay\config.
4. Speichern Sie die base64-codierte Konfigurationszeichenfolge von der Benutzeroberfläche als relay.config.b64enc. Die Bereitstellungsbefehle stellen dieses Verzeichnis als /relay-config in den Container bereit; ersetzen Sie den Beispielpfad durch Ihren.

Schritt 2: Konfigurieren der Umgebungsvariablen

Übergeben Sie diese Variablen als -e Flags mit Podman oder Docker oder als env: -Einträge im Kubernetes-Manifest in Schritt 3.

Benutzerdefiniertes Zertifizierungsstellenzertifikat

Wenn Ihre Organisation eine Unternehmens- oder selbstsignierte Zertifizierungsstelle verwendet, legen Sie die folgenden Variablen zusammen, bevor Sie den Container starten:

Variable	Zweck	Erforderlich
RELAY_CUSTOM_CA_PATH	Pfad zum benutzerdefinierten Zertifikat der Zertifizierungsstelle	Ja, wenn Sie eine benutzerdefinierte Zertifizierungsstelle verwenden
RELAY_CA_BUNDLE_PATH	Pfad, in den das zusammengeführte Zertifizierungsstellenpaket geschrieben wird	Ja, wenn Sie eine benutzerdefinierte Zertifizierungsstelle verwenden

Der Relay-Client führt die benutzerdefinierte Zertifizierungsstelle mit dem Systemzertifikatpaket zusammen, bevor er TLS-Verbindungen herstellt.

Proxy

So leiten Sie ausgehenden Datenverkehr über einen Proxy weiter:

Variable	Zweck	Erforderlich
HTTP_PROXY und HTTPS_PROXY	Proxy-URL	Nein
NO_PROXY	Durch Kommas getrennte Hostnamen, Domänen oder IP-Adressen, die den Proxy umgehen	Nein

Schritt 3: Bereitstellen

Ersetzen Sie <RELAY_ID> durch die tatsächliche ID aus der Relay-Benutzeroberfläche. Für hohe Verfügbarkeit mit Docker oder Podman führen Sie zwei Container auf separaten Knoten mit unterschiedlichen Namen aus, z. B. relay1-<RELAY_ID> auf Host1 und relay2-<RELAY_ID> auf Host2. Verwenden Sie in Kubernetes zwei Replikate mit Pod- Anti-Affinität, wie im Manifest unten. Ein erfolgreicher Start protokolliert All prerequisite checks passed.

Die folgenden Podman- und Docker-Befehle werden im Vordergrund mit -it --rm ausgeführt, sodass Sie den ersten Start beobachten können und der Container wird entfernt, wenn Sie ihn anhalten. Ersetzen Sie für eine Bereitstellung mit langer Ausführungszeit -it --rm durch -d.

Podman

Schnellstart:

podman run -it --name relay1-<RELAY_ID> --hostname relay1-<RELAY_ID> --rm \
  --read-only --read-only-tmpfs \
  -v /opt/uipath/relay/config:/relay-config:ro,z \
  registry.uipath.com/relay-client:<tag> \
  start --config-file /relay-config/relay.config.b64enc --accept-license-agreement

Mit einem benutzerdefinierten Zertifizierungsstellenzertifikat:

podman run -it --name relay1-<RELAY_ID> --hostname relay1-<RELAY_ID> --rm \
  --read-only --read-only-tmpfs \
  -v /opt/uipath/relay/config:/relay-config:ro,z \
  -v /tls/custom-ca.crt:/custom-ca.crt:z \
  -v /tmp/writable:/writable:z \
  -e RELAY_CUSTOM_CA_PATH=/custom-ca.crt \
  -e RELAY_CA_BUNDLE_PATH=/writable/merged-ca.crt \
  registry.uipath.com/relay-client:<tag> \
  start --config-file /relay-config/relay.config.b64enc --accept-license-agreement

Docker

Schnellstart:

docker run -it --name relay1-<RELAY_ID> --hostname relay1-<RELAY_ID> --rm \
  --read-only --tmpfs /tmp \
  -v /opt/uipath/relay/config:/relay-config:ro \
  registry.uipath.com/relay-client:<tag> \
  start --config-file /relay-config/relay.config.b64enc --accept-license-agreement

Mit einem benutzerdefinierten Zertifizierungsstellenzertifikat:

docker run -it --name relay1-<RELAY_ID> --hostname relay1-<RELAY_ID> --rm \
  --read-only --tmpfs /tmp \
  -v /opt/uipath/relay/config:/relay-config:ro \
  -v /tls/custom-ca.crt:/custom-ca.crt:ro \
  -v /tmp/writable:/writable \
  -e RELAY_CUSTOM_CA_PATH=/custom-ca.crt \
  -e RELAY_CA_BUNDLE_PATH=/writable/merged-ca.crt \
  registry.uipath.com/relay-client:<tag> \
  start --config-file /relay-config/relay.config.b64enc --accept-license-agreement

Kubernetes

Geheimnisse erstellen:

# Configuration secret
kubectl create secret generic relay-config \
  --from-file=relay.conf=/opt/uipath/relay/config/relay.config.b64enc

# Custom CA certificate secret (optional)
kubectl create secret generic custom-ca \
  --from-file=custom-ca.crt=./custom-ca.crt

# Headless service for the StatefulSet
kubectl create service clusterip relay-client-<RELAY_ID> --clusterip="None"

Stellen Sie ein StatefulSet bereit:

Verwenden Sie einen StatefulSet, wenn Hostnamenbeschränkungen erzwungen werden. StatefulSets bieten stabile, vorhersehbare Hostnamen (relay-client-<RELAY_ID>-0, relay-client-<RELAY_ID>-1 usw.), die der Relay-Dienst zur Identifizierung und Validierung von Clients verwendet.

Das Manifest stellt das custom-ca -Geheimnis bereit und legt die beiden RELAY_* -Variablen fest. Wenn Sie keine benutzerdefinierte Zertifizierungsstelle verwenden, entfernen Sie diese beiden Variablen, die Volume-Bereitstellung custom-ca und das Volume custom-ca. Der Bereitschaftstest verwendet den Integritätsendpunkt, der den Relay-Client 26.4.2 oder höher erfordert.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: relay-client-<RELAY_ID>
spec:
  serviceName: relay-client-<RELAY_ID>
  replicas: 2
  selector:
    matchLabels:
      app: relay-client-<RELAY_ID>
  template:
    metadata:
      labels:
        app: relay-client-<RELAY_ID>
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - relay-client-<RELAY_ID>
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: relay
        image: registry.uipath.com/relay-client:<tag>
        args:
        - start
        - --config-file=/config/relay.conf
        - --accept-license-agreement
        - --log-level=info
        - --heartbeat-interval=30
        env:
        - name: RELAY_CUSTOM_CA_PATH
          value: "/tls/custom-ca.crt"
        - name: RELAY_CA_BUNDLE_PATH
          value: "/writable/merged-ca.crt"
        imagePullPolicy: IfNotPresent
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
          privileged: false
          readOnlyRootFilesystem: true
          runAsGroup: 1001
          runAsNonRoot: true
          runAsUser: 1001
        readinessProbe:
          httpGet:
            path: /healthz
            port: 9090
          initialDelaySeconds: 5
          timeoutSeconds: 1
          periodSeconds: 3
          successThreshold: 1
          failureThreshold: 2
        resources:
          requests:
            cpu: 50m
            memory: 100Mi
        volumeMounts:
        - name: relay-config
          mountPath: /config/relay.conf
          subPath: relay.conf
          readOnly: true
        - mountPath: /writable
          name: writable
        - name: custom-ca
          mountPath: /tls/custom-ca.crt
          subPath: custom-ca.crt
          readOnly: true
      volumes:
      - name: relay-config
        secret:
          secretName: relay-config
      - name: writable
        emptyDir: {}
      - name: custom-ca
        secret:
          secretName: custom-ca
      restartPolicy: Always
      terminationGracePeriodSeconds: 30

Überprüfen Sie die Bereitstellung:

kubectl get statefulset relay-client-<RELAY_ID>

Startbefehlsoptionen

Diese gelten für jede Runtime.

Option	Beschreibung	Beispiel
--config	Inline-Base64-Konfigurationszeichenfolge	--config "base64string..."
--config-file	Pfad zur Konfigurationsdatei	--config-file /relay-config/relay.config.b64enc
--log-level	Ausführliche Protokollierung: trace, debug, info, warn oder error	--log-level debug
--heartbeat-interval	Heartbeat-Intervall in Sekunden (Minimum: 10)	--heartbeat-interval 10
--reconnect-interval	Verbindungsintervall in Sekunden (Minimum: 1800)	--reconnect-interval 1800
--health-addr	Bindeadresse für den Endpunkt /healthz . Standardmäßig auf 0.0.0.0:9090; Verwenden Sie einen leeren Wert, um ihn zu deaktivieren	--health-addr=0.0.0.0:9090
--enable-onprem-executor	Stellt eine Verbindung mit dem lokalen Executor-Container auf dem Standardport 18080 her. Siehe SAP BAPI und andere TCP-basierte Verbindungen	--enable-onprem-executor
--onprem-executor-listen-port	Stellt eine Verbindung mit dem lokalen Executor-Container auf diesem Port her, der mit dem SERVER_PORT des Containers übereinstimmen muss. Beide Flags aktivieren den Executor	--onprem-executor-listen-port 18080

SAP BAPI und andere TCP-basierte Verbindungen

Wichtig:

Erfordert den Relay-Client 26.4.3 oder höher. Dieser Abschnitt behandelt Docker und Podman.

Für unterstützte TCP-basierte Verbindungen wie SAP BAPI führen Sie zwei Container auf demselben Host aus:

• Relay-Client-Container: Öffnet die sichere ausgehende Verbindung zu UiPath.
• Lokaler Executor-Container: Stellt eine Verbindung mit Ihrem lokalen System her und verarbeitet die TCP-basierte Verbindung.

Der Executor-Container gibt das Netzwerk des Relay-Clients frei, sodass der Relay-Client den Executor auf localhost erreicht.

Voraussetzungen

• Image des lokalen Executor-Containers: registry.uipath.com/relay-onprem-executor:<tag>. Verwenden Sie dieselbe <tag> wie Ihr Relay-Client-Image. Die mindestens unterstützte Version ist 26.4.3.
• Die SAP JCo 3-Bibliotheken sapjco3.jar, sapidoc3.jar und libsapjco3.so. Laden Sie sie aus dem SAP Support Portal herunter, für das ein SAP-Konto erforderlich ist; UiPath liefert sie nicht.
  • sapjco3.jar und libsapjco3.so befinden sich im SAP Java Connector 3.1- Paket für Linux auf x86_64. Das Executor-Image ist linux/amd64, sodass ein Paket für eine andere Plattform nicht geladen wird.
  • sapidoc3.jar befindet sich im separaten Paket SAP Java IDoc Class Library 3.1 .
• Der Relay-Host kann den Hostnamen und Port des SAP-Systems auflösen und erreichen.

Bereitstellen der JCo-Bibliotheken

Die Bibliotheken können sich in jedem Verzeichnis auf dem Host befinden. Auf dieser Seite wird /opt/uipath/relay/executor-deps als Beispiel verwendet; Wichtig ist, dass der Bereitstellungsbefehl Ihr Verzeichnis unter /opt/uipath/onprem-runtime/dep-libs innerhalb des Executor-Containers bereitstellt. Die Befehle verwenden sudo, da /opt ein Stammverzeichnis unter Linux erfordert; lassen Sie es für ein Verzeichnis weg, das Sie besitzen.

1. Erstellen Sie das Verzeichnis:

   sudo mkdir -p /opt/uipath/relay/executor-deps
   

2. Kopieren Sie die drei Dateien hinein. Platzieren Sie sie direkt im Verzeichnis, nicht in Unterverzeichnissen:

   sudo cp sapjco3.jar sapidoc3.jar libsapjco3.so /opt/uipath/relay/executor-deps/
   

3. Bestätigen Sie, dass die native Bibliothek für x86-64 erstellt wurde:

   file /opt/uipath/relay/executor-deps/libsapjco3.so
   # Expect: ELF 64-bit LSB shared object, x86-64
   

   Wenn die Ausgabe ARM aarch64 oder eine andere Architektur anzeigt, laden Sie stattdessen das Paket für Linux unter x86_64 herunter. Überprüfen Sie unter Windows, in dem file nicht verfügbar ist, das Paket, aus dem Sie extrahiert haben: Das richtige heißt sapjco3-linuxx86_64-<version>.

Stellen Sie beide Container bereit

Führen Sie die Befehle in dieser Reihenfolge aus: zuerst der Relay-Client, dann der Executor. Der Executor tritt dem Netzwerk des Relay-Clients bei, sodass der Relay-Client ausgeführt werden muss, wenn der Executor gestartet wird.

Warnung:

Wenn Sie den Relay-Client neu starten oder neu erstellen, verliert der Executor sein Netzwerk und kann sich nicht von selbst erholen. Starten Sie den Executor anschließend neu, wie unter Neustart und Upgrade beschrieben.

Bevor Sie die Befehle ausführen:

• Ersetzen Sie /opt/uipath/relay/config und /opt/uipath/relay/executor-deps durch die Hostverzeichnisse, die Sie in Schritt 1 ausgewählt haben, und stellen Sie die JCo-Bibliotheken bereit. Behalten Sie die containerseitigen Pfade wie gezeigt bei.
• Wenn Sie bereits einen Relay-Client aus Schritt 3 gestartet haben, halten Sie ihn an und entfernen Sie ihn. Die Argumente eines ausgeführten Containers können nicht geändert werden.
• Wenn Sie eine benutzerdefinierte Zertifizierungsstelle oder einen Proxy verwenden, fügen Sie die Variablen aus Schritt 2 und für eine benutzerdefinierte Zertifizierungsstelle die beiden Volume-Bereitstellungen aus Schritt 3 zum Relay-Client-Befehl hinzu. Der Relay-Client ist der Container, der eine Verbindung mit UiPath herstellt.
• Veröffentlichen Sie den Executor-Port nicht mit -p. Nur der Relay-Client muss es erreichen.

Aktivieren Sie den Executor auf dem Relay-Client mit einem der beiden Flags:

Markieren	Auswirkung
--enable-onprem-executor	Verbindet den Executor am Standardport 18080
--onprem-executor-listen-port <port>	Stellt eine Verbindung mit dem Executor auf <port> her. Muss mit SERVER_PORTdes Executor-Containers übereinstimmen

Die anderen Executor-Flags --onprem-executor-java-home und --onprem-executor-dep-dir haben keine Auswirkungen in einem Container: Das Executor-Image enthält seine eigene Java-Runtime und liest seine Bibliotheken von /opt/uipath/onprem-runtime/dep-libs.

Podman

# 1. Relay client. It owns the network namespace that the executor joins.
podman run -d --name relay1-<RELAY_ID> --hostname relay1-<RELAY_ID> \
  --read-only --read-only-tmpfs \
  -v /opt/uipath/relay/config:/relay-config:ro,z \
  registry.uipath.com/relay-client:<tag> \
  start --config-file /relay-config/relay.config.b64enc \
  --accept-license-agreement \
  --onprem-executor-listen-port 18080

# 2. On-prem executor. SERVER_ADDRESS=127.0.0.1 restricts it to loopback,
#    which is where the Relay client reaches it. Without it, the executor
#    image listens on all interfaces of the shared namespace.
podman run -d --name relay-executor-<RELAY_ID> \
  --network container:relay1-<RELAY_ID> \
  -e SERVER_ADDRESS=127.0.0.1 \
  -e SERVER_PORT=18080 \
  -v /opt/uipath/relay/executor-deps:/opt/uipath/onprem-runtime/dep-libs:ro,z \
  registry.uipath.com/relay-onprem-executor:<tag>

Alternativ können Sie einen Podman-Pod erstellen und beide Container darin mit --pod ausführen. Der Infra-Container des Pods besitzt den Netzwerk-Namespace, sodass jeder Container eigenständig neu gestartet werden kann.

Docker

# 1. Relay client. It owns the network namespace that the executor joins.
docker run -d --name relay1-<RELAY_ID> --hostname relay1-<RELAY_ID> \
  --read-only --tmpfs /tmp \
  -v /opt/uipath/relay/config:/relay-config:ro \
  registry.uipath.com/relay-client:<tag> \
  start --config-file /relay-config/relay.config.b64enc \
  --accept-license-agreement \
  --onprem-executor-listen-port 18080

# 2. On-prem executor. SERVER_ADDRESS=127.0.0.1 restricts it to loopback,
#    which is where the Relay client reaches it. Without it, the executor
#    image listens on all interfaces of the shared namespace.
docker run -d --name relay-executor-<RELAY_ID> \
  --network container:relay1-<RELAY_ID> \
  -e SERVER_ADDRESS=127.0.0.1 \
  -e SERVER_PORT=18080 \
  -v /opt/uipath/relay/executor-deps:/opt/uipath/onprem-runtime/dep-libs:ro \
  registry.uipath.com/relay-onprem-executor:<tag>

Überprüfen

Lesen Sie die Protokolle mit den Befehlen für Ihre Runtime:

Laufzeit	Relay-Clientprotokolle	Executor-Protokolle
Podman	podman logs relay1-<RELAY_ID>	podman logs relay-executor-<RELAY_ID>
Docker	docker logs relay1-<RELAY_ID>	docker logs relay-executor-<RELAY_ID>

1. Bestätigen Sie in den Relay-Client-Protokollen die Voraussetzungszeile On-prem executor checks: OK.
2. Suchen Sie in denselben Protokollen den Executor-Endpunkt mit dem Namen relay1-<RELAY_ID>-system-onprem-executor-<id> und bestätigen Sie, dass er health check success erreicht.
3. Bestätigen Sie in den Executor-Protokollen Started OnPremRuntimeApplication.
4. Führen Sie einen Testaufruf von dem Connector aus, der diesen Endpunkt verwendet, um zu bestätigen, dass der vollständige Pfad funktioniert.

Hinweis:

Während der Executor-Container noch gestartet wird, kann Schritt 2 zuerst ein health check failed: dial tcp [::1]:18080: connect: connection refused anzeigen. Dies wird erwartet und wird bei der nächsten Prüfung etwa 10 Sekunden später gelöscht, ohne den Relay-Client neu zu starten.

Probleme finden Sie zuerst unter Fehlerbehebung auf dieser Seite, dann Probleme mit dem lokalen Executor.

Neustart und Upgrade

Sie können den Executor selbst neu starten oder aktualisieren. Wenn Sie den Relay-Client neu starten oder neu erstellen, müssen Sie anschließend auch den Executor neu starten oder neu erstellen: Der Executor wird innerhalb des Netzwerks des Relay-Clients ausgeführt, und der Neustart oder die Neuerstellung des Relay-Clients ersetzt dieses Netzwerk, sodass sich der vorhandene Executor-Container nicht von selbst wiederherstellen kann. Verwenden Sie dieselbe <tag> für beide Images, wenn Sie ein Upgrade durchführen. Ersetzen Sie bei Podman docker durch podman.

Aufgabe	Was zu tun ist
Starten Sie den Executor neu	docker restart relay-executor-<RELAY_ID>. Der Relay-Client wird weiter ausgeführt
Upgraden Sie den Executor	docker rm -f relay-executor-<RELAY_ID>und führen Sie dann den Executor-Befehl mit dem neuen erneut aus <tag>
Starten Sie den Relay-Client neu	docker restart relay1-<RELAY_ID>, dann docker restart relay-executor-<RELAY_ID>
Upgraden Sie den Relay-Client	Entfernen Sie beide Container und führen Sie dann beide Befehle erneut mit dem neuen <tag>, Relay-Client zuerst, aus. Ein neu erstellter Relay-Client ist ein neuer Container, daher muss auch der Executor neu erstellt werden

Betrieb

Configuration details

Die Konfigurationsdatei muss den base64-codierten JSON-String enthalten, der von der Relay-Benutzeroberfläche generiert wurde. Beim Start liest der Relay-Client die Konfiguration, decodiert sie, validiert sie und stellt eine Verbindung mit dem angegebenen Relay-Dienst-Endpunkt her.

• Erste Ausführung: Die Konfiguration wird verschlüsselt im Datenverzeichnis gespeichert.
• Nachfolgende Ausführungen: Die verschlüsselte Konfiguration wird automatisch entschlüsselt und verwendet.
• Änderungen an der Konfigurationsdatei: Erfordern einen Neustart des Containers, um wirksam zu werden.

Heartbeat-Intervall

Der Heartbeat hält inaktive TCP-Verbindungen aktiv. Verringern Sie das Intervall, wenn Ihre Firewall, Ihr Proxy oder Ihre Netzwerkadressenübersetzung (NAT) inaktive Verbindungen vor 30 Sekunden auslöst:

--heartbeat-interval=30    # Default
--heartbeat-interval=10    # For aggressive firewall or NAT environments

Intervall für die erneute Verbindung

Proaktive erneute Verbindung stellt die Verbindung nach einem festen Zeitplan wieder her. Verwenden Sie dies in Umgebungen, in denen ein Proxy oder Lastausgleich einen Timeout bei Inaktivität der Verbindung hat:

--reconnect-interval=0     # Disabled (default)
--reconnect-interval=1800  # Reconnect every 30 minutes (minimum)

Integritätsendpunkt

Hinweis:

Die Option --health-addr ist mit dem Relay-Client 26.4.2 und höher verfügbar.

Das Container-Image aktiviert standardmäßig einen /healthz -HTTP-Endpunkt auf 0.0.0.0:9090. Verwenden Sie --health-addr=<address> um die Bindungsadresse zu ändern, oder --health-addr= um den Endpunkt zu deaktivieren. Der Kubernetes-Bereitschaftstest im Beispielmanifest verwendet diesen Endpunkt.

Zugreifen auf Protokolle

# Podman
podman logs -f relay1-<RELAY_ID>

# Docker
docker logs -f relay1-<RELAY_ID>

# Kubernetes (current run)
kubectl logs -f relay-client-<RELAY_ID>-0

# Kubernetes (previous run, if the container restarted)
kubectl logs relay-client-<RELAY_ID>-0 --previous

Die Aufbewahrung von Containerprotokollen wird durch Ihre Container-Laufzeit- oder Kubernetes-Cluster-Protokollierungsrichtlinie gesteuert, nicht durch den Relay-Client.

Sicherheit

Wenden Sie die folgenden Sicherheitseinstellungen in Ihrem Containermanifest an:

• readOnlyRootFilesystem: true: Verhindert die Änderung des Container-Dateisystems.
• runAsNonRoot: true: Führt den Prozess als Nicht-Stammbenutzer aus.
• allowPrivilegeEscalation: false: Verhindert die Berechtigungseskalation.
• capabilities.drop: [ALL]: Verwirft alle Linux-Funktionen.
• privileged: false: Deaktiviert den privilegierten Modus.

Speichern Sie die Relay-Konfiguration in Kubernetes-Geheimnissen und verwenden Sie die rollenbasierte Zugriffskontrolle (RBAC), um den geheimen Zugriff einzuschränken. Betten Sie die Base64-Konfiguration nicht in das Container-Image ein und übergeben Sie sie nicht als einfache Umgebungsvariable.

Fehlersuche und ‑behebung

Symptome	Ursache	Resolution
license agreement not accepted beim Start	Lizenz-Flag oder -Variable nicht festgelegt	Fügen Sie --accept-license-agreement zum Startbefehl hinzu, oder legen Sie LICENSE_AGREEMENT=acceptfest.
Konfigurationsdatei nicht gefunden	Falscher Volume-Bereitstellungspfad oder geheimes Geheimnis	Führen Sie kubectl describe secret relay-config und kubectl describe pod <pod-name> aus, um Bereitstellungen zu überprüfen
Verbindung mit dem Relay-Dienst nicht möglich	Netzwerk- oder Firewallproblem	Überprüfen Sie die Pod-Protokolle mit kubectl logs <pod-name> und stellen Sie sicher, dass die erforderlichen ausgehenden Ziele unter Bereitstellen des Relay-Clients festgelegt sind
Die benutzerdefinierte Zusammenführung von Zertifizierungsstellen ist fehlgeschlagen	Nicht beide Umgebungsvariablen von Zertifizierungsstellen festgelegt	Legen Sie sowohl RELAY_CUSTOM_CA_PATH als auch RELAY_CA_BUNDLE_PATH zusammen fest
Hostname wird vom Relay-Dienst nicht erkannt	Pod-Name ist zufällig (eigenständiger Pod, nicht StatefulSet)	Verwenden Sie ein StatefulSet anstelle eines eigenständigen Pods
x509-Zertifikatsfehler	Ungültiges oder nicht zugängliches Zertifizierungsstellenzertifikat	Überprüfen Sie das Zertifikatformat mit openssl x509 -in custom-ca.crt -text -noout und überprüfen Sie die Dateiberechtigungen
Der Executor-Endpunkt erreicht nie health check success	Der Executor-Container gibt den Netzwerk-Namespace des Relay-Clients nicht frei, oder --onprem-executor-listen-port stimmt nicht mit dem SERVER_PORTdes Executors überein.	Starten Sie den Executor mit --network container:relay1-<RELAY_ID> und legen Sie beide Ports auf den gleichen Wert fest
Nach dem Neustart eines Containers verliert der andere den gesamten Netzwerkzugriff und kann nicht wiederhergestellt werden	Mit --network container: wird das Netzwerk des beitretenden Containers gelöscht, wenn der besitzende Container neu gestartet wird. Ein Podman-Pod ist nicht betroffen, da sein Infra-Container den Namespace besitzt	Starten Sie zuerst den Relay-Client, damit er den Namespace besitzt. Starten Sie nach einem Relay-Client-Neustart auch den Executor-Container neu
Executor kann die JCo-Bibliotheken nicht finden	Die Dateien befinden sich in einem Unterverzeichnis des bereitgestellten Volumes, oder das Volume ist am falschen Pfad bereitgestellt	Stellen Sie ein Verzeichnis bereit, das die Dateien direkt ohne Unterverzeichnisse enthält /opt/uipath/onprem-runtime/dep-libs

Informationen zu Executor-Problemen, die nicht spezifisch für Container sind, wie z. B. eine native JCo-Bibliothek, die für die falsche Architektur erstellt wurde, finden Sie unter Probleme mit dem lokalen Executor.