Review generated deployment files
Once you've finished migrating a workload using a processing cluster, download the YAML files that were generated as part of the migration.
These files, referred to as migration artifacts, 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 artifact files and review them for your own use in another cluster.
Before you begin
You should have first created a migration and executed the migration.
Ensure the user performing the download has read access to the artifacts repository. See Defining data repositories for more.
About the generated artifact files
The artifact files generated during the migration include:
deployment_spec.yaml
-- The YAML file that configures your workload.You can use
kubectl apply
with this file to deploy the workload to another cluster, such as a production or test cluster.Dockerfile -- The Dockerfile used to build the image for your migrated VM.
blocklist.yaml
-- The list of container services to disable based on your settings in the migration plan. Edit this file to control the list of services. See Customizing the services list.migration.yaml
-- A copy of the migration plan.You can use this file to verify what was done as part of the migration.
logs.yaml
-- A list of log files detected on the source VM. Data written to these log files by the migrated workload is forwarded to Cloud Logging. Edit this file to control log writing. See Customizing log data written to Cloud Logging.
These files are described in more detail below.
Download all artifact files
migctl
When the migration completes, you should see a message such as the following when you request status:
migctl migration status my-migration NAME CURRENT-OPERATION PROGRESS STEP STATUS AGE my-migration GenerateArtifacts [1/1] ExtractImage Completed 14m23s
Once the migration is complete, download all the generated artifact files with
migctl migration get-artifacts
.
migctl migration get-artifacts my-migration
CRD
When the migration completes, download all migration artifacts:
Get the Cloud Storage bucket containing the artifacts:
kubectl get migrations.anthos-migrate.cloud.google.com -n v2k-system my-migration -o jsonpath={.status.artifacts.deploymentFiles.bucket}
This command returns the bucket name in the form:
bucket-migration-artifacts
Get the Cloud Storage migration manifests YAML file:
kubectl get migrations.anthos-migrate.cloud.google.com -n v2k-system my-migration -o jsonpath={.status.artifacts.deploymentFiles.artifactsManifestFile}
This command returns the manifest YAML file name in the form:
bucket-migration-artifacts/v2k-system-my-migration/ID/manifest.yaml
Go to Cloud Storage in the Google Cloud console and fetch the manifest file. The example manifest file shown below includes the
artifacts
URLs :artifacts: - https:/storage.cloud.google.com/bucket-name/v2k-system-my-migration/ID/deployment_spec.yaml - https:/storage.cloud.google.com/bucket-name/v2k-system-my-migration/ID/Dockerfile - https:/storage.cloud.google.com/bucket-name/v2k-system-my-migration/ID/migration.yaml imageUrl: gcr.io/velos-auto-1/matanvm:v1.0.0 name: m1-84xqp namespace: v2k-system uid: daf762-d9-42-bfc-47b71255a version: "1.0"
Open the
artifacts
URLs in a browser to download the artifacts.
deployment_spec.yaml
This file is a YAML file you can use to deploy your workload to another cluster, such as a test or production cluster. If you do not configure a data migration, you will generate a Deployment object. When the data migration is configure, you generate a stateful set object.
Dockerfile
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 to Containers is upgraded (such as with a bug fix) and you want to rebuild the image with the new Migrate to Containers runtime. The upgraded runtime is 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/containers/docs/dockerfile-reference
FROM gcr.io/my-project/v2k-run-embedded:v1.12.0
# 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
COPY --from=migrate-for-anthos-runtime / /
ADD blocklist.yaml /.m4a/blocklist.yaml
ADD logs.yaml /code/config/logs/logsArtifact.yaml
# If you want to update parts of the image, add your 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
# Migrate to Containers image includes entrypoint
ENTRYPOINT [ "/.v2k.go" ]
migration.yaml
This file is a copy of the migration you created. Use this file to verify that the migration details Migrate to Containers 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 after deleting the migration (with
migctl migration delete
or the Google Cloud console and running it again from your migration plan.
blocklist.yaml
This file lists the container services to disable based on your settings in the migration plan. See Customizing the services list for more information on using this file.
What's next
- Learn how to configure logging to Cloud Logging.