Procédure

1. Procurez-vous le manifeste du CR MigrationController :

   $ oc get migrationcontroller <migration_controller> -n openshift-migration

2. Mettez à jour les paramètres du proxy :

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigrationController
   metadata:
     name: <migration_controller>
     namespace: openshift-migration
   ...
   spec:
     stunnel_tcp_proxy: http://<username>:<password>@<ip>:<port> 1
     noProxy: example.com 2

   1

   URL du proxy Stunnel pour la migration directe des volumes.

   2

   Liste, séparée par des virgules, de noms de domaines de destination, de domaines, d’adresses IP ou d’autres CIDR de réseau à exclure de la mise en proxy.

   Faites précéder un domaine du signe . pour ne faire correspondre que les sous-domaines. Par exemple, .y.com correspond à x.y.com, mais pas à y.com. Utilisez * pour ignorer le proxy pour toutes les destinations. Si vous mettez à l’échelle des workers qui ne sont pas inclus dans le réseau défini par le champ networking.machineNetwork[].cidr à partir de la configuration d’installation, vous devez les ajouter à cette liste pour éviter les problèmes de connexion.

   Ce champ est ignoré si ni le champ httpProxy ni le champ httpsProxy ne sont définis.

3. Enregistrez le manifeste en tant que migration-controller.yaml.

4. Appliquez le manifeste mis à jour :

   $ oc replace -f migration-controller.yaml -n openshift-migration

Procédure

1. Obtenez le point de terminaison S3, AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY en exécutant la commandedescribe sur la ressource personnalisée NooBaa.

   Vous utilisez ces informations d’identification pour ajouter MCG comme référentiel de réplication.

Procédure

1. Définissez la variable BUCKET :

   $ BUCKET=<your_bucket>

2. Définissez la variable REGION :

   $ REGION=<your_region>

3. Créez un compartiment AWS S3 :

   $ aws s3api create-bucket \
       --bucket $BUCKET \
       --region $REGION \
       --create-bucket-configuration LocationConstraint=$REGION 1

   1

   us-east-1 ne prend pas en charge la contrainte d’emplacement (LocationConstraint). Si votre région est us-east-1, omettez --create-bucket-configuration LocationConstraint=$REGION.

4. Créez un utilisateur IAM :

   $ aws iam create-user --user-name velero 1

   1

   Si vous souhaitez utiliser Velero pour sauvegarder plusieurs clusters avec plusieurs compartiments S3, créez un nom d’utilisateur unique pour chaque cluster.

5. Créez un fichier velero-policy.json :

   $ cat > velero-policy.json <<EOF
   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "ec2:DescribeVolumes",
                   "ec2:DescribeSnapshots",
                   "ec2:CreateTags",
                   "ec2:CreateVolume",
                   "ec2:CreateSnapshot",
                   "ec2:DeleteSnapshot"
               ],
               "Resource": "*"
           },
           {
               "Effect": "Allow",
               "Action": [
                   "s3:GetObject",
                   "s3:DeleteObject",
                   "s3:PutObject",
                   "s3:AbortMultipartUpload",
                   "s3:ListMultipartUploadParts"
               ],
               "Resource": [
                   "arn:aws:s3:::${BUCKET}/*"
               ]
           },
           {
               "Effect": "Allow",
               "Action": [
                   "s3:ListBucket",
                   "s3:GetBucketLocation",
                   "s3:ListBucketMultipartUploads"
               ],
               "Resource": [
                   "arn:aws:s3:::${BUCKET}"
               ]
           }
       ]
   }
   EOF

6. Attachez les politiques pour donner à l'utilisateur velero les permissions minimales nécessaires :

   $ aws iam put-user-policy \
     --user-name velero \
     --policy-name velero \
     --policy-document file://velero-policy.json

7. Créez une clé d’accès pour l’utilisateur velero :

   $ aws iam create-access-key --user-name velero

   Exemple de sortie

   {
     "AccessKey": {
           "UserName": "velero",
           "Status": "Active",
           "CreateDate": "2017-07-31T22:24:41.576Z",
           "SecretAccessKey": <AWS_SECRET_ACCESS_KEY>,
           "AccessKeyId": <AWS_ACCESS_KEY_ID>
     }
   }

   Enregistrez AWS_SECRET_ACCESS_KEY et AWS_ACCESS_KEY_ID. Vous utilisez les informations d’identification pour ajouter AWS comme référentiel de réplication.

Procédure

1. Connectez-vous à GCP :

   $ gcloud auth login

2. Définissez la variable BUCKET :

   $ BUCKET=<bucket> 1

   1

   Indiquez le nom de votre compartiment.

3. Créez le compartiment de stockage :

   $ gsutil mb gs://$BUCKET/

4. Définissez la variable PROJECT_ID sur votre projet actif :

   $ PROJECT_ID=$(gcloud config get-value project)

5. Créez un compte de service :

   $ gcloud iam service-accounts create velero \
       --display-name "Velero service account"

6. Répertoriez vos comptes de service :

   $ gcloud iam service-accounts list

7. Définissez la variable SERVICE_ACCOUNT_EMAIL pour qu’elle corresponde à sa valeur email :

   $ SERVICE_ACCOUNT_EMAIL=$(gcloud iam service-accounts list \
       --filter="displayName:Velero service account" \
       --format 'value(email)')

8. Attachez les politiques pour donner à l'utilisateur velero les permissions minimales nécessaires :

   $ ROLE_PERMISSIONS=(
       compute.disks.get
       compute.disks.create
       compute.disks.createSnapshot
       compute.snapshots.get
       compute.snapshots.create
       compute.snapshots.useReadOnly
       compute.snapshots.delete
       compute.zones.get
   )

9. Créez le rôle personnalisé velero.server :

   $ gcloud iam roles create velero.server \
       --project $PROJECT_ID \
       --title "Velero Server" \
       --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")"

10. Ajoutez une liaison de stratégie IAM au projet :

    $ gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \
        --role projects/$PROJECT_ID/roles/velero.server

11. Mettez à jour le compte de service IAM :

    $ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}

12. Enregistrez les clés du compte de service IAM dans le fichier credentials-velero du répertoire actuel :

    $ gcloud iam service-accounts keys create credentials-velero \
        --iam-account $SERVICE_ACCOUNT_EMAIL

    Vous utilisez le fichier credentials-velero pour ajouter GCP comme référentiel de réplication.

Procédure

1. Connectez-vous à Azure :

   $ az login

2. Définissez la variable AZURE_RESOURCE_GROUP :

   $ AZURE_RESOURCE_GROUP=Velero_Backups

3. Créez un groupe de ressources Azure :

   $ az group create -n $AZURE_RESOURCE_GROUP --location CentralUS 1

   1

   Indiquez votre emplacement.

4. Définissez la variable AZURE_STORAGE_ACCOUNT_ID :

   $ AZURE_STORAGE_ACCOUNT_ID="velero$(uuidgen | cut -d '-' -f5 | tr '[A-Z]' '[a-z]')"

5. Créez un compte de stockage Azure :

   $ az storage account create \
       --name $AZURE_STORAGE_ACCOUNT_ID \
       --resource-group $AZURE_RESOURCE_GROUP \
       --sku Standard_GRS \
       --encryption-services blob \
       --https-only true \
       --kind BlobStorage \
       --access-tier Hot

6. Définissez la variable BLOB_CONTAINER :

   $ BLOB_CONTAINER=velero

7. Créez un conteneur de stockage Azure Blob :

   $ az storage container create \
     -n $BLOB_CONTAINER \
     --public-access off \
     --account-name $AZURE_STORAGE_ACCOUNT_ID

8. Créez des informations d’identification et un principal de service pour velero :

   $ AZURE_SUBSCRIPTION_ID=`az account list --query '[?isDefault].id' -o tsv` \
     AZURE_TENANT_ID=`az account list --query '[?isDefault].tenantId' -o tsv` \
     AZURE_CLIENT_SECRET=`az ad sp create-for-rbac --name "velero" \
     --role "Contributor" --query 'password' -o tsv` \
     AZURE_CLIENT_ID=`az ad sp list --display-name "velero" \
     --query '[0].appId' -o tsv`

9. Enregistrez les informations d’identification du principal du service dans le fichier credentials-velero :

   $ cat << EOF > ./credentials-velero
   AZURE_SUBSCRIPTION_ID=${AZURE_SUBSCRIPTION_ID}
   AZURE_TENANT_ID=${AZURE_TENANT_ID}
   AZURE_CLIENT_ID=${AZURE_CLIENT_ID}
   AZURE_CLIENT_SECRET=${AZURE_CLIENT_SECRET}
   AZURE_RESOURCE_GROUP=${AZURE_RESOURCE_GROUP}
   AZURE_CLOUD_NAME=AzurePublicCloud
   EOF

   Vous utilisez le fichier credentials-velero pour ajouter Azure comme référentiel de réplication.

Procédure

1. Procurez-vous le manifeste du CR MigrationController :

   $ oc get migrationcontroller <migration_controller> -n openshift-migration

2. Mettez à jour les paramètres du proxy :

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigrationController
   metadata:
     name: <migration_controller>
     namespace: openshift-migration
   ...
   spec:
     stunnel_tcp_proxy: http://<username>:<password>@<ip>:<port> 1
     noProxy: example.com 2

   1

   URL du proxy Stunnel pour la migration directe des volumes.

   2

   Liste, séparée par des virgules, de noms de domaines de destination, de domaines, d’adresses IP ou d’autres CIDR de réseau à exclure de la mise en proxy.

   Faites précéder un domaine du signe . pour ne faire correspondre que les sous-domaines. Par exemple, .y.com correspond à x.y.com, mais pas à y.com. Utilisez * pour ignorer le proxy pour toutes les destinations. Si vous mettez à l’échelle des workers qui ne sont pas inclus dans le réseau défini par le champ networking.machineNetwork[].cidr à partir de la configuration d’installation, vous devez les ajouter à cette liste pour éviter les problèmes de connexion.

   Ce champ est ignoré si ni le champ httpProxy ni le champ httpsProxy ne sont définis.

3. Enregistrez le manifeste en tant que migration-controller.yaml.

4. Appliquez le manifeste mis à jour :

   $ oc replace -f migration-controller.yaml -n openshift-migration

Procédure

1. Pour exécuter Rsync en tant que root, configurez le CR MigMigration selon cet exemple :

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigMigration
   metadata:
     name: migration-controller
     namespace: openshift-migration
   spec:
     [...]
     runAsRoot: true

2. Pour exécuter Rsync en tant qu'identifiant d'utilisateur (UID) ou de groupe (GID) spécifique, configurez le CR MigMigration selon cet exemple :

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigMigration
   metadata:
     name: migration-controller
     namespace: openshift-migration
   spec:
     [...]
     runAsUser: 10010001
     runAsGroup: 3

Procédure

1. Obtenez le point de terminaison S3, AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY en exécutant la commandedescribe sur la ressource personnalisée NooBaa.

Procédure

1. Placez un composant réseau extérieur, tel qu’un équilibreur de charge d’application ou un proxy inverse, entre les clients et le cluster cible.
2. Mettez à jour le nom de domaine complet de l’application sur le cluster source dans le serveur DNS pour renvoyer l’adresse IP du composant réseau extérieur.
3. Configurez le composant réseau de manière à envoyer les demandes reçues pour l’application dans le domaine source à l’équilibreur de charge dans le domaine du cluster cible.
4. Créez un enregistrement DNS générique pour le domaine *.apps.source.example.com qui pointe vers l’adresse IP de l’équilibreur de charge du cluster source.
5. Créez un enregistrement DNS pour chaque application qui pointe vers l’adresse IP du composant réseau extérieur devant le cluster cible. Un enregistrement DNS spécifique a une priorité plus élevée qu’un enregistrement générique, de sorte qu’aucun conflit ne survient lorsque le nom de domaine complet de l’application est résolu.

1. Créez, dans le projet du cluster cible, une route configurée pour accepter les demandes adressées au nom de domaine complet (FQDN) de l’application dans le cluster source :

   $ oc expose svc <app1-svc> --hostname <app1.apps.source.example.com> \
    -n <app1-namespace>

   Avec cette nouvelle route, le serveur accepte toute demande portant sur ce FQDN et l’envoie aux pods d’application correspondants. En outre, lorsque vous migrez l’application, une autre route est créée dans le domaine du cluster cible. Les demandes atteignent l’application migrée en utilisant l’un de ces noms d’hôte.

2. Créez un enregistrement DNS avec votre fournisseur DNS qui fait pointer le FQDN de l’application dans le cluster source vers l’adresse IP de l’équilibreur de charge par défaut du cluster cible. Cela permettra de rediriger le trafic de votre cluster source vers votre cluster cible.

   Le FQDN de l’application est résolu sur l’équilibreur de charge du cluster cible. Le routeur du contrôleur d'entrée par défaut accepte les demandes pour ce FQDN car une route pour ce nom d'hôte est exposée.

1. Remplacez le certificat x509 du contrôleur d'entrée par défaut créé pendant le processus d'installation par un certificat personnalisé.

2. Configurez ce certificat de manière à inclure les domaines DNS génériques pour les clusters source et cible dans le champ subjectAltName.

   Le nouveau certificat est valide pour sécuriser les connexions effectuées à l’aide de l’un des domaines DNS.

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 :

   $ 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 :

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

   Exemple de sortie

   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 :

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

     • Pour OpenShift Container Platform 4 :

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

Procédure

1. Créez un manifeste de CR MigCluster pour le cluster hôte :

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigCluster
   metadata:
     name: <host_cluster>
     namespace: openshift-migration
   spec:
     isHostCluster: true
   EOF

2. Créez un manifeste d’objets Secret pour chaque cluster distant :

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Secret
   metadata:
     name: <cluster_secret>
     namespace: openshift-config
   type: Opaque
   data:
     saToken: <sa_token> 1
   EOF

   1

   Indiquez le token de compte de service (SA) migration-controller codé en base64 du cluster distant. Vous pouvez obtenir le token en exécutant la commande suivante :

   $ oc sa get-token migration-controller -n openshift-migration | base64 -w 0

3. Créez un manifeste de CR MigCluster pour chaque cluster distant :

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigCluster
   metadata:
     name: <remote_cluster> 1
     namespace: openshift-migration
   spec:
     exposedRegistryPath: <exposed_registry_route> 2
     insecure: false 3
     isHostCluster: false
     serviceAccountSecretRef:
       name: <remote_cluster_secret> 4
       namespace: openshift-config
     url: <remote_cluster_url> 5
   EOF

   1

   Indiquez la ressource personnalisée Cluster du cluster distant.

   2

   Facultatif : pour la migration directe d’images, indiquez la route de registre exposée.

   3

   La vérification SSL est activée si la valeur est définie sur false. Les certificats CA ne sont pas requis ni vérifiés si la valeur est définie sur true.

   4

   Indiquez l’objet Secret du cluster distant.

   5

   Indiquez l’URL du cluster distant.

4. Vérifiez que tous les clusters sont dans l’état Ready :

   $ oc describe cluster <cluster>

5. Créez un manifeste d’objets Secret pour le référentiel de réplication :

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Secret
   metadata:
     namespace: openshift-config
     name: <migstorage_creds>
   type: Opaque
   data:
     aws-access-key-id: <key_id_base64> 1
     aws-secret-access-key: <secret_key_base64> 2
   EOF

   1

   Indiquez l’ID de la clé au format base64.

   2

   Indiquez la clé secrète au format base64.

   Les informations d’identification AWS sont codées en base64 par défaut. Pour les autres fournisseurs de stockage, vous devez coder vos informations d’identification en exécutant la commande suivante avec chaque clé :

   $ echo -n "<key>" | base64 -w 0 1

   1

   Indiquez l’ID de la clé ou la clé secrète. Les deux clés doivent être codées en base64.

6. Créez un manifeste de CR MigStorage pour le référentiel de réplication :

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigStorage
   metadata:
     name: <migstorage>
     namespace: openshift-migration
   spec:
     backupStorageConfig:
       awsBucketName: <bucket> 1
       credsSecretRef:
         name: <storage_secret> 2
         namespace: openshift-config
     backupStorageProvider: <storage_provider> 3
     volumeSnapshotConfig:
       credsSecretRef:
         name: <storage_secret> 4
         namespace: openshift-config
     volumeSnapshotProvider: <storage_provider> 5
   EOF

   1

   Indiquez le nom du compartiment.

   2

   Indiquez la ressource personnalisée Secrets du stockage d’objets. Vous devez vous assurer que les informations d’identification stockées dans la ressource personnalisée Secrets du stockage d’objets sont correctes.

   3

   Indiquez le fournisseur de stockage.

   4

   Facultatif : si vous copiez des données en utilisant des clichés, indiquez la ressource personnalisée Secrets du stockage d’objets. Vous devez vous assurer que les informations d’identification stockées dans la ressource personnalisée Secrets du stockage d’objets sont correctes.

   5

   Facultatif : si vous copiez des données en utilisant des clichés, indiquez le fournisseur de stockage.

7. Vérifiez que la ressource personnalisée MigStorage se trouve dans l’état Ready :

   $ oc describe migstorage <migstorage>

8. Créez un manifeste de CR MigPlan :

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigPlan
   metadata:
     name: <migplan>
     namespace: openshift-migration
   spec:
     destMigClusterRef:
       name: <host_cluster>
       namespace: openshift-migration
     indirectImageMigration: true 1
     indirectVolumeMigration: true 2
     migStorageRef:
       name: <migstorage> 3
       namespace: openshift-migration
     namespaces:
       - <source_namespace_1> 4
       - <source_namespace_2>
       - <source_namespace_3>:<destination_namespace> 5
     srcMigClusterRef:
       name: <remote_cluster> 6
       namespace: openshift-migration
   EOF

   1

   La migration directe des images est activée si la valeur est définie sur false.

   2

   La migration directe des volumes est activée si la valeur est définie sur false.

   3

   Indiquez le nom de l’instance CR MigStorage.

   4

   Indiquez un ou plusieurs espaces de nommage sources. Par défaut, l’espace de nommage de destination porte le même nom.

   5

   Indiquez un espace de nommage de destination s’il est différent de l’espace de nommage source.

   6

   Indiquez le nom de l’instance MigCluster du cluster source.

9. Vérifiez que l’instance MigPlan se trouve dans l’état Ready :

   $ oc describe migplan <migplan> -n openshift-migration

10. Créez un manifeste de CR MigMigration pour lancer la migration définie dans l’instance MigPlan :

    $ cat << EOF | oc apply -f -
    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: <migmigration>
      namespace: openshift-migration
    spec:
      migPlanRef:
        name: <migplan> 1
        namespace: openshift-migration
      quiescePods: true 2
      stage: false 3
      rollback: false 4
    EOF

    1

    Indiquez le nom de la ressource personnalisée MigPlan.

    2

    Les pods sur le cluster source sont arrêtés avant la migration si la valeur est définie sur true.

    3

    Une migration par étapes, qui copie la plupart des données sans arrêter l’application, est effectuée si la valeur est définie sur true.

    4

    Une migration terminée est annulée si la valeur est définie sur true.

11. Vérifiez la migration en observant la progression de la ressource personnalisée MigMigration :

    $ oc watch migmigration <migmigration> -n openshift-migration

    La sortie se présente comme suit :

    Exemple de sortie

    Name:         c8b034c0-6567-11eb-9a4f-0bc004db0fbc
    Namespace:    openshift-migration
    Labels:       migration.openshift.io/migplan-name=django
    Annotations:  openshift.io/touch: e99f9083-6567-11eb-8420-0a580a81020c
    API Version:  migration.openshift.io/v1alpha1
    Kind:         MigMigration
    ...
    Spec:
      Mig Plan Ref:
        Name:       migplan
        Namespace:  openshift-migration
      Stage:        false
    Status:
      Conditions:
        Category:              Advisory
        Last Transition Time:  2021-02-02T15:04:09Z
        Message:               Step: 19/47
        Reason:                InitialBackupCreated
        Status:                True
        Type:                  Running
        Category:              Required
        Last Transition Time:  2021-02-02T15:03:19Z
        Message:               The migration is ready.
        Status:                True
        Type:                  Ready
        Category:              Required
        Durable:               true
        Last Transition Time:  2021-02-02T15:04:05Z
        Message:               The migration registries are healthy.
        Status:                True
        Type:                  RegistriesHealthy
      Itinerary:               Final
      Observed Digest:         7fae9d21f15979c71ddc7dd075cb97061895caac5b936d92fae967019ab616d5
      Phase:                   InitialBackupCreated
      Pipeline:
        Completed:  2021-02-02T15:04:07Z
        Message:    Completed
        Name:       Prepare
        Started:    2021-02-02T15:03:18Z
        Message:    Waiting for initial Velero backup to complete.
        Name:       Backup
        Phase:      InitialBackupCreated
        Progress:
          Backup openshift-migration/c8b034c0-6567-11eb-9a4f-0bc004db0fbc-wpc44: 0 out of estimated total of 0 objects backed up (5s)
        Started:        2021-02-02T15:04:07Z
        Message:        Not started
        Name:           StageBackup
        Message:        Not started
        Name:           StageRestore
        Message:        Not started
        Name:           DirectImage
        Message:        Not started
        Name:           DirectVolume
        Message:        Not started
        Name:           Restore
        Message:        Not started
        Name:           Cleanup
      Start Timestamp:  2021-02-02T15:03:18Z
    Events:
      Type    Reason   Age                 From                     Message
      ----    ------   ----                ----                     -------
      Normal  Running  57s                 migmigration_controller  Step: 2/47
      Normal  Running  57s                 migmigration_controller  Step: 3/47
      Normal  Running  57s (x3 over 57s)   migmigration_controller  Step: 4/47
      Normal  Running  54s                 migmigration_controller  Step: 5/47
      Normal  Running  54s                 migmigration_controller  Step: 6/47
      Normal  Running  52s (x2 over 53s)   migmigration_controller  Step: 7/47
      Normal  Running  51s (x2 over 51s)   migmigration_controller  Step: 8/47
      Normal  Ready    50s (x12 over 57s)  migmigration_controller  The migration is ready.
      Normal  Running  50s                 migmigration_controller  Step: 9/47
      Normal  Running  50s                 migmigration_controller  Step: 10/47

Procédure

1. Migrer les données des volumes persistants du cluster source vers le cluster cible.

   Vous pouvez effectuer cette étape autant de fois que nécessaire. L'application source continue de fonctionner.

2. Mettre en pause l'application source.

   Vous pouvez le faire en définissant les répliques des ressources de charge de travail à 0, soit directement sur le cluster source, soit en mettant à jour les manifestes dans GitHub et en resynchronisant l'application Argo CD.

3. Cloner les manifestes de l'application sur le cluster cible.

   Vous pouvez utiliser Argo CD pour cloner les manifestes d'application sur le cluster cible.

4. Migrer les données de volume restantes de la source vers le cluster cible.

   Migrer toutes les nouvelles données créées par l'application au cours du processus de migration des états en effectuant une migration finale des données.

5. Si l'application clonée est en état d'arrêt, il faut l'arrêter.
6. Basculer l'enregistrement DNS vers le cluster cible pour rediriger le trafic utilisateur vers l'application migrée.

Procédure

1. Migrer les données des volumes persistants du cluster source vers le cluster cible.

   Vous pouvez effectuer cette étape autant de fois que nécessaire. L'application source continue de fonctionner.

2. Mettre en pause l'application source.

   Vous pouvez le faire en définissant les répliques des ressources de charge de travail à 0, soit directement sur le cluster source, soit en mettant à jour les manifestes dans GitHub et en resynchronisant l'application Argo CD.

3. Cloner les manifestes de l'application sur le cluster cible.

   Vous pouvez utiliser Argo CD pour cloner les manifestes d'application sur le cluster cible.

4. Migrer les données de volume restantes de la source vers le cluster cible.

   Migrer toutes les nouvelles données créées par l'application au cours du processus de migration des états en effectuant une migration finale des données.

5. Si l'application clonée est en état d'arrêt, il faut l'arrêter.
6. Basculer l'enregistrement DNS vers le cluster cible pour rediriger le trafic utilisateur vers l'application migrée.

Procédure

1. Modifiez le manifeste de ressources personnalisées MigrationController :

   $ oc edit migrationcontroller <migration_controller> -n openshift-migration

2. Mettez à jour la section spec en ajoutant des paramètres pour exclure des ressources spécifiques. Pour les ressources qui ne disposent pas de leurs propres paramètres d'exclusion, ajoutez le paramètre additional_excluded_resources:

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigrationController
   metadata:
     name: migration-controller
     namespace: openshift-migration
   spec:
     disable_image_migration: true 1
     disable_pv_migration: true 2
     additional_excluded_resources: 3
     - resource1
     - resource2
     ...

   1

   Ajoutez disable_image_migration: true pour exclure les flux d’images de la migration. imagestreams est ajouté à la liste des ressources exclues dans main.yml lorsque le pod MigrationController redémarre.

   2

   Ajoutez disable_pv_migration: true pour exclure les volumes persistants du plan de migration. persistentvolumes et persistentvolumeclaims sont ajoutés à la liste excluded_resources dans main.yml lorsque le pod MigrationController redémarre. La désactivation de la migration des volumes persistants désactive également leur découverte lorsque vous créez le plan de migration.

   3

   Vous pouvez ajouter les ressources OpenShift Container Platform que vous souhaitez exclure à la liste additional_excluded_resources.

3. Attendez deux minutes pour que le pod MigrationController redémarre afin que les modifications soient appliquées.

4. Vérifiez que la ressource est exclue :

   $ oc get deployment -n openshift-migration migration-controller -o yaml | grep EXCLUDED_RESOURCES -A1

   La sortie contient les ressources exclues :

   Exemple de sortie

   name: EXCLUDED_RESOURCES
   value:
   resource1,resource2,imagetags,templateinstances,clusterserviceversions,packagemanifests,subscriptions,servicebrokers,servicebindings,serviceclasses,serviceinstances,serviceplans,imagestreams,persistentvolumes,persistentvolumeclaims

Procédure

1. Dans le volet de navigation de gauche de la console web OpenShift Container Platform, cliquez sur Projects.

2. Dans la liste des projets, cliquez sur votre projet.

   La page Project details s'ouvre.

3. Cliquez sur le nom DeploymentConfig. Notez le nom du pod en cours d'exécution.
4. Ouvrez l'onglet YAML du projet. Trouvez les PV et notez les noms de leurs réclamations de volume persistantes (PVC) correspondantes.
5. Dans la console Web MTC, cliquez sur Migration plans.
6. Cliquez sur Add migration plan.

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

   Le nom du plan de migration doit contenir de 3 à 63 caractères alphanumériques minuscules (a-z, 0-9) et ne doit pas contenir d'espaces ni de traits de soulignement (_).

8. Dans le menu Migration type, sélectionnez Storage class conversion.
9. Dans la liste Source cluster, sélectionnez le cluster souhaité pour la conversion de la classe de stockage.

10. Cliquez sur Next.

    La page Namespaces s'ouvre.

11. Sélectionnez le projet souhaité.

12. Cliquez sur Next.

    La page Persistent volumes s'ouvre. La page affiche les PV du projet, tous sélectionnés par défaut.

13. Pour chaque PV, sélectionnez la classe de stockage cible souhaitée.

14. Cliquez sur Next.

    L'assistant valide le nouveau plan de migration et indique qu'il est prêt.

15. Cliquez sur Close.

    Le nouveau plan apparaît sur la page Migration plans.

16. Pour lancer la conversion, cliquez sur le menu des options du nouveau plan.

    Sous Migrations, deux options sont affichées, Stage et Cutover.

    Note

    La migration de basculement met à jour les références PVC dans les applications.

    La migration d'étape ne met pas à jour les références PVC dans les applications.

17. Sélectionnez l'option souhaitée.

    Selon l'option choisie, la notification Stage migration ou Cutover migration apparaît.

18. Cliquez sur Migrate.

    Selon l'option choisie, le message Stage started ou Cutover started apparaît.

19. Pour connaître l'état de la migration en cours, cliquez sur le numéro dans la colonne Migrations.

    La page Migrations s'ouvre.

20. Pour obtenir plus de détails sur la migration en cours et suivre sa progression, sélectionnez la migration dans la colonne Type.

    La page Migration details s'ouvre. Lorsque la migration progresse jusqu'à l'étape DirectVolume et que l'état de l'étape devient Running Rsync Pods to migrate Persistent Volume data, vous pouvez cliquer sur View details et voir l'état détaillé des copies.

21. Dans le fil d'Ariane, cliquez sur Stage ou Cutover et attendez que toutes les étapes soient terminées.

22. Ouvrez l'onglet PersistentVolumeClaims de la console web OpenShift Container Platform.

    Vous pouvez voir de nouveaux PVC avec les noms des PVC initiaux mais se terminant par new, qui utilisent la classe de stockage cible.

23. Dans le volet de navigation de gauche, cliquez sur Pods. Constatez que le pod de votre projet fonctionne à nouveau.

Procédure

1. Mettez à jour le CR MigPlan pour inclure les ressources Kubernetes et, éventuellement, pour filtrer les ressources incluses en ajoutant le paramètre labelSelector:

   1. Pour mettre à jour le CR MigPlan afin d'inclure les ressources Kubernetes :

      apiVersion: migration.openshift.io/v1alpha1
      kind: MigPlan
      metadata:
        name: <migplan>
        namespace: openshift-migration
      spec:
        includedResources:
        - kind: <kind> 1
          group: ""
        - kind: <kind>
          group: ""

      1

      Indiquez l’objet Kubernetes ; Secret ou ConfigMap, par exemple.

   2. Facultatif : Pour filtrer les ressources incluses en ajoutant le paramètre labelSelector:

      apiVersion: migration.openshift.io/v1alpha1
      kind: MigPlan
      metadata:
        name: <migplan>
        namespace: openshift-migration
      spec:
        includedResources:
        - kind: <kind> 1
          group: ""
        - kind: <kind>
          group: ""
      ...
        labelSelector:
          matchLabels:
            <label> 2

      1

      Indiquez l’objet Kubernetes ; Secret ou ConfigMap, par exemple.

      2

      Indiquez l’étiquette des ressources à migrer ; app: frontend, par exemple.

2. Créer un CR MigMigration pour migrer les ressources Kubernetes sélectionnées. Vérifiez que le bon site MigPlan est référencé dans migPlanRef:

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigMigration
   metadata:
     generateName: <migplan>
     namespace: openshift-migration
   spec:
     migPlanRef:
       name: <migplan>
       namespace: openshift-migration
     stage: false

Procédure

1. Modifiez le manifeste de la ressource personnalisée (CR) MigrationController :

   $ oc edit migrationcontroller -n openshift-migration

2. Mettez à jour les paramètres suivants :

   ...
   mig_controller_limits_cpu: "1" 1
   mig_controller_limits_memory: "10Gi" 2
   ...
   mig_controller_requests_cpu: "100m" 3
   mig_controller_requests_memory: "350Mi" 4
   ...
   mig_pv_limit: 100 5
   mig_pod_limit: 100 6
   mig_namespace_limit: 10 7
   ...

   1

   Spécifie le nombre de processeurs disponibles pour la CR MigrationController.

   2

   Spécifie la quantité de mémoire disponible pour la CR MigrationController.

   3

   Spécifie le nombre d’unités centrales disponibles pour les demandes de CR MigrationController. 100m représente 0,1 unité centrale (100 * 1e-3).

   4

   Spécifie la quantité de mémoire disponible pour les demandes de CR MigrationController.

   5

   Spécifie le nombre de volumes persistants qui peuvent être migrés.

   6

   Spécifie le nombre de pods qui peuvent être migrés.

   7

   Spécifie le nombre n’espaces de nommage qui peuvent être migrés.

3. Créez un plan de migration qui utilise les paramètres mis à jour pour vérifier les modifications.

   Si votre plan de migration dépasse les limites de CR MigrationController, la console MTC affiche un message d’avertissement lorsque vous enregistrez le plan.

Procédure

1. Connectez-vous au cluster hôte.

2. Activez le redimensionnement des PV en appliquant un correctif à la ressource personnalisée MigrationController :

   $ oc patch migrationcontroller migration-controller -p '{"spec":{"enable_dvm_pv_resizing":true}}' \ 1
     --type='merge' -n openshift-migration

   1

   Définissez la valeur sur false pour désactiver le redimensionnement des PV.

3. Facultatif : mettez à jour le paramètre pv_resizing_threshold pour augmenter le seuil :

   $ oc patch migrationcontroller migration-controller -p '{"spec":{"pv_resizing_threshold":41}}' \ 1
     --type='merge' -n openshift-migration

   1

   La valeur par défaut est 3.

   Lorsque le seuil est dépassé, le message d’état suivant est affiché dans l’état de la ressource personnalisée MigPlan :

   status:
     conditions:
   ...
     - category: Warn
       durable: true
       lastTransitionTime: "2021-06-17T08:57:01Z"
       message: 'Capacity of the following volumes will be automatically adjusted to avoid disk capacity issues in the target cluster:  [pvc-b800eb7b-cf3b-11eb-a3f7-0eae3e0555f3]'
       reason: Done
       status: "False"
       type: PvCapacityAdjustmentRequired

   Note

   Pour le stockage AWS gp2, ce message n’apparaît que si la valeur pv_resizing_threshold est supérieure ou égale à 42 % en raison de la manière dont gp2 calcule l’utilisation et la taille des volumes. (BZ#1973148)

Procédure

1. Activez les clients en cache en exécutant la commande suivante :

   $ oc -n openshift-migration patch migrationcontroller migration-controller --type=json --patch \
     '[{ "op": "replace", "path": "/spec/mig_controller_enable_cache", "value": true}]'

2. Facultatif : augmentez les limites de mémoire de la CR MigrationController en exécutant la commande suivante :

   $ oc -n openshift-migration patch migrationcontroller migration-controller --type=json --patch \
     '[{ "op": "replace", "path": "/spec/mig_controller_limits_memory", "value": <10Gi>}]'

3. Facultatif : augmentez le nombre de requêtes de mémoire MigrationController CR en exécutant la commande suivante :

   $ oc -n openshift-migration patch migrationcontroller migration-controller --type=json --patch \
     '[{ "op": "replace", "path": "/spec/mig_controller_requests_memory", "value": <350Mi>}]'

Procédure

1. Dans la console Web MTC, cliquez sur Migration Plans.
2. Cliquez sur le numéro Migrations en regard d’un plan de migration pour afficher la page Migrations.
3. Cliquez sur une migration pour en afficher les détails (Migration details).

4. Développez Migration resources pour afficher les ressources de migration et leur état dans une arborescence.

   Note

   Pour résoudre un échec de migration, commencez par une ressource de haut niveau qui a échoué, puis descendez dans l’arborescence vers les ressources de niveau inférieur.

5. Cliquez sur le menu Options à côté d'une ressource et sélectionnez l'une des options suivantes :

   • La commande Copy oc describe copie la commande dans votre presse-papiers.

     • Connectez-vous au cluster concerné, puis exécutez la commande.

       Les conditions et les événements de la ressource sont affichés au format YAML.

   • La commande Copy oc logs copie la commande dans votre presse-papiers.

     • Connectez-vous au cluster concerné, puis exécutez la commande.

       Si la ressource prend en charge le filtrage des journaux, un journal filtré est affiché.

   • View JSON affiche les données de la ressource au format JSON dans un navigateur Web.

     Les données sont les mêmes que celles de la sortie de la commande oc get <resource>.

Procédure

1. Dans la console Web MTC, cliquez sur Migration Plans.
2. Cliquez sur le numéro Migrations en regard d’un plan de migration.
3. Cliquez sur View logs.
4. Cliquez sur l’icône Copier pour copier la commande oc logs dans votre presse-papiers.

5. Connectez-vous au cluster concerné et saisissez la commande dans la CLI.

   Le journal agrégé relatif au plan de migration est affiché.

Procédure

1. Procurez-vous le pod mig-log-reader :

   $ oc -n openshift-migration get pods | grep log

2. Saisissez la commande suivante pour afficher un seul journal de migration :

   $ oc -n openshift-migration logs -f <mig-log-reader-pod> -c color 1

   1

   L’option -c plain affiche le journal sans couleurs.

Procédure

1. Dans la console Web OpenShift Container Platform, cliquez sur Observe → Metrics.

2. Saisissez une requête PromQL, sélectionnez une fenêtre temporelle à afficher, puis cliquez sur Run Queries.

   Si votre navigateur Web n’affiche pas tous les résultats, utilisez la console Prometheus.

Procédure

1. Accédez au répertoire dans lequel vous souhaitez stocker les données must-gather.

2. Exécutez la commande oc adm must-gather pour l’une des options de collecte de données suivantes :

   • Pour collecter les données relatives à l’heure écoulée :

     $ oc adm must-gather --image=registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.7

     Les données sont enregistrées en tant que must-gather/must-gather.tar.gz. Vous pouvez envoyer ce fichier dans un dossier d’assistance sur le Portail Client de Red Hat.

   • Pour collecter les données des dernières 24 heures :

     $ oc adm must-gather --image=registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.7 \
       -- /usr/bin/gather_metrics_dump

     Cette opération peut prendre beaucoup de temps. Les données sont enregistrées sous le nom must-gather/metrics/prom_data.tar.gz.

Procédure

1. Décompressez le fichier prom_data.tar.gz :

   $ tar -xvzf must-gather/metrics/prom_data.tar.gz

2. Créez une instance Prometheus locale :

   $ make prometheus-run

   La commande produit l’URL Prometheus.

   Sortie

   Started Prometheus on http://localhost:9090

3. Démarrez un navigateur Web et accédez à l’URL pour afficher les données à l’aide de la console Web Prometheus.

4. Après avoir consulté les données, supprimez l’instance Prometheus, ainsi que les données :

   $ make prometheus-cleanup

Procédure

1. Vérifiez l’état d’une CR MigMigration :

   $ oc get migmigration <migmigration> -o yaml

   Exemple de sortie

   status:
     conditions:
     - category: Warn
       durable: true
       lastTransitionTime: "2021-01-26T20:48:40Z"
       message: 'Final Restore openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf: partially failed on destination cluster'
       status: "True"
       type: VeleroFinalRestorePartiallyFailed
     - category: Advisory
       durable: true
       lastTransitionTime: "2021-01-26T20:48:42Z"
       message: The migration has completed with warnings, please look at `Warn` conditions.
       reason: Completed
       status: "True"
       type: SucceededWithWarnings

2. Vérifiez l’état de la CR Restore en utilisant la commande Velero describe :

   $ oc -n {namespace} exec deployment/velero -c velero -- ./velero \
     restore describe <restore>

   Exemple de sortie

   Phase:  PartiallyFailed (run 'velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf' for more information)
   
   Errors:
     Velero:     <none>
     Cluster:    <none>
     Namespaces:
       migration-example:  error restoring example.com/migration-example/migration-example: the server could not find the requested resource

3. Vérifiez les journaux de la CR Restore en utilisant la commande Velero logs :

   $ oc -n {namespace} exec deployment/velero -c velero -- ./velero \
     restore logs <restore>

   Exemple de sortie

   time="2021-01-26T20:48:37Z" level=info msg="Attempting to restore migration-example: migration-example" logSource="pkg/restore/restore.go:1107" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf
   time="2021-01-26T20:48:37Z" level=info msg="error restoring migration-example: the server could not find the requested resource" logSource="pkg/restore/restore.go:1170" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

   Le message d’erreur du journal de la CR Restore (the server could not find the requested resource) indique la cause de l’échec partiel de la migration.

Procédure

1. Répertoriez les CR MigMigration dans l’espace de nommage openshift-migration :

   $ oc get migmigration -n openshift-migration

   Exemple de sortie

   NAME                                   AGE
   88435fe0-c9f8-11e9-85e6-5d593ce65e10   6m42s

2. Inspectez la CR MigMigration :

   $ oc describe migmigration 88435fe0-c9f8-11e9-85e6-5d593ce65e10 -n openshift-migration

   La sortie est semblable aux exemples suivants.

Procédure

1. Vérifiez l’état de la CR MigMigration :

   $ oc describe migmigration <pod> -n openshift-migration

   La sortie comprend le message d’état suivant :

   Exemple de sortie

   Some or all transfer pods are not running for more than 10 mins on destination cluster

2. Sur le cluster source, procurez-vous les détails d’un espace de nommage migré :

   $ oc get namespace <namespace> -o yaml 1

   1

   Indiquez l’espace de nommage migré.

3. Sur le cluster cible, modifiez l’espace de nommage migré :

   $ oc edit namespace <namespace>

4. Ajoutez les annotations openshift.io/node-selector manquantes à l’espace de nommage migré comme dans l’exemple suivant :

   apiVersion: v1
   kind: Namespace
   metadata:
     annotations:
       openshift.io/node-selector: "region=east"
   ...

5. Exécutez à nouveau le plan de migration.

Procédure

1. Dans la console Web MTC, cliquez sur Migration plans.
2. Cliquez sur le menu Options à côté d'un plan de migration et sélectionnez Rollback sous Migration.

3. Cliquez sur Rollback et attendez que le processus d’annulation soit terminé.

   Dans les détails du plan de migration, le message Rollback succeeded est affiché.

4. Vérifiez que l’annulation a réussi dans la console Web OpenShift Container Platform du cluster source :

   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 le volume persistant migré est correctement mis en service.

Procédure

1. Créez une CR MigMigration sur la base de l’exemple suivant :

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigMigration
   metadata:
     labels:
       controller-tools.k8s.io: "1.0"
     name: <migmigration>
     namespace: openshift-migration
   spec:
   ...
     rollback: true
   ...
     migPlanRef:
       name: <migplan> 1
       namespace: openshift-migration
   EOF

   1

   Indiquez le nom de la CR MigPlan associée.

2. Dans la console Web MTC, vérifiez que les ressources de projet ayant fait l’objet d’une migration ont été supprimées du cluster cible.
3. Vérifiez que les ressources migrées sont présentes dans le cluster source et que l’application est en cours d’exécution.

Procédure

1. Supprimez les pods stage sur tous les clusters :

   $ oc delete $(oc get pods -l migration.openshift.io/is-stage-pod -n <namespace>) 1

   1

   Espaces de nommage spécifiés dans la CR MigPlan.

2. Réactivez l’application sur le cluster source en dimensionnant les réplicas sur leur nombre d’avant la migration :

   $ oc scale deployment <deployment> --replicas=<premigration_replicas>

   L’annotation migration.openshift.io/preQuiesceReplicas dans la CR Deployment affiche le nombre de réplicas d’avant la migration :

   apiVersion: extensions/v1beta1
   kind: Deployment
   metadata:
     annotations:
       deployment.kubernetes.io/revision: "1"
       migration.openshift.io/preQuiesceReplicas: "1"

3. Vérifiez que les pods d’application sont en cours d’exécution sur le cluster source :

   $ oc get pod -n <namespace>