Deploying a Windows workload to a target cluster

After you build the Windows container, you can deploy the container to another cluster.

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.
Built the Windows container as described in Building a Windows container image.

Deploying 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, edit the deployment_spec.yaml file included in artifacts.zip to set the location of the container image you built in Building a Windows container image. Shown below is an example deployment_spec.yaml file for a container located at gcr.io/myproject/myimagename:v1.0.0:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myworkload
  labels:
    app: myworkload
    migrate-for-anthos-optimization: "true"
    migrate-for-anthos-version: "1.14.1"
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myworkload
      migrate-for-anthos-optimization: "true"
      migrate-for-anthos-version: "1.14.1"
  template:
    metadata:
      labels:
        app: myworkload
        migrate-for-anthos-optimization: "true"
        migrate-for-anthos-version: "1.14.1"
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: myworkload-container
        image: gcr.io/myproject/myimagename:v1.0.0
        ports:
        - containerPort: 80

Deploying a container when storing SSL certificates as Kubernetes secrets

We recommend that you use a Cloud Load Balancing, Ingress, or Anthos Service Mesh as an HTTPS frontend to secure external access to your deployed container. This option let you secure external communication without including any certificates inside the cluster. See Customizing a migration plan for more.

However, you can also store SSL certificates as Kubernetes secrets and mount them at runtime into the container.

To use Kubernetes secrets:

Create a PFX file with the certificate and password.
Create a configuration YAML file that defines site access:
```
sites:
 - sitename: "sitename"
   sslport: 443
   pfxpath: c:\sslconfig\pfx
   password: "password"
   thumbprint: "3e858d0551fc0536f52d411dad92b680a4fad4da"
```
Where:
- sitename specifies the name of the site configured to use SSL. The sites property can contain multiple sitename entries.
- sslport specifies the port to listen to for SSL connections (typically 443).
- pfxpath specifies the path to the PFX file. Configure it as part of the volumeMounts of the deployment of the pod as shown below.
- password specifies the password for the PFX file.
- thumbprint specifies the SHA1 thumbprint of the PFX file that can be retrieved using the PowerShell command:
```
Get-PfxCertificate -FilePath "path to pfx"
```
Or view in the Windows Certificate manager.

Create the Kubernetes secret:

kubectl create secret generic secret-name --from-file=pfx=path-to-pfx --from-file=config=path-to-config

Create the volume and volume mount in the deployment of the image:

apiVersion: v1
kind: Pod
metadata:
 name: iis-pod
 labels:
   app: iis-server-simple
 spec:
   nodeSelector:
     kubernetes.io/os: windows
   containers:
   - name: iis-server
     image: your-image-url
     volumeMounts:
     - name: ssl-secret
       mountPath: c:\sslconfig
     env:
     - name: M4A_CERT_YAML
       value: c:\sslconfig\config
   volumes:
   - name: ssl-secret
     secret:
       secretName: secret-name

Where:

mountPath is the same path as specified by pfxpath in the configuration file you created in Step 2.
M4A_CERT_YAML is an environment variable set to the full path to the configuration YAML file you created in Step 2.
secret-name is the name of the secret you created in step 3.

Deploying a container configured to use gMSA

Migrate to Containers lets you configure a Windows container to use a Group Managed Service Account (gMSA). A gMSA lets you execute the container under a specific service account identity.

To support gMSA in a migrated Windows container, you must:

Edit the migration plan to set the necessary properties to configure the migrated container to use a gMSA. You must perform this step before you migrate the Windows IIS Application workload. See Customizing a migration plan for more.
Configure the target cluster that hosts the deployed container to support gMSA. This configuration process is described below.

Configure a target cluster to support gMSA

You attach a gMSA in the Kubernetes cluster as part of the pod configuration, rather than as a static identity configuration inside the container image.

To configure a cluster hosting the migrated Windows container to support gMSA, you must have:

For additional information, see:

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.

Deploying a Windows workload to a target cluster

Before you begin

Deploying the container image

Deploying a container when storing SSL certificates as Kubernetes secrets

Deploying a container configured to use gMSA

Configure a target cluster to support gMSA

What's next

Linux

Migrate

Deploy

Windows

Migrate

Deploy

Tomcat

Migrate

Deploy

WebSphere

Migrate

Deploy

JBoss

Migrate

Deploy

Apache

Migrate

Deploy

WordPress

Migrate

Deploy