11.3. Hooks für die Migration


Sie können einem einzelnen Migrationsplan bis zu vier Hooks für die Migration hinzufügen, wobei jeder Hook in einer anderen Phase der Migration ausgeführt wird. Hooks für die Migration übernehmen Aufgaben wie die Anpassung der Anwendungsruhezeit, die manuelle Migration nicht unterstützter Datentypen und die Aktualisierung von Anwendungen nach der Migration.

Ein Hook für die Migration wird auf einem Quell- oder Ziel-Cluster bei einem der folgenden Migrationsschritte ausgeführt:

  • PreBackup: Bevor die Ressourcen auf dem Quell-Cluster gesichert werden.
  • PostBackup: Nachdem die Ressourcen auf dem Quell-Cluster gesichert wurden.
  • PreRestore: Bevor die Ressourcen auf dem Ziel-Cluster wiederhergestellt werden.
  • PostRestore: Nachdem die Ressourcen auf dem Ziel-Cluster wiederhergestellt wurden.

Sie können einen Hook erstellen, indem Sie ein Ansible-Playbook erstellen, das mit dem standardmäßigen Ansible-Image oder mit einem benutzerdefinierten Hook-Container ausgeführt wird.

Ansible-Playbook

Das Ansible-Playbook wird in einen Hook-Container als Config-Map eingebunden. Der Hook-Container wird als Auftrag ausgeführt und verwendet den Cluster, den Service Account und den Namespace, die in der Custom Resource MigPlan angegeben sind. Der Auftrag wird so lange ausgeführt, bis er die Standardgrenze von 6 Wiederholungen erreicht oder erfolgreich abgeschlossen wird. Dies gilt auch dann, wenn der ursprüngliche Pod gestoppt oder beendet wird.

Das standardmäßige Ansible-Laufzeit-Image ist registry.redhat.io/rhmtc/openshift-migration-hook-runner-rhel7:1.6. Dieses Image basiert auf dem Ansible-Runner-Image und enthält python-openshift für Ansible-Kubernetes-Ressourcen und eine aktualisierte oc-Binärdatei.

Kundenspezifischer Hook-Container

Sie können einen eigenen Hook-Container anstelle des standardmäßigen Ansible-Image verwenden.

11.3.1. Schreiben eines Ansible-Playbooks für einen Hook für die Migration

Sie können ein Ansible-Playbook schreiben, das als Hook für die Migration dient. Der Hook wird einem Migrationsplan über die MTC-Webkonsole oder durch Angabe von Werten für die spec.hooks-Parameter im Manifest der Custom Resource (CR) MigPlan hinzugefügt.

Das Ansible-Playbook wird als Config-Map in einen Hook-Container eingebunden. Der Hook-Container wird als Auftrag ausgeführt und verwendet den Cluster, den Service Account und den Namespace, die in der CR MigPlan angegeben sind. Der Hook-Container verwendet ein bestimmtes Service Account-Token, sodass die Aufgaben keine Authentifizierung erfordern, bevor sie im Cluster ausgeführt werden.

11.3.1.1. Ansible-Module

Sie können das Ansible-Modul shell verwenden, um oc-Befehle auszuführen.

Beispiel für ein shell-Modul

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

Sie können kubernetes.core-Module wie z. B. k8s_info verwenden, um mit Kubernetes-Ressourcen zu interagieren.

Beispiel für ein k8s_facts-Modul

- 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

Sie können das Modul fail verwenden, um einen Exit-Status ungleich 0 in Fällen zu erzeugen, in denen dieser Status normalerweise erzeugt werden würde. Dies würde die Erkennung eines erfolgreichen oder fehlerhaften Hook sicherstellen. Hooks werden als Aufträge ausgeführt und der Erfolg oder Misserfolg eines Hook basiert auf dem Exit-Status des Auftragscontainers.

Beispiel für ein fail-Modul

- 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

11.3.1.2. Umgebungsvariablen

Der CR-Name MigPlan und die Namespaces für die Migration werden als Umgebungsvariablen an den Hook-Container übergeben. Der Zugriff auf diese Variablen erfolgt über das Plugin lookup.

Beispiel für Umgebungsvariablen

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

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

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

Nach oben
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2025 Red Hat