Red Hat Summit Red Hat SummitSupportoConsoleSviluppatoriInizia una provaContatti

11.3. Hook di migrazione

È possibile aggiungere fino a quattro hook di migrazione a un singolo piano di migrazione, con ogni hook in esecuzione in una diversa fase della migrazione. Gli hook di migrazione eseguono compiti come la personalizzazione della inattività delle applicazioni, la migrazione manuale dei tipi di dati non supportati e l'aggiornamento delle applicazioni dopo la migrazione.

Un hook di migrazione viene eseguito su un cluster di origine o di destinazione in uno dei seguenti stadi della migrazione:

  • PreBackup: prima di eseguire il backup delle risorse sul cluster di origine.
  • PostBackup: dopo il backup delle risorse sul cluster di origine.
  • PreRestore: prima che le risorse siano ripristinate sul cluster di destinazione.
  • PostRestore: dopo il ripristino delle risorse sul cluster di destinazione.

È possibile creare un hook creando un Ansible Playbook che viene eseguito con l'immagine predefinita di Ansible o con un container degli hook personalizzato.

Ansible Playbook

L'Ansible Playbook è montato su un container degli hook come mappa di configurazione. Il container degli hook viene eseguito come un processo, utilizzando il cluster, l'account di servizio e lo spazio dei nomi specificati nella risorsa personalizzata MigPlan. Il processo continua a essere eseguito fino a quando non raggiunge il limite predefinito di 6 tentativi o viene completato correttamente. Questo continua anche se il pod iniziale viene eliminato o terminato.

L'immagine di runtime predefinita di Ansible è registry.redhat.io/rhmtc/openshift-migration-hook-runner-rhel7:1.6. Questa immagine è basata sull'immagine di Ansible Runner e include python-openshift per le risorse Kubernetes Ansible e un file binario oc aggiornato.

Container degli hook personalizzato

È possibile usare un container degli hook personalizzato invece dell'immagine predefinita di Ansible.

11.3.1. Scrivere un Ansible Playbook per un hook di migrazione
Copia collegamento

È possibile scrivere un Ansible Playbook da usare come hook di migrazione. L'hook viene aggiunto a un piano di migrazione usando la console web di MTC o specificando i valori per i parametri spec.hooks nel manifest della risorsa personalizzata MigPlan.

L'Ansible Playbook è montato su un container degli hook come mappa di configurazione. Il container degli hook viene eseguito come un processo, utilizzando il cluster, l'account di servizio e lo spazio dei nomi specificati nella risorsa personalizzata MigPlan. Il container degli hook utilizza un token di account di servizio specificato in modo che i compiti non richiedano l'autenticazione prima di essere eseguiti nel cluster.

11.3.1.1. Moduli Ansible
Copia collegamento

È possibile usare il modulo Ansible shell per eseguire i comandi oc.

Modulo shell di esempio

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

È possibile usare i moduli kubernetes.core, come k8s_info, per interagire con le risorse di Kubernetes.

Modulo k8s_facts di esempio

- 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 Toggle word wrap

È possibile usare il modulo fail per generare uno stato di uscita non zero in casi in cui uno stato di uscita non zero non sarebbe normalmente generato, assicurando così di rilevare la riuscita o l'esito negativo di un hook. Gli hook vengono eseguiti come processi e lo stato di successo o esito negativo di un hook è basato sullo stato di uscita del container dei processi.

Modulo fail di esempio

- 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 Toggle word wrap

11.3.1.2. Variabili d'ambiente
Copia collegamento

Il nome della risorsa personalizzata MigPlan e gli spazi dei nomi di migrazione vengono passati come variabili d'ambiente al container degli hook. Si accede a queste variabili usando il plug-in lookup.

Esempio di variabili d'ambiente

- 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 Toggle word wrap

Torna in cima
Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2025 Red Hat