Deploy a Tomcat workload to a target cluster

After you have migrated a workload from your source platform, you can use the deployment artifacts generated by that process to deploy the migrated workload.

Skaffold can handle the workflow for building, pushing and deploying your application. For more information, see Build and deploy multiple images using Skaffold.

Before you begin

Before deploying your workload, you should have first:

Migrated the workload using Migrate to Containers tools.
Reviewed the generate deployment files.

Deploy a workload

To deploy a migrated workload to a target cluster you use the following command:

kubectl apply -f deployment_spec.yaml

Where deployment_spec.yaml is the YAML file that contains the deployment information for your migrated workload. This file is located within the generated artifacts.

Included in the deployment_spec.yaml is the containers property, which specifies the location of the Docker image and registry. This is a mandatory parameter which should list the full path, including the registry name of the images.

For example:

    spec:
      containers:
      - image: gcr.io/PROJECT_ID/quickstart-instance:v1.0.0
        name: quickstart-instance

In this example, the deployment_spec.yaml specifies that the Docker image registry uses the Google Container Registry (GCR).

Before you can deploy a migrated workload to a target cluster, you must ensure that the cluster has read access to the Docker registry. The following sections describe how to enable access to the different types of registries.

Deploy on a target cluster using GCR as the Docker registry

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

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.
Create a Kubernetes secret that contains the credentials required to access GCR:
```
kubectl create secret docker-registry gcr-json-key \
 --docker-server=gcr.io --docker-username=_json_key --docker-password="$(cat ~/m4a-install.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 GCR 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.

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, as shown below.

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

Deploy the workload secret, if secrets.yaml exists. A secrets file will exist for Tomcat-based workloads.
```
kubectl apply -f secrets.yaml
```

Apply generated deployment YAML file

Use kubectl to apply the deployment spec to your target cluster, such as a production cluster.

kubectl

Ensure that the target cluster has read access to the Docker image registry as described above in Ensure the target cluster has read access to the Docker image registry.
Deploy the container:
```
kubectl apply -f deployment_spec.yaml
```
After you complete your validation testing on the migrated workload to ensure that the migrated workload is functioning correctly, you should delete the migration to free up resources. See Deleting a migration for more information.

Note: If you installed Migrate to VMs as part of migrating a VM from VMware, then you must delete the migration to release control of the VM from Migrate to VMs.

What's next

Linux

Migrate

Deploy

Review generated artifacts.
Configure logging.
Mounting external volumes.
Deploy a workload to a target cluster.
Deploy migrated VMs.
Post-migration image updates.
Monitor migrated workload.
Test your migrate app and validate the migration.

Deploy a Tomcat workload to a target cluster

Before you begin

Deploy a workload

Deploy on a target cluster using GCR as the Docker registry

Apply generated deployment YAML file

kubectl

What's next

Linux

Migrate

Deploy

Windows

Migrate

Deploy

Tomcat

Migrate

Deploy

WebSphere

Migrate

Deploy

JBoss

Migrate

Deploy

Apache

Migrate

Deploy