Deploy a Linux 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 container to another cluster.
Skaffold cab 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.
Before you run your migrated workloads, you must install
migctl
with runtime support for Container-Optimized OS nodes on your cluster:migctl setup install --runtime
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 do not have to perform any additional configuration on the processing cluster because the cluster already requires read/write access to the Docker registry to perform a migration.
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 theimagePullSecrets
value to thespec.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 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.
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.
Delete a migration
After you validate and test the migrated workload to ensure that it is functioning correctly, you should delete the migration. Deleting the migration frees up any resources used by the migration.
migctl
Delete a completed migration by using the following command:
migctl migration delete MIGRATION_NAME
Where MIGRATION_NAME is the name of the migration.
Console
Open the Migrate to Containers page in the Google Cloud console.
Click the Migrations tab to display a table containing the available migrations.
For the migration to delete, click the trash icon,
, on the right side of the table, and then select Delete migration.
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.
Windows
Migrate
Deploy
- Deploy a workload to a target cluster.
- Deploy migrated VMs.
- Monitor migrated workload.
- Test your migrate app and validate the migration.
Tomcat
Migrate
Deploy
- Deploy a workload to a target cluster.
- Deploy migrated VMs.
- Monitor migrated workload.
- Test your migrate app and validate the migration.
WebSphere
Migrate
- Migration overview.
- Requirements.
- Before you begin.
- Add a migration source.
- Create a migration plan.
- Migrate data.
- Customize the migration plan.
- Execute the migration.
- Monitor the migration.
- Build an app container image.
- Deploy an app container to a target cluster.
- Delete a migration.
- Troubleshooting.
Deploy
- Deploy a workload to a target cluster.
- Deploy migrated VMs.
- Monitor migrated workload.
- Test your migrate app and validate the migration.
JBoss
Migrate
Deploy
- Deploy a workload to a target cluster.
- Deploy migrated VMs.
- Monitor migrated workload.
- Test your migrate app and validate the migration.
Apache
Migrate
Deploy
- Deploy a workload to a target cluster.
- Deploy migrated VMs.
- Monitor migrated workload.
- Test your migrate app and validate the migration.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2023-03-24 UTC.