This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.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
- hosts: localhost
gather_facts: false
tasks:
- name: get pod name
shell: oc get po --all-namespaces
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 }}"
- 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 }}"
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
- 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
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') }}"
- 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') }}"