Customizing a migration plan

You should review the migration plan file resulting from creating a migration, and customize it before proceeding to executing the migration. The details of your migration plan is used to extract the workload container artifacts from the source VM.

This section describes the migration plan's contents and the kinds of customizations you might consider before you execute the migration and generate deployment artifacts.

Before you begin

  • This topic assumes that you've already created a migration and have the resulting migration plan file.

Editing the migration plan

Edit the migration plan by using the migctl tool or the Google Cloud Console.

migctl

You must download the migration plan before you can edit it:

  1. Download the migration plan. The migration plan is represented by WindowsGenerateArtifacts:

    migctl migration get my-migration
    
  2. Edit the downloaded migration plan, my-migration.yaml, in a text editor.

  3. When your edits are complete, upload the edited migration plan:

    migctl migration update my-migration
    
  4. Repeat these steps if more edits are necessary.

CRD

You must download the migration plan, edit it, the apply it. The migration plan is represented by WindowsGenerateArtifacts:

  1. Get the name of the WindowsGenerateArtifacts:

    kubectl get migrations.anthos-migrate.cloud.google.com -n v2k-system my-migration -o jsonpath={.status.resources.windowsGenerateArtifacts.name}

    The name is returned in the form windows-generate-artifacts-flow-id.

  2. Get the WindowsGenerateArtifacts by name and write to a file named my-plan.yaml:

    kubectl get windowsgenerateartifacts.anthos-migrate.cloud.google.com -n v2k-system generate-artifacts-flow-id -o yaml > my-plan.yaml
  3. Edit the migration plan as necessary.

  4. Apply the file:

    kubectl apply -f my-plan.yaml

Console

Edit the migration plan in the Google Cloud Console by using the YAML editor. The migration plan is represented by WindowsGenerateArtifacts:

  1. Open the Migrate for Anthos and GKE page in the Cloud Console.

    Go to the Migrate to containers page

  2. Click the Migrations tab to display a table containing the available migrations.

  3. In the row for the desired migration, select the migration Name to open the Details tab.

  4. Select the YAML tab.

  5. Edit the migration plan as necessary.

  6. When you are done editing, you can either:

    1. Save the migration plan. You then have to manually execute the migration to generate the migration artifacts using the procedure shown in Executing a migration.

    2. Save and generate the artifacts. Execute the migration by using your edits to generate the migration artifacts. The process is the same as described in Executing a migration. You can then monitor the migration as described in Monitoring a migration.

Configuring SSL

Because you cannot easily extract SSL certificates from a source VM, and it is not recommended to install SSL certificates and private keys in a Docker image, Migrate for Anthos and GKE provides several ways of handling SSL for Windows.

Use a self-signed auto-generated certificate

By default, a Windows container with an HTTPS binding is assigned a self-signed auto-generated certificate that is generated on the initialization of the Docker container. This configuration lets you test your migrated workload but cannot be used in a production environment because the certificate is both self-signed and re-generated every time the container is run.

You can customize the bindings in the migration plan to use HTTP, and then use Cloud Load Balancing, Ingress, or Anthos Service Mesh as an HTTPS frontend to secure external access. This option let you secure external communication without including any certificates inside the cluster.

To customize the binding, edit the site definition in the WindowsGenerateArtifacts that represents the migration to set protocol to http:

sites:
  site:
  - applications:
    - path: /
      virtualdirectories:
        - path: /
          physicalpath: '%SystemDrive%\inetpub\wwwroot'
          bindings:
          - port: 8080
            protocol: http
          name: Default Web Site

You can then forward requests from the HTTPS frontend to the HTTP path and port of the Windows workload.

Advanced - store SSL certificates as Kubernetes secrets

It is recommended that you use Cloud Load Balancing, Ingress, or Anthos Service Mesh as an HTTPS frontend to secure external access. However, you can also store SSL certificates as Kubernetes secrets and mount them at runtime into the container.

To use SSL certificates stored as Kubernetes secrets, you must edit the deployment image of the container. See Deploying a Windows workload to a target cluster for more.

Setting the Cloud Storage location for deployment artifacts

During migration, Migrate for Anthos and GKE uses Cloud Storage to store files that you later use to deploy the container on a production cluster. Use the folder option to change the bucket and folder names to use.

spec:
  folder: folder-name-and-bucket/

Setting the apppools and sites options

Set the apppools and sites options using the same syntax as you use for setting the corresponding options in IIS. See these links for more details:

Setting the useractions options

Set options under useractions in the form:

      useractions:
        files: 
        - source: DRIVE:\FOLDER-OR-FILE-PATH
          target: DRIVE:\FOLDER-OR-FILE-PATH
        - source: C:\myfolder
          target: C:\myfolder
        - source: D:\myfile
          target: D:\myfile
        - source: D:\myfile
          target: C:\myfile
        ...
        registry:
          currentcontrolset:
          - path: KEY
          ...
          software:
          - path: KEY
          ...

For files, the path to the file or folder on the migrated container is determined by the target DRIVE specification:

  • If the target drive is C, then the path is:

    C:\FOLDER-OR-FILE-PATH
  • If the target drive is any value other than C, then the path is:

    C:\Volumes\DRIVE\FOLDER-OR-FILE-PATH

    For example:

    C:\Volumes\D\myfile

The paths specified for currentcontrolset and software are to keys in the HKEY_LOCAL_MACHINE\System\CurrentControlSet registry hive or in the HKEY_LOCAL_MACHINE\Software registry hive.

Setting connection strings for a data provider

Connection strings define a connection from the migrated container workload to a .NET Framework data provider.

Migrate for Anthos and GKE supports connection strings to an SQL Server data provider at the site scope. To add a connection string, edit the site definition in the WindowsGenerateArtifacts file that represents the migration plan to set the connectionstrings property:

sites:
  site:
    # Add the site connection strings here.
    connectionstrings:
    - name: connectionname1
      providername: System.Data.SqlClient
      connectionstring: Database=connectedDB1;Password=Welcome1;User=admin;
    - name: connectionname2
      providername: System.Data.SqlClient
      connectionstring: Database=connectedDB2;Password=Welcome2;User=admin;
  - applications:
    - path: /
      virtualdirectories:
      ...

Where:

  • name specifies the connection name.
  • providername optionally specifies the data provider type. Migrate for Anthos and GKE only supports a value of System.Data.SqlClient.
  • connectionstring specifies the SqlClient Connection Strings used to connect to SQL Server.

If you do not know which connection strings you should add to the migration plan, Microsoft provides guidance for determining it. See Retrieving Connection Strings at Run Time for information on how to determine the connection strings for a site.

You must be aware of the following considerations when using connection strings:

  • Connection strings can contain dependencies, such as a reference to a file at a location in the filesystem or to a Windows user associated with the site. You can add custom user actions to the migration plan to copy an additional file in the filesystem. You must manually edit the Dockerfile to add a Windows user.

  • Connection strings can contain dependencies, such as a reference to an external data source. These dependencies must be migrated manually to ensure that the migrated container workload has access to the data source.

Configuring migrated workloads to use gMSA

Windows VM workloads are often Active Directory (AD) joined and operate using domain identities. When migrating these VMs to containers, the containers themselves are not domain-joined, but rather their host Kubernetes cluster nodes can be domain-joined.

When you deploy your migrated containers to a cluster, you can use a Group Managed Service Account (gMSA) to execute the container under a specific service account identity. 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 support gMSA in a migrated Windows container, you must:

  1. Edit the migration plan to set the necessary properties to configure the migrated container to use a gMSA. This configuration process is described below.

  2. Configure the processing cluster that hosts the deployed container to support gMSA. See Deploying a Windows workload to a target cluster for more.

About gMSA

You can find a more information about gMSA in the Google Cloud documentation and in other documentation sets. For example, see:

Supporting gMSA in Migrate for Anthos and GKE

When migrating workloads from VMs to Windows containers, you must transform any IIS configuration and other Windows services configured to use AD identities. This transformation is required for each Windows source VM.

Migrate for Anthos and GKE helps you in the process of transforming your workloads by automatically discovering the configuration of IIS application pools and adding recommendations to the generated migration plan. You can then evaluate these recommendations and modify them for your specific environment and requirements.

If Migrate for Anthos and GKE determines that the configuration of an application pool does not require a gMSA, then it maintains the original application pool configuration. For example, when it uses a built-in account types such as ApplicationPoolIdentity, NetworkService, LocalSystem, or LocalService.

Editing the migration plan to configure gMSA

Migrate for Anthos and GKE adds the following properties, with recommended values, to the generated migration plan. You can then modify them as necessary to control gMSA:

  • enablegmsa: Supported values:

    • auto (default): Convert the migrated container to use gMSA if Migrate for Anthos and GKE determines that its current configuration is not allowed.
    • all: Always convert the migrated container to use gMSA and ignore the setting of identitytype. In this case, identitytype is always interpreted as being set to NetworkService.
  • identitytype: Specifies the IIS identity of an application pool as either ApplicationPoolIdentity (default), NetworkService, LocalSystem, or LocalService. See Understanding identities in IIS and Application Pool Identities for more.

    A container is typically given a single gMSA, meaning you typically set identitytype to NetworkService to use the gMSA identity. See Configure your app to use a gMSA for more.

Shown below is an example migration plan containing enablegmsa and identitytype:

migrationPlan:
    applications:
      iis:
        # Allowed values include: auto (default), all
        enablegmsa: auto|all
        applicationhost:
          apppools:
          - name: DefaultAppPool
            # Allowed values include: ApplicationPoolIdentity (default), NetworkService, LocalSystem, LocalService
            identitytype="NetworkService"
          - managedruntimeversion: v4.0
            name: .NET v4.5 Classic
          - managedruntimeversion: v4.0
            name: .NET v4.5

Generating artifacts for supporting gMSA

When you execute the migration plan to generate the container artifacts, Migrate for Anthos and GKE automatically adds the necessary Dockerfile directives to assign the NetworkService account as described in Configure your app to use a gMSA.

For example, if you set identitytype to NetworkService the directive is in the form:

RUN c:\windows\system32\inetsrv\appcmd.exe set apppool \"DefaultAppPool\" \"/-processModel.identityType:NetworkService\";

For the application file system items, such as directories and files, where the original application identity account was specified either by inheritance or explicitly, Migrate for Anthos and GKE automatically adds read ACL directives to the site's folders according to the target identitytype, and for the IUSR built-in user. See Setting ACLs for more on setting ACLs.

Next Steps