Checkpoints
Create a firewall rule
/ 20
Create a processing cluster
/ 20
Install Migrate for Anthos
/ 20
Migrating the VM
/ 20
Execute the Migration
/ 10
Deploying container image and testing migration
/ 10
Migrate to Containers: Windows
GSP816
Overview
Anthos is an open source application platform that enables you to modernize your existing applications on your hybrid or multi-cloud environment. Anthos is built on open source technologies pioneered by Google — including Kubernetes, Istio, and Knative — and enables consistency between on-premises and cloud environments.
When workloads are upgraded to containers, IT departments can eliminate OS-level maintenance and security patching for VMs and automate policy and security updates at scale. Monitoring across on-premises and cloud environments is done through a single interface in the Cloud Console.
Migrate to Containers is a tool to containerize existing VM-based applications to run on Google Kubernetes Engine (GKE) or Anthos. By leveraging the GKE ecosystem, Migrate to Containers provides a fast and simple way to move to modernized orchestration and application management without requiring access to source code, rewriting, or re-architecting applications. Migrate to Containers supports migrations of VMs to containers on Google Kubernetes Engine on these Windows operating systems:
- Microsoft Windows Server 2008R2 or higher.
- Microsoft IIS 7 or higher web applications.
- ASP.NET and .NET Framework version 3.5 or higher.
In this lab you will use Migrate to Containers to migrate a Compute Engine VM running a Windows image into a Kubernetes Cluster using a processing cluster.
Setup
Before you click the Start Lab button
Read these instructions. Labs are timed and you cannot pause them. The timer, which starts when you click Start Lab, shows how long Google Cloud resources will be made available to you.
This hands-on lab lets you do the lab activities yourself in a real cloud environment, not in a simulation or demo environment. It does so by giving you new, temporary credentials that you use to sign in and access Google Cloud for the duration of the lab.
To complete this lab, you need:
- Access to a standard internet browser (Chrome browser recommended).
- Time to complete the lab---remember, once you start, you cannot pause a lab.
How to start your lab and sign in to the Google Cloud Console
-
Click the Start Lab button. If you need to pay for the lab, a pop-up opens for you to select your payment method. On the left is the Lab Details panel with the following:
- The Open Google Console button
- Time remaining
- The temporary credentials that you must use for this lab
- Other information, if needed, to step through this lab
-
Click Open Google Console. The lab spins up resources, and then opens another tab that shows the Sign in page.
Tip: Arrange the tabs in separate windows, side-by-side.
Note: If you see the Choose an account dialog, click Use Another Account. -
If necessary, copy the Username from the Lab Details panel and paste it into the Sign in dialog. Click Next.
-
Copy the Password from the Lab Details panel and paste it into the Welcome dialog. Click Next.
Important: You must use the credentials from the left panel. Do not use your Google Cloud Skills Boost credentials. Note: Using your own Google Cloud account for this lab may incur extra charges. -
Click through the subsequent pages:
- Accept the terms and conditions.
- Do not add recovery options or two-factor authentication (because this is a temporary account).
- Do not sign up for free trials.
After a few moments, the Cloud Console opens in this tab.
Activate Cloud Shell
Cloud Shell is a virtual machine that is loaded with development tools. It offers a persistent 5GB home directory and runs on the Google Cloud. Cloud Shell provides command-line access to your Google Cloud resources.
-
Click Activate Cloud Shell
at the top of the Google Cloud console.
-
Click Continue.
It takes a few moments to provision and connect to the environment. When you are connected, you are already authenticated, and the project is set to your PROJECT_ID. The output contains a line that declares the PROJECT_ID for this session:
gcloud
is the command-line tool for Google Cloud. It comes pre-installed on Cloud Shell and supports tab-completion.
-
(Optional) You can list the active account name with this command:
Output:
-
(Optional) You can list the project ID with this command:
Output:
Example output:
gcloud
, in Google Cloud, refer to the gcloud CLI overview guide.
Prepare your working environment
Set your Project ID:
Click Authorize:
Set your Project ID to an environment variable:
A Compute Engine VM named source-vm
has been created for you with a simple website. This will serve as the source VM that will be migrated. Next you will create a firewall for the instance and verify that you can access the website.
Create a firewall rule to allow the HTTP:
In the Cloud Console navigate to Compute Engine > VM instances and locate the row for source-vm
and copy the External IP address.
Click Check my progress to verify the objective.
Paste the instance's IP address to your browser address bar. Prefix it with http://
.
You should now see the "Hello World" page. If you get an error message, wait a minute or 2, then refresh the page.
To migrate the VM, first stop it from running.
In the Cloud Console navigate to Compute Engine > VM instances, check the checkbox to the left of the source-vm
then click the STOP button on the top.
Confirm the shutdown by clicking Stop in the pop-up window. You can continue to the next section while the VM is shutting down.
Note: The VM must be stopped for you to migrate it. You can start it again after you create the migration below, by using the UI.
Create a processing cluster
In the following steps you'll create a GKE cluster in the Cloud that you'll use as a processing cluster. This is where you'll install Migrate to Containers and execute the migration.
In Cloud Shell use the following command to create a new Kubernetes cluster to use as a processing center:
This will take a couple of minutes to complete.
Sample output:
Create the Windows node pool used to process the migration:
This will take about 5 minutes to build In Compute Engine > VM instances you can see the resources getting added.
Go to Navigation menu > Kubernetes Engine > Clusters to see the cluster getting added.
Click Check my progress to verify the objective.
Now connect to the cluster:
Install Migrate to Containers
To allow Migrate to Containers to access Container Registry and Cloud Storage you need to create a service account with the storage.admin role.
In Cloud Shell create the m4a-install
service account:
Grant the storage.admin
role to the service account:
Download the key file for the service account:
Set up Migrate to Containers components on your processing cluster by using the migctl
command-line tool included with Migrate to Containers:
Validate the Migrate to Containers installation. Use the migctl doctor
command to confirm a successful deployment:
It may take more than a minute before the command returns the following success result.
Sample Output:
Re-run the command until you see the successful deployment.
Click Check my progress to verify the objective.
Migrate the VM
Now you'll create a migration plan with migration details, then use it to migrate the VM.
Create service account for the migration
To use Compute Engine as a migration source, you must first create a service account with the compute.viewer and compute.storageAdmin roles:
In Cloud Shell create the m4a-ce-src
service account:
Grant the compute.viewer role to the service account:
Grant the compute.storageAdmin role to the service account:
Download the key file for the service account:
Click Check my progress to verify the objective.
Create the migration source
The migration source specifies the platform hosting the VM to migrate, such as AWS, Azure, VMware, or Compute Engine. In this example, you specify the ce
option to the command to create a source for VM running on Compute Engine.
Run the following to create the migration source:
After you add the source, check the status of your source name my-ce-src:
Expected output:
Create a Migration
You begin migrating VMs by creating a migration. This results in a migration plan object.
A migration is the central object with which you perform migration actions, monitor migration activities and status with the migctl tool or in the Cloud Console. The migration object is implemented as a Kubernetes Custom Resource Definition (CRD).
Next you will create a migration by running the migctl tool.
These examples use the Image value for the intent flag, which is the only option supported for Windows. This flag configures Migrate to Containers to create the Dockerfile and other buildable artifacts required for a Windows migration.
-
Create the migration, where
--vm-id
specifies the name of the Compute Engine instance as shown in the Cloud Console:
-
Monitor the progress:
It should take about 3 minutes for the migration to be created. Rerun the command until the migration has Completed.
Optional: Review the migration plan
Download the migration plan to review it:
Open the my-migration.yaml
file in your preferred text editor or the Cloud Shell code editor to review. If you make changes, upload the new plan with:
Execute the Migration
Use the migctl migration generate-artifact
s command to generate target container artifacts as part of processing a VM for migration:
When you generate artifacts for Windows workloads, Migrate to Containers writes the artifacts to a zip file and then uploads the zip file to a Cloud Storage bucket. This zip file contains a Dockerfile and several directories and files that are extracted from the source and used by the Dockerfile.
Run the following to check on the migration's progress:
When the migration is complete you will see Completed as the Status.
Click Check my progress to verify the objective.
Build a Windows container image
When you generate artifacts for Windows workloads, the artifacts are copied into a Cloud Storage bucket as an intermediate location that you can download. This folder contains a Dockerfile and several directories and files that are extracted from the source that you then use to build the Windows container.
After the migration has completed, use migctl migration get-artifacts to download the generated artifacts:
Prepare the environment for building Windows Server multi-arch images
To build the migrated container image you'll use gke-windows-builder. This is a Cloud Build image that allows building windows multi-arch container images.
This flow requires some setup steps:
Enable the Compute Engine, Cloud Build and Artifact Registry APIs for your project. The gke-windows-builder is invoked using Cloud Build, and the resulting multi-arch container images are pushed to Artifact Registry. Compute Engine is required for the builder to create and manage Windows Server VMs.
Assign roles. These roles are required for the builder to create the Windows Server VMs, to copy the workspace to a Cloud Storage bucket, to configure the networks to build the Docker image and to push resulting image to Artifact Repository:
Add a firewall rule named allow-winrm-ingress
to allow WinRM to connect to
Windows Server VMs to run a Docker build:
Build the container image
Navigate to the artifact folder:
Create a file named cloudbuild.yaml
.
Enter the following contents into cloudbuild.yaml
:
This file is your build config file. At build time, Container Builder automatically replaces $PROJECT_ID with your project ID. Start the build with the following command:
You'll see logs like the following example. The last line in the log shows that the build succeeded:
You've just built the image using the build config file and pushed the image to Artifact Registry at gcr.io/myproject/myimagename:v1.0.0
.
Deploy the container image
With your container image in Container Registry, you can deploy the image to a GKE cluster. See Deploying a Windows Server application for more. As part of deploying the container, you have to create a deployment.yaml
file in Cloud Shell.
Using nano
in Cloud Shell or the Cloud Shell code editor, create a file called deployment.yaml
.
Paste the content below into the file, replacing myproject
with your Project ID :
Save the file.
Now apply the deployment file:
It may take a few minutes for the deployment to finish.
Now check for an external IP address:
Sample output:
It will take about 5 minutes for the pod to start running. Run the following to monitor their status:
When the status is Running, you'll see an external IP address for the my-service
you added.
Test the migration
Test the migration by opening a browser tab and visiting the web page at the external IP address of my-service (be sure to use HTTP rather than HTTPS).
For example:
Click Check my progress to verify the objective.
Congratulations!
You migrated a Compute Engine instance with a Windows image to a Kubernetes pod using Migrate to Containers. This same technique can be used for other sources of VMs including VMWare vSphere, AWS, and Azure.
Next Steps / Learn More
- Full documentation: https://cloud.google.com/migrate/containers/docs/windows/migrating-win-vm-overview
- Prerequisites for migrating Windows with Migrate to Containers: https://cloud.google.com/migrate/containers/docs/migration-prerequisites-win
Google Cloud training and certification
...helps you make the most of Google Cloud technologies. Our classes include technical skills and best practices to help you get up to speed quickly and continue your learning journey. We offer fundamental to advanced level training, with on-demand, live, and virtual options to suit your busy schedule. Certifications help you validate and prove your skill and expertise in Google Cloud technologies.
Manual Last Updated: June 17, 2022
Lab Last Tested: June 17, 2022
Copyright 2022 Google LLC All rights reserved. Google and the Google logo are trademarks of Google LLC. All other company and product names may be trademarks of the respective companies with which they are associated.