Building a Windows container image

When you generate artifacts for Windows workloads, the artifacts are zipped and copied into a Cloud Storage bucket as an intermediate location that you can download. This zip file contains a Dockerfile and several directories and files that are extracted from the source that you then use to build the Windows container.

Before you begin

Before building the Windows container, you should have first:

Executed a migration.

Determine the URL of the migration artifacts zip file

The migration artifacts are contained in a single zip file named artifacts.zip that you must download as part of building the container image. This step describes how to determine the location of the artifacts.zip file. You perform the actual download on a Windows machine as described below.

migctl

When the migration completes, you should see a message such as the following when you request status:

migctl migration status my-migration

NAME            CURRENT-OPERATION       PROGRESS        STEP            STATUS    AGE
my-migration    GenerateArtifacts       [1/1]           ExtractImage    Completed 14m23s

After the migration has completed, use migctl migration get-artifacts to obtain the gsutil command that you use to download the generated artifacts.zip file:
```
migctl migration get-artifacts my-migration

Artifacts are accessible through `gsutil cp gs://PATH/artifacts.zip ./`
```

Console

When the migration completes, you see Artifacts generated in the Status column of the migration. To download all migration artifacts:

Open the Migrate for Anthos page in the Cloud Console.

Go to the Migrate for Anthos page
Click the Migrations tab to display a table containing the available migrations.
In the row for the desired migration, under Options select Review artifacts.
In the panel that opens on the right, select Container artifacts zip to view the URL of the artifacts.zip file.

Building the container image

Using the migration artifacts in the zip file, build a container image that you can then deploy to your GKE cluster.

You must run docker build on a Windows version that is the same as the version used by the target container.

In Cloud Shell, create a Windows Server instance on Compute Engine. For example, use the following command to create an instance:

gcloud beta compute instances create win-builder-1 \
  --project=project-name --zone=gcp-zone \
  --machine-type=n1-standard-4 --subnet=default --scopes=cloud-platform \
  --image=windows-server-1909-dc-core-for-containers-v20200310 --image-project=windows-cloud \
  --boot-disk-size=32GB --boot-disk-type=pd-ssd

To determine when the server instance is ready for an RDP connection, run the following command at your Cloud Shell command line:
```
gcloud compute instances get-serial-port-output win-builder-1 --zone=gcp-zone
```
Repeat the command until you see the following in the command output, which tells you that the OS components have initialized and the Windows Server is ready to accept your RDP connection:
```
Instance setup finished. win-builder-1 is ready to use.
```
In the Cloud Console, navigate to the Compute Engine page.
For win-builder-1 click RDP > Set Windows Password to generate a password for this Windows instance.
Copy the username and password and save it so you can log into the instance.
Click RDP to connect to the Windows server.
On the login page, enter the username and password that you saved previously.
Open powershell on the Windows instance. You can do this by entering the command powershell in a terminal window, or by using the Windows GUI (if the Windows machine is confugred to include a GUI).
To account for very long paths during zip operations, set the following registry key and restart the machine:
```
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
Value: LongPathsEnabled
Data: 1
```
For example, you can use the PowerShell Set-ItemProperty and Restart-Computer commands to update the registry and restart:
```
Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem -Name LongPathsEnabled -Value 1 -Type DWord
Restart-Computer
```
For more, see Enable Long Paths in Windows 10, Version 1607, and Later.
The Windows machine will restart. When the machine is available, RDP into it again, using the same password you used earlier, and restart powershell.
Use gsutil to download the artifacts.zip file using the URL you determined above in Determine the URL of the migration artifacts zip file:
```
gsutil cp gs://PATH/artifacts.zip ./
```
Using PowerShell, expand the artifacts.zip file you downloaded above with a command such as the following:
```
Expand-Archive .\artifacts.zip
```
Note: Using the Windows File Explorer Extract All option to expand the zip file will not work with very long paths.
Optionally configure logging to Cloud Logging by editing the LogMonitorConfig.json file.

See Configuring logging to Cloud Logging below for more.
Optionally edit the set_acls.bat script to set ACL permissions for the Windows container.

See Setting ACLs below for more.
Using the Dockerfile included in the zip file, use docker build to build an image from the unzipped files:
```
docker build -t gcr.io/myproject/myimagename:v1.0.0 .\artifacts\
```
Authenticate with the Container Registry:
```
gcloud auth configure-docker
```
Use docker push to push the image to the Container Registry:
```
docker push gcr.io/myproject/myimagename:v1.0.0
```

Configuring logging to Cloud Logging

Migrate for Anthos uses the LogMonitor tool to extract logs from a Windows container and forward them to your GKE cluster. These logs are then automatically forwarded to Cloud Logging, which provides a suite of tools to monitor your containers.

By default Migrate for Anthos enables IIS logging to monitor the IIS logs, and also forwards the Application/System event logs to Cloud Logging.

Configuring logging

Expanding the generated artifacts.zip file creates several directories, including the m4a directory. Included in the m4a directory is the LogMonitorConfig.json file that you can edit to control logging.

For more on editing LogMonitorConfig.json see Authoring a Config File.

Setting ACLs

Some IIS applications require that you set specific access control lists (ACL) permissions on files and folders in order for the applications to perform correctly. Migrate for Anthos automatically scans all migrated IIS applications and adds any specific permissions defined in the source VM that apply to IIS accounts (the IUSR account and the IIS_IUSRS group) and applies them to the copied files and directories in the generated container image.

Because Windows container images do not support setting ACLs as part of the Docker COPY command, the ACLs are set in a script called set_acls.bat. Migrate for Anthos automatically creates set_acls.bat in the root directory of expanded artifacts.zip file. Migrate for Anthos then calls set_acls.bat when you execute the docker build command.

Edit set_acls.bat to add or remove custom permissions, or edit permission that are not related to specific IIS users and therefore were not detected by Migrate for Anthos.

The script uses the Windows built-in icacls tool to set permissions.

About the .NET Global Assembly Cache

Migrate for Anthos scans the source image .NET Global Assembly Cache (GAC) for .NET resources that are installed on the source machine and not available as part of the official images. Any discovered DLL is copied into the Docker context and installed as part of the building of the target image by a utility script install_gac.ps1.

All .NET assemblies are copied into the Docker context under the m4a\gac directory. To remove assemblies from the image, delete them from the m4a\gac directory.

Next Steps

Monitor a migration