11.3. Hooks de migração
Você pode adicionar até quatro hooks de migração a um único plano de migração, com cada hook sendo executado em uma etapa diferente da migração. Os hooks de migração realizam tarefas como personalização da inatividade dos aplicativos, migração manual de tipos de dados sem suporte e atualização de aplicativos após a migração.
Um hook de migração é executado em um cluster de origem ou de destino, em uma das seguintes etapas de migração:
-
PreBackup: antes que o backup dos recursos seja feito no cluster de origem. -
PostBackup: depois que o backup dos recursos for feito no cluster de origem. -
PreRestore: antes que os recursos sejam restaurados no cluster de destino. -
PostRestore: depois que os recursos forem restaurados no cluster de destino.
É possível criar um hook criando um playbook do Ansible que seja executado com a imagem padrão do Ansible ou com um contêiner de hook personalizado.
Playbook do Ansible
O playbook do Ansible é montado em um contêiner de hook como um mapa de configuração. O contêiner de hook é executado como um trabalho, usando o cluster, a conta de serviço e o namespace especificados no recurso personalizado MigPlan. O trabalho continua a ser executado até atingir o limite padrão de 6 tentativas ou uma conclusão com êxito. Isso prosseguirá mesmo se o pod inicial for removido ou encerrado.
A imagem padrão do tempo de execução do Ansible é registry.redhat.io/rhmtc/openshift-migration-hook-runner-rhel7:1.6. Essa imagem é baseada na imagem do Ansible Runner e inclui python-openshift para recursos do Kubernetes para o Ansible e um binário oc atualizado.
Contêiner de hook personalizado
É possível usar um contêiner de hook personalizado em vez da imagem padrão do Ansible.
11.3.1. Criação de playbook do Ansible para um hook de migração Copiar o linkLink copiado para a área de transferência!
Você pode criar um playbook do Ansible para usar como um hook de migração. O hook é adicionado a um plano de migração usando o console web do MTC ou especificando valores para os parâmetros spec.hooks no manifesto de recurso personalizado (CR) MigPlan.
O playbook do Ansible é montado em um contêiner de hook como um mapa de configuração. O contêiner do hook é executado como um trabalho, usando o cluster, a conta de serviço e o namespace especificados no CR MigPlan. O contêiner do hook usa um token de conta de serviço especificado para que as tarefas não exijam autenticação antes de serem executadas no cluster.
11.3.1.1. Módulos do Ansible Copiar o linkLink copiado para a área de transferência!
Você pode usar o módulo shell do Ansible para executar comandos oc.
Exemplo de módulo shell
- hosts: localhost
gather_facts: false
tasks:
- name: get pod name
shell: oc get po --all-namespaces
Você pode usar os módulos kubernetes.core, como k8s_info, para interagir com os recursos do Kubernetes.
Exemplo de módulo 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 }}"
Você pode usar o módulo fail para produzir um status de saída não zero nos casos em que um status de saída não zero normalmente não seria produzido, assegurando que o êxito ou a falha de um hook sejam detectados. Os hooks são executados como trabalhos e o status de êxito ou falha de um hook é baseado no status de saída do contêiner do trabalho.
Exemplo de módulo falha
- 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. Variáveis de ambiente Copiar o linkLink copiado para a área de transferência!
O nome do CR MigPlan e os namespaces de migração são passados como variáveis de ambiente ao contêiner do hook. Essas variáveis são acessadas usando o plugin lookup.
Exemplo de variáveis de 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') }}"