- Vue d'ensemble (Overview)
- Prérequis
- Pré-installation
- Préparation de l'installation
- Téléchargement des packages d'installation
- Configuration du registre conforme à OCI
- Octroi d'autorisations d'installation
- Installation et configuration du service Mesh
- Installer et configurer l'outil GitOps
- Installation de l'opérateur de clés secrètes externes dans Kubernetes
- Application de diverses configurations
- Exécution de uipathctl
- Installation
- Post-installation
- Migration et mise à niveau
- Surveillance et alerte
- Administration du cluster
- Configuration spécifique au produit
- Configuration avancée d'Orchestrator
- Configuration des paramètres d'Orchestrator
- Configuration des paramètres d'application
- Configuration de la taille maximale de la requête
- Remplacement de la configuration du stockage au niveau du cluster
- Configuration de NLog
- Enregistrement des journaux du robot dans Elasticsearch
- Configuration des magasins d'informations d'identification
- Configuration de la clé de chiffrement par locataire
- Nettoyer la base de données Orchestrator
- Ignorer l’installation de la bibliothèque hôte
- Rotation des informations d’identification de stockage d’objets blob
- Désactivation de l'utilisation d'URL pré-signées lors du téléchargement de données vers le stockage Amazon S3
- Configuration de la sécurité de l'application de processus
- Configurer une authentification Kerberos avec l’authentification MSSQL de base pour Process Mining
- AI Trust Layer
- Résolution des problèmes
- La configuration de sauvegarde ne fonctionne pas en raison d’un échec de connexion à Azure Government
- Pods dans l'espace de noms uipath bloqués lors de l'activation des rejets de nœuds personnalisés
- Impossible de lancer Automation Hub et Apps avec la configuration proxy
- La sauvegarde de Velero échoue avec l'erreur FailedValidation
- Résolution des problèmes de clés secrètes externes
- Résolution des problèmes de Temporel en tant que service
- Les pods AI Center et Document Understanding ne démarrent pas avec la vérification du certificat TLS activée
- Erreurs de validation du certificat TLS
- Fluentd n’exporte pas les journaux dans les environnements IPv6
- Studio Desktop ne peut pas charger les connecteurs et activités Integration Service
- Atténuation manuelle de la politique réseau ArgoCD
- Configurer les requêtes et les limites de ressources pour les charges de travail créées par uipathctl
Architectures de déploiement en ligne, hors ligne et multi-sites pour Automation Suite sur EKS/AKS.
Déploiement en ligne
Un déploiement en ligne d’Automation Suite nécessite un accès à Internet durant l’installation et l’exécution. Tous les produits UiPath® et les bibliothèques associées sont hébergés soit dans le registre UiPath®, soit dans un magasin tiers approuvé par UiPath.
Vous pouvez limiter l'accès à Internet à l'aide d'un pare-feu restreint ou d'un serveur proxy en bloquant tout trafic Internet autre que celui requis par Automation Suite. Pour plus d’informations sur les règles de pare-feu ou de proxy, consultez la section Configuration du proxy.
Déploiement hors ligne
Un déploiement hors ligne (air-gapped) est une configuration complètement isolée, sans accès à Internet. Ce type de configuration nécessite l’installation d’un registre supplémentaire pour stocker toutes les images de conteneur et les fichiers binaires des produits UiPath®, livrés sous la forme d’une archive tar.
Vous n'êtes pas autorisé à modifier la méthode de déploiement après l'installation. Cela signifie que vous ne pouvez pas passer en mode hors ligne si l'installation est effectuée en ligne, et vice versa. Il est recommandé de choisir votre stratégie de déploiement après un examen approfondi.
Déploiement d'Automation Suite sur EKS
Architecture de déploiement
Vous pouvez référencer les schémas d'architecture suivants pour déployer Automation Suite sur EKS.
Déploiement en ligne
Déploiement hors ligne
Vue d'ensemble (Overview)
Le diagramme d'architecture précédent montre comment Automation Suite peut être configuré sur le cluster AWS EKS.
Un cluster EKS est déployé dans une seule région AWS, où les nœuds de travail EC2 se trouvent dans un groupe de mise à l'échelle automatique réparti sur trois zones de disponibilité. La distribution des nœuds à travers les zones de disponibilité est ce qui apporte la résilience à la défaillance complète de la zone.
Zones de disponibilité et mise en réseau
Chaque zone a un sous-réseau privé et un sous-réseau public. Les nœuds de travail EC2 sont hébergés dans un sous-réseau privé, tandis que le sous-réseau public héberge une adresse IP Elastic et une passerelle NAT. La passerelle NAT est requise pour se connecter à Internet tout en accédant au plan de contrôle EKS à partir des nœuds de travail et en se connectant au registre Docker pour obtenir les images de conteneur pour le déploiement d' Automation Suite .
Les adresses IP Elastic hébergées dans chaque sous-réseau public sont transmises à Automation Suite lors de l'installation pour l'enregistrer en tant que point de terminaison où Istio doit écouter tout trafic entrant. Pour la même raison, le Network Load Balancer (NLB) doit utiliser ces points de terminaison pour transmettre toute demande effectuée à Automation Suite .
Sources de données
Les sources de données telles qu'Amazon RDS pour Microsoft SQL Server, le compartiment S3, Elastic File System et Elastic Cache doivent être configurés pour avoir suffisamment de redondance en cas de défaillance et doivent être accessibles à partir du sous-réseau privé où les instances de travail EC2 sont hébergées.
Le cluster Kubernetes doit disposer d'une connectivité réseau et avoir accès au magasin secret pour récupérer les informations d'identification.
- Automation Suite n'a pas de règles d'affinité pour s'assurer que les pods de travail sont répartis de manière égale dans la zone. En cas de défaillance au niveau de la zone, il peut y avoir une dégradation momentanée du service, qui sera résolue lorsque ce service sera automatiquement déplacé vers une nouvelle zone par le plan de contrôle EKS.
- Insights requiert que les volumes EBS stockent le tableau de bord et les autres métadonnées. Dans AWS, les volumes EBS sont liés à la zone dans laquelle ils sont présents et ne sont pas déplacés lorsque la zone est en panne. Insights ne sera pas disponible tant que la zone dans laquelle les insights ont été planifiées n’a pas été récupérée.
- EKS n’active pas la mise à l’échelle automatique par défaut, contrairement à AKS. Pour activer cette fonctionnalité, vous devez généralement installer et configurer des logiciels supplémentaires tels que Serveur de métriques (Metrics Server) et Mise à l’échelle automatique du cluster (Cluster-Autoscaler) ou des solutions alternatives qui offrent des capacités de mise à l’échelle automatique similaires.
Déploiement d'Automation Suite sur AKS
Architecture de déploiement
Vous pouvez référencer les schémas d'architecture suivants pour déployer Automation Suite sur AKS.
Déploiement en ligne
Déploiement hors ligne
Vue d'ensemble (Overview)
Un cluster AKS est déployé dans une seule région où les nœuds de travail sont répartis entre pools de nœuds système et pools de nœuds utilisateur. Les composants principaux d’AKS, à l’exception du plan de contrôle, sont hébergés dans le pool de nœuds système. En outre, les services de base de UiPath® sont également hébergés dans ce même pool de nœuds. Des pools de nœuds utilisateur supplémentaires peuvent héberger les nœuds de travail pour les Automation Suite Robots et le GPU.
Pools de nœuds et mise en réseau
Chaque pool de nœuds héberge le groupe de machines virtuelles identiques (VMSS), garantissant que les nœuds de travail sont répartis sur plusieurs zones pour fournir une résilience à la défaillance de la zone et à l'échelle si nécessaire.
L'adresse IP statique associée à l'équilibreur de charge est transmise à Automation Suite lors de l'installation pour l'enregistrer en tant que point de terminaison où Istio doit écouter tout trafic entrant. Pour la même raison, l'équilibreur de charge Azure (L4) doit utiliser ces points de terminaison pour transmettre toute demande à Automation Suite .
Sources de données et accès
Les sources de données telles que Microsoft SQL Server, le compte de stockage Azure et le cache Redis Azure doivent être configurés pour avoir suffisamment de redondance en cas de défaillance et doivent être accessibles à partir du sous-réseau où les nœuds de travail AKS sont hébergés.
Le cluster Kubernetes doit disposer d'une connectivité réseau et avoir accès au magasin secret pour récupérer les informations d'identification.
En outre, une Jump Box/Bastion Server supplémentaire peut être nécessaire, qui peut disposer de tous les privilèges requis pour faire fonctionner le cluster AKS.
Automation Suite n'a pas de règles d'affinité pour s'assurer que les pods de travail sont répartis de manière égale dans la zone. En cas de défaillance au niveau de la zone, il peut y avoir une dégradation momentanée du service, qui sera résolue lorsque ce service sera automatiquement déplacé vers une nouvelle zone par le plan de contrôle AKS.
Modes de déploiement et cas d'utilisation
Automation Suite prend en charge les modes de déploiement suivants :
| Mode de déploiement | Description |
|---|---|
| Multi-nœuds | Pris en charge pour une utilisation en production. Les modes suivants sont disponibles: - Mode léger: déploiement léger avec configuration haute disponibilité sélective. Pour des détails, reportez-vous à Installations en mode Lite. - Mode haute disponibilité: entièrement activé. Pour des détails, reportez-vous à Installations haute disponibilité. |
Installations en mode Lite
Les installations en mode léger offrent un processus de configuration simple et léger, qui inclut toutes les fonctionnalités à l'exception de la haute disponibilité. Par défaut, l'infrastructure et les composants partagés sont déployés en mode haute disponibilité, et tous les services sont en mode léger (la mise à l'échelle automatique des pods horizontaux est activée avec au moins une réplique).
Le mode léger garantit une gestion flexible de l’infrastructure en vous permettant d’activer la haute disponibilité pour certains services pendant ou après l’installation, selon les besoins.
Vous pouvez utiliser le mode plus léger en production, mais vous devez être conscient des implications et des risques d'avoir des services sans haute disponibilité activée.
Installations haute disponibilité
Les installations multi-nœuds sont prises en charge pour les déploiements de production, offrant une évolutivité accrue, une fiabilité améliorée et une gestion efficace des ressources. Il prend en charge à la fois la haute disponibilité au niveau du cluster et en externe.
Déploiement d'Automation Suite avec un magasin secret
Automation Suite nécessite plusieurs informations d'identification d'infrastructure pour déployer tous ses produits.
Au lieu de définir les informations d'identification directement dans le fichier input.json , vous pouvez configurer un magasin de clés secrètes afin de gérer et de fournir en toute sécurité des informations sensibles. Lors du déploiement, uipathctl récupère les informations d'identification du magasin de clés secrètes configuré et les applique automatiquement.
Vous pouvez stocker des informations d'identification telles que :
- Identifiants SQL
- Nom d'utilisateur (Username)
- Mot de passe (Password)
- Chaînes de connexion SQL
- Identifiants de stockage
- S3/AWS
- Clé d'accès
- Clé secrète
- ARN (Nom de la ressource Amazon)
- Azure
- accountKey
- ID de client
- Secret du client
- ID d'abonnement
- ID de locataire
- S3/AWS
- Identifiants Redis
- Mot de passe (Password)
- Licence (License)
- Authentification Kerberos
- Nom d’utilisateur AD
- Keytab utilisateur
- Domaine AD
- Durée de vie du ticket
Vous ne pouvez pas stocker les chemins de certificat ou les informations d'identification liées au certificat dans le magasin secret.
Clé secrète Kubernetes
Vous pouvez utiliser une clé secrète Kubernetes pour fournir toutes les données sensibles au lieu de les inclure dans input.json.
uipathctl utilise les informations d'identification stockées dans la clé secrète lors du déploiement d'Automation Suite et de ses produits.
Azure Key Vault
Vous pouvez configurer toutes les données ou informations d'identification sensibles dans un Azure Key Vault.
uipathctl utilise les informations d'identification stockées dans Azure Key Vault lors du déploiement d'Automation Suite.
HashiCorp Vault
Vous pouvez configurer toutes les données ou informations d'identification sensibles dans une instance HashiCorp Vault. HashiCorp Vault prend en charge le moteur de clés secrètes KV (Key-Value) v1 et v2.
uipathctl s'authentifie auprès de Vault à l'aide de jetons de compte de service Kubernetes ou des informations d'identification AppRole et récupère les informations d'identification stockées lors du déploiement d'Automation Suite.
AWS Secrets Manager
Vous pouvez configurer toutes les données ou informations d'identification sensibles dans AWS Secrets Manager. Les clés secrètes peuvent être stockées sous forme de paires clé-valeur ou de chaînes de texte brut.
uipathctl utilise la chaîne d'informations d'identification AWS SDK pour s'authentifier et récupérer les informations d'identification d'AWS Secrets Manager lors du déploiement d'Automation Suite.
- Déploiement en ligne
- Déploiement hors ligne
- Déploiement d'Automation Suite sur EKS
- Architecture de déploiement
- Vue d'ensemble (Overview)
- Déploiement d'Automation Suite sur AKS
- Architecture de déploiement
- Vue d'ensemble (Overview)
- Modes de déploiement et cas d'utilisation
- Installations en mode Lite
- Installations haute disponibilité
- Déploiement d'Automation Suite avec un magasin secret
- Clé secrète Kubernetes
- Azure Key Vault
- HashiCorp Vault
- AWS Secrets Manager