Once you've finished migrating a workload using a processing cluster, you can download the YAML files that were generated as part of the migration.
These files were generated so that you can deploy your migrated workload container to another cluster, such as a testing or production cluster.
This topic describes how you can download the generated files and review them for your own use in another cluster.
Before you begin
Download deployment YAML files
When the migration completes, you should see a message such as the following when you request status:
migctl migration status my-migration NAME STATE STATUS PROGRESS AGE my-migration completed COMPLETED [15/15] 8m35s
Once the migration is complete, get the generated YAML artifacts with
migctl migration get-artifacts.
migctl migration get-artifacts my-migration
get-artifacts command downloads files generated during the migration:
deployment_spec.yaml -- The YAML file that configures your workload.
You can use
kubectl applywith this file to deploy the workload to a another cluster, such as a production or test cluster.
Dockerfile -- The Dockerfile used to build the image for your migrated VM.
migration.yaml -- A copy of the migration plan.
You can use this to verify what was done as part of the migration.
Note that now that the migration has completed, you can only perform it again by deleting the migration and re-running it.
This is a YAML file you can use to deploy your workload to another cluster,
such as a test or production cluster. The file's contents will differ
depending on the kind of migration you created with the
intent flag of the
migctl migration create command.
|Intent value||State||Output results|
The YAML defines a stateless application. Its Pods will be identical and managed as a Service.
The YAML defines a stateful application. Its Pods are each unique... associated with persistent volumes.
The Dockerfile used to build the image for your migrated VM.
Use this file if you need to generate a new version of the image. For example, you might want to install a package and capture a new image afterward. Rebuilding the image can also be useful when the Migrate for Anthos is upgraded (such as with a bug fix) and you want to rebuild the image with the new Migrate for Anthos runtime. The upgraded runtime will be available in the Container Registry.
You can edit this file as you would any other Dockerfile to customize your image. For tips, see Best practices for writing Dockerfiles. Also, see Post-migration image updates for information on editing the Dockerfile.
# Please refer to the documentation: # https://cloud.google.com/migrate/anthos/docs/dockerfile-reference # Image containing data captured from the source VM FROM gcr.io/my-project/my-vm-instance-1-non-runnable-base:v1.0.0 as source-content # If you want to update parts of your image, add you commands here. # For example: # RUN apt-get update # RUN apt-get install -y \ # package1=version \ # package2=version \ # package3=version # RUN yum update # RUN wget http://github.com FROM gcr.io/my-project/v2k-run-embedded:v1.3.0 as migrate-for-anthos-runtime COPY --from=source-content / / # Migrate for Anthos image includes entrypoint ENTRYPOINT [ "/.v2k.go" ]
This is a copy of the migration you created. Use this file to verify that the migration details Migrate for Anthos is using match those you specified in the migration plan.
Note that you should not use this file to re-run the migration. Once you've
executed the migration, you can only re-run it by deleting the migration (with
migctl migration delete) and
running it again from your migration plan.