Étapes post-migration

Les étapes post-migration sont obligatoires et comprennent :

Étape 1 : Mise à jour des clés secrètes et de la configuration d'Identity Server

Mise à jour des clés secrètes de l'application Identity avec les données de configuration d'identité précédemment enregistrées

Procédez comme suit :

1. Exécutez kubectl edit secret platform-service-secrets -n uipath et mettez à jour identity.sqlConnectionString, identity.hostAdminUsername et identity.hostAdminPassword à l'aide de valeurs encodées en base64.
2. Suivez les instructions fournies dans Mise à jour du certificat de signature du jeton d'identité.
3. Si vous utilisez SAML, exécutez kubectl edit secret identity-saml-certificates -n uipath et mettez à jour current.saml2.pfx et future.saml2.pfx via les clés privées déchiffrées, et currentCertPassword et futureCertPassword via des valeurs encodées en base64.
4. Si vous utilisez Kerberos, exécutez kubectl edit secret krb5-keytab -n uipath et mettez à jour la valeur krb5.keytab.

Supprimer les anciennes clés de cache d'identité

Procédez comme suit :

1. Exécutez kubectl --kubeconfig <directory of SF cluster yaml file> get secrets/redb-redis-cluster-db -n uipath --template '{{ .data.password }}' pour obtenir le mot de passe Redis. Décodez la valeur Base64.
2. Exécutez kubectl --kubeconfig <directory of SF cluster yaml file> get secrets/redb-redis-cluster-db -n uipath --template '{{ .data.port }}' pour obtenir le port Redis. Décodez la valeur Base64.
3. Exécutez kubectl  --kubeconfig <directory of SF cluster yaml file>  exec -i -t -n redis-system redis-cluster-0 -c redis-enterprise-node "--" sh -c "clear; (bash || ash || sh)" pour accéder au nœud Redis.
4. Utilisez le port et le mot de passe obtenus à partir des commandes précédentes pour exécuter redis-cli -p <Port number> -a <Password> --scan --pattern is:* | xargs redis-cli -p <Port number> -a <Password> del afin de supprimer les anciennes clés.
5. Exécutez exit pour sortir.

Exécution de l'interface en ligne de commande Identity Server DataMigrator

Exécutez Identity Server DataMigration à partir d’une machine jointe à un domaine à l’aide des paramètres suivants. Vous pouvez trouver l’exécutable du migrateur dans le dossier d’installation d’Orchestrator, par exemple C:\Program Files (x86)\UiPath\Orchestrator\Identity\Tools\DataMigrator.Cli

• .\UiPath.DataMigrator.Cli.exe kube-migrate -d <identity.sqlConnectionString for the k8s env>

  Redémarrez identity-service-api après avoir exécuté la commande du migrateur.

Étape 2 : Liaison des locataires d'une installation autonome à Automation Suite

pour Linux

Prérequis

L’outil MSIToAutomationSuiteTenantMigrator nécessite .NET 6.0 au minimum. Si .NET 6.0 ou une version ultérieure n’est pas présent, téléchargez et installez .NET Runtime pour Linux avant d’utiliser l’outil MSIToAutomationSuiteTenantMigrator.

Pour installer .NET Runtime 3.1 sur RHEL, exécutez la commande suivante : sudo yum install dotnet-sdk-6.0 -y

Téléchargement de l'outil

L’outil MSIToAutomationSuiteTenantMigrator est disponible en téléchargement ici.

Exécution de l'outil

Remarque : assurez-vous de suivre les instructions d'échappement générales pour les différents types de shell. Dans Bash, ajoutez \ avant les caractères spéciaux.

Pour lier les locataires d'une installation autonome à Automation Suite, exécutez :

./MSIToAutomationSuiteTenantMigrator -s '<Orchestrator DB connection string (the one cloned from the standalone installation server)>' -p '<Platform DB connection string (Automation Suite)>' -t '<List of tenant names separated by comma, e.g. orchTenant1,orchTenant2>'

pour Windows

Prérequis

L’outil MSIToAutomationSuiteTenantMigrator nécessite .NET 6.0 au minimum. Si .NET 6.0 ou une version ultérieure n’est pas présent, téléchargez et installez .NET Runtime 6.0.3 pour Windows avant d’utiliser l’outil MSIToAutomationSuiteTenantMigrator.

Téléchargement de l'outil

L’outil MSIToAutomationSuiteTenantMigrator est disponible en téléchargement ici.

Exécution de l'outil

Remarque : pour exécuter correctement l'outil MSIToAutomationSuiteTenantMigrator, vous devez échapper votre mot de passe SQL s'il contient des caractères spéciaux. Pour ce faire, assurez-vous de remplacer chaque instance de $ par `$.

Pour lier les locataires d'une installation autonome à Automation Suite, exécutez :

MSIToAutomationSuiteTenantMigrator.exe -s "<Orchestrator DB connection string (the one cloned from the standalone installation server)>" -p "<Platform DB connection string (Automation Suite)>" -t "<List of tenant names separated by comma, e.g. orchTenant1,orchTenant2>"

Mise à jour des informations de configuration SMTP

Configurez SMTP pour l'hôte (Configure SMTP for the host) et (éventuellement) pour toutes les organisations pour lesquelles vous souhaitez utiliser des paramètres SMTP différents de ceux de l'hôte.

Remarque : Vous ne pouvez plus utiliser les informations d'identification par défaut. Vous devez donc fournir un nom d'utilisateur et un mot de passe pour le compte de messagerie de l'expéditeur et vous avez également besoin d'un certificat TLS valide, sinon la connexion SMTP ne fonctionnera pas lorsque vous essayerez de tester la connexion.

Étape 3 : Mise à jour de l'intégration et de l'authentification AD

Pour configurer l'intégration AD, reportez-vous à Configuration de l'authentification unique : Active Directory.

Si l'intégration et l'authentification AD ont été activées dans le déploiement autonome, procédez comme suit dans le cluster Automation Suite :

• Assurez-vous que les contrôleurs de domaine sont détectables par le cluster Automation Suite. Sinon, utilisez la configuration DNS Kube ;
• Configurez l'authentification Windows intégrée et l'authentification Kerberos à l'aide du fichier keytab ;
• Configurez l'intégration LDAP via le portail sous l'administrateur hôte ;
• Configurez l'authentification Windows via le portail sous l'administrateur hôte ;

• Configurez LDAPS pour une connexion sécurisée à LDAP.

  Remarque : Le compte utilisé pour la configuration de l'intégration LDAP ne doit avoir qu'un accès en lecture seule à tous les domaines approuvés dans les forêts actuelles et approuvées.

Étape 4 : Mettre à jour la configuration d'Orchestrator

Mettez à jour la configuration d'Orchestrator. Assurez-vous de revoir les éléments suivants :

• Configuration personnalisée de UiPath.Orchestrator.dll.config
• Tous les paramètres web.config.
• Stockage (packages, supports d'exécution et données de compartiments) : principalement applicable à Storage.Type=FileSystem
• Cibles NLog personnalisées.
• Magasins d'identifiants personnalisés.
• Clé de chiffrement par configuration de locataire.

Vous pouvez simplifier la plupart des étapes suivantes à l'aide de l'outil Orchestrator Configurator fourni.

L'outil bash orchestrator_configurator.sh peut mettre à jour le mappage de configuration personnalisé d'Orchestrator et télécharger des fichiers vers les emplacements de stockage Blob connus d'Orchestrator. Utilisez le paramètre -y pour ignorer la confirmation des actions proposées.

Configuration de web.config

Modifiez la carte de configuration orchestrator-customconfig à l'aide d'un outil tel que Lens ou kubectl.

Configurez la limite de requêtes dans le fichier values.json. Le déploiement d'Orchestrator devrait redémarrer automatiquement après ce changement de configuration.

{
  "Kestrel": {
    "Limits": {
      "MaxRequestBodySize": 314572800
    }
  }

Configuration des paramètres d'application

Le fichier appSettings.custom.json modifié dans les étapes de pré-migration contient maintenant toute la personnalisation nécessaire dans la section appSettings. Vous devez placer ce fichier .json dans la carte de configuration orchestrator-customconfig, dans le fichier values.json, sous la clé appSettings.

{
    "ExampleSetting.Enabled": true,
    "ExampleSetting.Type": "BasicExample",
    "ExampleSetting.Count": 3
}

L'outil Orchestrator Configurator peut fusionner les clés dans les paramètres de l'application personnalisés avec les clés déjà présentes dans la carte de configuration. Vous pouvez importer les paramètres de l'application à l'aide du paramètre -c|--app-settings :

./orchestrator-configurator.sh -c appSettings.custom.json

Si vous utilisez l'outil de configuration, suivez toutes les étapes pour rassembler tous les remplacements des paramètres de l'application requis, puis exécutez une fois le script à la fin de la procédure.

Configuration du stockage

Si vous utilisez FileStore local et que vous devez télécharger le contenu du stockage existant vers Orchestrator, assurez-vous de le placer dans n'importe quel pod Orchestrator dans le chemin /var/orchestator/data.

Orchestrator Configurator peut importer les fichiers avec kubectl cp, en utilisant le paramètre -s|--storage-folder :

./orchestrator-configurator.sh -s blobstoragefolder

Grâce à ce script, le contenu du dossier storage devient le contenu du dossier /var/orchestrator/data.

Pour utiliser le réseau FileStore, modifiez les paramètres de l'application Orchestrator ArgoCD et définissez les éléments suivants :

• storage.type = smb
• storage.smb.domain
• storage.smb.password
• storage.smb.source
• storage.smb.username
• storage.smb.size

Pour configurer d'autres options de stockage, modifiez les paramètres de l'application Orchestrator ArgoCD et définissez les éléments suivants :

• storage.type au fournisseur souhaité (Azure, AWS, Minio)
• storage.connectionString

Présentation des paramètres de stockage de l'application Orchestrator :

Compartiments de stockage Azure/Amazon S3

L’accès du navigateur Web Orchestrator aux compartiments de stockage Amazon et Azure peut être restreint en raison de la politique de même origine côté fournisseur. Pour accéder avec succès au contenu d’un tel compartiment, vous devez configurer le fournisseur concerné pour autoriser les requêtes d’origine croisée générées depuis Orchestrator.

Consultez les instructions sur la façon de configurer chaque fournisseur pour autoriser les requêtes d’origine croisée depuis Orchestrator.

Configuration de NLog

Pour installer les extensions NLog, celles-ci doivent être copiées dans Ceph, dans le compartiment uipath. Le pod Orchestrator pourra alors les charger au démarrage. Vous devez également placer la configuration dans orchestrator-customconfig dans le fichier nlog.json.

Le configurateur peut le faire avec les paramètres -n|--nlog-extensions-folder et -l|--nlog-config-file.

./orchestrator-configurator.sh -n nlogextensions -l nlog.custom.json

Les plug-ins seront disponibles dans le pod Orchestrator sous le chemin local /var/orchestrator/plugins/nlog. Le configurateur met automatiquement à jour les chemins d'assemblyFile en y ajoutant le chemin des plugins.

Configuration des magasins d'informations d'identification

Les modifications de configuration des magasins d'identifiants sont incluses dans appsettings.custom.json ; il n'y a donc plus de mises à jour de configuration requises.

Pour effectuer les modifications manuellement, placez-les dans le fichier values.json de orchestrator-customconfig sous la section appSettings.

Si des assemblages de magasins sécurisés sont également requis, vous devez les placer dans n'importe quel pod Orchestrator sur le chemin /var/orchestrator/plugins/securestore/.

L'outil de configuration d'Orchestrator peut le faire à l'aide du paramètre -p|--securestore-plugins-folder :

./orchestrator-configurator.sh -p securestoreplugins

Configuration de la clé de chiffrement

Pour configurer EncryptionKey, remplacez-la dans la clé secrète Kubernetes orchestrator-generated-secrets en écrasant la valeur de APPSETTINGS__EncryptionKey.

Configuration de la clé de chiffrement par locataire

Pour migrer la clé de chiffrement par locataire, procédez comme suit :

1. Ajoutez les paramètres AzureKeyVault et le certificat dans l'interface utilisateur ArgoCD, en tant que paramètres de remplacement pour l'application Orchestrator.
   • encryptionKeyPerTenant.certificateBase64
   • encryptionKeyPerTenant.certificatePassword
   • encryptionKeyPerTenant.clientId
   • encryptionKeyPerTenant.directoryId
   • encryptionKeyPerTenant.vaultAddress
   1. Utilisez les valeurs des clés de configuration suivantes (référencées dans les étapes de préparation) :
      • Azure.KeyVault.VaultAddress
      • Azure.KeyVault.ClientId

      • Azure.KeyVault.DirectoryId

   2. b. Convertissez le certificat en base64 et utilisez-le comme remplacement de paramètre. Pour le convertir, utilisez la commande suivante :

      PowerShell :

      [convert]::ToBase64String((Get-Content -path "path_to_certificate" -Encoding byte))

      Shell :

      base64 [_path_to_certificate_]

2. Appliquez les remplacements de paramètre de l'application Orchestrator ArgoCD, puis exécutez l'outil Orchestrator Configurator.
3. Une fois la nouvelle configuration reflétée dans ArgoCD, attendez que l'application soit à nouveau synchronisée.
4. Activez la fonctionnalité EncryptionKeyPerTenant comme suit :
   • utilisez les deux paramètres placés dans appSettings.custom.json et exécutez l'outil Orchestrator Configurator ;
   • ou manuellement dans le orchestrator-customconfig, dans la section appConfig du fichier values.json.

   "EncryptionKeyPerTenant.Enabled": "true", "EncryptionKeyPerTenant.KeyProvider": "AzureKeyVault",

5. Redémarrez le déploiement d'Orchestrator Automation Suite à partir du cluster pour que les modifications prennent effet.
   Remarque : Les paramètres SMTP dans Identity Server ne sont pas chiffrés avec la clé par locataire. Une fois la migration terminée, assurez-vous de saisir à nouveau le mot de passe SMTP dans le portail Automation Suite.

Étape 5 : Recréer le fichier cluster_config.json

Pour terminer la migration, vous devez recréer le fichier cluster_config.json . Cela garantit que toutes les modifications apportées via ArgoCD sont correctement enregistrées dans le fichier de configuration d'Automation Suite.

Pour recréer cluster_config.json , exécutez la commande suivante :

./configureUiPathAS.sh config get -i /path/to/old/cluster_config.json -o ./cluster_config.json

Dans le cadre de cette étape, vous devez également définir manuellement create_db sur false. Ne pas le faire empêcherait le programme d'installation de remplacer les chaînes de connexion SQL et de conserver le dernier état du cluster.

Important :

Ne configurez pas l'authentification Kerberos via cluster_config.json à ce stade. L'opération nécessite l'exécution du programme d'installation, qui annule les modifications apportées aux chaînes de connexion SQL.

Pour plus de détails sur les autres options de configuration de l'authentification Kerberos, consultez Configuration d'Automation Suite en tant que client Kerberos.

Étape 6 : Reconnecter les robots

Reconnectez les robots à Orchestrator dans Automation Suite.