Vérifications des prérequis

Exécutez uipathctl préreq run pour valider les prérequis d'infrastructure pour Automation Suite sur OpenShift, y compris le flux au niveau de l'espace de noms.

Il est recommandé d'effectuer les vérifications des prérequis pour vous assurer que vous avez correctement configuré l'infrastructure Cloud et pour valider input.json avant de démarrer l'installation Automation Suite.

Cette page couvre:

• Exécuter les vérifications des prérequis
• Ce que les vérifications des prérequis valident
• Exécuter des vérifications des prérequis sans rôles de cluster
• Valider manuellement les vérifications exclues

Exécuter les vérifications des prérequis

Effectuez les vérifications des prérequis avec un kubeconfig disposant d'un accès au niveau du cluster. Si uipathadmin est uniquement basé sur l'espace de noms, suivez plutôt la section Exécuter des vérifications des prérequis sans rôles de cluster .

Pour vérifier les prérequis en fonction des entrées que vous avez configurées dans le fichier input.json, exécutez la commande suivante à partir d'une machine avec accès à l'API Kubernetes du cluster:

uipathctl prereq run input.json --versions versions.json

Pour plus de détails sur les indicateurs que vous pouvez utiliser avec la commande uipathctl prereq run , reportez-vous à uipathctl préreq run.

Par défaut, la commande uipathctl prereq vérifie tous les prérequis. Alternativement, la commande vous permet également d'effectuer uniquement les vérifications qui vous intéressent, comme suit :

• Si vous souhaitez exclure des composants de l'exécution, utilisez l'indicateur --excluded. Par exemple, si vous ne souhaitez pas vérifier les chaînes de connexion à la base de données, exécutez uipathctl prereq --excluded SQL. La commande exécute toutes les vérifications des prérequis, à l'exception de celle qui est relative à SQL.
• Si vous souhaitez inclure uniquement certains composants dans l'exécution, utilisez l'indicateur --included. Par exemple, si vous souhaitez uniquement vérifier le DNS et l'objectstore, exécutez uipathctl prereq --included DNS,OBJECTSTORAGE.
• Si vous souhaitez accéder à la sortie de vérification détaillée des prérequis, utilisez l'indicateur --verbose. Vous pouvez ignorer cet indicateur pour une sortie plus concise et simplifiée.

Remarque :

Vous pouvez trouver les noms des composants que vous pouvez inclure ou exclure des vérifications des prérequis dans la sortie de vérification des prérequis. Dans l'exemple, le premier mot de chaque ligne en retrait représente le nom du composant. Par exemple: SQL, OBJECTSTORE, DNS, etc.

Les prérequis et les vérifications/tests d'intégrité s'exécutent dans l'espace de noms <uipath> . Vous devez soit accorder à l'outil uipathctl les autorisations nécessaires pour permettre la création de l'espace de noms <uipath> , soit le créer vous-même avant d'exécuter les vérifications/tests. De plus, des vérifications/tests nécessitent que vous activiez l'utilisation de hostNetwork.

Pour exécuter les tests liés au réseau hôte, vous devez autoriser l'outil à s'exécuter avec des privilèges d'administrateur de cluster. Sinon, l'avertissement suivant s'affiche dans la sortie de vérification des prérequis :

Ran CONNECTIVITY checks...
     ⚠  [CONNECTIVITY]
        ⚠  [NETWORK_TEST_SETUP] Failed to create the network test infrastructure: failed to create echo-host-role role: error creating role: roles.rbac.authorization.k8s.io "network-prereq-6c5mt-echo-host-role" is forbidden: user "system:serviceaccount:uipath:uipathadmin" (groups=["system:serviceaccounts" "system:serviceaccounts:uipath" "system:authenticated"]) is attempting to grant RBAC permissions not currently held:
{APIGroups:["security.openshift.io"], Resources:["securitycontextconstraints"], ResourceNames:["hostnetwork-v2"], Verbs:["use"]}

Ce que les vérifications des prérequis valident

Les vérifications du tableau suivant sont exécutées sur chaque nœud :

Vérifier (Check)	Description
Connexion SQL	Confirme qu’Automation Suite peut se connecter avec succès au serveur SQL pour les produits UiPath® et les services partagés (identification, portail, gestion de l’organisation, etc.) à l’aide des chaînes de connexion SQL fournies dans le fichier input.json . Cette vérification est obligatoire pour réussir l’installation.
Rôles de la base de données SQL	Valide les rôles et autorisations requis par les produits UiPath®. Cette vérification est obligatoire pour réussir l’installation.
Compatibilité de la base de données SQL	Valide les exigences de compatibilité de la base de données SQL.
Résolution du nom de domaine complet	Vérifie que le nom de domaine complet et les sous-domaines peuvent être résolus avec succès.
API de stockage d'objets	Confirme que les API du magasin d’objets sont accessibles en se basant sur les informations d’accès fournies dans le fichier input.json . Cette vérification est obligatoire pour réussir l’installation des services UiPath®.
Cache/Redis	Valide la connexion à Redis. Cette vérification est obligatoire pour réussir l’installation.
Capacité	Valide que vous avez une capacité minimale de CPU et de RAM sur les nœuds de travail en fonction des produits activés dans le fichier input.json .
Classe de stockage	Valide que les classes de stockage pour le stockage des fichiers sont configurées comme requises pour les Automation Suite Robots.
Composants facultatifs	Vérifie que votre cluster contient des composants que vous avez choisi d'exclure de l'installation d' Automation Suite .
Entrée	Confirme que l’entrée du cluster a été configurée correctement et que les requêtes URL des noms de domaine complets peuvent accéder aux produits UiPath®.
Stratégies réseau	Vérifie si les stratégies réseau configurées dans Automation Suite sont compatibles avec le cluster.
Registre	Confirme qu’Automation Suite peut accéder au registre docker UiPath®. Cette vérification est obligatoire pour réussir l’installation.
Connectivité du cluster	Vérifie si la communication du cluster est configurée correctement : - Entre deux pods aléatoires terminés - Entre un pod et une adresse IPCluster multi-nœuds - Entre le pod et une ClusterIP multi-nœuds sans clusterIP - Entre un pod et une adresse IPCluster multinœud à l'aide de HostNetwork - Entre le pod et une adresse IPCluster multi-nœuds sans ensemble d'adresses IP de cluster à l'aide de HostNetwork - Entre deux pods colocalisés sur le même nœud via ClusterIP Les vérifications de connectivité peuvent échouer sur OpenShift 4.16–4.18 nœuds du plan de contrôle en raison de conflits de ports. Pour résoudre le problème, consultez la section Résolution des problèmes .

Exécuter des vérifications des prérequis sans rôles de cluster

Remarque :

Cette section s'applique uniquement si vous avez accordé au compte du service d'installation d'Automation Suite (uipathadmin) uniquement des autorisations au niveau de l'espace de noms, sans aucune autorisation au niveau du cluster. Pour plus de détails, consultez la section Octroi d’autorisations d’installation sans rôles de cluster.

Si uipathadmin dispose des autorisations au niveau du cluster, exécutez plutôt les vérifications des prérequis comme décrit dans la section Exécution des vérifications des prérequis .

Lorsque l'étendue uipathadmin est limitée à l'espace de noms, un ensemble fixe de vérifications uipathctl prereq run échoue, car elles nécessitent un accès au niveau du cluster (soit une lecture sur une ressource à l'échelle du cluster) (telle que nodes, namespaces, storageclasses) , ou customresourcedefinitions) ou, dans le cas de la vérification de la connectivité, la possibilité d'utiliser la contrainte de contexte de sécurité hostnetwork-v2. Utilisez l'indicateur --excluded pour ignorer exactement ces vérifications:

uipathctl prereq run input.json \
  --kubeconfig <uipathadmin.kubeconfig> \
  --versions versions.json \
  --excluded "INGRESS,NAMESPACE,OSS,StorageClass,NODE,GPU,CONNECTIVITY"

L’exclusion d’une case ne supprime pas l’exigence sous-jacente; la propriété est toujours requise pour une installation correcte. Le tableau suivant décrit ce que chaque vérification exclue vérifie, l'accès au niveau du cluster dont elle a besoin et exactement ce qu'un administrateur de cluster doit confirmer comme hors-ligne, à l'aide d'un kubeconfig avec des privilèges d'administrateur du cluster.

Jeton exclu	Accès à l’échelle du cluster requis	Ce que la vérification vérifie
INGRESS	nodes [list]	Que le nom de domaine complet d'Automation Suite soit accessible via HTTPS via la passerelle d'entrée Istio, depuis le cluster, sur chaque nœud.
NAMESPACE	namespaces [get, list]	Que les <argocd>, le programme d'installation et les espaces de noms <uipath> existent et que <uipath> porte les libellés d'injection requis.
OSS	customresourcedefinitions [list]	Que les composants « Apps» que vous avez exclus de l'installation (par exemple, Istio et OPA Gatekeeper) soient présents et dans une version prise en charge.
StorageClass	storageclasses [get], nodes [list]	Que la classe de stockage dans input.json existe et puisse réellement enregistrer et monter un volume sur vos nœuds de travail (la vérification crée un ensemble d’états de test et attend la liaison et le montage du volume).
NODE	nodes [list, get], mesures de nœud	Que chaque nœud de travail réponde aux exigences minimales de CPU et de RAM et ne soit pas surutilisé au niveau du CPU, de la mémoire ou du nombre de pods.
GPU	nodes [list]	Qu'il existe suffisamment de nœuds labellisés GPU avec des GPU disponibles pour les produits GPU activés, avec un nombre minimum de nœuds en fonction des produits GPU activés.
CONNECTIVITY	securitycontextconstraints use le hostnetwork-v2; roles [create] pour les pods de test du réseau hôte	Que les pods puissent communiquer entre les nœuds sur le réseau de superposition (par IP de pod), via une ClusterIP Service et en utilisant hostNetwork.

Valider manuellement les vérifications exclues

Après avoir exclu les vérifications, un administrateur de cluster doit valider manuellement chaque exigence exclue, à l'aide d'un kubeconfig avec des privilèges d'administrateur de cluster:

• INGRESS: confirmez que tous les nœuds de travail sont Ready et que les chemins d'entrée existent:

  kubectl get nodes -o wide
  oc get routes -n <istio-system>
  curl -sko /dev/null -w "%{http_code}\n" https://<fqdn>
  

  La vérification INGRESS du programme d'installation sonde le nom de domaine complet de l'intérieur du cluster, sur chaque nœud, et traite la passerelle comme accessible lorsqu'elle répond (y compris avec un 404 ou un 503 sur OpenShift), car aucun backend ne sert le nom de domaine complet avant Automation Suite est installé. Ne vous attendez pas à un 200 à ce stade. Étant donné que la commande curl ci-dessus s'exécute à partir de votre station de travail, elle peut à la place imprimer 000 lorsque le nom de domaine complet ne résout pas ou n'achemine pas encore depuis votre machine; qui reflète l’accessibilité côté client et n’est pas en lui-même un problème de cluster. Les signaux qui comptent ici sont que les nœuds de travail sont Ready et que les chemins d'entrée existent.

• NAMESPACE: confirmez que les espaces de noms existent et que <uipath> porte les libellés d'injection requis:

  kubectl get ns <argocd> <uipath>
  kubectl get ns <uipath> --show-labels
  

  La sortie doit afficher istio-injection=enabled et uipath-injection=enabled.

• OSS: confirmez que les CRD sont présents, qu'Istio est à une version prise en charge et que la passerelle configurée s'exécute:

  kubectl get crd | grep -E 'istio.io|gatekeeper'
  istioctl version
  oc get pods -l istio=ingressgateway -n <istio-system>
  

  Confirmez que la version d’Istio est 1.14.0 ou ultérieure et que le gateway_selector dans input.json correspond à la passerelle en cours d’exécution.

• StorageClass: confirmez que la classe de stockage existe:

  kubectl get sc <name>
  

  Créez ensuite un PersistentVolumeClaim de 1 Gio et un pod qui le montera. Confirmez que le PVC atteint Bound et que le pod démarre sur un nœud de travail - cela applique la même compatibilité de zone et de topologie que la vérification couvre.

• NODE: confirmer la capacité et l'utilisation attribuables par nœud:

  kubectl get nodes -o custom-columns=NAME:.metadata.name,CPU:.status.allocatable.cpu,MEM:.status.allocatable.memory
  kubectl top nodes
  

  Chaque nœud doit afficher au moins 8 processeurs et 16 Gio attribuables, avec une utilisation du processeur et de la mémoire inférieure à 80 %. Vérifiez par rapport au dimensionnement des nœuds dans le cluster et les nœuds Kubernetes.

• GPU: confirmez que le nombre de nœuds GPU répond à l'exigence (5 nœuds pour les projets modernes Document Understanding; sinon, aucun minimum) et que des GPU attribuables sont disponibles sur ces nœuds:

  kubectl get nodes -l nvidia.com/gpu.present=true
  kubectl get nodes -o custom-columns=NAME:.metadata.name,GPU:.status.allocatable.'nvidia\.com/gpu'
  

  La sortie de la deuxième commande doit afficher une valeur supérieure à 0. Pour les exigences de dimensionnement du GPU, reportez-vous à Cluster et nœuds Kubernetes.

• CONNECTIVITY: l'option la plus fiable consiste pour un administrateur de cluster à exécuter uniquement cette vérification avec un kubeconfig d'administrateur:

  uipathctl prereq run input.json --versions versions.json --included CONNECTIVITY
  

  Vous pouvez également planifier deux pods sur des nœuds de travail différents et confirmer qu'ils peuvent se joindre par IP de pod et via une ClusterIP Service.

Important :

L’exclusion de ces vérifications ne supprime pas les exigences sous-jacentes; le comportement correspondant est toujours requis au moment de l’exécution. Validez chaque propriété dans le tableau ci-dessus avant de procéder à l'installation.