Como personalizar um plano de migração

Revise o arquivo do plano de migração gerado ao criar a migração e personalize ele antes de prosseguir com a execução. Os detalhes do plano de migração serão usados para extrair os artefatos do contêiner da carga de trabalho da VM de origem. Além disso, serão gerados arquivos de implantação do Kubernetes para implementar a imagem do contêiner em outros clusters, como os de produção.

Nesta seção, você verá uma descrição do conteúdo do plano de migração e dos tipos de personalização disponíveis antes de executar a migração e gerar artefatos de implantação.

Pré-requisitos

• Para seguir este tópico, é necessário criar uma migração e ter o arquivo do plano de migração resultante.

Editar o plano de migração

Para editar o plano de migração, use a ferramenta migctl ou o console do Google Cloud.

migctl

É necessário fazer o download do plano de migração antes de editá-lo:

1. Faça o download do plano de migração. O plano é representado por GenerateArtifactsFlow:

   migctl migration get my-migration
   

2. Edite o plano de migração transferido por download, my-migration.yaml, em um editor de texto.

3. Quando tiver terminado as edições, salve e faça upload do plano de migração revisado:

   migctl migration update my-migration --file my-migration.yaml
   

4. Repita essas etapas se mais alterações forem necessárias.

Console

Edite o plano de migração no console do Google Cloud usando o editor YAML. O plano de migração é representado pelo CRD GenerateArtifactsFlow:

1. Abra a página do Migrate for Anthos and GKE no console do Cloud.

   Acessar a página "Migrar para contêineres".

2. Clique na guia Migrações para exibir uma tabela com as migrações disponíveis.

3. Na linha da migração desejada, selecione o Nome da migração para abrir a guia Detalhes.

4. Selecione a guia YAML.

   Observação: também é possível selecionar Fazer o download do plano de migração para fazer o download de uma cópia local.

5. Edite o plano de migração conforme necessário.

6. Quando terminar de editar, será possível:

   1. salvar o plano de migração. Em seguida, execute manualmente a migração para gerar os artefatos de migração. Use o procedimento mostrado em Como executar uma migração.

   2. salvar e gerar os artefatos. Execute a migração usando as edições feitas para gerar os artefatos de migração. O processo é o mesmo descrito em Como executar uma migração. Depois, monitore a migração conforme descrito em Como monitorar uma migração.

CRD

É necessário fazer o download do plano de migração, editá-lo e aplicá-lo. O plano de migração é representado pelo CRD GenerateArtifactsFlow:

1. Consiga o nome do GenerateArtifactsFlow:

   kubectl get migrations.anthos-migrate.cloud.google.com -n v2k-system my-migration -o jsonpath={.status.resources.generateArtifacts.name}

   O padrão de nomenclatura é retornado na forma de generate-artifacts-flow-id.

2. Consiga o GenerateArtifactsFlow por nome e grave em um arquivo chamado my-plan.yaml:

   kubectl get generateartifactsflows.anthos-migrate.cloud.google.com -n v2k-system generate-artifacts-flow-id -o yaml > my-plan.yaml

3. Edite o plano de migração conforme necessário.

4. Aplique o arquivo:

   kubectl apply -f my-plan.yaml

Especificar o conteúdo a ser excluído da migração

Por padrão, o Migrate for Anthos and GKE exclui o conteúdo comum da VM que não seja relevante no contexto do GKE. É possível personalizar esse filtro.

Com o valor do campo filters, você lista os caminhos que precisam ser excluídos da migração e não farão parte da imagem do contêiner. Use esse valor para listar as regras de filtragem de rsync que especificam quais arquivos transferir e quais ignorar. Insira um sinal de menos no começo de cada caminho ou arquivo para especificar que o item na lista precisa ser excluído da migração. A lista é processada seguindo a ordem das linhas no YAML, e as exclusões/inclusões são avaliadas de acordo com isso.

Para mais informações, consulte a seção "INCLUDE/EXCLUDE PATTERN RULES" do manual do rsync (em inglês).

Os arquivos grandes demais para serem incluídos na imagem do Docker serão listados no arquivo YAML. Isso sinalizará arquivos com mais de 1 GB para você considerar. Imagens do Docker muito grandes ou maiores do que 15 GB correm o risco de falhar durante a migração.

É possível editar a lista YAML para adicionar ou remover caminhos. Veja um exemplo de YAML abaixo, que inclui exclusões de exemplo, bem como notificações de arquivos grandes e esparsos. Siga as orientações in-line para:

• Para excluir as pastas detectadas, remova a marca de comentário e coloque-as na seção de filtros globais.
• Mova as pastas detectadas para um volume permanente removendo os comentários e colocando-as na seção da pasta de dados.

Considere também excluir ou mover os arquivos esparsos detectados da mesma maneira.

  global:
    # Files and directories to exclude from the migration, in rsync format.
    filters:
      - "- *.swp"
      - "- /etc/fstab"
      - "- /boot/"
      - "- /tmp/*"
      - "- /var/log/*.log*"
      - "- /var/log/*/*.log*"
      - "- /var/cache/*"

    ## The data folders below are too large to be included in the docker image.
    ## Consider uncommenting and placing them under either the global filters
    ## or the data folder section.
      # - '- /a' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
      # - '- /a/c' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)

    ## Sparse files will fail the run of a docker image. Consider excluding the below
    ## detected files and any other sparse files by uncommenting and placing them in
    ## the global filters section, or export them to a persistent volume by specifying
    ## them in the data folder section.
      # - '- /a/b' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
      # - '- /a/d' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)

Definir o processamento do volume de dados

O campo dataVolumes especifica uma lista de pastas a serem incluídas no volume de dados como parte da migração.

Observação: o campo filters descrito acima especifica os caminhos da pasta a serem excluídos da migração. Esses filtros são aplicados à migração antes da seção dataVolumes. Portanto, se uma pasta for excluída por uma das regras na lista filters, ela também será excluída do volume de dados exportados.

Por padrão, folders contém um valor de marcador que precisa ser alterado. Se você não alterar o valor do marcador, verá um erro ao gerar os artefatos de migração, no formato Replace the folder placeholder with the relevant path: <migration-name>.data.yaml

        dataVolumes:

        # Folders to include in the data volume, e.g. "/var/lib/mysql"
        # Included folders contain data and state, and therefore are automatically excluded from a generated container image
        # Replace the placeholder with the relevant path and add more items if needed
        - folders:
          - <folders>

Veja abaixo um exemplo que especifica uma lista de pastas a serem incluídas no volume de dados:

        - folders:
          - /var/lib/mysql
          - /my-data-folder

Definir o nome da imagem do contêiner

Com o valor do campo image, você define os nomes e os locais de duas imagens criadas a partir de uma VM migrada. Será possível alterar esses valores se preferir usar outros nomes.

Por padrão, o Migrate for Anthos and GKE copia os arquivos e diretórios que representam a carga de trabalho da migração para o Container Registry para uso durante a migração. O processo de migração adapta a carga de trabalho extraída para uma imagem executável no GKE.

O Migrate for Anthos and GKE preserva os arquivos e diretórios da VM original (no caminho base) no registro. Essa imagem funciona como uma camada de base não executável que inclui os arquivos de carga de trabalho extraídos. Ela é combinada com a camada de software do ambiente de execução do Migrate for Anthos and GKE para criar uma imagem de contêiner executável.

O uso de camadas separadas simplifica as próximas atualizações da imagem do contêiner. Isso é possível ao realizar atualizações separadas da camada de base ou de software do Migrate for Anthos and GKE, conforme necessário.

Não é possível executar essa imagem, mas ela possibilita que o Migration for Anthos and GKE atualizem o contêiner dela quando você faz o upgrade do Migration for Anthos and GKE.

Os valores dos campos base e name especificam as imagens criadas no registro.

• base: o nome da imagem criada dos arquivos e diretórios de VM copiados da plataforma de origem. Não é possível executar esta imagem no GKE porque ela não foi adaptada para implantação.
• name: o nome da imagem executável que é usada para o contêiner. Ela inclui o conteúdo da VM de origem e o ambiente de execução do Migrate for Anthos and GKE, o que possibilita a execução.

        image:
          # Review and set the name for extracted non-runnable base image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          base: "centos-mini-non-runnable-base"

          # Review and set the name for runnable container image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          name: "centos-mini"

Por padrão, uma tag correspondente ao carimbo de data/hora da migração é aplicada automaticamente a esses valores. Essa tag está neste formato:

MM-DD-YYYY--hh:mm:ss

Para aplicar sua própria tag, substituindo a tag padrão, edite o CRD e adicione-o conforme mostrado abaixo:

        image:
          # Review and set the name for extracted non-runnable base image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          base: "centos-mini-non-runnable-base:tag"

          # Review and set the name for runnable container image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          name: "centos-mini:tag"

Observação: como a tag é usada para armazenar os valores em cache, confirme que ela seja exclusiva para todos os CRDs GenerateArtifactsFlow.

Configurar o armazenamento permanente

   pvc:
     spec:
       accessModes:
       - ReadWriteOnce
       resources:
         requests:
         # Modify the required disk size on the storage field below based on the capacity needed
           storage: 10G

Observação: ao usar clusters do Anthos na AWS para migrar VMs do Linux, a VM de origem pode fazer referência a um volume EBS criptografado. Se você quiser exportar dados para um volume criptografado, edite o plano de migração adequadamente. Consulte Pré-requisitos para migrar VMs do Linux usando clusters de processamento da AWS para mais informações.

Personalizar a lista de serviços

Por padrão, o Migrate for Anthos and GKE desativa serviços desnecessários em uma VM quando você o migra para um contêiner. Esses serviços às vezes podem causar problemas no contêiner migrado ou não são necessários em um contexto de contêiner.

Além dos serviços desativados automaticamente pelo Migration for Anthos and GKE, é possível desativar opcionalmente outros serviços:

• O Migrate for Anthos and GKE descobre automaticamente serviços que você pode desativar, opcionalmente, e os lista no plano de migração. Esses serviços, como ssh ou um servidor da Web, podem não ser necessários na carga de trabalho migrada, mas cabe a você tomar essa decisão. Se necessário, edite o plano de migração para desativar esses serviços.

• O Migration for Anthos and GKE não lista todos os serviços em execução na VM de origem. Por exemplo, ele omite serviços relacionados ao sistema operacional. Também é possível, opcionalmente, editar o plano de migração para adicionar sua própria lista de serviços a serem desativados no contêiner migrado.

O campo systemServices especifica a lista de serviços descobertos pelo Migrate for Anthos and GKE. Exemplo:

    systemServices:
    - enabled: true|false
      name: service-name
    - enabled: true|false
      name: service-name
      ...

Para desativar um serviço, defina enabled como false.

O Migrate for Anthos and GKE não lista todos os serviços em execução na VM de origem, como os serviços relacionados ao sistema operacional. Também é possível adicionar outros serviços à lista. Por exemplo, para desativar service2 e o serviço cron:

    systemServices:
    - enabled: true
      name: service1
    - enabled: false
      name: service2
    - enabled: false
      name: cron

Ao executar uma migração para gerar os artefatos de migração, o Migration for Anthos and GKE cria o arquivo blocklist.yaml. Esse arquivo lista os serviços de contêiner a serem desativados com base nas configurações no plano de migração. Exemplo:

service_list:
- name: disabled-services
  services:
  # Because you used systemServices above to disabled service2 and cron:
  - service2
  - cron

Para modificar posteriormente a lista de serviços desativados:

• Edite a lista de serviços no plano de migração.
• Execute a migração para gerar novamente os artefatos de migração, incluindo um arquivo blocklist.yaml atualizado, um arquivo deployment_spec.yaml e o Dockerfile.

Como alternativa, depois de executar uma migração para gerar os artefatos de migração, é possível editar o arquivo blocklist.yaml diretamente, recriar e enviar a imagem do contêiner por conta própria. Exemplo:

1. Atualize o arquivo blocklist.yaml.

2. Recrie e envie a imagem do contêiner.

   A maneira de recriar e enviar a imagem do contêiner depende do ambiente de criação. Você pode usar:

   1. gcloud para recriar a imagem e enviá-la ao Container Registry, conforme descrito em Guia de início rápido: criar.
   2. docker build, conforme descrito em Criar e executar a imagem.

3. Depois de recriar e enviar a nova imagem, abra o arquivo deployment_spec.yaml em um editor para atualizar o local da imagem:

   spec:
    containers:
      - image: new-image-location
   

   Por exemplo, new-image-location pode ser my-new-image:v1.0 se você usou gcloud para recriar a imagem e enviá-la para o Container Registry.

Personalizar endpoints de serviço

O plano de migração inclui a matriz endpoints que define as portas e os protocolos usados para criar os Serviços do Kubernetes fornecidos pela carga de trabalho migrada. É possível adicionar, editar ou excluir definições de endpoints para personalizar o plano de migração.

Observação: Para gerar automaticamente as entradas na matriz endpoints, primeiro execute a ferramenta de avaliação de adequação.

Para cada endpoint de serviço detectado, o Migrate for Anthos and GKE adicionam a seguinte definição ao plano de migração:

    endpoints:
    - port: PORT_NUMBER
      protocol: PORT_PROTOCOL
      name: PORT_NAME

Em que:

• PORT_NUMBER especifica o número da porta do contêiner para que as solicitações enviadas ao serviço são roteadas.
• PORT_PROTOCOL especifica o protocolo da porta, como HTTP, HTTPS ou TCP. Consulte Protocolos compatíveis para ver a lista completa.
• PORT_NAME especifica o nome usado para receber o endpoint do serviço. O Migrate for Anthos and GKE gera uma PORT_NAME exclusiva para cada definição de endpoint gerada.

Por exemplo, o Migration for Anthos and GKE detecta os seguintes endpoints:

  endpoints:
    - port: 80
      protocol: HTTP
      name: backend-server-nginx
    - port: 6379
      protocol: TCP
      name: backend-server-redis

Para definir o valor da propriedade name, o Migrate for Anthos and GKE combina o nome da VM de origem, backend-server neste exemplo, com o nome do programa do Serviço. Os nomes gerados são compatíveis com as convenções de nomenclatura do Kubernetes e são exclusivos dentro do plano de migração. Por exemplo, o plano de migração acima cria um serviço que segmenta o Nginx na porta 80 sobre HTTP.

Para nomes duplicados, o Migrate for Anthos and GKE anexa um sufixo de contador. Por exemplo, se o Nginx estiver associado a duas portas, ele adicionará o sufixo -2 ao name na segunda definição:

  endpoints:
    - port: 80
      protocol: HTTP
      name: backend-server-nginx
    - port: 8080
      protocol: HTTPS
      name: backend-server-nginx-2
    - port: 6379
      protocol: TCP
      name: backend-server-redis

Ao executar uma migração para gerar os artefatos de migração, o Migrate for Anthos and GKE cria uma definição de Serviço no arquivo deployment_spec.yaml para cada endpoint.

Por exemplo, mostrado abaixo é uma definição Service no arquivo deployment_spec.yaml:

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  name: backend-server-nginx
spec:
  ports:
  - port: 80
    protocol: HTTP
    targetPort: 80
  selector:
    app: backend-server
status:
  loadBalancer: {}

Personalizar montagens NFS

O Migrate for Anthos and GKE inclui montagens de NFS no plano de migração gerado. Essas informações são coletadas do arquivo fstab e gravadas na matriz nfsMounts no plano de migração. É possível adicionar ou editar definições de ponto de montagem do NFS para personalizar o plano de migração.

Observação: as entradas na matriz nfsMounts são desativadas por padrão. Ative-os se quiser que o Migrate for Anthos and GKE gere entradas no arquivo deployment_spec.yaml para cada motagem do NFS.

Ao gerar o plano de migração, o Migrate for Anthos and GKE:

• Ignora as ativações NFS para /sys e /dev.
• Ignora as montagens de NFS com um tipo diferente de nfs ou nfs4.

Cada ativação do NFS no plano de migração inclui o endereço IP do servidor ou o nome DNS e o caminho de ativação local no formato:

    nfsMounts:
    - mountPoint: MOUNT_POINT
      exportedDirectory: DIR_NAME
      nfsServer: IP_OR_DNS
      mountOptions:
         - OPTION_1
         - OPTION_2
      enabled: false|true

Em que:

• MOUNT_POINT especifica o ponto de montagem obtido de fstab.
• DIR_NAME especifica o nome do diretório compartilhado.
• IP_OR_DNS especifica o endereço IP ou o nome DNS do servidor que hospeda o ponto de ativação.
• OPTION_N especifica qualquer opção extraída do fstab para o ponto de ativação.

Por exemplo, para a seguinte entrada em fstab:

<file system>       <mount point>   <type>  <options>   <dump>  <pass>
10.49.232.26:/vol1  /mnt/test       nfs     rw,hard     0       0

O Migration for Anthos and GKE gera a seguinte entrada no plano de migração:

    nfsMounts:
    - mountPoint: /mnt/test
      exportedDirectory: /vol1
      nfsServer: 10.49.232.26
      mountOptions:
         - rw
         - hard
      enabled: false

Para configurar o Migrate for Anthos and GKE para processar entradas na matriz nfsMounts, defina enabled como true para a entrada mountPoint. É possível ativar uma, algumas ou todas as entradas mountPoints, editar ou adicionar suas próprias entradas.

Ao executar uma migração para gerar os artefatos de migração, o Migrate for Anthos and GKE cria uma definição de volumes e volumeMounts e uma definição de PersistentVolume e PersistentVolumeClaim no arquivo deployment_spec.yaml para cada montagem de NFS ativada.

Observação: o Migrate for Anthos and GKE exige que os servidores de NFS sejam acessíveis a partir do cluster de implantação que hospeda a carga de trabalho do contêiner migrado. No entanto, o Migration for Anthos and GKE não validam essa conectividade. Um contêiner migrado com um problema de conectividade não pode ser iniciado e talvez seja necessário editar o arquivo deployment_spec.yaml para corrigir o problema. Consulte Como acessar compartilhamentos de arquivos de clusters do Google Kubernetes Engine para mais informações.

Por exemplo, mostrado abaixo é uma definição volumeMounts no arquivo deployment_spec.yaml:

    spec:
      containers:
          - image: gcr.io/myimage-1/image-name
            name: some-app
            volumeMounts:
                   - mountPath: /sys/fs/cgroup
                     name: cgroups
                   - mountPath: /mnt/test
                     name: nfs-pv

Em que o valor de name é um identificador exclusivo gerado pelo Migrate for Anthos and GKE.

Veja abaixo um exemplo de definições PersistentVolumeClaim e PersistentVolume no arquivo deployment_spec.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Mi
  storageClassName: ""
  volumeName: nfs-pv

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  mountOptions:
    - rw
    - hard
  nfs:
    path: /vol1
    server: 10.49.232.26

Personalizar dados de registro gravados no Cloud Logging

Normalmente, uma VM de origem grava informações em um ou mais arquivos de registro. Como parte da migração da VM, é possível configurar a carga de trabalho migrada para gravar essas informações de registro no Cloud Logging.

Observação: as versões anteriores do Migrate for Anthos e do GKE eram compatíveis com a personalização do registro usando um ConfigMap no cluster de carga de trabalho de destino, conforme descrito em Como configurar a geração de registros no Cloud Logging. Nesta seção, descrevemos como usar o arquivo logs.yaml para configurar a geração de registros. Se o arquivo logs.yaml existir, as configurações de registro definidas por um ConfigMap serão ignoradas.

Quando você gera o plano de migração, o Migrate for Anthos e o GKE pesquisam automaticamente arquivos de destino de registro na VM de origem. Em seguida, o Migrate for Anthos e o GKE gravam informações sobre os arquivos detectados na área logPaths do plano de migração:

spec:
    ...
    logPaths:
    - appName: APP_NAME
      globs:
      - LOG_PATH

Exemplo:

spec:
    ...
    logPaths:
    - appName: tomcat
      globs:
      - /var/log/tomcat*/catalina.out

Quando você gera os artefatos de migração, o Migrate for Anthos e o GKE geram o arquivo logs.yaml do plano de migração. Esse arquivo contém a lista de arquivos de registro detectados na VM de origem. Por exemplo, na definição logsPath acima, logs.yaml contém:

logs:
  tomcat:
  - /var/log/tomcat*/catalina.out

Neste exemplo, quando você implanta a carga de trabalho migrada, as informações de registro gravadas em catalina.out são gravadas automaticamente no Cloud Logging.

As entradas aparecem em uma linha no registro, no seguinte formato:

DATE TIME APP_NAME LOG_OUTPUT

O exemplo a seguir ilustra o formulário com uma entrada do Tomcat:

2019-09-22 12:43:08.681193976 +0000 UTC tomcat log-output

Para configurar a geração de registros, é possível:

• Edite o plano de migração antes de gerar os artefatos de migração para adicionar, remover ou editar as entradas logPaths. Quando você gera os artefatos de migração, essas edições são refletidas no arquivo logs.yaml.

• Edite logs.yaml depois de gerar os artefatos de migração para adicionar, remover ou editar entradas logs.

A vantagem de editar o plano de migração é que suas edições são refletidas em logs.yaml sempre que você gerar os artefatos. Se você editar logs.yaml diretamente e gerar os artefatos novamente por algum motivo, será necessário reaplicar as edições ao logs.yaml.

Próximas etapas

• Executar uma migração