This section describes the migration plan's contents and the kinds of customizations you might consider before you execute the migration and generate deployment artifacts.
Before you begin
- This topic assumes that you've already created a migration and have the resulting migration plan file.
Editing the migration plan
Edit the migration plan by using the migctl
tool or the Google Cloud Console.
migctl
You must download the migration plan before you can edit it:
Download the migration plan. The migration plan is represented by GenerateArtifactsFlow:
migctl migration get my-migration
Edit the downloaded migration plan,
my-migration.yaml
, in a text editor.When your edits are complete, upload the edited migration plan:
migctl migration update my-migration --file my-migration.yaml
Repeat these steps if more edits are necessary.
Console
Edit the migration plan in the Google Cloud Console by using the YAML editor. The migration plan is represented by GenerateArtifactsFlow:
Open the Migrate for Anthos page in the Cloud Console.
Click the Migrations tab to display a table containing the available migrations.
In the row for the desired migration, select the migration Name to open the Details tab.
Select the YAML tab.
Edit the migration plan as necessary.
When you are done editing, you can either:
Save the migration plan. You then have to manually execute the migration to generate the migration artifacts using the procedure shown in Executing a migration.
Save and generate the artifacts. Execute the migration by using your edits to generate the migration artifacts. The process is the same as described in Executing a migration. You can then monitor the migration as described in Monitoring a migration.
CRD
You must download the migration plan, edit it, then apply it. The migration plan is represented by GenerateArtifactsFlow:
Get the name of the GenerateArtifactsFlow:
kubectl get migrations.anthos-migrate.cloud.google.com -n v2k-system my-migration -o jsonpath={.status.resources.generateArtifacts.name}
The name is returned in the form
generate-artifacts-flow-id
.Get the GenerateArtifactsFlow by name and write to a file named
my-plan.yaml
:kubectl get generateartifactsflows.anthos-migrate.cloud.google.com -n v2k-system generate-artifacts-flow-id -o yaml > my-plan.yaml
Edit the migration plan as necessary.
Apply the file:
kubectl apply -f my-plan.yaml
Impact of Intent on migration plan
The contents of the migration plan you generated will differ depending on the kind of migration you created with the Intent flag.
This topic describes the purpose of each migration plan section. Each section indicates which Intent value is relevant for YAML in the section. For more information on using the Intent flag, see Creating a migration.
Specifying content to exclude from the migration
Intent: Any
By default, Migrate for Anthos excludes typical VM content that isn't relevant in the context of GKE. You can customize that filter.
The filters
field value lists paths that should be excluded from migration
and will not be part of either the container image or the data volume.
The field's value lists rsync filter rules that specify which files to transfer
and which to skip. Preceding each path and file with a minus sign specifies that
the item in the list should be excluded from migration. The list is processed
according to the order of lines in the YAML, and exclusions/inclusions are
evaluated accordingly.
For more, see the INCLUDE/EXCLUDE PATTERN RULES section of the rsync manpage
You can edit this list to add or remove paths.
global:
# Files and directories to exclude from the migration, in rsync format
filters:
- "- *.swp"
- "- /etc/fstab"
- "- /boot/"
- "- /tmp/*"
- "- /var/log/*.log*"
- "- /var/log/*/*.log*"
- "- /var/cache/*"
Setting handling for the data volume
Intent: Data
or ImageAndData
The dataVolumes
field specifies a list of folders to include in the data volume
as part of the migration.
You must edit this list for a migration with an intent of Data
or ImageAndData
.
By default, folders
contains a placeholder value that you must change.
If you do not change the placeholder value, you get an error when you generate
the migration artifacts, in the form Replace the folder placeholder with the relevant path
:
dataVolumes: # Folders to include in the data volume, e.g. "/var/lib/mysql" # Included folders contain data and state, and therefore are automatically excluded from a generated container image # Replace the placeholder with the relevant path and add more items if needed - folders: - <folders>
Shown below is an example that specifies a list of folders to include in the data volume:
- folders: - /var/lib/mysql - /my-data-folder
Setting the migration's name and namespace
Intent: Any
Using the metadata
field, you can specify the name and namespace for the
migration. By default, Migrate for Anthos uses the values you specified when
you created the migration. (You should not change the
kind
and apiVersion
values.) The fields are the same for all intent
values.
name
-- Name of the migration.namespace
-- Namespace for the migration defined in this YAML file. It should bev2k-system
.
apiVersion: anthos-migrate.cloud.google.com/v1beta2 kind: GenerateArtifactsFlow metadata: name: generate-artifacts-flow-id namespace: v2k-system
Setting the name of the container image
Intent: Image
or ImageAndData
The image
field value defines the names and locations of two images created from
a migrated VM. You can change these values if you prefer to use other names.
During migration, Migrate for Anthos copies files and directories representing your migrating workload to (by default) Container Registry for use during migration. The migration process adapts the extracted workload to an image runnable on GKE.
Migrate for Anthos preserves files and directories from the original VM (at
the base
path) in the registry. This image functions as a non-runnable base
layer that includes the extracted workload files, which are then combined with
the Migrate for Anthos runtime software layer to build an executable container
image.
The use of separate layers simplifies later updates to the container image by allowing separate updates to the base layer or to the Migrate for Anthos software layer, as needed.
This image isn't runnable, but makes it possible for Migrate for Anthos to update the container from that original when you upgrade Migrate for Anthos.
The base
and name
field values specify images created in the registry.
base
-- Name of the image that is created from the VM files and directories copied from the source platform. This image is not runnable on GKE because it hasn't been adapted for deployment there.name
-- Name of the runnable image that is used for the container. This image contains both the content from the source VM, and the Migrate for Anthos runtime, which allows it to be runnable.
image: # Review and set the name for extracted non-runnable base image, # if an image tag is not specified, a random tag is auto-generated when the image is built. base: "gcr.io/my-project/centos-mini-non-runnable-base" # Review and set the name for runnable container image, # if an image tag is not specified, a random tag is auto-generated when the image is built. name: "gcr.io/my-project/centos-mini"
By default, a tag corresponding to the timestamp of the migration is automatically applied to these values. This tag is in the form:
MM-DD-YYYY--hh:mm:ss
To apply your own tag, overriding the default tag, edit the CRD and add it as shown below:
image: # Review and set the name for extracted non-runnable base image, # if an image tag is not specified, a random tag is auto-generated when the image is built. base: "gcr.io/my-project/centos-mini-non-runnable-base:tag" # Review and set the name for runnable container image, # if an image tag is not specified, a random tag is auto-generated when the image is built. name: "gcr.io/my-project/centos-mini:tag"
Setting the Cloud Storage location for deployment artifacts
Intent: Any
During migration, Migrate for Anthos uses Cloud Storage to store files that you'll later use to deploy your VM on a production cluster. You can change the bucket and folder names to use your own.
bucket
-- Name of the Cloud Storage bucket in which to store artifacts.folder
-- Name of the folder insidebucket
in which to store artifacts.appName
-- Name to give the Kubernetes controller to use in the deployment file. The type of controller will differ based on the value you specified for theintent
flag when you created the migration:- For an
image-and-data
value, the result is aStatefulSet
object with this name. - For an
image
value, the result is aDeployment
object with this name.
- For an
deployment:
# Review and set the app-name for your StatefulSet or Deployment YAML spec
appName: app-centos-mini
# Artifacts are uploaded to the project-default artifacts repository.
# In order to specify a custom repository, uncomment the lines below and replace the placeholders with the relevant values
# artifactsRepository:
# spec:
# bucket: bucket_name
# credentials:
# type: gcs
# secret: secret
folder: storage-folder-name/
Configuring persistent storage
Intent: Data
or ImageAndData
For Data
or ImageAndData
migration intents, the migration plan includes a
pvc
definition with default values. You can change these values to match the needs of your system.
pvc:
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
# Modify the required disk size on the storage field below based on the capacity needed
storage: 10G
Headings in g3doc-style (H1 → H2, etc.)
Customizing the services list
Intent: Image
or ImageAndData
By default, Migrate for Anthos disables unneeded services on a VM when you migrate it to a container. These services can sometimes cause issues with the migrated container, or are not needed in a container context.
Along with the services automatically disabled by Migrate for Anthos, you can optionally disable other services:
Migrate for Anthos automatically discovers services that you can optionally disable and lists them in the migration plan. These services, such as
ssh
or a web server, might not be required in your migrated workload but it is up to you to make that decision. If necessary, edit the migration plan to disable these services.Migrate for Anthos does not list all services running on the source VM. For example, it omits operating-system related services. You can optionally edit the migration plan to add your own list of services to disable in the migrated container.
The systemServices
field specifies the list of services discovered by Migrate for Anthos.
For example:
systemServices: - enabled: true|false name: service-name - enabled: true|false name: service-name ...
To disable a service, set enabled
to false
.
Migrate for Anthos does not list all services running on the source VM, such as
operating-system related services. You can also add additional services to the list.
For example, to disable service2
and the cron
service:
systemServices: - enabled: true name: service1 - enabled: false name: service2 - enabled: false name: cron
When you execute a migration to generate
the migration artifacts, Migrate for Anthos creates the blocklist.yaml
file.
This file lists the container services to disable based on your settings in the migration plan.
For example:
service_list: - name: disabled-services services: # Because you used systemServices above to disabled service2 and cron: - service2 - cron
To later modify the list of disabled services:
- Edit the list of services in the migration plan.
- Execute the migration to regenerate
the migration artifacts, including an updated
blocklist.yaml
file,deployment_spec.yaml
file, and Dockerfile.
Alternatively, after you execute a migration
to generate the migration artifacts, you can edit the blocklist.yaml
file directly,
and then rebuild and push the container image yourself. For example:
Update the
blocklist.yaml
file.Rebuild and push the container image.
The way you rebuild and push the container image depends on your build environment. You can use:
gcloud
to rebuild the image and push it to the Container Registry as described at Quickstart: Build.docker build
as described at Build and run your image.
After you rebuild and push the new image, open the
deployment_spec.yaml
file in an editor to update the image location:spec: containers: - image: new-image-location
For example, new-image-location could be
gcr.io/my-project/my-new-image:v1.0
if you usedgcloud
to rebuild the image and push it to the Container Registry.