Post-migration image updates

The container artifacts you create with the migctl migration generate-artifacts command aren't meant only for deployment of the migrated workload in the target cluster. They're also for "Day 2" maintenance operations, including applying application and user-mode OS software updates, security patches, editing embedded configurations, adding or replacing files, and for updating the Migrate for Anthos runtime software.

Reviewing the generated image Dockerfile

Such maintenance operations leverage the generated dockerfile and the captured system image layer. When combined with the Migrate for Anthos runtime layer, these can be built into an executable container image.

The generated container artifacts have been created with CI/CD pipeline build phase integration in mind, as described in the following diagram:

Diagram showing CI/CD pipeline.

The Dockerfile is structured as a multi-stage build, for easier maintenance and manipulation, while keeping the image from inflating.

Here's a sample of a generated Dockerfile:

# Please refer to the documentation:
# https://cloud.google.com/migrate/anthos/docs/dockerfile-reference

FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.3.0 as migrate-for-anthos-runtime

# Image containing data captured from the source VM
FROM gcr.io/myproject/myworkload-non-runnable-base:v1.0.0 as source-content

# 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

COPY --from=migrate-for-anthos-runtime / /

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

The second FROM directive references the captured system image layer from the migrated VM. This layer is not runnable by itself and needs to be combined with the Migrate for Anthos runtime layer to build an executable image.

For more information on building container images with Cloud Build, see Building container images.

Updating migrated workload components layer

For any updates or modifications you want to apply to the migrated workload image layer, you should apply them after the second FROM directive.

In the following example we update a container image migrated from a SUSE Enterprise Linux (SLES) VM as source, using Cloud Build and the gcloud tool. The following example updates the SLES distro openssh package.

Updated Dockerfile:

# Image containing data captured from the source VM
FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.3.0 as migrate-for-anthos-runtime

# Image containing data captured from the source VM
FROM gcr.io/myproject/myworkload-non-runnable-base:v1.0.0 as source-content

# 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

RUN zypper ref -s && zypper -n in openssh
COPY --from=migrate-for-anthos-runtime / /

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

Building the updated image:

Download the generated Dockerfile from the Cloud Storage bucket into a local directory in your Cloud Shell environment.
Edit the Dockerfile to add the highlighted RUN directive as in the example above.
Build the updated image and push to Container Registry with an updated version tag, ensuring you allow enough time for the build to finish. In the following example, the image is in the current directory:
```
gcloud builds submit --timeout 4h --tag gcr.io/myproject/mySUSEworkload:v1.0.1 .
```
You may use the newly built image to update an existing deployment -- such as to perform a rolling upgrade on the deployed application:
```
kubectl set image deployment/myWorkload my-app=gcr.io/myproject/mySUSEworkload:v1.0.1 --record
```

Updating the Migrate for Anthos layer version

When new versions of Migrate for Anthos software are released, you ca,n update that software version in deployed workload images. Such updates may include new functionality, enhancements or bug fixes.

To update the Migrate for Anthos software layer, you will need to edit the Dockerfile and change the version tag to the updated version you want to apply.

Using the previous example, you can update the version from 1.3.0 to the hypothetical version 1.3.1 by editing the FROM directive to the following:

FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.3.1 as migrate-for-anthos-runtime

After updating the Dockerfile, you will need to build a new workload container image version and apply it to existing deployments to get them updated.