Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

9.3. Scripts de migration automatiques

Vous pouvez ajouter jusqu’à quatre scripts de migration automatiques à un seul plan de migration, chaque script s’exécutant alors lors d’une phase différente de la migration. Les scripts de migration automatiques exécutent des tâches telles que la personnalisation de la quiescence des applications, la migration manuelle des types de données non pris en charge et la mise à jour des applications après la migration.

Un script de migration automatique s’exécute sur un cluster source ou cible lors de l’une des étapes de migration suivantes :

  • PreBackup : avant la sauvegarde des ressources sur le cluster source.
  • PostBackup : après la sauvegarde des ressources sur le cluster source.
  • PreRestore : avant la restauration des ressources sur le cluster cible.
  • PostRestore : après la restauration des ressources sur le cluster cible.

Vous pouvez créer un script automatique en créant un playbook Ansible qui s’exécute avec l’image Ansible par défaut ou avec un conteneur de scripts automatiques personnalisé.

Playbook Ansible

Le playbook Ansible est monté sur un conteneur de scripts automatiques en tant qu’objet ConfigMap. Ce conteneur s’exécute comme une tâche, en utilisant le cluster, le compte de service et l’espace de nommage spécifiés dans la ressource personnalisée MigPlan. L’exécution de la tâche se poursuit jusqu’à ce que la limite par défaut de 6 tentatives soit atteinte ou que l’opération soit terminée correctement. L’opération se poursuit même si le pod initial est évincé ou supprimé.

L'image d'exécution Ansible par défaut est registry.redhat.io/rhmtc/openshift-migration-hook-runner-rhel7:1.7. Cette image est basée sur l’image Ansible Runner et inclut python-openshift pour les ressources Ansible Kubernetes, ainsi qu’un binaire oc mis à jour.

Conteneur de scripts automatiques personnalisé

Vous pouvez utiliser un conteneur de scripts automatiques personnalisé au lieu de l’image Ansible par défaut.

9.3.1. Écriture d’un playbook Ansible pour un script de migration automatique

Vous pouvez écrire un playbook Ansible à utiliser comme script de migration automatique. Le script automatique est ajouté à un plan de migration en utilisant la console Web MTC ou en spécifiant des valeurs pour les paramètres spec.hooks dans le manifeste de la ressource personnalisée (CR) MigPlan.

Le playbook Ansible est monté sur un conteneur de scripts automatiques en tant qu’objet ConfigMap. Ce conteneur s’exécute comme une tâche, en utilisant le cluster, le compte de service et l’espace de nommage spécifiés dans la ressource personnalisée MigPlan. Le conteneur de scripts automatiques utilise un token de compte de service spécifié afin que les tâches ne doivent pas être authentifiées avant leur exécution dans le cluster.

9.3.1.1. Modules Ansible

Vous pouvez utiliser le module Ansible shell pour exécuter des commandes oc.

Exemple de module shell

- hosts: localhost
  gather_facts: false
  tasks:
  - name: get pod name
    shell: oc get po --all-namespaces
Copy to Clipboard

Vous pouvez utiliser des modules kubernetes.core, tels que k8s_info, pour interagir avec les ressources Kubernetes.

Exemple de module k8s_facts

- hosts: localhost
  gather_facts: false
  tasks:
  - name: Get pod
    k8s_info:
      kind: pods
      api: v1
      namespace: openshift-migration
      name: "{{ lookup( 'env', 'HOSTNAME') }}"
    register: pods

  - name: Print pod name
    debug:
      msg: "{{ pods.resources[0].metadata.name }}"
Copy to Clipboard

Vous pouvez utiliser le module fail pour produire un état de sortie non nul dans les cas où un tel état ne serait normalement pas produit, garantissant ainsi la détection du succès ou de l’échec d’un script automatique. Les scripts automatiques s’exécutent comme des tâches, et leur état de réussite ou d’échec est basé sur l’état de sortie du conteneur de tâches.

Exemple de module fail

- hosts: localhost
  gather_facts: false
  tasks:
  - name: Set a boolean
    set_fact:
      do_fail: true

  - name: "fail"
    fail:
      msg: "Cause a failure"
    when: do_fail
Copy to Clipboard

9.3.1.2. Variables d’environnement

Le nom du CR MigPlan et les espaces de noms de la migration sont transmis en tant que variables d'environnement au conteneur de crochets. Ces variables sont accessibles à l'aide du plugin lookup.

Exemples de variables d’environnement

- hosts: localhost
  gather_facts: false
  tasks:
  - set_fact:
      namespaces: "{{ (lookup( 'env', 'MIGRATION_NAMESPACES')).split(',') }}"

  - debug:
      msg: "{{ item }}"
    with_items: "{{ namespaces }}"

  - debug:
      msg: "{{ lookup( 'env', 'MIGRATION_PLAN_NAME') }}"
Copy to Clipboard

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat