- Vue d'ensemble (Overview)
- Prérequis
- Installation
- Questions et réponses : modèles de déploiement
- Configuration des machines
- Configuration du magasin d'objets externe
- Configurer l'équilibreur de charge
- Configuration du DNS
- Configuration de Microsoft SQL Server
- Configuration des certificats
- Installation de production en ligne multi-nœuds compatible haute disponibilité
- Installation de production hors ligne multi-nœuds compatible haute disponibilité
- Téléchargement des packages d'installation
- install-uipath.sh parameters
- Activation du module complémentaire Redis High Availability Add-on pour le cluster
- Fichier de configuration de Document Understanding
- Ajout d'un nœud d'agent dédié avec prise en charge GPU
- Connexion de l'application Task Mining
- Ajout d'un nœud d'agent dédié pour Task Mining
- Ajout d'un nœud d'agent dédié pour les Automation Suite Robots
- Post-installation
- Accéder à Automation Suite
- Gestion des certificats
- Redimensionner le PVC
- Mise à jour des chaînes de connexion SQL
- Administration du cluster
- Surveillance et alerte
- Migration et mise à niveau
- Chemins de mise à niveau Automation Suite
- Automatisée : mise à niveau en ligne
- Automatisée : mise à niveau hors ligne
- Manuel : mise à niveau en ligne
- Manuel : mise à niveau hors ligne
- Annulation en cas d'erreur
- Migration d'un disque physique Longhorn vers LVM
- Migration de Canal vers Cilium CNI
- Rétrogradation de Ceph de la version 16.2.6 à la version 15.2.9
- Options de migration :
- É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 de produits 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é
- Step 6: Migrating standalone Insights
- Étape 7 : suppression du locataire par défaut
- B) Migration à locataire unique
- Configuration spécifique au produit
- Bonnes pratiques et maintenance
- Résolution des problèmes
- Comment résoudre les problèmes des services lors de l'installation
- Comment désinstaller le cluster
- Comment nettoyer les artefacts hors ligne pour améliorer l'espace disque
- Comment effacer les données Redis
- Comment activer la journalisation Istio
- Comment nettoyer manuellement les journaux
- Comment nettoyer les anciens journaux stockés dans le bundle sf-logs
- Comment désactiver les journaux de diffusion pour AI Center
- Comment déboguer les installations d'Automation Suite ayant échoué
- Comment supprimer des images de l’ancien programme d’installation après la mise à niveau
- Comment nettoyer automatiquement les instantanés Longhorn
- Comment désactiver le déchargement de la somme de contrôle de la carte réseau
- Impossible d'exécuter une installation hors ligne sur le système d'exploitation RHEL 8.4
- Erreur lors du téléchargement du bundle
- L'installation hors ligne échoue en raison d'un fichier binaire manquant
- Problème de certificat dans l'installation hors ligne
- La première installation échoue lors de la configuration de Longhorn
- Erreur de validation de la chaîne de connexion SQL
- Échec de la vérification des prérequis pour le module selinux iscsid
- Disque Azure non marqué comme SSD
- Échec après la mise à jour du certificat
- L'antivirus provoque des problèmes d'installation
- Automation Suite ne fonctionne pas après la mise à niveau du système d'exploitation
- Automation Suite requiert que backlog_wait_time soit défini sur 0
- Volume impossible à monter car il n'est pas prêt pour les charges de travail
- Impossible de lancer Automation Hub et Apps avec la configuration proxy
- Échec du chargement ou du téléchargement des données dans l'objectstore
- Le redimensionnement de la PVC ne répare pas Ceph
- Échec du redimensionnement du PVC
- Échec du redimensionnement du PVC objectstore
- Rook Ceph ou pod Looker bloqué dans l'état Init
- Erreur de pièce jointe du volume Ensembles d'états.
- Échec de la création de volumes persistants
- Correctif de récupération du stockage
- La sauvegarde a échoué en raison de l’erreur TropInstantanés (TooManySnapshots)
- Toutes les répliques Longhorn sont défaillantes
- Définition d'un délai d'expiration pour les portails de gestion
- Mettre à jour les connexions du répertoire sous-jacent
- L'authentification ne fonctionne pas après la migration
- Kinit : Impossible de trouver le KDC pour le domaine <AD Domain> lors de l'obtention des informations d'identification initiales
- Kinit : Keytab ne contient aucune clé appropriée pour *** lors de l'obtention des informations d'identification initiales
- L'opération GSSAPI a échoué en raison d'un code de statut non valide
- Alarme reçue pour l'échec de la tâche Kerberos-tgt-update
- Fournisseur SSPI : serveur introuvable dans la base de données Kerberos
- La connexion a échoué pour l'utilisateur AD en raison d'un compte désactivé
- Échec de connexion à ArgoCD
- Impossible d'obtenir l'image du bac à sable
- Les pods ne s'affichent pas dans l'interface utilisateur ArgoCD
- Échec de la sonde Redis
- Le serveur RKE2 ne démarre pas
- Secret introuvable dans l'espace de noms UiPath
- ArgoCD passe à l'état Progression (Progressing) après la première installation
- Incohérence inattendue ; exécuter fsck manuellement
- Pods MongoDB en mode CrashLoopBackOff ou enregistrement PVC en attente après suppression
- Le pod MongoDB ne parvient pas à mettre à niveau la version 4.4.4-ent vers la version 5.0.7-ent
- Services défectueux après la restauration ou l'annulation du cluster
- Pods bloqués dans Init:0/X
- Prometheus dans l'état CrashloopBackoff avec erreur de mémoire insuffisante (OOM)
- Métriques Ceph-rook manquants dans les tableaux de bord de surveillance
- Document Understanding n'est pas affiché sur la barre de gauche d'Automation Suite
- État Échec (Failed) lors de la création d'une session de labellisation des données
- État Échec (Failed) lors de la tentative de déploiement d'une compétence ML
- La tâche de migration échoue dans ArgoCD
- La reconnaissance de l'écriture manuscrite avec l'Extracteur de formulaires intelligents (Intelligent Form Extractor) ne fonctionne pas
- Utilisation de l'outil de diagnostic d'Automation Suite
- Utilisation de l'outil Automation Suite Support Bundle
- Explorer les journaux
Gestion des certificats
Le bundle d'installation fournit un outil de gestion de cluster qui vous permet de mettre à jour les certificats après l'installation. Pour accéder à l'outil, accédez à l'emplacement du bundle d'installation :
cd /opt/UiPathAutomationSuite/
cd /opt/UiPathAutomationSuite/
Pour générer la CSR et la clé privée, exécutez la commande suivante :
# copy the machine openssl configuration locally
cp /etc/pki/tls/openssl.cnf ./openssl.tmp.cnf
# Replace the [AUTOMATION_SUITE_FQDN] value. For example, "automationsuite.corp.com"
AS_FQDN=[AUTOMATION_SUITE_FQDN]
cat >> ./openssl.tmp.cnf <<EOF
[SAN]
subjectAltName=DNS:$AS_FQDN,DNS:alm.$AS_FQDN,DNS:monitoring.$AS_FQDN,DNS:registry.$AS_FQDN,DNS:objectstore.$AS_FQDN,DNS:insights.$AS_FQDN
EOF
# create the certificate request
openssl req -new -sha256 -newkey rsa:2048 -nodes -keyout server.key -subj "/C=xx/ST=xx/O=xx/OU=xx/CN=$AS_FQDN" -reqexts SAN -config openssl.tmp.cnf -out ${AS_FQDN}.csr
# copy the machine openssl configuration locally
cp /etc/pki/tls/openssl.cnf ./openssl.tmp.cnf
# Replace the [AUTOMATION_SUITE_FQDN] value. For example, "automationsuite.corp.com"
AS_FQDN=[AUTOMATION_SUITE_FQDN]
cat >> ./openssl.tmp.cnf <<EOF
[SAN]
subjectAltName=DNS:$AS_FQDN,DNS:alm.$AS_FQDN,DNS:monitoring.$AS_FQDN,DNS:registry.$AS_FQDN,DNS:objectstore.$AS_FQDN,DNS:insights.$AS_FQDN
EOF
# create the certificate request
openssl req -new -sha256 -newkey rsa:2048 -nodes -keyout server.key -subj "/C=xx/ST=xx/O=xx/OU=xx/CN=$AS_FQDN" -reqexts SAN -config openssl.tmp.cnf -out ${AS_FQDN}.csr
Votre équipe informatique utilise les valeurs obtenues pour générer un certificat signé. La clé privée générée reste locale.
Pour afficher plus d'informations sur les certificats de serveur, exécutez la commande suivante :
sudo ./configureUiPathAS.sh tls-cert --help
sudo ./configureUiPathAS.sh tls-cert --help
Sortie :
************************************************************************************
Manage cluster tls and server certificate
Usage:
configureUiPathAS.sh tls-cert [command]
configureUiPathAS.sh tls-cert [flags]
Available Commands:
update Update the tls / server certificate
get Get the tls / server certificate
Flags:
-h|--help Display help
************************************************************************************
************************************************************************************
Manage cluster tls and server certificate
Usage:
configureUiPathAS.sh tls-cert [command]
configureUiPathAS.sh tls-cert [flags]
Available Commands:
update Update the tls / server certificate
get Get the tls / server certificate
Flags:
-h|--help Display help
************************************************************************************
./configureUiPathAS.sh tls-cert
.
Installation en ligne : Comment trouver le certificat du serveur
istio-ingressgateway-certs
dans l'espace de noms istio-system
.
Consultez les fichiers de certificat dans la liste suivante :
- Le certificat TLS du serveur est stocké en tant que
tls.crt
- Clé privée TLS du serveur en tant que
tls.key
- Le bundle CA est stocké en tant que
ca.crt
Vous pouvez vérifier les secrets à l'aide de la commande suivante :
kubectl -n istio-system get secrets istio-ingressgateway-certs -o yaml
kubectl -n istio-system get secrets istio-ingressgateway-certs -o yaml
Certificates are also stored in the UiPath namespace. This is applicable to every UiPath® product that needs certificate information to trust incoming calls. For details, see Understanding the container architecture related to certificates.
Installation hors ligne : comment trouver le certificat du serveur
rootCA.crt
et tls.crt
: ArgoCD et le registre Docker. Les certificats sont ensuite stockés dans les espaces de noms Docker et ArgoCD.
Vous pouvez vérifier les secrets à l'aide de la commande suivante :
# For docker registry
kubectl -n docker-registry get secrets docker-registry-tls -o yaml
# For Argocd
argocd cert list --cert-type https
# For docker registry
kubectl -n docker-registry get secrets docker-registry-tls -o yaml
# For Argocd
argocd cert list --cert-type https
Comment mettre à jour les certificats de serveur
Pour déchiffrer la clé de certificat, exécutez la commande suivante :
# replace /path/to/encrypted/cert/key to absolute file path of key
# replace /path/to/decrypt/cert/key to store decrypt key
# Once prompted, please entry the passphrase or password to decrypt the key
openssl rsa -in /path/to/encrypted/cert/key -out /path/to/decrypt/cert/key
# replace /path/to/encrypted/cert/key to absolute file path of key
# replace /path/to/decrypt/cert/key to store decrypt key
# Once prompted, please entry the passphrase or password to decrypt the key
openssl rsa -in /path/to/encrypted/cert/key -out /path/to/decrypt/cert/key
configureUiPathAS.sh
pour mettre à jour le certificat comme indiqué ci-dessous. Vous avez besoin du chemin d'accès à chacun des trois fichiers de certificat. Tout le fichier de certificat doit être au format PEM
.
- Ensemble de l'autorité de certification (Certificate Authority Bundle) : ce bundle ne doit contenir que les certificats de chaîne utilisés pour signer le certificat du serveur TLS. La limite de la chaîne est de neuf certificats.
- Certificat de serveur - Certificat de serveur public
-
Clé privée - Clé privée pour le certificat du serveur
sudo ./configureUiPathAS.sh tls-cert update --ca-cert-file /path/to/cacert --tls-cert-file /path/to/tlscert --tls-key-file /path/to/tlskey
sudo ./configureUiPathAS.sh tls-cert update --ca-cert-file /path/to/cacert --tls-cert-file /path/to/tlscert --tls-key-file /path/to/tlskey
/directory/path/to/store/certificate
.
Pour imprimer les fichiers de certificat, exécutez la commande suivante en spécifiant le répertoire dans lequel les certificats sont stockés.
sudo ./configureUiPathAS.sh tls-cert get --outpath /directory/path/to/store/certificate
sudo ./configureUiPathAS.sh tls-cert get --outpath /directory/path/to/store/certificate
Vous êtes responsable de vous assurer que les certificats générés sont approuvés.
Pour ajouter le certificat au magasin d'approbations de machine virtuelle hôte, exécutez les commandes suivantes :
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust
Pour afficher plus d'informations sur les certificats CA supplémentaires, exécutez la commande suivante :
./configureUiPathAS.sh additional-ca-certs --help
./configureUiPathAS.sh additional-ca-certs --help
Sortie :
***************************************************************************************
Manage additional CA certificates, this can be used to add sql server CA
Usage:
configureUiPathAS.sh additional-ca-certs [command]
configureUiPathAS.sh additional-ca-certs [flags]
Available Commands:
update Update the additional trusted CA certificates.
get Get the additional trusted CA certificates
Flags:
-h|--help Display help
***************************************************************************************
***************************************************************************************
Manage additional CA certificates, this can be used to add sql server CA
Usage:
configureUiPathAS.sh additional-ca-certs [command]
configureUiPathAS.sh additional-ca-certs [flags]
Available Commands:
update Update the additional trusted CA certificates.
get Get the additional trusted CA certificates
Flags:
-h|--help Display help
***************************************************************************************
./configureUiPathAS.sh
additional-ca-certs
.
Cette commande vous aide à mettre à jour ou à remplacer les certificats CA configurés existants.
./configureUiPathAS.sh additional-ca-certs update --ca-cert-file /path/to/ca/certs
./configureUiPathAS.sh additional-ca-certs update --ca-cert-file /path/to/ca/certs
--replace
à la fin.
.pem
valide et peut contenir plusieurs certificats.
Pour télécharger les certificats CA déjà configurés, exécutez la commande suivante :
./configureUiPathAS.sh additional-ca-certs get --outpath /path/to/download/certs
./configureUiPathAS.sh additional-ca-certs get --outpath /path/to/download/certs
Vous êtes responsable de vous assurer que les certificats générés sont approuvés.
Pour ajouter le certificat au magasin d'approbations de machine virtuelle hôte, exécutez les commandes suivantes :
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust
Pour afficher plus d'informations sur les certificats de signature de jeton d'identité, exécutez la commande suivante :
sudo ./configureUiPathAS.sh identity token-cert --help
sudo ./configureUiPathAS.sh identity token-cert --help
Sortie :
************************************************************************************
Manage Identity token signing certificate
Usage:
configureUiPathAS.sh identity token-cert [command]
configureUiPathAS.sh identity token-cert [flags]
Available Commands:
update Update secondary certificate to signing
the authentication token
rotate Switch secondary certificate as a primary
token signing certificate
get Get token signing certificate
Flags:
-h|--help Display help
************************************************************************************
************************************************************************************
Manage Identity token signing certificate
Usage:
configureUiPathAS.sh identity token-cert [command]
configureUiPathAS.sh identity token-cert [flags]
Available Commands:
update Update secondary certificate to signing
the authentication token
rotate Switch secondary certificate as a primary
token signing certificate
get Get token signing certificate
Flags:
-h|--help Display help
************************************************************************************
./configureUiPathAS.sh identity
token-cert
.
Pour télécharger le nouveau certificat afin de signer le jeton, exécutez la commande suivante :
La commande suivante ne remplace pas le certificat de signature de jeton existant.
.pem
.
sudo ./configureUiPathAS.sh identity token-cert update --cert-file-path /path/to/cert --cert-key-file-path /path/to/certkey
sudo ./configureUiPathAS.sh identity token-cert update --cert-file-path /path/to/cert --cert-key-file-path /path/to/certkey
Pour faire pivoter ou remplacer l'ancien certificat par le nouveau, exécutez la commande suivante :
sudo ./configureUiPathAS.sh identity token-cert rotate
sudo ./configureUiPathAS.sh identity token-cert rotate
Il devrait y avoir un délai d'environ 24 à 48 heures entre la mise à jour du certificat et sa rotation.
Nous avons besoin de ce délai pour continuer à prendre en charge l'authentification pour le jeton mis en cache signé par l'ancien certificat.
Si vous effectuez la rotation du certificat trop tôt avant l'expiration du jeton de cache, cela peut entraîner des temps d'arrêt. Et vous devrez peut-être redémarrer tous vos robots.
Pour effectuer une mise à jour d'urgence du certificat, procédez comme suit :
Exécutez la commande suivante pour télécharger le certificat de signature de jeton actuel :
sudo ./configureUiPathAS.sh identity token-cert get --outpath /directory/path/to/store/certificate
sudo ./configureUiPathAS.sh identity token-cert get --outpath /directory/path/to/store/certificate
Par défaut, les certificats RKE2 expirent sous 12 mois. Au cours des 90 jours précédant leur date d’expiration, les certificats font l’objet d’une rotation lorsque vous redémarrez RKE2.
Pour plus de détails, consultez la section RKE2 - Options avancées - Rotation du certificat.
# Directory path to check
if [[ -d "/var/lib/rancher/rke2/server/tls" ]];
then
dir="/var/lib/rancher/rke2/server/tls"
else
dir="/var/lib/rancher/rke2/agent/tls"
fi
# Loop through each .crt file in the directory
for file in "$dir"/*.crt;
# Extract the expiry date from the certificate
do
expiry=$(openssl x509 -enddate -noout -in "$file" | cut -d= -f 2-)
# Get the file name without the path
filename=$(basename "$file")
# Print the filename and expiry date in a pretty format
printf "%-30s %s\n" "$filename:" "$expiry"
done
# Directory path to check
if [[ -d "/var/lib/rancher/rke2/server/tls" ]];
then
dir="/var/lib/rancher/rke2/server/tls"
else
dir="/var/lib/rancher/rke2/agent/tls"
fi
# Loop through each .crt file in the directory
for file in "$dir"/*.crt;
# Extract the expiry date from the certificate
do
expiry=$(openssl x509 -enddate -noout -in "$file" | cut -d= -f 2-)
# Get the file name without the path
filename=$(basename "$file")
# Print the filename and expiry date in a pretty format
printf "%-30s %s\n" "$filename:" "$expiry"
done
La sortie que vous obtenez doit être similaire à celle illustrée dans l’image suivante :
Pour effectuer une rotation des certificats RKE2, vous devez d’abord exécuter une série d’actions sur les nœuds de serveur, puis poursuivre certaines étapes sur les nœuds d’agent.
- Arrêtez le serveur RKE2 :
systemctl stop rke2-server.service
systemctl stop rke2-server.service - Effacez tous les processus RKE2 restants :
rke2-killall.sh
rke2-killall.sh - Supprimez le fichier
dynamic-cert.json
situé dans/var/lib/rancher/rke2/server/tls/
. - Redémarrez le serveur RKE2 :
systemctl start rke2-server.service
systemctl start rke2-server.serviceRemarque : si le cluster comporte plusieurs nœuds de serveur, les étapes 1 à 4 peuvent ne pas s’exécuter entièrement car etcd peut ne pas permettre de finaliser l’élection du responsable. Si cela se produit, répétez les étapes 1 à 4 sur d’autres nœuds de serveur. - Supprimez la clé secrète
rke2-serving
de l’espace de nomskube-system
:kubectl delete secret -n kube-system rke2-serving
kubectl delete secret -n kube-system rke2-servingRemarque :Dans un déploiement multi-nœuds, vous ne pourrez peut-être pas exécuter les commandeskubectl
tant que vous n’aurez pas effectué les quatre premières opérations sur le nombre nécessaire de nœuds de serveur. Cela permet de répondre à l’exigence de quorum etcd. Vous pouvez supprimer la clé secrèterke2-serving
immédiatement après le démarrage du serveur RKE2.
kubectl get nodes
. Lorsque vos nœuds de serveur sont prêts, vous pouvez passer aux nœuds d’agent pour régénérer les certificats.
Effectuez les étapes suivantes sur les nœuds d’agent :
- Arrêtez le serveur RKE2 :
systemctl stop rke2-agent.service
systemctl stop rke2-agent.service - Effacez tous les processus RKE2 restants :
rke2-killall.sh
rke2-killall.sh - Redémarrez le serveur RKE2 :
systemctl start rke2-agent.service
systemctl start rke2-agent.service
- Génération d'une demande de signature de certificat (CSR) et d'une clé privée
- Gestion des certificats de serveur
- Mise à jour du certificat du serveur
- Accéder au certificat TLS
- Ajout du certificat CA au magasin d'approbations hôte
- Gestion des certificats CA supplémentaires
- Mise à jour des certificats CA
- Accéder aux certificats CA
- Ajout du certificat CA au magasin d'approbations hôte
- Gestion des certificats de signature de jeton d'identité
- Mise à jour du certificat
- Rotation du certificat
- Rotation des certificats d'urgence
- Accéder au certificat
- Gestion des certificats Rancher
- Vérification de la date d’expiration du certificat RKE2
- Rotation du certificat RKE2