Déploiement du client de relais en tant que conteneur

Déployez le client UiPath Relay en tant qu'image de conteneur à l'aide de Podman, Docker ou Kubernetes pour établir des tunnels sortants sécurisés dans des environnements conteneurisés.

Exécutez le client Relay en tant qu'image de conteneur pour établir des tunnels sortants sécurisés vers Test Cloud à partir d'environnements conteneurisés. Avant de commencer, configurez un groupe Relay et préparez la string de configuration du client à partir de l'interface utilisateur Relay.

Prérequis

• Runtime du conteneur: Podman, Docker ou un cluster Kubernetes.
• Image du conteneur du client de relais: registry.uipath.com/relay-client:<tag>. Remplacez <tag> par une version Relay à partir de la page de téléchargements du UiPath Customer Portal . La version minimale prise en charge est 26.4.1 ou 26.4.3 pour les connexions basées sur TCP telles que SAP BAPI.
• Un fichier de configuration encodé en base64 généré à partir de l'interface utilisateur du relais.
• Acceptation du contrat de licence: définissez LICENSE_AGREEMENT=accept comme variable d'environnement ou ajoutez --accept-license-agreement à la commande de démarrage.
• (Facultatif) Un certificat CA personnalisé si votre organisation utilise un PKI d'entreprise.

Pour connaître la configuration matérielle requise et les prérequis réseau spécifiques à la version, consultez la section Déployer le client de relais.

Important :

Pour les connexions basées sur TCP, telles que les SAP BAPI, vous déployez le client de relais avec un deuxième conteneur, l'exécuteur sur site. Si vous en avez besoin, ignorez l'étape 3 et suivez plutôt SAP BAPI et d'autres connexions basées sur TCP . Cette section couvre Docker et Podman.

Étape 1: Obtenir la configuration

1. Ouvrez le tableau de bord de l'interface utilisateur du relais.
2. Créez ou copiez votre configuration de relais.
3. Créez un répertoire sur l’hôte pour le fichier de configuration. N'importe quel répertoire fonctionne; cette page utilise /opt/uipath/relay/config comme exemple. Sur Windows, utilisez un chemin d'accès Windows tel que C:\uipath\relay\config.
4. Enregistrez la chaîne de configuration encodée en base64 de l'interface utilisateur sous le nom relay.config.b64enc. Les commandes de déploiement monteront ce répertoire dans le conteneur en tant que /relay-config; remplacez l'exemple de chemin par le vôtre.

Étape 2: configurer les variables d'environnement

Transmettez ces variables sous forme d'indicateurs -e avec Podman ou Docker, ou sous forme d'entrées env: dans le manifeste Kubernetes, à l'étape 3.

Certificat CA personnalisé

Si votre organisation utilise une autorité de certification d'entreprise ou auto-signée, définissez les variables suivantes avant de lancer le conteneur:

Variable	Objectif	Requis
RELAY_CUSTOM_CA_PATH	Chemin d'accès au certificat CA personnalisé	Oui, si vous utilisez une autorité de certification personnalisée
RELAY_CA_BUNDLE_PATH	Chemin où le bundle d’autorité de certification fusionné est écrit	Oui, si vous utilisez une autorité de certification personnalisée

Le client de relais fusionne l'autorité de certification personnalisée avec le bundle de certificats système avant d'établir des connexions TLS.

Proxy

Pour acheminer le trafic sortant via un proxy:

Variable	Objectif	Requis
HTTP_PROXY et HTTPS_PROXY	URL du proxy	Non (No)
NO_PROXY	Noms d'hôte, domaines ou adresses IP séparés par des virgules qui contournent le proxy	Non (No)

Étape 3: Déployer

Remplacez <RELAY_ID> par l'ID réel de l'interface utilisateur du relais. Pour la haute disponibilité avec Docker ou Podman, exécutez deux conteneurs sur des nœuds distincts avec des noms distincts, par exemple relay1-<RELAY_ID> sur host1 et relay2-<RELAY_ID> sur host2. Dans Kubernetes, utilisez deux répliques avec une affinité de pod, comme dans le manifeste ci-dessous. Un démarrage réussi enregistre All prerequisite checks passed.

Les commandes Podman et Docker ci-dessous s'exécutent au premier plan avec -it --rm, vous pouvez donc regarder le premier démarrage et le conteneur est supprimé lorsque vous l'arrêtez. Pour un déploiement de longue durée, remplacez -it --rm par -d.

Podman

Démarrage rapide:

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

Avec un certificat CA personnalisé:

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

Démarrage rapide:

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

Avec un certificat CA personnalisé:

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

Créer des clés secrètes:

# 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"

Déployez un ensemble d'états:

Utilisez un Ensemble d'états lorsque des restrictions de nom d'hôte sont appliquées. Les ensembles d'états fournissent des noms d'hôtes stables et prévisibles (relay-client-<RELAY_ID>-0, relay-client-<RELAY_ID>-1, etc.), que le service de relais utilise pour identifier et valider les clients.

Le manifeste montant la clé secrète custom-ca et définit les deux variables RELAY_*. Si vous n'utilisez pas d'autorité de certification personnalisée, supprimez ces deux variables, le montage de volume custom-ca et le volume custom-ca. La sonde de disponibilité utilise le point de terminaison de santé, ce qui nécessite le client de relais 26.4.2 ou une version ultérieure.

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

Vérifiez le déploiement:

kubectl get statefulset relay-client-<RELAY_ID>

Démarrer les options de la commande

Celles-ci s’appliquent à chaque runtime.

Option	Description	Exemple
--config	Chaîne de configuration base64 intégrée	--config "base64string..."
--config-file	Chemin d’accès au fichier de configuration	--config-file /relay-config/relay.config.b64enc
--log-level	Détail de la journalisation: trace, debug, info, warn, ou error	--log-level debug
--heartbeat-interval	Intervalle des pulsations en secondes (3e minimum: 10)	--heartbeat-interval 10
--reconnect-interval	Intervalle de reconnexion en secondes (minimum: 1 800)	--reconnect-interval 1800
--health-addr	Adresse de liaison pour le point de terminaison /healthz . La valeur par défaut est 0.0.0.0:9090; Si vous indiquez une valeur vide pour la désactiver,	--health-addr=0.0.0.0:9090
--enable-onprem-executor	Se connecte au conteneur d’exécuteur local sur le port par défaut 18080. Voir SAP BAPI et autres connexions basées sur TCP	--enable-onprem-executor
--onprem-executor-listen-port	Se connecte au conteneur d’exécuteur local sur ce port, qui doit correspondre au conteneur SERVER_PORT du conteneur. L’un ou l’autre des indicateurs active l’exécuteur	--onprem-executor-listen-port 18080

SAP BAPI et autres connexions basées sur TCP

Important :

Nécessite le client de relais 26.4.3 ou une version ultérieure. Cette section couvre Docker et Podman.

Pour les connexions basées sur TCP, telles que SAP BAPI, vous exécutez deux conteneurs sur le même hôte:

• Conteneur de client de relais: ouvre la connexion sortante sécurisée à UiPath.
• Conteneur d’exécuteur local: se connecte à votre système local et gère la connexion basée sur TCP.

Le conteneur d'exécuteur partage le réseau du client de relais, de sorte que le client de relais atteint l'exécuteur sur localhost.

Prérequis

• Image de conteneur d'exécuteur local: registry.uipath.com/relay-onprem-executor:<tag>. Utilisez la même <tag> que votre image de client de relais. La version minimale prise en charge est de 26.4.3.
• Les bibliothèques SAP JCo 3 sapjco3.jar, sapidoc3.jar et libsapjco3.so. Téléchargez-les depuis le portail d’assistance SAP, qui nécessite un compte SAP; UiPath ne les fournit pas.
  • sapjco3.jar et libsapjco3.so sont dans le package SAP Java Connector 3.1 pour Linux sur x86_64. L'image de l'exécuteur est linux/amd64, donc un package pour une autre plate-forme ne se charge pas.
  • sapidoc3.jar se trouve dans le package distinct de la bibliothèque de classes SAP Java IDoc 3.1 .
• L'hôte de relais peut résoudre et atteindre le nom d'hôte et le port du système SAP.

Organisation des bibliothèques JCo

Les bibliothèques peuvent se trouver dans n'importe quel répertoire de l'hôte. Cette page utilise /opt/uipath/relay/executor-deps comme exemple. ce qui compte, c'est que la commande de déploiement montera votre répertoire sur /opt/uipath/onprem-runtime/dep-libs à l'intérieur du conteneur de l'exécuteur. Les commandes utilisent sudo car /opt nécessite la racine sur Linux; Omettez-le pour un répertoire qui vous appartient.

1. Créez le répertoire:

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

2. Copiez les trois fichiers à l'intérieur. Placez-les directement dans le répertoire, et non dans les sous-répertoires:

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

3. Confirmez que la bibliothèque native est conçue pour x86-64:

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

   Si la sortie indique ARM aarch64 ou une autre architecture, téléchargez plutôt le package Linux sur x86_64. Sur Windows, où file n'est pas disponible, vérifiez le package à partir duquel vous avez extrait: le bon se nomme sapjco3-linuxx86_64-<version>.

Déployer les deux conteneurs

Exécutez les commandes dans cet ordre: le client de relais d’abord, puis l’exécuteur. L'exécuteur rejoint le réseau du client de relais, de sorte que le client de relais doit être en cours d'exécution au démarrage de l'exécuteur.

Avertissement :

Si vous redémarrez ou recréez le client de relais, l’exécuteur perd son réseau et ne récupère pas de lui-même. Redémarrez l'exécuteur ensuite, comme décrit dans la section Redémarrage et mise à niveau.

Avant d'exécuter les commandes:

• Remplacez /opt/uipath/relay/config et /opt/uipath/relay/executor-deps par les répertoires hôtes que vous avez choisis à l'étape 1 et l'étape des bibliothèques JCo. Conservez les chemins côté conteneur comme indiqué.
• Si vous avez déjà démarré un client de relais depuis l'étape 3, arrêtez-le et supprimez-le. Les arguments d'un conteneur en cours d'exécution ne peuvent pas être modifiés.
• Si vous utilisez une autorité de certification ou un proxy personnalisé, ajoutez les variables de l'étape 2 et, pour une autorité de certification personnalisée, les deux montages de volume de l'étape 3 à la commande du client de relais. Le client de relais est le conteneur qui se connecte à UiPath.
• Ne publiez pas le port de l’exécuteur avec -p. Seul le client de relais doit l'atteindre.

Activez l'exécuteur sur le client de relais avec l'un des indicateurs suivants:

Drapeau	Effet
--enable-onprem-executor	Se connecte à l’exécuteur sur le port par défaut 18080
--onprem-executor-listen-port <port>	Se connecte à l’exécuteur sur <port>. Doit correspondre au SERVER_PORTdu conteneur d’exécution

Les autres indicateurs de l'exécuteur, --onprem-executor-java-home et --onprem-executor-dep-dir, n'ont aucun effet dans un conteneur: l'image de l'exécuteur inclut son propre runtime Java et lit ses bibliothèques à partir de /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>

Vous pouvez également créer un pod Podman et exécuter les deux conteneurs à l'intérieur avec --pod. Le conteneur infra du pod possède l'espace de noms réseau, donc l'un ou l'autre des conteneurs peut redémarrer de manière autonome.

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>

Vérifier

Lisez les journaux avec les commandes pour votre runtime:

Runtime	Journaux du client de relais	Journaux de l’exécuteur
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. Dans les journaux du client de relais, confirmez la ligne de prérequis On-prem executor checks: OK.
2. Dans les mêmes journaux, recherchez le point de terminaison de l'exécuteur, nommé relay1-<RELAY_ID>-system-onprem-executor-<id>, et confirmez qu'il atteint health check success.
3. Dans les journaux de l'exécuteur, confirmez Started OnPremRuntimeApplication.
4. Exécutez un appel de test à partir du connecteur qui utilise ce point de terminaison pour confirmer que le chemin complet fonctionne.

Remarque :

Alors que le conteneur d'exécuteur est toujours en cours de démarrage, l'étape 2 peut afficher un health check failed: dial tcp [::1]:18080: connect: connection refused en premier. Cela est attendu et s’efface lors de la prochaine vérification, environ 10 secondes plus tard, sans redémarrer le client de relais.

Pour les problèmes, consultez d’abord la section Résolution des problèmes sur cette page, puis Problèmes rencontrés avec l’exécuteur local.

Redémarrage et mise à niveau

Vous pouvez redémarrer ou mettre à niveau l'exécuteur de manière autonome. Si vous redémarrez ou recréez le client de relais, redémarrez ou recréez également l'exécuteur par la suite: l'exécuteur s'exécute à l'intérieur du réseau du client de relais, et le redémarrage ou la recréation du client de relais remplace ce réseau, de sorte que le conteneur d'exécuteur existant ne peut pas récupérer de lui-même. Utilisez le même <tag> pour les deux images lors de la mise à niveau. Pour Podman, remplacez docker par podman.

Tâche	Que faire
Redémarrer l’exécuteur	docker restart relay-executor-<RELAY_ID>. Le client de relais continue de s’exécuter
Mettre à niveau l’exécuteur	docker rm -f relay-executor-<RELAY_ID>, puis exécutez à nouveau la commande de l’exécuteur avec le nouveau <tag>
Redémarrer le client de relais	docker restart relay1-<RELAY_ID>, puis docker restart relay-executor-<RELAY_ID>
Mettre à niveau le client de relais	Supprimez les deux conteneurs, puis exécutez à nouveau les deux commandes avec le nouveau <tag>, client de relais en premier. Un client de relais recréé est un nouveau conteneur, l’exécuteur doit donc également être recréé

Opérations

Configuration details

Le fichier de configuration doit contenir la chaîne JSON encodée en base64 générée par l'interface utilisateur du relais. Au démarrage, le client de relais lit la configuration, la décode, la valide et se connecte au point de terminaison du service de relais spécifié.

• Première exécution: la configuration est stockée chiffrée dans le répertoire de données.
• Exécutions suivantes: la configuration chiffrée est automatiquement déchiffrée et utilisée.
• Modifications du fichier de configuration: nécessitent un redémarrage du conteneur pour prendre effet.

Intervalle des pulsations

La pulsation maintient les connexions TCP inactives actives. Réduisez l'intervalle si votre pare-feu, votre proxy ou la traduction d'adresses réseau abandonne les connexions inactives avant 30 secondes:

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

Intervalle de reconnexion

La reconnexion proactive rétablit la connexion selon un calendrier fixe. Utilisez cette option dans les environnements où un proxy ou un équilibreur de charge a un délai d'expiration de connexion inactive:

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

Point de terminaison de santé

Remarque :

L'option --health-addr est disponible avec le client de relais 26.4.2 et les versions ultérieures.

L'image de conteneur active un point de terminaison HTTP /healthz par défaut sur 0.0.0.0:9090. Utilisez --health-addr=<address> pour modifier l'adresse de liaison ou --health-addr= pour désactiver le point de terminaison. La sonde de disponibilité Kubernetes du manifeste utilise ce point de terminaison.

Accéder aux journaux

# 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

La rétention du journal de conteneur est contrôlée par votre runtime de conteneur ou par votre stratégie de journalisation de cluster Kubernetes, et non par le client de relais.

Sécurité

Appliquez les paramètres de sécurité suivants dans votre manifeste de conteneur:

• readOnlyRootFilesystem: true: empêche la modification du système de fichiers du conteneur.
• runAsNonRoot: true: exécute le processus en tant qu'utilisateur non root.
• allowPrivilegeEscalation: false: empêche l’escalade des privilèges.
• capabilities.drop: [ALL]: supprime toutes les fonctionnalités Linux.
• privileged: false: désactive le mode privilégié.

Stockez la configuration du Relay dans les clés secrètes Kubernetes et utilisez le contrôle d’accès basé sur les rôles pour restreindre l’accès aux secrets. N'intégrez pas la configuration base64 dans l'image du conteneur et ne la transmettez pas en tant que variable d'environnement simple.

Résolution des problèmes

Symptôme	Origine	Résolution
license agreement not accepted au démarrage	Indicateur de licence ou variable non défini	Ajoutez --accept-license-agreement à la commande de démarrage, ou définissez LICENSE_AGREEMENT=accept
Fichier de configuration introuvable	Chemin de montage de volume ou clé secrète incorrecte	Exécutez kubectl describe secret relay-config et kubectl describe pod <pod-name> pour vérifier les montages
Impossible de se connecter au service de relais	Problème de réseau ou de pare-feu	Vérifiez les journaux de pod avec kubectl logs <pod-name> et vérifiez les destinations sortantes requises dans le déploiement du client de relais
Échec de la fusion de l’autorité de certification personnalisée	Variables d'environnement CA non définies les deux	Définir RELAY_CUSTOM_CA_PATH et RELAY_CA_BUNDLE_PATH ensemble
Nom d'hôte non reconnu par le service de Relay	Le nom du pod est aléatoire (pod autonome, non Ensembles d'états)	Utiliser un Ensemble d'états au lieu d'un Pod autonome
erreurs de certificat x509	Certificat CA non valide ou inaccessible	Vérifiez le format du certificat avec openssl x509 -in custom-ca.crt -text -noout et vérifiez les autorisations du fichier
Le point de terminaison de l’exécuteur n’atteint jamais health check success	Le conteneur d’exécuteur ne partage pas l’espace de noms réseau du client de relais, ou --onprem-executor-listen-port ne correspond pas au SERVER_PORTde l’exécuteur	Démarrez l’exécuteur avec --network container:relay1-<RELAY_ID> et définissez les deux ports sur la même valeur
Après avoir redémarré un conteneur, l'autre perd tout l'accès au réseau et ne récupère pas	Avec --network container:, la mise en réseau du conteneur de jonction est supprimée lorsque le conteneur propriétaire redémarre. Un pod Podman n'est pas affecté, car son conteneur infra possède l'espace de noms	Démarrez d'abord le client de relais afin qu'il possède l'espace de noms. Après un redémarrage d’un client de relais, redémarrez également le conteneur d’exécuteur
L’exécuteur ne peut pas trouver les bibliothèques JCo	Les fichiers se trouvent dans un sous-répertoire du volume monté, ou le volume est monté sur le chemin d’accès incorrect	Montez un répertoire qui contient les fichiers directement, sans sous-répertoires, au niveau de /opt/uipath/onprem-runtime/dep-libs

Pour les problèmes d’exécuteur qui ne sont pas spécifiques aux conteneurs, tels qu’une bibliothèque native JCo conçue pour la mauvaise architecture, consultez la section Problèmes liés à l’exécuteur local.