- Vue d'ensemble (Overview)
- Prérequis
- Installation
- Questions et réponses : modèles de déploiement
- 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
- Post-installation
- Administration du cluster
- Surveillance et alerte
- Migration et mise à niveau
- Mode d'évaluation à nœud unique en ligne
- Mode d'évaluation à nœud unique hors ligne
- Mode de production en ligne multi-nœuds compatible haute disponibilité
- Mode de production hors ligne multi-nœuds compatible haute disponibilité
- Migration d'un disque physique Longhorn vers LVM
- Rétrogradation de Ceph de la version 16.2.6 à la version 15.2.9
- Options de migration :
- 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 désactiver TLS 1.0 et 1.1
- Comment activer la journalisation Istio
- Comment nettoyer manuellement les journaux
- Comment nettoyer les anciens journaux stockés dans le compartiment sf-logs
- Comment déboguer les installations d'Automation Suite ayant échoué
- Comment désactiver le déchargement de la somme de contrôle txt
- 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
- Erreur de validation de la chaîne de connexion SQL
- Échec après la mise à jour du certificat
- Automation Suite requiert que Backlog_wait_time soit défini sur 1
- Impossible de se connecter après la migration
- Définition d'un délai d'expiration pour les portails de gestion
- Mettre à jour les connexions du répertoire sous-jacent
- 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 de l'erreur suivante : un code d'état non valide a été fourni (les informations d'identification du client ont été révoquées).
- La connexion a échoué pour l'utilisateur <ADDOMAIN><aduser>.Raison : Le compte est désactivé.
- Alarme reçue pour l'échec de la tâche Kerberos-tgt-update
- Fournisseur SSPI : serveur introuvable dans la base de données Kerberos
- 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
- L’opérateur d’auto-guérison et le référentiel Sf-k8-utils manquants
- MongoDB ou applications métier dégradées après la restauration du cluster
- Services défectueux après la restauration ou la restauration du cluster
- 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 du pack d'assistance Automation Suite
- Explorer les journaux
Étapes pré-migration
Pour garantir la réussite de la migration d'une installation autonome de plate-forme vers Automation Suite, assurez-vous de suivre les étapes décrites dans les sections suivantes. Les étapes de pré-migration sont obligatoires.
Étape 1 : enregistrer les données de configuration de Identity Server
Assurez-vous d'enregistrer les données de configuration Identity Server suivantes :
Nom d'utilisateur et mot de passe de l'administrateur de l'hôte
Enregistrez le nom d'utilisateur et le mot de passe de l'administrateur de l'hôte.
Certificats de signature de jetons
Identity Server utilise des certificats .pfx pour signer les jetons OAuth. Si vous utilisez vos propres jetons dans le déploiement autonome, vous devez les convertir en .pfx et les mettre à jour dans le ou les clés secrètes correspondantes du cluster Automation Suite.
Vous pouvez également effectuer cette étape lors de la configuration initiale du cluster si vous décidez d'utiliser les mêmes certificats de signature dans le déploiement d'Automation Suite : kubectl edit secret identity-token-signing-certificate -n uipath.
Certificats SAML
La configuration du fournisseur d'identité SAML utilise des magasins de certificats pour lire les certificats client et serveur. Vous devez mettre à jour tout certificat précédemment utilisé dans le déploiement autonome dans la ou les clés secrètes correspondante(s) du cluster Automation Suite : kubectl edit secret identity-saml-certificates -n uipath.
Paramètres d'application de Identity Server
Enregistrez les paramètres d'application Identity Server suivants :
DatabaseProtectionSettingsà partir deappsetting.production.jsondans le dossier/identitydu déploiement autonome.- Le paramètre
DatabaseProtectionSettings.EncryptionKey2021est utilisé pour chiffrer les données sensibles au repos. Vous devez répliquer cette valeur dans le déploiement d'Automation Suite durant la phase de post-migration :kubectl edit secret identity-generated-secrets -n uipath.
Certificats d'exportation
Si vous utilisez Azure Key Vault ou Windows Certificate Store, exportez les certificats au format .pfx.
Étape 2 : Créer des paires organisation-locataire
Pour chaque locataire du déploiement autonome, créez une paire organisation-locataire dans l'environnement Automation Suite.
Exemple : si dans une installation d'Orchestrator autonome, vous avez un locataire nommé Tenant1, dans Automation Suite, vous devez créer une organisation Tenant1 et un locataire au sein de cette organisation également nommé Tenant1. Une fois que vous avez créé le locataire, assurez-vous que le service Orchestrator est activé pour ce locataire.
Un locataire 'Default' est automatiquement créé pour chaque organisation. Vous n'êtes pas obligé de le supprimer, mais vous devez ajouter un autre locataire nommé exactement comme votre organisation. Par exemple, dans l'exemple précédent, lors de la création d'une organisation Tenant1, vous finissiez par avoir également un locataire nommé Default dans cette organisation. La dernière étape consiste à ajouter un autre locataire appelé Tenant1 à cette organisation. Vous pouvez ensuite passer à la création de la prochaine paire organisation-locataire.
Étape 3 : Enregistrement des chaînes de connexion et des noms de locataires
Enregistrez les informations suivantes pour une utilisation ultérieure :
- La chaîne de connexion à la base de données Orchestrator dans le déploiement autonome ;
- La chaîne de connexion à la base de données AutomationSuite_Platform dans le déploiement Automation Suite ;
- Le ou les noms de locataire du déploiement autonome ; vous pouvez le rechercher dans l'interface utilisateur d'Orchestrator ou à l'aide de la colonne
TenancyNamedans la table des locataires d'Orchestrator ; - Chaîne de connexion Insights.
Étape 4 : Préparation d'Orchestrator
Présentation de la migration
Pour migrer Orchestrator d'une version autonome vers Automation Suite, vous devez rassembler les paramètres et divers fichiers de l'installation autonome et les appliquer à l'installation d'Automation Suite.
Bien qu'une partie seulement des paramètres soit configurable au moment de l'installation, tous doivent être disponibles pour la configuration post-installation.
- Pour configurer les paramètres au moment de l'installation, ajoutez-les dans le fichier
cluster_config.json; - La mise à jour des paramètres une fois l'installation terminée dépend de l'étendue du paramètre et de l'existence ou non d'une fonctionnalité destinée à la configuration dans les paramètres des applications.
You can store custom files that are needed inside the Orchestrator pods, such as assemblies or other storage files, in the built-in Ceph object store. The storage files are stored in a bucket for each tenant. The plugins are stored in the uipath bucket under orchestrator/plugins/nlog or orchestrator/plugins/securestore.
Vous pouvez ajouter une configuration personnalisée comme suit :
- en modifiant les paramètres de l'application dans ArgoCD (paramètres prioritaires) ;
- en modifiant les fichiers dans Kubernetes ConfigMap
orchestrator-customconfigà partir de l'espace de nomsuipath.
Préparation de web.config
La plupart des paramètres web.config n'ont pas d'équivalent ou sont implémentés dans Automation Suite à l'aide d'autres mécanismes.
Les options que vous devez configurer sont les suivantes :
security.requestFiltering.requestLimits.maxAllowedContentLength
security.requestFiltering.requestLimits.maxAllowedContentLength
Notez la valeur de ce paramètre pour une utilisation ultérieure. Décidez si vous devez le configurer dans Automation Suite. Sa valeur par défaut est de 300 Mo.
Préparation des paramètres d'application
Vous devrez peut-être migrer les modifications personnalisées apportées dans la section appSettings ou secureAppSettings du fichier de configuration UiPath.Orchestrator.dll.config. Vous pouvez ajouter des appSettings et secureAppSettings personnalisés à la carte de configuration orchestrator-customconfig.
Dans la section appSettings du fichier de configuration UiPath.Orchestrator.dll.config, identifiez tous les paramètres modifiés ou ajoutés. Enregistrez ces paramètres dans un fichier .json, afin qu'ils soient disponibles dans les étapes ultérieures.
Vous pouvez déchiffrer n'importe quelle section de configuration d'application protégée avec l'option de configuration protégée de l'interface en ligne de commande d'Orchestrator. Il vous suffit d'utiliser les paramètres que vous avez modifiés ou ajoutés et qui sont toujours pertinents dans Automation Suite.
You can create the appsettings.json file as shown in the following example:
{
"ExampleSetting.Enabled": true,
"ExampleSetting.Type": "BasicExample",
"ExampleSetting.Count": 3
}
{
"ExampleSetting.Enabled": true,
"ExampleSetting.Type": "BasicExample",
"ExampleSetting.Count": 3
}
Préparation du stockage
Decide what you need for the storage migration and if your current storage configuration stays the same or if you would instead let Automation Suite manage the storage for you. Automation Suite offers the option to store the blobs in Ceph, which can be used in all Orchestrator pods. In the case of a migration, you must copy the existing files to the current blob storage.
Si vous utilisez un stockage de type FileSystem avec un dossier local, copiez les données du dossier de stockage vers un dossier sur un nœud à partir d'Automation Suite. Ensuite, à l'aide d'un utilitaire S3 tel que s3cmd, vous pouvez copier les données vers Orchestrator. Si vous utilisez Ceph, aucune autre configuration n'est requise, car il s'agit de l'option par défaut.
Si vous souhaitez utiliser le système de fichiers avec un partage réseau Windows, vous devez configurer le stockage dans l'application ArgoCD Orchestrator. Récupérez les données de connexion au partage réseau Windows depuis votre configuration Orchestrator actuelle à partir de la clé Storage.Location. Étant donné qu'Automation Suite s'exécute sur des machines Linux, vous ne pouvez pas compter sur l'authentification intégrée pour accéder au partage réseau, vous avez donc besoin des informations d'identification d'un compte qui peut y accéder.
Actuellement, seuls les partages réseau qui utilisent le protocole SMB sont pris en charge. Les partages réseau qui utilisent NFS ne sont pas pris en charge.
Si vous utilisez des options de stockage à distance telles qu'Azure, AWS ou Minio, assurez-vous d'ajouter les paramètres Storage.Location et Storage.Type au appsettings.json.
Préparation de NLog
Vous pouvez effectuer les personnalisations suivantes sur NLog :
- modifier les cibles existantes
- ajouter de nouvelles cibles
- ajouter des extensions NLog
Passez en revue la section NLog du fichier de configuration et créez la configuration personnalisée NLog. Pour activer le stockage des journaux d'évènements du robot dans Elasticsearch, vous pouvez fournir le nom d'utilisateur, le mot de passe et l'URI en tant que paramètres Automation Suite, et la cible est configurée automatiquement. Pour activer les scénarios personnalisés pour les journaux de robot, vous devez configurer la cible manuellement.
Si des extensions NLog sont nécessaires, créez un dossier contenant toutes les extensions et leurs dépendances.
For example, the folder could be named nlogextensions. By default, Orchestrator loads the following extensions, so you do not need to include them in the folder or the NLog configuration:
NLog.Targets.ElasticSearch
UiPath.Orchestrator.Logs.Elasticsearch
Microsoft.ApplicationInsights.NLogTarget
NLog.Extensions.AzureEventHub
NLog.Targets.ElasticSearch
UiPath.Orchestrator.Logs.Elasticsearch
Microsoft.ApplicationInsights.NLogTarget
NLog.Extensions.AzureEventHub
Créez le fichier nlog.custom.config contenant les sections standards : extensions, cibles et règles.
La section extensions est un tableau d'éléments qui spécifient les assemblys d'extension à l'aide de assemblyFile et le chemin de l'assembly par rapport au dossier nlogextensions.
Orchestrator définit les cibles et les règles NLog qui sont configurées ou partiellement configurées pour les cas d'utilisation courants. Lorsque la personnalisation est nécessaire pour ces cibles, il vous suffit d'inclure les propriétés modifiées dans la configuration NLog. Vous ne pouvez pas supprimer les propriétés existantes de la configuration prédéfinie ; vous pouvez cependant les modifier. Dans le pod Orchestrator, les cibles incluses par défaut sont définies à l'emplacement /opt/app-root/app/nlog.config.json.
Example: nlog.custom.config file that writes logs to Azure Blob:
{ "NLog": {
"extensions": [
{ "assemblyFile": "NLog.Extensions.AzureBlobStorage.dll" }
],
"targets": {
"azureBlob": {
"type": "AzureBlobStorage",
"connectionString": "DefaultEndpointsProtocol=https;AccountName=test;AccountKey=key;EndpointSuffix=core.windows.net",
"container": "orchestratorlogs",
"blobName": "${date:format=yyyy-MM-dd hh.mm}",
"layout": {
"type": "JsonLayout",
"includeAllProperties": true,
"Attributes": [
{"name": "ts","layout": "${longdate}"},
{"name": "level","layout": "${level:upperCase=true}"},
{"name": "logger","layout": "${logger}"},
{"name": "message","layout": "${message}"},
{"name": "exception","layout": "${onexception:${ui-pretty-exception}}"}
]
}
}
},
"rules": { "70_Final": { "writeTo": "stdout,azureBlob" } }
}
}
{ "NLog": {
"extensions": [
{ "assemblyFile": "NLog.Extensions.AzureBlobStorage.dll" }
],
"targets": {
"azureBlob": {
"type": "AzureBlobStorage",
"connectionString": "DefaultEndpointsProtocol=https;AccountName=test;AccountKey=key;EndpointSuffix=core.windows.net",
"container": "orchestratorlogs",
"blobName": "${date:format=yyyy-MM-dd hh.mm}",
"layout": {
"type": "JsonLayout",
"includeAllProperties": true,
"Attributes": [
{"name": "ts","layout": "${longdate}"},
{"name": "level","layout": "${level:upperCase=true}"},
{"name": "logger","layout": "${logger}"},
{"name": "message","layout": "${message}"},
{"name": "exception","layout": "${onexception:${ui-pretty-exception}}"}
]
}
}
},
"rules": { "70_Final": { "writeTo": "stdout,azureBlob" } }
}
}
To overwrite robot logs target, replace 70_final with 20_robot_primary in the above example .
Le dossier d'extensions nlogextensions est copié dans le magasin d'objets à l'emplacement connu des plugins. L'outil Orchestrator Configurator peut le faire automatiquement tout en mettant à jour la configuration NLog. Le script modifie automatiquement nlog.custom.config pour ajouter le préfixe /var/orchestrator/plugins/nlog/ à chaque assemblyFile du tableau d'extensions s'il n'est pas déjà préfixé.
Préparation des magasins d'informations d'identification
Vous pouvez migrer des plug-ins personnalisés pour les magasins d'informations d'identification vers Automation Suite. Pour ce faire, mettez à jour la configuration dans la carte de configuration et copiez les assemblages de plug-ins dans le compartiment de magasin d'objets correspondant.
- Les plugins doivent fonctionner sous Linux.
- Les plugins ne doivent écrire sur aucun stockage, à l'exception de
/tmp.
Les plug-ins de magasins d'informations d'identification suivants sont automatiquement déployés sur Orchestrator dans Automation Suite :
UiPath.Orchestrator.AzureKeyVault.SecureStore.dllUiPath.Orchestrator.SecureStore.CyberArkCCP.dll
Automation Suite ne prend pas en charge CyberArk AIM, vous ne pouvez donc pas le migrer. Nous vous recommandons de migrer vers le magasin d'informations d'identification CyberArkCCP.
Si vous utilisez d'autres plug-ins Credential Stores, copiez-les dans un dossier, tel que securestoreplugins.
Ajoutez les paramètres du magasin d'identifiants dans le fichier appsettings.json comme suit :
- pour désactiver les plugins par défaut, ajoutez la configuration
Plugins.SecureStores.Defaultavec une valeur de string vide dansappsettings.json; - ajoutez tous les plugins personnalisés au paramètre
Plugins.SecureStoresséparés par un;dansappsettings.json; - ajoutez les paramètres de plug-in personnalisés comme suit :
Plugins.SecureStores.<<FriendlyName>>.<<SettingName>>.
Le dossier de plug-in securestoreplugins est copié dans le magasin d'objets à l'emplacement bien connu des plug-ins.
Les assemblies dans Plugins.SecureStores sont chargés à partir de ce dossier.
Les assemblies de Plugins.SecureStore.Default sont chargés à partir du dossier plugins dans le dossier de l'application Orchestrator.
Préparation de la clé de chiffrement
Par défaut, lors de l'installation, Orchestrator génère une clé de chiffrement à utiliser pour les informations sensibles de la base de données. Vous devez migrer cette clé si vous souhaitez réutiliser une base de données sur un nouveau déploiement Orchestrator.
Dans la section secureAppSettings de la configuration, récupérez la valeur de EncryptionKey et stockez-la en toute sécurité pour une utilisation ultérieure.
Préparation de la clé de chiffrement par locataire
Le certificat de clé de chiffrement est installé dans le magasin de certificats Windows. Vous devez fournir le certificat dans l'environnement Automation Suite afin qu'il soit disponible pour les pods Orchestrator.
Les paramètres CertificatesStoreLocation et Azure.KeyVault.CertificateThumbprint ne sont plus requis dans Automation Suite, mais vous pouvez utiliser le CertificatePassword si nécessaire.
Procédez comme suit :
- Passez en revue les paramètres d'application et obtenez les paramètres
AzureKeyVault.*. - Stockez les
Azure.KeyVault.VaultAddress,Azure.KeyVault.ClientIdetAzure.KeyVault.DirectoryIdpour une utilisation ultérieure. - Récupérez le certificat et, si nécessaire, le mot de passe du certificat.
- Étape 1 : enregistrer les données de configuration de Identity Server
- Nom d'utilisateur et mot de passe de l'administrateur de l'hôte
- Certificats de signature de jetons
- Certificats SAML
- Paramètres d'application de Identity Server
- Certificats d'exportation
- Étape 2 : Créer des paires organisation-locataire
- Étape 3 : Enregistrement des chaînes de connexion et des noms de locataires
- Étape 4 : Préparation d'Orchestrator
- Présentation de la migration
- Préparation de web.config
- Préparation des paramètres d'application
- Préparation du stockage
- Préparation de NLog
- Préparation des magasins d'informations d'identification
- Préparation de la clé de chiffrement
- Préparation de la clé de chiffrement par locataire