Personalizar plano de migração de VMs do Linux

Antes de executar um plano de migração, confira e, opcionalmente, personalize-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.

Antes de começar

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 de migração das cargas de trabalho do Linux é representado por LinuxMigrationCommonSpec:

    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 --main-config 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 das cargas de trabalho do Linux é representado pela CRD LinuxMigrationCommonSpec:

  1. Abra a página "Migrate to Containers" no Console do Google Cloud.

    Acesse a página do Migrate to Containers.

  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.

  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 das cargas de trabalho do Linux é representado pela CRD LinuxMigrationCommonSpec:

  1. Consiga o nome do AppXGenerateArtifactsFlow:

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

    O padrão de nomenclatura é retornado na forma de appx-generateartifactsflow-id.

  2. Para encontrar o plano de migração por nome e gravar em um arquivo chamado my-plan.yaml:

    kubectl -n v2k-system get appxgenerateartifactsflows.anthos-migrate.cloud.google.com -o jsonpath={.spec.appXGenerateArtifactsConfig} appx-generateartifactsflow-id > my-plan.yaml

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

  4. Aplique o arquivo:

    kubectl patch appxgenerateartifactsflows.anthos-migrate.cloud.google.com --type merge -n v2k-system --patch '{"spec": {"appXGenerateArtifactsConfig": '"$(jq -n --rawfile plan my-plan.yaml '$plan')"'}}' appx-generateartifactsflow-id

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

Por padrão, o Migrate to Containers exclui o conteúdo típico da VM que não é 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 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 to Containers copia os arquivos e diretórios que representam a carga de trabalho de sua 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 to Containers preserva no registro os arquivos e diretórios da VM original no caminho base. 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 to Containers para criar uma imagem executável de contêiner.

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 to Containers, conforme necessário.

Esta imagem não pode ser executada, mas permite que o Migrate to Containers atualize o contêiner a partir do original ao fazer upgrade para o Migrate to Containers.

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 to Containers, 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"

Personalizar a lista de serviços

Por padrão, o Migrate to Containers desativa os serviços desnecessários em uma VM quando ela é migrada 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 Migrate to Containers, é possível desativar opcionalmente outros serviços:

  • O Migrate to Containers 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 Migrate to Containers 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 to Containers. Exemplo:

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

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

O Migrate to Containers 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
      probed: false
    - enabled: false
      name: service2
      probed: false
    - enabled: false
      name: cron
      probed: false

Ao executar uma migração para gerar os artefatos de migração, o Migrate to Containers 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.

Para cada endpoint de Serviço, adicione 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 to Containers gera uma PORT_NAME exclusiva para cada definição de endpoint gerada.

Por exemplo, o Migrate to Containers 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 to Containers 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 recurso o Migrate to Containers 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

Quando você executa uma migração para gerar os artefatos de migração, o Migrate to Containers cria uma definição de Service 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 to Containers 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.

Ao gerar o plano de migração, o Migrate to Containers:

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

Cada montagem de NFS no plano de migração inclui o endereço IP do servidor e o caminho de montagem local no formato:

    nfsMounts:
    - mountPoint: MOUNT_POINT
      exportedDirectory: DIR_NAME
      nfsServer: IP
      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 especifica o endereço IP do servidor que hospeda o ponto de montagem.
  • 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 Migrate to Containers 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 to Containers 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.

Quando você executa uma migração para gerar os artefatos de migração, o Migrate to Containers cria uma definição de volumes e volumeMounts e uma definição de PersistentVolume e PersistentVolumeClaim em o arquivo deployment_spec.yaml para cada ativação NFS ativada.

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 to Containers.

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.

Quando você gera o plano de migração, o Migrate to Containers pesquisa automaticamente os arquivos de destino do registro na VM de origem. Em seguida, o Migrate to Containers grava informações sobre os arquivos detectados na área logPaths do plano de migração:

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

Exemplo:

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

Quando você gera os artefatos de migração, o Migrate to Containers gera 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.

Definir sondagens de integridade do Linux v2kServiceManager

É possível monitorar o tempo de inatividade e o status pronto dos contêineres gerenciados especificando as sondagens no plano de migração do servidor da Web do Tomcat. O monitoramento da sondagem de integridade pode ajudar a reduzir a inatividade dos contêineres migrados e oferecer um monitoramento melhor.

Os estados de integridade desconhecidos podem gerar degradação de disponibilidade, monitoramento de disponibilidade falso positivo e possível perda de dados. Sem uma sondagem de integridade, o kubelet só pode pressupor a integridade de um contêiner e enviar o tráfego para uma instância que não esteja pronta. Isso pode causar perda de tráfego. O Kubelet também pode não detectar contêineres que estão no estado congelado e não os reiniciará.

Uma sondagem de integridade funciona executando uma pequena instrução de script quando o contêiner é iniciado. O script verifica as condições bem-sucedidas, que são definidas pelo tipo de sondagem usada a cada período. O período é definido no plano de migração por um campo do periodSeconds. É possível executar ou definir esses scripts manualmente.

Para saber mais sobre as sondagens do kubelet, consulte Configurar atividade, prontidão e startups na documentação do Kubernetes.

Há dois tipos de sondagens disponíveis para configuração. As duas sondagens são probe-v1-core definidas na referência probe-v1-core e compartilham a mesma função que os campos correspondentes de container-v1-core

  • Sondagem de atividade: são usadas para saber quando reiniciar um contêiner.

  • Sondagem de prontidão: são usadas para saber quando um contêiner está pronto para começar a aceitar tráfego. Para começar a enviar tráfego a um pod somente quando a sondagem for bem-sucedida, especifique uma sondagem de prontidão. Uma sondagem de prontidão pode atuar de maneira semelhante a uma sondagem de atividade, mas uma sondagem de prontidão nas especificações indica que um pod vai começar sem receber nenhum tráfego e só vai começar a receber tráfego depois que a sondagem for bem-sucedida.

Após a descoberta, a configuração da sondagem é adicionada ao plano de migração. As sondagens podem ser usadas na configuração padrão, conforme mostrado abaixo. Para desativar as sondagens, remova a seção probes do yaml.

v2kServiceManager: true
deployment:
  probes:
    livenessProbe:
      exec:
        command:
        - gamma
        - /probe

    readinessProbe:
      exec:
        command:
        - gamma
        - /probe
      initialDelaySeconds: 60
      periodSeconds: 5

image:
  # Disable system services that do not need to be executed at the migrated workload containers.
  # Enable the 'probed' property to include system services in the container health checks.
  systemServices:
  - enabled: true
    name: apache2
    probed: true
  - enabled: true
    name: atd
    probed: false

Por padrão, toda a sondagem de serviço fica desativada. Defina qual subconjunto de serviços será monitorado.

Há quatro maneiras predefinidas de verificar um contêiner usando uma sondagem. Cada sondagem precisa definir exatamente um destes quatro mecanismos:

  • exec: executa um comando especificado no contêiner. A execução será considerada bem-sucedida se o código de status de saída for 0.
  • grpc: executa uma chamada de procedimento remoto usando 'gRPC". As sondagens "gRPC" são um recurso Alfa.
  • httpGet: executa uma solicitação GET HTTP para o endereço IP do pod em uma porta e caminho especificados. A solicitação será considerada bem-sucedida se o código de status for maior ou igual a 200 e menor que 400.
  • tcpSocket: executa uma verificação TCP no endereço IP do pod em uma porta especificada. O diagnóstico será considerado bem-sucedido se a porta estiver aberta.

Por padrão, um plano de migração ativa o método de sondagem exec. Use a configuração manual do seu plano de migração para ativar outro método.

Para adicionar dependências externas à sondagem de prontidão, ao usar a sondagem de atividade padrão, defina uma sondagem de prontidão executiva e um script que implemente a lógica.

A seguir