Os arquivos de artefatos gerados durante a migração incluem:
deployment_spec.yaml: o arquivo YAML que configura a carga de trabalho.
É possível usar o kubectl apply com esse arquivo para implantar a carga de trabalho em outro
cluster, como de produção ou de teste.
Dockerfile: usado para criar a imagem da VM
migrada.
Alguns plug-ins podem gerar mais de um Dockerfile e um arquivo deployment_spec.yaml,
por exemplo, se você tiver uma VM executando vários servidores Tomcat ao mesmo
tempo.
Além disso, ao executar a migração para um contêiner do sistema Linux,
a CLI do Migrate to Containers também gera os seguintes arquivos:
migration.yaml: uma cópia do plano de migração. É possível usar esse arquivo
para verificar o que foi feito como parte da migração.
blocklist.yaml: a lista de serviços de contêineres a serem desativados com base nas
configurações no plano de migração. Edite esse arquivo para controlar a lista de
serviços. Para mais informações, consulte
Personalizar a lista de serviços.
logs.yaml: uma lista de arquivos de registros detectados na VM de origem. Os dados gravados
nesses arquivos de registros pela carga de trabalho migrada são encaminhados para o
Cloud Logging.
Edite este arquivo para controlar a gravação de registros.
Para mais informações, consulte
Personalizar dados de registros gravados no Cloud Logging.
Arquivo deployment_spec.yaml
É um arquivo YAML usado para implantar a carga de trabalho em
outro cluster, como de teste ou de produção.
Se você não configurar uma migração de dados, vai gerar um objeto Deployment.
Quando a migração de dados é configurada, você gera um objeto StatefulSet.
Dockerfile
Use esse arquivo se precisar gerar uma nova versão da imagem.
Por exemplo, se quiser instalar um pacote e depois capturar uma nova
imagem. A recriação da imagem também pode ser útil quando a
CLI do Migrate to Containers é atualizada, por exemplo, para implementar uma correção de bug,
e você quer recriar a imagem com o
novo ambiente de execução da CLI do Migrate to Containers. O ambiente de execução atualizado fica disponível
no Container Registry.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-04 UTC."],[],[],null,["# Review the migration artifacts\n==============================\n\nThis page describes the migration artifacts that the Migrate to Containers CLI\ngenerates as part of your migration.\n\nBefore you begin\n----------------\n\n- You should have first [created a migration plan](/migrate/containers/docs/m2c-cli/create-a-migration-plan) and [executed the migration](/migrate/containers/docs/m2c-cli/execute-the-migration-plan).\n\nAbout the generated artifact files\n----------------------------------\n\nThe artifact files generated during the migration include the following:\n\n- `deployment_spec.yaml`: The YAML file that configures your workload.\n You can use `kubectl apply` with this file to deploy the workload to another\n cluster, such as a production or test cluster.\n\n- Dockerfile: The Dockerfile used to build the image for your migrated\n VM.\n\nSome plugins might generate more than one Dockerfile and `deployment_spec.yaml`\nfile, for example if you have a VM running multiple Tomcat servers at the\nsame time.\n\nAdditionally, when you run the migration to a Linux system container,\nMigrate to Containers CLI also generates the following files:\n\n- `migration.yaml`: A copy of the migration plan. You can use this file\n to verify what was done as part of the migration.\n\n- `blocklist.yaml`: The list of container services to disable based on your\n settings in the migration plan. Edit this file to control the list of\n services. For more information, see\n [Customize the services list](/migrate/containers/docs/m2c-cli/linux/customizing-a-migration-plan#customize_the_services_list).\n\n- `logs.yaml`: A list of log files detected on the source VM. Data written\n to these log files by the migrated workload is forwarded to\n [Cloud Logging](/logging/docs/overview).\n Edit this file to control log writing.\n For more information, see\n [Customize log data written to Cloud Logging](/migrate/containers/docs/m2c-cli/linux/customizing-a-migration-plan#log-files).\n\n### The `deployment_spec.yaml` file\n\nThis file is a YAML file that you can use to deploy your workload to\nanother cluster, such as a test or production cluster.\nIf you don't configure a data migration, you will generate a `Deployment`\nobject.\nWhen the data migration is configured, you generate a stateful set object.\n\n### Dockerfile\n\nUse this file if you need to generate a new version of the image.\nFor example, you might want to install a package and capture a new image\nafterward. Rebuilding the image can also be useful when the\nMigrate to Containers CLI is upgraded, for example to implement a bug fix,\nand you want to rebuild the image with the\nnew Migrate to Containers CLI runtime. The upgraded runtime is available in\nthe Container Registry.\n\nYou can edit this file like any other Dockerfile to customize your image.\nFor tips, see\n[Best practices for writing Dockerfiles](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/).\nFor information on how to edit the Dockerfile, see\n[Post-migration image updates](/migrate/containers/docs/post-migration-image-updates).\n\nWhat's next\n-----------\n\n- Learn how to [migrate data](/migrate/containers/docs/m2c-cli/migrate-data)."]]