8.2. Migration de vos applications en utilisant la console Web MTC

Procédure

1. Connectez-vous au cluster OpenShift Container Platform sur lequel vous avez installé MTC.

2. Saisissez la commande suivante pour obtenir l’URL de la console Web MTC :

   Copy to Clipboard Toggle word wrap

   $ oc get -n openshift-migration route/migration -o go-template='https://{{ .spec.host }}'

   La sortie ressemble à ce qui suit : https://migration-openshift-migration.apps.cluster.openshift.com.

3. Ouvrez un navigateur et accédez à la console Web MTC.

   Note

   Si vous essayez d’accéder à la console Web MTC immédiatement après avoir installé l’opérateur Migration Toolkit for Containers, il se peut que la console ne se charge pas, car l’opérateur est toujours en train de configurer le cluster. Attendez quelques minutes, puis réessayez.

4. Si vous utilisez des certificats CA auto-signés, vous serez invité à accepter le certificat CA du serveur d’API du cluster source. La page Web vous guide dans le processus d’acceptation des certificats restants.
5. Connectez-vous à l’aide de votre nom d’utilisateur et de votre mot de passe OpenShift Container Platform.

Procédure

1. Connectez-vous au cluster.

2. Procurez-vous le token du compte du service migration-controller :

   Copy to Clipboard Toggle word wrap

   $ oc sa get-token migration-controller -n openshift-migration

   Exemple de sortie

   Copy to Clipboard Toggle word wrap

   eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJtaWciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoibWlnLXRva2VuLWs4dDJyIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Im1pZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImE1YjFiYWMwLWMxYmYtMTFlOS05Y2NiLTAyOWRmODYwYjMwOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDptaWc6bWlnIn0.xqeeAINK7UXpdRqAtOj70qhBJPeMwmgLomV9iFxr5RoqUgKchZRG2J2rkqmPm6vr7K-cm7ibD1IBpdQJCcVDuoHYsFgV4mp9vgOfn9osSDp2TGikwNz4Az95e81xnjVUmzh-NjDsEpw71DH92iHV_xt2sTwtzftS49LpPW2LjrV0evtNBP_t_RfskdArt5VSv25eORl7zScqfe1CiMkcVbf2UqACQjo3LbkpfN26HAioO2oH0ECPiRzT0Xyh-KwFutJLS9Xgghyw-LD9kPKcE_xbbJ9Y4Rqajh7WdPYuB0Jd9DPVrslmzK-F6cgHHYoZEv0SvLQi-PO0rpDrcjOEQQ

3. Dans la console Web MTC, cliquez sur Clusters.
4. Cliquez sur Add cluster.

5. Renseignez les champs suivants :

   • Cluster name : le nom du cluster peut contenir des lettres minuscules (a-z) et des chiffres (0-9). Il ne doit pas contenir d’espaces ni de caractères internationaux.
   • URL : indiquez l’URL du serveur d’API ; https://<www.example.com>:8443, par exemple.
   • Service account token : collez le token du compte de service migration-controller.

   • Exposed route host to image registry : si vous utilisez la migration directe d’images, spécifiez la route exposée vers le registre d’images du cluster source.

     Pour créer la route, exécutez la commande suivante :

     • Pour OpenShift Container Platform 3 :

       Copy to Clipboard Toggle word wrap

       $ oc create route passthrough --service=docker-registry --port=5000 -n default

     • Pour OpenShift Container Platform 4 :

       Copy to Clipboard Toggle word wrap

       $ oc create route passthrough --service=image-registry --port=5000 -n openshift-image-registry

   • Azure Cluster : vous devez sélectionner cette option si vous utilisez des clichés Azure pour copier vos données.
   • Azure resource group : ce champ est affiché si l’option Azure Cluster est sélectionnée. Spécifiez le groupe de ressources Azure.
   • Require SSL verification : (facultatif) sélectionnez cette option pour vérifier les connexions SSL au cluster.
   • CA bundle file : ce champ est affiché si l’option Require SSL verification est sélectionnée. Si vous avez créé un fichier de groupement de certificats CA personnalisé pour les certificats auto-signés, cliquez sur Browse, sélectionnez le fichier en question, puis envoyez-le.

6. Cliquez sur Add cluster.

   Le cluster apparaît dans la liste Clusters.

Procédure

1. Dans la console Web MTC, cliquez sur Replication repositories.
2. Cliquez sur Add repository.

3. Sélectionnez un type de fournisseur de stockage (Storage provider type) et renseignez les champs suivants :

   • AWS pour les fournisseurs S3, y compris AWS et MCG :

     • Replication repository name : indiquez le nom du référentiel de réplication dans la console Web MTC.
     • S3 bucket name : indiquez le nom du compartiment S3.
     • S3 bucket region : indiquez la région du compartiment S3. Requis pour AWS S3. Facultatif pour certains fournisseurs S3. Consultez la documentation du produit de votre fournisseur S3 pour connaître les valeurs attendues.
     • S3 endpoint : indiquez l’URL du service S3, et non du compartiment ; https://<s3-storage.apps.cluster.com>, par exemple. Requis pour un fournisseur S3 générique. Vous devez utiliser le préfixe https://.
     • S3 provider access key : indiquez la clé <AWS_SECRET_ACCESS_KEY> pour AWS ou la clé d’accès du fournisseur S3 pour MCG et les autres fournisseurs S3.
     • S3 provider secret access key : indiquez la clé <AWS_ACCESS_KEY_ID> pour AWS ou la clé d’accès secrète du fournisseur S3 pour MCG et les autres fournisseurs S3.
     • Require SSL verification : désactivez cette case à cocher si vous utilisez un fournisseur S3 générique.
     • Si vous avez créé un fichier de groupement de certificats CA personnalisé pour les certificats auto-signés, cliquez sur Browse et accédez ensuite au fichier codé en Base64.

   • GCP :

     • Replication repository name : indiquez le nom du référentiel de réplication dans la console Web MTC.
     • GCP bucket name : indiquez le nom du compartiment GCP.
     • GCP credential JSON blob : indiquez la chaîne dans le fichier credentials-velero.

   • Azure :

     • Replication repository name : indiquez le nom du référentiel de réplication dans la console Web MTC.
     • Azure resource group : indiquez le groupe de ressources du stockage d’objets blob Azure.
     • Azure storage account name: indiquez le nom du compte de stockage d’objets blob Azure.
     • Azure credentials - INI file contents : indiquez la chaîne dans le fichier credentials-velero.
4. Cliquez sur Add repository et attendez la validation de la connexion.

5. Cliquez sur Close.

   Le nouveau référentiel apparaît dans la liste Replication repositories.

Procédure

1. Dans la console Web MTC, cliquez sur Migration plans.
2. Cliquez sur Add migration plan.

3. Saisissez le nom du plan dans le champ Plan name.

   Le nom du plan de migration ne doit pas dépasser 253 caractères alphanumériques minuscules (a-z, 0-9), ni contenir d’espaces ou de traits de soulignement (_).

4. Sélectionnez un cluster source, un cluster cible et un référentiel dans les champs appropriés.
5. Cliquez sur Next.
6. Sélectionnez les projets à faire migrer.
7. Facultatif : cliquez sur l’icône d’édition en regard d’un projet pour modifier l’espace de nommage cible.
8. Cliquez sur Next.

9. Sélectionnez un type de migration pour chaque volume persistant (PV) :

   • L’option Copy copie les données du PV d’un cluster source vers le référentiel de réplication, puis restaure les données sur un nouveau PV, avec des caractéristiques similaires, dans le cluster cible.
   • L’option Move démonte un volume distant (NFS, par exemple) du cluster source, crée une ressource PV sur le cluster cible pointant vers le volume distant, puis monte le volume distant sur le cluster cible. Les applications qui s’exécutent sur le cluster cible utilisent le même volume distant que celui qui était utilisé par le cluster source.
10. Cliquez sur Next.

11. Sélectionnez une méthode de copie (Copy method) pour chaque PV :

    • La méthode Snapshot copy sauvegarde et restaure les données à l’aide de la fonctionnalité de cliché du fournisseur de cloud. Elle est nettement plus rapide que la méthode Filesystem copy.

    • La méthode Filesystem copy sauvegarde les fichiers sur le cluster source et les restaure sur le cluster cible.

      La méthode de copie du système de fichiers est requise pour la migration directe des volumes.

12. Vous pouvez sélectionner Verify copy pour vérifier les données migrées avec la méthode Filesystem copy. La vérification des données s’effectue en générant une somme de contrôle pour chaque fichier source et en vérifiant la somme de contrôle après la restauration. La vérification des données réduit sensiblement les performances.

13. Sélectionnez une classe de stockage cible (Target storage class).

    Si vous avez sélectionné Filesystem copy, vous pouvez modifier la classe de stockage cible.

14. Cliquez sur Next.

15. Sur la page Migration options, l’option Direct image migration est sélectionnée si vous avez spécifié une route de registre d’images exposée pour le cluster source. L’option Direct PV migration est sélectionnée si vous migrez des données avec la méthode Filesystem copy.

    Les options de migration directe copient les images et les fichiers directement du cluster source vers le cluster cible. Cette option s’avère beaucoup plus rapide que la copie d’images et de fichiers du cluster source vers le référentiel de réplication, puis du référentiel de réplication vers le cluster cible.

16. Cliquez sur Next.

17. Facultatif : cliquez sur Add Hook pour ajouter un script automatique au plan de migration.

    Un script automatique exécute un code personnalisé. Vous pouvez ajouter jusqu’à quatre scripts automatiques à un seul plan de migration. Chaque script automatique est exécuté pendant une étape de migration différente.

    1. Saisissez le nom du script automatique à afficher dans la console Web.
    2. Si le script automatique est un playbook Ansible, sélectionnez Ansible playbook, puis cliquez sur Browse pour télécharger le playbook ou collez le contenu du playbook dans le champ.
    3. Facultatif : indiquez une image d’exécution Ansible si vous n’utilisez pas l’image de script automatique par défaut.

    4. Si le script automatique n’est pas un playbook Ansible, sélectionnez Custom container image, et indiquez le nom et le chemin de l’image.

       Une image de conteneur personnalisée peut inclure des playbooks Ansible.

    5. Sélectionnez Source cluster ou Target cluster.
    6. Saisissez le nom et l’espace de nommage du compte de service dans les champs Service account name et Service account namespace, respectivement.

    7. Sélectionnez l’étape de migration pour le script automatique :

       • preBackup : avant la sauvegarde de la charge de travail de l’application sur le cluster source
       • postBackup : après la sauvegarde de la charge de travail de l’application sur le cluster source
       • preRestore : avant la restauration de la charge de travail de l’application sur le cluster cible
       • postRestore : après la restauration de la charge de travail de l’application sur le cluster cible
    8. Cliquez sur Add.

18. Cliquez sur Finish.

    Le plan de migration est affiché dans la liste Migration plans.

Procédure

1. Connectez-vous à la console Web MTC et cliquez sur Migration plans.

2. Cliquez sur le menu Options à côté d'un plan de migration et sélectionnez l'une des options suivantes sous Migration:

   • Stage copie les données du cluster source vers le cluster cible sans arrêter l’application.

   • Cutover arrête les transactions sur le cluster source et déplace les ressources vers le cluster cible.

     Facultatif : dans la boîte de dialogue Cutover migration, vous pouvez désactiver la case à cocher Halt transactions on the source cluster during migration.

   • State copie les réclamations de volumes persistants (PVC) sélectionnées.

     Important

     N’utilisez pas la migration d’état pour migrer un espace de nommage entre des clusters. Utilisez plutôt la migration par étapes ou à basculement.

     • Sélectionnez une ou plusieurs PVC dans la boîte de dialogue State migration et cliquez ensuite sur Migrate.

3. Une fois la migration terminée, vérifiez que l’application a été migrée correctement dans la console Web OpenShift Container Platform :

   1. Cliquez sur Home Projects.
   2. Cliquez sur le projet migré pour afficher son état.
   3. Dans la section Routes, cliquez sur Location pour vérifier que l’application fonctionne correctement, le cas échéant.
   4. Cliquez sur Workloads Pods pour vérifier que les pods s’exécutent dans l’espace de nommage migré.
   5. Cliquez sur Storage Persistent volumes pour vérifier que les volumes persistants migrés ont été mis en service correctement.