Prepare a Linux cluster for deployment

This page describes how to prepare your target cluster for deployment.

Before you begin

This document assumes that you've already completed the migration and have the resulting generated artifacts.

Ensure the target cluster has read access to the Docker registry

As part of performing a migration, Migrate to Containers uploads Docker images representing a migrated VM to a Docker registry. These Docker images represent the files and directories of the migrating VM.

For the Docker registry you can choose to use:

For more information, see Defining data repositories.

Deploy a workload to a Google Cloud project other than the one used for migration

Often you have multiple Google Cloud projects in your environment. If you perform a migration in one Google Cloud project, but then want to deploy the migrated workload to a cluster in a different project, you must ensure that you have the permissions configured correctly.

For example, you perform the migration in project A. In this case, the migrated workload is copied into a Container Registry bucket in project A. For example:

gcr.io/project-a/image_name:image_tag

You then want to deploy the workload to a cluster in project B. If you don't configure permissions correctly the workload pod fails to run because the cluster in project B has no image pull access to project A. You then see an event on the pod containing a message in the form:

Failed to pull image "gcr.io/project-a/image_name:image_tag...
pull access denied...
repository does not exist or may acquire 'docker login'...

All projects that have enabled the Compute Engine API have a Compute Engine default service account, which has the following email address:

PROJECT_NUMBER-compute@developer.gserviceaccount.com

Where PROJECT_NUMBER is the project number for project B.

To work around this issue, ensure that the Compute Engine default service account for project B has the necessary permissions to access the Container Registry bucket. For example, you can use the following gsutil command to enable access:

gsutil iam ch serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com:objectViewer gs://artifacts.project-a.appspot.com

Deploy workloads on the processing cluster

You can deploy the migrated workload on the same cluster as you used to perform the migration, referred to as the Migrate to Containers processing cluster. In most situations you don't have to perform any additional configuration on the processing cluster because the cluster already requires read or write access to the Docker registry to perform a migration.

Deploy on a target cluster using Container Registry as the Docker registry

To ensure that a target cluster has access to the Container Registry, create a Kubernetes secret that contains the credentials required to access Container Registry:

  1. Create a service account for deploying a migration as described in Creating a service account for accessing Container Registry and Cloud Storage.

    This process has you download a JSON key file named m4a-install.json.

  2. Create a Kubernetes secret that contains the credentials required to access Container Registry:

    kubectl create secret docker-registry gcr-json-key \
 --docker-server=gcr.io --docker-username=_json_key --docker-password="$(cat ~/m4a-install.json.json)" \
 --docker-email=account@project.iam.gserviceaccount.com

    where:

    • docker-registry specifies the name of the Kubernetes secret, gcr-json-key in this example.
    • docker-server=gcr.io specifies Container Registry as the server.
    • docker-username=_json_key specifies that the username is contained in the JSON key file.
    • docker-password specifies to use a password from the JSON key file.
    • docker-email specifies the email address of the service account.

  3. Set the Kubernetes secret by either:

    • Changing the default imagePullSecrets value:

      kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "gcr-json-key"}]}'

    • Editing the deployment_spec.yaml file to add the imagePullSecrets value to the spec.template.spec definition. When using WebSphere traditional, the deployment YAML file is named twas_deployment_spec.yaml, liberty_deployment_spec.yaml or openliberty_deployment_spec.yaml, depending on your target.

      spec:
  containers:
  - image: gcr.io/PROJECT_ID/mycontainer-instance:v1.0.0
    name: mycontainer-instance
    ...
  volumes:
  - hostPath:
      path: /sys/fs/cgroup
      type: Directory
    name: cgroups
  imagePullSecrets:
  - name: gcr-json-key

      Replace PROJECT_ID with your project ID.

  4. Deploy the workload secret, if secrets.yaml exists. A secrets file will exist for Tomcat-based workloads and WebSphere traditional based workloads with Liberty. The Liberty file is named liberty-secrets.yaml.

    kubectl apply -f secrets.yaml

Deploy on a target cluster using a Docker registry with basic authentication

If you use a Docker registry to store for migration images, then the registry must support basic authentication using a username and password. Because there are many ways to configure a read-only connection to a Docker registry, you should use the method appropriate for your cluster platform and Docker registry.

What's next