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:
Faça o download do plano de migração. O plano é representado por GenerateArtifactsFlow:
migctl migration get my-migration
Edite o plano de migração transferido por download,
my-migration.yaml
, em um editor de texto.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
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:
Abra a página do Migrate for Anthos and GKE no console do Cloud.
Clique na guia Migrações para exibir uma tabela com as migrações disponíveis.
Na linha da migração desejada, selecione o Nome da migração para abrir a guia Detalhes.
Selecione a guia YAML.
Edite o plano de migração conforme necessário.
Quando terminar de editar, será possível:
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.
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:
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
.Consiga o
GenerateArtifactsFlow
por nome e grave em um arquivo chamadomy-plan.yaml
:kubectl get generateartifactsflows.anthos-migrate.cloud.google.com -n v2k-system generate-artifacts-flow-id -o yaml > my-plan.yaml
Edite o plano de migração conforme necessário.
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.
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"
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
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 arquivodeployment_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:
Atualize o arquivo
blocklist.yaml
.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:
gcloud
para recriar a imagem e enviá-la ao Container Registry, conforme descrito em Guia de início rápido: criar.docker build
, conforme descrito em Criar e executar a imagem.
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ê usougcloud
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 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.
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
ounfs4
.
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.
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.
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 arquivologs.yaml
.Edite
logs.yaml
depois de gerar os artefatos de migração para adicionar, remover ou editar entradaslogs
.
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
.