Zu den während der Migration generierten Artefaktdateien gehören:
deployment_spec.yaml: Die YAML-Datei, die die Arbeitslast konfiguriert.
Sie können kubectl apply mit dieser Datei verwenden, um die Arbeitslast auf einem anderen Cluster, z. B. einem Produktions- oder Testcluster, bereitzustellen.
Dockerfile: Das Dockerfile, das zum Erstellen des Images für die migrierte VM verwendet wird.
Einige Plug-ins generieren möglicherweise mehr als ein Dockerfile und mehr als eine deployment_spec.yaml-Datei, z. B. wenn auf einer VM mehrere Tomcat-Server gleichzeitig ausgeführt werden.
Wenn Sie die Migration zu einem Linux-Systemcontainer ausführen, generiert die Migrate to Containers-Befehlszeile außerdem die folgenden Dateien:
migration.yaml: Eine Kopie des Migrationsplans. Damit können Sie prüfen, was im Rahmen der Migration ausgeführt wurde.
blocklist.yaml: Die Liste der Containerdienste, die anhand Ihrer Einstellungen im Migrationsplan deaktiviert werden sollen. Bearbeiten Sie diese Datei, um die Liste der Dienste zu steuern. Weitere Informationen finden Sie unter Liste der Dienste anpassen.
logs.yaml: Eine Liste der Logdateien, die auf der Quell-VM erkannt wurden. Daten, die von der migrierten Arbeitslast in diese Logdateien geschrieben werden, werden an Cloud Logging weitergeleitet.
Bearbeiten Sie diese Datei, um das Schreiben von Logs zu steuern.
Weitere Informationen finden Sie unter In Cloud Logging geschriebene Logdaten anpassen.
Datei deployment_spec.yaml
Diese Datei ist eine YAML-Datei, mit der Sie die Arbeitslast in einem anderen Cluster bereitstellen können, z. B. in einem Test- oder Produktionscluster.
Wenn Sie keine Datenmigration konfigurieren, generieren Sie ein Deployment-Objekt.
Wenn die Datenmigration konfiguriert ist, generieren Sie ein zustandsorientiertes Set-Objekt.
Dockerfile
Verwenden Sie diese Datei, wenn Sie eine neue Version des Images erstellen müssen.
Sie können beispielsweise ein Paket installieren und anschließend ein neues Image erfassen. Das Neuerstellen des Images kann auch nützlich sein, wenn die Migrate to Containers-Befehlszeile beispielsweise mit einer Fehlerkorrektur aktualisiert wird und Sie das Image mit der neuen Laufzeit der Migrate to Containers-Befehlszeile neu erstellen möchten. Die aktualisierte Laufzeit ist in Container Registry verfügbar.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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)."]]
