Migration d'Automation Suite sur Linux vers Automation Suite sur EKS/AKS

Vous pouvez effectuer la migration depuis Automation Suite déployé sur une machine Linux vers Automation Suite sur EKS/AKS. Pour ce faire, vous devez déplacer vos données depuis une version d'Automation Suite vers une autre à l'aide de uipathctl.

L'un des avantages de ce processus de migration est que vous pouvez essayer de l'effectuer plusieurs fois sans avoir d'impact sur votre cluster existant.

Important :

Vous ne pouvez effectuer une migration que vers une nouvelle installation d'Automatisation Suite sur EKS/AKS. La migration vers une installation existante d'Automation Suite sur EKS/AKS n'est actuellement pas prise en charge.

Prérequis

Pour migrer d'Automation Suite sur Linux vers Automation Suite sur EKS/AKS, vous devez répondre aux exigences suivantes :

• Vous devez établir la connectivité entre les deux environnements.

• Un magasin d'objets externe doit être configuré dans votre cluster source. Si vous utilisez le stockage intégré au cluster, consultez la section Migration du magasin d'objets du cluster vers un magasin d'objets externe.

• La version de votre Automation Suite sur Linux doit être 2022.10 ou une version plus récente.

• Exigences hors ligne uniquement : vous devez hydrater le cluster source.

Vue d'ensemble du processus

#	Étape de migration
1.	Obligatoire. Téléchargez uipathctl. Pour obtenir des instructions de téléchargement, consultez la section uipathctl.
2.	Obligatoire. Téléchargez versions.json. Pour obtenir des instructions de téléchargement, consultez versions.json.
3.	Préparez les images Docker pour le cluster source et cible. Facultatif. Si votre déploiement est hors ligne ou si vous utilisez un registre OCI privé, assurez-vous que les images requises sont disponibles.
4.	Préparez le cluster cible : Créez le fichier input.json. Exécutez la vérification des prérequis.
5.	Exécutez la migration et déplacez les données. La migration exécute des pods sur les clusters source et cible. Le stockage d'objets externe configuré pour le cluster source, en particulier le compartiment Platform, est utilisé comme emplacement de stockage de migration intermédiaire. Cluster source : Les pods general-migration-* sont chargés de l'exportation des objets Kubernetes du cluster source vers le cluster cible. Les pods volume-migration-* sont chargés de copier les données PVC dans le stockage externe intermédiaire. Cluster cible : Les pods inbound-pvc-migration-* sont chargés de créer des PVC dans le cluster cible et d'y copier les données source.
6.	Exécutez l'installation d'Automation Suite sur AKS ou EKS.

Migration de données et responsabilités

Données	Mécanisme de migration
	État (Status)	Responsabilité
SQL	Retained (Conservé) Vous avez deux options : Réutilisez les mêmes bases de données pour la nouvelle installation. Pointez les chaînes de connexion SQL de la configuration du cluster sur le serveur de base de données existant. Clonez vos bases de données et utilisez plutôt les clones.	Client
Registre Docker	Non migré Si vous utilisez un registre privé, vous devez hydrater le registre cible. Si vous utilisez registry.uipath.com pour le cluster cible, aucune autre étape n'est nécessaire.)	Client
Nom de domaine complet	Facultatif Vous devez choisir un nouveau nom de domaine complet pour le nouveau cluster. Vous pouvez éventuellement revenir au nom de domaine complet précédent si nécessaire.	Client
Certificats	Non migré Vous devez apporter des certificats dans le cadre de la nouvelle installation de cluster.	Client
Configuration du cluster	Non migré Vous devez générer le nouveau input.json applicable au type de cluster cible (AKS ou EKS).	Client
Alertes et tableaux de bord personnalisés créés par les utilisateurs	Non migré Vous devez reconfigurer les alertes et tableaux de bord personnalisés après la migration.	Client
Journaux d'application/configuration du flux Prometheus créés par les utilisateurs	Non migré Vous devez reconfigurer le journal des applications et le flux Prometheus.	Client
Charges de travail dynamiques	Dépend de l'application Les tâches d'entraînement AI Center sont perdues ; les compétences sont conservées.	Compétences (script nécessaire pour une exécution après la mise à niveau) : UiPath® Tâches d'entraînement : Client
Magasin d'objets	Magasin d'objets externe : Conservé (Retained) Pour le magasin d'objets externe, vous avez deux options : Réutiliser le magasin d'objets externe existant et le connecter au nouvel environnement. Créer une réplique de votre magasin d'objets actuel et l'utiliser pour la nouvelle configuration. Attention : si vous utilisez un magasin d'objets intégré au cluster, vous devez effectuer une migration ceph vers un système externe avant la mise à niveau.	Migration d'un magasin d'objets intégré au cluster vers un magasin externe : Client (Customer) Magasin d’objets externe : UiPath®
Insights	Retained (Conservé)	UiPath®
Données MongoDB	Retained (Conservé) Les données MongoDB sont déplacées vers le serveur SQL cible.	UiPath®
RabbitMQ	Non nécessaire	UiPath®
Surveillance (données)	Non nécessaire Les données de surveillance ne s'appliquent pas au nouveau cluster.	S/O

Préparation

Préparation du fichier cluster_config.json

Remarque :

Ne modifiez pas le cluster source après le démarrage du processus de migration.

Pour préparer le fichier cluster_config.json, procédez comme suit :

1. Téléchargez la version ciblée de uipathctl sur le cluster source et générez le fichier input.json en exécutant uipathctl manifest get-revision. Pour plus de détails, consultez le schéma suivant :
   
2. Sur la base du fichier input.json généré précédemment, modifiez le fichier input.json du cluster cible. Pour obtenir des instructions, consultez la section Configuration de input.json.

   Vous devez transférer la configuration spécifique à Orchestrator qui inclut la clé de chiffrement par locataire et les paramètres des compartiments de stockage Azure/Amazon S3.

3. Validez les prérequis dans le cluster cible en exécutant la commande suivante :

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

4. Clonez les bases de données SQL du déploiement source vers le déploiement cible.

Registre privé sans conditions d'accès à Internet

Le processus de migration nécessite que la dernière balise d'image Docker uipathcore soit disponible à la fois pour les clusters source et cible. Si votre cluster source est hors ligne, rendez l'image disponible en procédant comme suit :

1. Suivez les étapes pour hydrater le registre utilisé par le cluster cible avec le bundle hors ligne décrites dans Option B : Hydratation du registre avec le bundle hors ligne.
2. Copiez le binaire uipathctl et le fichier versions.json sur une machine virtuelle avec accès au cluster source.
3. Exécutez la commande suivante :

   jq -r '.[][] | select(.name=="uipath/uipathcore") | .ref + ":" + .version' "/path/to/versions.json" > images.txt

4. Ajoutez l'image uipathcore à votre registre privé à l'aide du binaire uipathctl :

   ./uipathctl registry seed --tag-file ./images.txt \
               --source-registry "target.registry.fqdn.com" \
               --source-password "target-registry-username" \
               --source-username "target-registry-password" \
               --dest-registry "<source.registry.fqdn.com>" \
               --dest-username "<source-registry-username>" \
               --dest-password "<source-registry-password>"

   Remarque : assurez-vous de remplacer registry.fqdn, registry-username et registry-password par les valeurs appropriées pour le registre privé utilisé par votre installation hors ligne source.

Registre privé avec conditions d'accès à Internet

Si vous utilisez un registre privé, vous devez le référencer. Pour obtenir des instructions, consultez la section Configuration du registre compatible OCI.

Hors ligne avec les exigences de registre intégrées au cluster

Si vous utilisez un registre intégré au cluster dans votre environnement hors ligne, procédez comme suit :

1. Téléchargez as.tar.gz sur le cluster source.
2. Hydratez votre registre en exécutant le script configureUiPathAS.sh :

   cd /opt/UiPathAutomationSuite/{version}/installer
   
   ./configureUiPathAS.sh registry upload --offline-bundle /uipath/{version}/as.tar.gz --offline-tmp-folder /uipath/tmp

Exécution

Pour migrer vers Automation Suite sur EKS/AKS, procédez comme suit :

1. Effectuez la migration en exécutant la commande suivante :

   uipathctl cluster migration run input-target.json --kubeconfig kubeconfig.source --target-kubeconfig kubeconfig.target --versions versions-target.json

2. Terminez l'installation d'Automation Suite sur AKS/EKS sur le cluster cible en exécutant la commande suivante :

   uipathctl manifest apply input-target.json --kubeconfig kubeconfig.target --versions versions-target.json

Migration des compétences AI Center

Les étapes de cette section ne s'appliquent que si vous avez activé AI Center sur les clusters source et cible. Notez que les instructions supposent que AI Center au niveau du cluster cible pointe vers la base de données contenant les données de compétence pour exécuter les compétences.

Une fois la migration terminée, vous devez synchroniser les compétences AI Center afin de pouvoir les utiliser à nouveau.

Vérification du statut de la migration des compétences

Pour récupérer le statut des compétences sur le système Automation Suite cible sur EKS/AKS, procédez comme suit :

1. Configurez les variables pour l'exécution des commandes suivantes.

   aicJobsImage=$(kubectl -n uipath get configmap aic-jobs-config -o "jsonpath={.data['AIC_JOBS_IMAGE']}")
   podName="skillstatuspod"

2. Nettoyez tout pod skillstatuspod qui pourrait être en cours d'exécution avant de récupérer à nouveau le statut de la compétence. Utilisez la commande suivante avec précaution, car elle supprime le pod de l'itération précédente.

   kubectl -n uipath delete pod "$podName" --force.

3. Créez le pod skillstatuspod pour obtenir le statut de la compétence. Le pod peut prendre un certain temps pour extraire l'image et s'exécuter, généralement moins de 30 secondes.

   kubectl -n uipath run "$podName" --image="$aicJobsImage" --restart=Never --labels="app.kubernetes.io/component=aicenter" --overrides='{ "metadata": { "annotations": {"sidecar.istio.io/inject": "false"}}}' -- /bin/bash -c "curl -sSL -XPOST -H 'Content-Type: application/json' 'ai-deployer-svc.uipath.svc.cluster.local/ai-deployer/v1/system/mlskills:restore-status' | jq -r '([\"SKILL_ID\",\"SKILL_NAME\", \"STATUS\"] | (., map(length*\"-\"))), (.data[] | [.skillId, .skillName, .syncStatus]) | @tsv' | column -ts $'\t'; exit"

4. Vérifiez la sortie du statut de la compétence.

   kubectl -n uipath logs -f "$podName" -c "$podName"

Exécution de la migration des compétences

Pour exécuter la migration des compétences, procédez comme suit :

1. Configurez les variables pour l'exécution des commandes suivantes.

   aicJobsImage=$(kubectl -n uipath get configmap aic-jobs-config -o "jsonpath={.data['AIC_JOBS_IMAGE']}")
   podName="skillsyncpod"

2. Nettoyez tout pod skillsyncpod qui pourrait être en cours d'exécution avant de récupérer à nouveau le statut de la compétence. Utilisez la commande suivante avec précaution, car elle supprime le pod de l'itération précédente.

   kubectl -n uipath delete pod "$podName" --force

3. Lancez la synchronisation des compétences. Le pod peut prendre un certain temps pour extraire l'image et s'exécuter, généralement moins de 30 secondes.

   kubectl -n uipath run "$podName" --image="$aicJobsImage" --restart=Never --labels="app.kubernetes.io/component=aicenter" --overrides='{ "metadata": { "annotations": {"sidecar.istio.io/inject": "false"}}}' -- /bin/bash -c "curl -sSL -XPOST -H 'Content-Type: application/json' 'ai-deployer-svc.uipath.svc.cluster.local/ai-deployer/v1/system/mlskills:restore-all' -d "[skill_id1, skill_id2, .... ]; exit"

4. Vérifiez la sortie du statut de synchronisation des compétences.

   kubectl -n uipath logs -f "$podName" -c "$podName"

5. L'opération peut prendre beaucoup de temps selon le nombre de compétences à synchroniser, vous pouvez donc vérifier régulièrement le statut de migration des compétences jusqu'à ce qu'il n'y en ait plus à l'état IN_PROGRESS.

Remarque :

Lors de la vérification du statut de la migration des compétences ou de l'exécution de la migration des compétences, vous couvrez toutes les compétences en même temps. Vous pouvez également effectuer ces opérations uniquement pour certaines compétences en ajoutant -d "[skill_id1, skill_id2, .... ]" comme argument supplémentaire pour curl à l'étape 3.