Reviewing 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.

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 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.

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

Console

When the migration completes, you see Artifacts generated in the Status column of the migration. To download all migration artifacts:

  1. Open the Migrate for Anthos page in the Cloud Console.

    Go to the Migrate for Anthos page

  2. In the row for the desired migration, under Options select either:

    1. Review artifacts

      In the panel that opens on the right, download each artifact separately.

    2. Download artifact links YAML

      A new browser tab opens displaying the artifacts manifest yaml. Use the artifacts URLs to download the artifacts.

      Shown below is an example manifest that includes the artifacts URLs:

      artifacts:
      - https:/storage.cloud.google.com/bucket-name/folder/deployment_spec.yaml
      - https:/storage.cloud.google.com/bucket-name/folder/Dockerfile
      - https:/storage.cloud.google.com/bucket-name/folder/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"

CRD

When the migration completes, download all migration artifacts:

  1. 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
  2. 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/manifest.yaml
  3. Go to Cloud Storage in the 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/folder/deployment_spec.yaml
     - https:/storage.cloud.google.com/bucket-name/folder/Dockerfile
     - https:/storage.cloud.google.com/bucket-name/folder/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"
  4. Use the artifacts URLs to download the artifacts.

deployment_spec.yaml

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
Image Stateless

The YAML defines a stateless application. Its Pods will be identical and managed as a Service.

  • Deployment -- Represents a set of identical Pods deployed from the image resulting from your migrated VM and stored in the Container Registry.
  • Service -- Groups Pods in your Deployment into a single resource accessible from a stable IP address.

    This is a suggested configuration for you to review. By default, this Service specification includes no load-balancing, with a single cluster internal IP reachable only from within the cluster. The Kubernetes endpoints controller will modify the DNS configuration to return records (addresses) that point to the Pods, which are labeled with "app": "app-name".

    You might want to change the service so that it exposes the Pods outside of Kubernetes.

  • Logging configuration -- Configures logging to Cloud Logging by listing many of the most common log files. You can add other log files that you want included in Cloud Logging by adding your own entries under logs.
ImageAndData Stateful

The YAML defines a stateful application. Its Pods are each unique... associated with persistent volumes.

  • StatefulSet -- Represents a set of Pods deployed from the image resulting from your migrated VM and stored in the Container Registry.
  • Service -- Groups Pods in your StatefulSet into a single resource accessible from a stable IP address.

    This is a suggested configuration for you to review. By default, this Service specification includes no load-balancing, with a single cluster internal IP reachable only from within the cluster. The Kubernetes endpoints controller will modify the DNS configuration to return records (addresses) that point to the Pods, which are labeled with "app": "[appName]".

    You might want to change the service so that it exposes the Pods outside of Kubernetes.

  • PersistentVolume -- Resource to manage durable storage backed, by default, by Compute Engine Persistent Disks.
  • PersistentVolumeClaim -- Represents a request for and claim to the PersistentVolume resource. PersistentVolumeClaim objects request a specific size, and access mode for the PersistentVolume.
  • Logging configuration -- Configures logging to Cloud Logging by listing many of the most common log files. You can add other log files that you want included in Cloud Logging by adding your own entries under logs.
Data None.

Intro

Docker file

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.5.0 as migrate-for-anthos-runtime

COPY --from=source-content / /

# Migrate for Anthos image includes entrypoint
ENTRYPOINT [ "/.v2k.go" ]

migration.yaml

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 after deleting the migration (with migctl migration delete or the GCP Console) and running it again from your migration plan.

Next Steps