Migration entre les clusters Automation Suite

À propos de la migration du cluster

Vous pouvez migrer d'un cluster Automation Suite à un autre si vous utilisez l'espace de noms uipath au lieu d'un espace de noms personnalisé et que vous souhaitez passer d'une version d'Automation Suite à une autre. Nous prenons en charge les scénarios suivants :

• faire migrer depuis Automation Suite sur Linux vers une nouvelle installation d'Automation Suite sur EKS/AKS ;

• Migrer d'Automation Suite sur EKS/AKS vers une nouvelle installation d'Automation Suite sur OpenShift ;

• Migrer d'Automation Suite sur OpenShift vers une nouvelle installation d'Automation Suite sur EKS/AKS ;

• Faites migrer depuis Automation Suite sur EKS vers Automation Suite sur AKS ou depuis Automation Suite sur AKS vers Automation Suite sur EKS.

Notez que vous pouvez tenter d'effectuer l'opération de migration plusieurs fois sans avoir d'impact sur votre cluster existant.

Les scénarios de migration suivants ne sont pas pris en charge :

• Migration d'Automation Suite sur Linux vers une installation existante d'Automation sur EKS/AKS ou d'Automation Suite sur OpenShift ;

• Migration d'un cluster Automation Suite sur OpenShift vers Automation Suite sur un cluster Linux.

Vue d'ensemble du processus

Étape	Description
1.	Obligatoire. Assurez-vous de répondre aux exigences de migration. Prérequis Migration de données et responsabilités
2.	Obligatoire. Préparez le cluster cible et les images Docker pour le cluster source et le cluster cible. Préparation du cluster 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. Hydratation du registre compatible OCI dans une configuration hors ligne Hydratation du registre compatible OCI dans une configuration en ligne
3.	Obligatoire. Démarrez la migration, déplacez les données et exécutez l'installation d'Automation Suite. Exécution de la migration du cluster
4.	Facultatif. Si AI Center est activé sur les clusters source et cible, migrez les compétences. Migration des compétences d'AI Center

Prérequis

Pour migrer d'un cluster Automation Suite à un autre, vous devez répondre aux exigences suivantes :

• Téléchargez les artefacts suivants :

  • uipathctl

• 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.

• Si vous migrez depuis Automation Suite sur Linux, la version de votre cluster source doit être 2022.10 ou une version plus récente.

• Si vous migrez vers Automation Suite sur OpenShift, la version de votre cluster source doit être 2023.10 ou une version plus récente.

• Exigences pour le mode hors ligne uniquement : vous devez hydrater le cluster cible.

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 de la migration du cluster

Préparation du cluster cible

Remarque :

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

Pour préparer le cluster cible, procédez comme suit :

1. Téléchargez la version ciblée de input.json sur le cluster source et générez le fichier input.json en exécutant la commande suivante :

   uipathctl manifest get-revision

   Pour plus de détails, reportez-vous au 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.

   Vous devez transférer la configuration spécifique à Orchestrator qui inclut les paramètres.

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

   Remarque :

   input-target.json est le fichier input.json correspondant au cluster cible.
4. Clonez les bases de données SQL du déploiement source vers le déploiement cible.

Hydrater le registre compatible OCI sans 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. Référencez l'image uipathcore du registre du cluster cible vers le registre du cluster source :

   ./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 mettre à jour la commande comme suit :

   • Remplacez target.registry.fqdn.com, target.registry.fqdn.com et target-registry-password par les valeurs appropriées qui correspondent au registre associé au cluster cible ;
   • Remplacez source.registry.fqdn.com, source.registry.fqdn.com et source-registry-password par les valeurs appropriées qui correspondent au registre associé au cluster source.

Hydratation du registre conforme à OCI avec 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.

Exécution de la migration du cluster

Pour migrer vers le cluster Automation Suite cible, 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 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 d'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['aicenter/aicenter-jobs:v23.10-10.15-rc02']}")
   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.

   skill_arr="[]"
   kubectl -n <uipath> run "$podName" --image="$aicJobsImage" --restart=Never --labels="app.kubernetes.io/component=aicenter" --overrides='{ "metadata": { "annotations": {"sidecar.istio.io/inject": "false"}}}' --command -- /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' -d \"$skill_arr\" | jq -r '([\"SKILL_ID\",\"SKILL_NAME\", \"STATUS\"] | (., map(length*\"-\"))), (.data[] | [.skillId, .skillName, .syncStatus]) | @tsv' | column -ts $'\t'; exit"

   Remarque :

   • Remplacez $skill_arr par [] pour exécuter toutes les compétences, ou ['abcd', 'efgh'] pour exécuter uniquement les deux compétences mentionnées.
   • La sortie skills id est nécessaire pour les prochaines commandes.
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"}}}' --command -- /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"

   Remarque : remplacez skill ids par les valeurs copiées lors de la procédure Vérification du statut de la migration des compétences .
   Consultez l'exemple suivant pour déclarer la variable skill_arr :

   skill_arr='[\"fb14154a-ce63-43ab-yyyy-xxxxxxxxxxxxxx\", \"ad58942d-e038-4d38-yyyy-xxxxxxxxxxxx\"]' # Replace them with ML skill ids in your environment
   kubectl -n uipath run "$podName" --image="$aicJobsImage" --restart=Never --labels="app.kubernetes.io/component=aicenter" --overrides='{ "metadata": { "annotations": {"sidecar.istio.io/inject": "false"}}}' --command -- /bin/bash -c -x "curl -sSL -XPOST -H 'Content-Type: application/json' '/ai-deployer/v1/system/mlskills:restore-all' -d \"$skill_arr\"; 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.