- Vue d'ensemble (Overview)
- Prérequis
- Installation
- Post-installation
- Migration et mise à niveau
- Mise à niveau d'Automation Suite sur EKS/AKS
- Étape 1 : Déplacement des données d'organisation Identity d'installation autonome vers Automation Suite
- Étape 2 : Restauration de la base de données du produit autonome
- Étape 3 : Sauvegarder la base de données de la plate-forme dans Automation Suite
- Étape 4 : Fusion des organisations dans Automation Suite
- Étape 5 : Mise à jour des chaînes de connexion du produit migré
- Étape 6 : migration de la version autonome d'Orchestrator
- Étape 7 : Migration d’Insights en version autonome
- Étape 8 : Migration de Test Manager autonome
- Étape 9 : suppression du locataire par défaut
- Exécution d'une seule migration de locataire
- Migration d'Automation Suite sur Linux vers Automation Suite sur EKS/AKS
- Surveillance et alerte
- Administration du cluster
- Configuration spécifique au produit
- Configuration des paramètres d'Orchestrator
- Paramètres de l'application 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 des magasins d'informations d'identification
- Configuration de la clé de chiffrement par locataire
- Nettoyer la base de données Orchestrator
- 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
- 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
- Les pods ne peuvent pas communiquer avec le nom de domaine complet dans un environnement proxy
- La chaîne de connexion SQL de l’automatisation de test est ignorée
- Échec de la sauvegarde EKS en raison de la version de Velero
- La sauvegarde de Velero échoue avec l'erreur FailedValidation
- L'accès au nom de domaine complet renvoie une erreur d'accès refusé RBAC
- Atténuation manuelle de la politique réseau ArgoCD
Mise en réseau
Enregistrez et configurez les ressources de mise en réseau Azure ou AWS pour Automation Suite sur EKS/AKS.
Vous devez enregistrer et configurer des ressources Azure ou de mise en réseau AWS pour vous assurer qu'Automation Suite sur votre cluster dispose d'une connectivité et d'un accès aux prérequis de l'infrastructure cloud (par exemple, stockage, base de données, cache et DNS). Selon votre architecture de mise en réseau, cela peut inclure la configuration de VNETs / VPC, DNS, sous-réseaux, NSGs /groupes de sécurité, passerelle NAT, Elastic IP et la passerelle Internet. Pour de plus amples informations, consultez la section Scénarios de déploiement.
Notez qu'en fonction de la mise à l'échelle de la charge de travail, davantage de répliques peuvent être nécessaires. Par défaut, le mode haute disponibilité nécessite deux répliques et peut aller jusqu'à dix répliques ou plus. Assurez-vous que votre réseau prend en charge ce niveau de mise à l'échelle.
Vous pouvez utiliser n'importe quelle interface réseau de conteneur, du moment que les pods peuvent communiquer entre eux. De plus, pour bénéficier des stratégies réseau incluses avec Automation Suite, votre CNI doit prendre en charge et appliquer les stratégies réseau Kubernetes. Certains CNI, tels que le CNI Amazon VPC, n’activent pas l’application de la stratégie réseau par défaut. Pour de plus amples informations, consultez la section Politiques réseau.
Il existe des considérations spéciales pour les CNI cloud tels que le CNI Azure et le CNI Amazon VPC, qui ne prennent pas en charge les sous-réseaux de pods internes ou privés.
Dimensionnement des pods et des IP
Le nombre de pods requis pour Automation Suite dépend de votre sélection de produits et de l’amplitude de votre charge de travail. Par exemple, pour un déploiement où tous les services seraient activés et à utilisation élevée, vous pouvez avoir besoin de plus de 400 adresses IP pour prendre en charge les exigences de mise à l'échelle. C’est pourquoi nous recommandons d’allouer une plage CIDR d’au moins /23.
Automation Suite ne prend pas en charge le protocole Internet IPv6.
Les modifications apportées aux tables d’adresses IP ne sont pas recommandées ou prises en charge.
Contrôleur d'entrée personnalisé
Si vous avez un contrôleur d’entrée personnalisé (NGINX), reportez-vous à Configuration de l’entrée NGINX et ignorez le reste de la page.
Configuration de l'équilibreur de charge
Automation Suite enregistre un équilibreur de charge en votre nom lors de l'installation. L'équilibreur de charge doit se voir attribuer des adresses IP publiques ou privées pour acheminer les requêtes FQDN entrantes. Vous avez deux options pour configurer l'équilibreur de charge :
- IP pré-allouées: affectez des adresses IP publiques ou privées pour l'équilibreur de charge, configurez les enregistrements DNS pour mapper les noms de domaine complets à ces adresses IP et fournissez ces adresses IP dans la section d'entrée de
input.json. - IPs allouées dynamiquement : si vous ne fournissez pas d'adresse IP, Automation Suite allouera dynamiquement les adresses IP du sous-réseau du cluster à l'équilibreur de charge.
Les groupes de sécurité réseau sur l'équilibreur de charge doivent autoriser le trafic HTTPS depuis les clients finaux via le port 443. Par défaut, nous configurons l'équilibreur de charge pour effectuer des vérifications de l'intégrité TCP régulières.
Si vous utilisez votre propre entrée comme NGINX, assurez-vous de répondre aux exigences réseau documentées dans Configuration du contrôleur d'entrée NGINX. Lorsque vous utilisez Istio qui déploie un NLB, notez qu'il crée généralement trois processus d'écoute, qui incluent les ports 80, 443 et 15021. Cependant, il s'agit d'une configuration standard, et vos exigences réelles peuvent différer en fonction de vos circonstances exactes. Effectuez les ajustements selon les besoins.
IP pré-allouées
Vous devez fournir les annotations de service suivantes dans la section ingress de input.json.
Pour obtenir la liste des annotations de service dans EKS, consultez la section documentation AWS Load Balancer.
Pour obtenir la liste des annotations de service dans AKS, consultez la section documentation d’Azure Load Balancer.
Exemples d’annotations EKS
Les exemples suivants illustrent comment créer la section ingress.service_annotations dans input.json. Vous devez déployer un contrôleur d'équilibreur de charge AWS sur votre cluster EKS avant l'installation pour que ces exemples fonctionnent correctement.
L'exemple suivant montre comment allouer des adresses IP Elastic à partir d'AWS et enregistrer un équilibreur de charge public. Si vous utilisez cet exemple comme point de départ pour votre configuration, assurez-vous de remplacer les adresses IP par des valeurs réelles.
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
"service.beta.kubernetes.io/aws-load-balancer-eip-allocations": "<elastic_ip_id_0>,<elastic_ip_id_1>",
"service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
"service.beta.kubernetes.io/aws-load-balancer-scheme": "internet-facing",
"service.beta.kubernetes.io/aws-load-balancer-type": "nlb"
}
}
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
"service.beta.kubernetes.io/aws-load-balancer-eip-allocations": "<elastic_ip_id_0>,<elastic_ip_id_1>",
"service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
"service.beta.kubernetes.io/aws-load-balancer-scheme": "internet-facing",
"service.beta.kubernetes.io/aws-load-balancer-type": "nlb"
}
}
L'exemple suivant montre comment allouer des adresses IP privées à un équilibreur de charge interne à partir des sous-réseaux du cluster EKS. Si vous utilisez cet exemple comme point de départ pour votre configuration, assurez-vous de mettre à jour les adresses IP et les sous-réseaux avec les valeurs réelles.
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
"service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
"service.beta.kubernetes.io/aws-load-balancer-private-ipv4-addresses":"<IP_0>,<IP_1>",
"service.beta.kubernetes.io/aws-load-balancer-subnets": "<SUBNET_ID_0>,<SUBNET_ID_1>",
"service.beta.kubernetes.io/aws-load-balancer-scheme": "internal",
"service.beta.kubernetes.io/aws-load-balancer-type": "nlb"
"service.beta.kubernetes.io/aws-load-balancer-target-group-attributes": "preserve_client_ip.enabled=false"
}
}
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
"service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
"service.beta.kubernetes.io/aws-load-balancer-private-ipv4-addresses":"<IP_0>,<IP_1>",
"service.beta.kubernetes.io/aws-load-balancer-subnets": "<SUBNET_ID_0>,<SUBNET_ID_1>",
"service.beta.kubernetes.io/aws-load-balancer-scheme": "internal",
"service.beta.kubernetes.io/aws-load-balancer-type": "nlb"
"service.beta.kubernetes.io/aws-load-balancer-target-group-attributes": "preserve_client_ip.enabled=false"
}
}
Les adresses IP et les sous-réseaux doivent correspondre. Dans l'exemple précédent, <IP_0> est dans <SUBNET_0> et <IP_1> dans <SUBNET_1>.
Exemple d'annotations AKS
L'exemple suivant montre comment allouer des adresses IP publiques à partir d'Azure et enregistrer un équilibreur de charge public. Si vous utilisez cet exemple comme point de départ pour votre configuration, assurez-vous de mettre à jour les adresses IP avec des valeurs réelles.
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/azure-load-balancer-internal": "false",
"service.beta.kubernetes.io/azure-load-balancer-ipv4": "<IP>"
}
}
...
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/azure-load-balancer-internal": "false",
"service.beta.kubernetes.io/azure-load-balancer-ipv4": "<IP>"
}
}
...
L’exemple suivant montre comment allouer des adresses IP privées à un équilibreur de charge interne à partir des sous-réseaux du cluster AKS. Si vous utilisez cet exemple comme point de départ de votre configuration, assurez-vous de mettre à jour les adresses IP et les sous-réseaux avec les valeurs réelles.
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/azure-load-balancer-internal": "true",
"service.beta.kubernetes.io/azure-load-balancer-ipv4": "<IP>",
"service.beta.kubernetes.io/azure-load-balancer-internal-subnet": "<SUBNET>",
}
}
...
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/azure-load-balancer-internal": "true",
"service.beta.kubernetes.io/azure-load-balancer-ipv4": "<IP>",
"service.beta.kubernetes.io/azure-load-balancer-internal-subnet": "<SUBNET>",
}
}
...
Configuration DNS
Veillez à ce que les enregistrements DNS soient configurés de façon à mapper les noms de domaine complets UiPath® suivants à l’équilibreur de charge :
FQDNalm.FQDNmonitoring.FQDNinsights.FQDN(si vous installez UiPath Insights)
Le nom de domaine complet est l'une des vérifications préalables à l'installation. Si vous ne fournissez pas d'adresse IP ou n'avez pas encore effectué le mappage du nom de domaine complet, la vérification échouera.
IP allouées dynamiquement
Si vous ne fournissez pas d'adresse IP dans input.json, Automation Suite alloue dynamiquement les adresses IP privées à partir des sous-réseaux du nœud de travail. Dans ce scénario, exécutez l'installation d'Automation Suite de la manière suivante.
Exemple EKS de input.json
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
"service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
"service.beta.kubernetes.io/aws-load-balancer-scheme": "internal",
"service.beta.kubernetes.io/aws-load-balancer-type": "nlb",
"service.beta.kubernetes.io/aws-load-balancer-internal": true
}
}
...
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
"service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
"service.beta.kubernetes.io/aws-load-balancer-scheme": "internal",
"service.beta.kubernetes.io/aws-load-balancer-type": "nlb",
"service.beta.kubernetes.io/aws-load-balancer-internal": true
}
}
...
Exemple AKS de input.json
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/azure-load-balancer-internal": "true"
}
}
...
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/azure-load-balancer-internal": "true"
}
}
...
Étapes d'installation
Dans ce scénario, exécutez le programme d'installation comme suit :
- Exécutez le programme d'installation uniquement jusqu'à l'enregistrement de l'équilibreur de charge :
uipathctl manifest apply <INPUT_JSON> --versions <VERSIONS_JSON> --override=gatewayuipathctl manifest apply <INPUT_JSON> --versions <VERSIONS_JSON> --override=gateway - Récupérez le nom d'hôte de l'équilibreur de charge :
kubectl get svc -n istio-system istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'kubectl get svc -n istio-system istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}' - Configurez votre DNS avec des noms de domaine complets mappés au point de terminaison ou aux adresses IP de l'équilibreur de charge.
- Réexécutez le programme d'installation pour terminer l'installation :
uipathctl manifest apply input.json --versions versions.jsonuipathctl manifest apply input.json --versions versions.json
Notez que sans mappage DNS, la vérification des prérequis du nom de domaine complet échouera. Les vérifications des prérequis sont destinées à vous assurer que vous avez correctement enregistré toutes les conditions préalables avant d'installer Automation Suite . La vérification du nom de domaine complet ne vous empêche pas d'installer Automation Suite .