准备 Windows 集群以进行部署

本页面讨论了一些您可能需要自定义迁移工件的场景。

须知事项

本文档假定您已完成迁移。

确保目标集群具有 Docker 注册表的读取权限

在执行迁移的过程中，Migrate to Containers 会将代表迁移后的虚拟机的 Docker 映像上传到 Docker 注册表。这些 Docker 映像代表迁移虚拟机的文件和目录。

对于 Docker 注册表，您可以选择使用：

如需了解详情，请参阅定义数据存储库。

将工作负载部署到用于迁移的项目之外的 Google Cloud 项目

您的环境中通常有多个 Google Cloud 项目。如果您在一个 Google Cloud 项目中执行迁移，但想要将迁移后的工作负载部署到其他项目中的集群，则必须确保已正确配置权限。

例如，在项目 A 中执行迁移。在这种情况下，迁移的工作负载会复制到项目 A 中的 Container Registry 存储桶。例如：

gcr.io/project-a/image_name:image_tag

然后，您可以将工作负载部署到项目 B 中的集群。如果您没有正确配置权限，则工作负载 pod 无法运行，因为项目 B 中的集群没有对项目 A 的映像拉取访问权限。然后，您会在 pod 中看到一个包含消息的事件，消息格式如下：

Failed to pull image "gcr.io/project-a/image_name:image_tag...
pull access denied...
repository does not exist or may acquire 'docker login'...

所有已启用 Compute Engine API 的项目都有一个 Compute Engine 默认服务账号，该账号具有以下电子邮件地址：

PROJECT_NUMBER-compute@developer.gserviceaccount.com

其中，PROJECT_NUMBER 是项目 B 的项目编号。

如需解决此问题，请确保项目 B 的 Compute Engine 默认服务账号具有访问 Container Registry 存储桶所需的权限。例如，您可以使用以下 gsutil 命令启用访问权限：

gsutil iam ch serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com:objectViewer gs://artifacts.project-a.appspot.com

在处理集群上部署工作负载

您可以将迁移后的工作负载部署在您用于执行迁移的同一集群上，此集群称为 Migrate to Containers 处理集群。在大多数情况下，您不必对处理集群执行任何额外配置，因为该集群已经是需要有 Docker 注册表的读写访问权限才能执行迁移。

在目标集群上部署并使用 Container Registry 作为 Docker 注册表

如需确保目标集群可以访问 Container Registry，请创建包含访问 Container Registry 所需的凭据的 Kubernetes Secret：

  1. 按照创建用于访问 Container Registry 和 Cloud Storage 的服务账号中所述，创建用于部署的服务账号。

    此过程允许您下载名为 m4a-install.json 的 JSON 密钥文件。

  2. 创建包含访问 Container Registry 所需的凭据的 Kubernetes Secret：

    kubectl create secret docker-registry gcr-json-key \
 --docker-server=gcr.io --docker-username=_json_key --docker-password="$(cat ~/m4a-install.json.json)" \
 --docker-email=account@project.iam.gserviceaccount.com

    其中：

    • docker-registry 用于指定 Kubernetes Secret 的名称，在此示例中为 gcr-json-key。
    • docker-server=gcr.io 用于将 Container Registry 指定为服务器。
    • docker-username=_json_key 用于指定 JSON 密钥文件中包含用户名。
    • docker-password 用于指定使用 JSON 密钥文件中的密码。
    • docker-email 用于指定服务账号的电子邮件地址。

  3. 使用以下任一方法设置 Kubernetes Secret：

    • 更改默认的 imagePullSecrets 值：

      kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "gcr-json-key"}]}'

    • 修改 deployment_spec.yaml 文件以将 imagePullSecrets 值添加到 spec.template.spec 定义中。使用 WebSphere 传统工作负载时，部署 YAML 文件名为 twas_deployment_spec.yaml、liberty_deployment_spec.yaml 或 openliberty_deployment_spec.yaml，具体取决于您的目标。

      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

      将 PROJECT_ID 替换为您的项目 ID。

  4. 部署工作负载 Secret（如果存在 secrets.yaml）。基于 Tomcat 的工作负载和基于 Liberty 的 WebSphere 传统工作负载将存在 Secret 文件。Liberty 文件名为 liberty-secrets.yaml。

    kubectl apply -f secrets.yaml

在目标集群上部署并使用具有基本身份验证的 Docker 注册表

如果您使用 Docker 注册表来存储迁移映像，则注册表必须支持使用用户名和密码进行基本身份验证。您可以通过多种方式配置与 Docker 注册表的只读连接，因此您应该使用适合您的集群平台和 Docker 注册表的方法。

将迁移的工作负载配置为使用 gMSA

Windows IIS 应用工作负载通常加入 Active Directory (AD) 并使用网域身份运行。将这些虚拟机迁移到容器时，容器本身未加入网域，但其主机 Kubernetes 集群节点可以加入网域。

将迁移的容器部署到集群时，您可以使用群组代管式服务账号 (gMSA)。使用 gMSA 在特定服务账号身份中执行容器。您可以在 Pod 集群中将 gMSA 作为 Pod 配置的一部分进行附加，而不是作为容器映像中的静态身份配置附加。

Migrate to Containers 可帮助您实现工作负载转换。 Migrate to Containers 会自动发现 IIS 应用池的配置，并向生成的迁移计划添加建议。然后，您可以评估这些建议，并根据您的具体环境和要求对其进行修改。

如果 Migrate to Containers 确定应用池的配置不需要 gMSA，则会保留原始的应用池配置。例如，当该账号使用内置账号类型（如 ApplicationPoolIdentity、NetworkService、LocalSystem 或 LocalService）时。

如需在迁移的 Windows 容器中支持 gMSA，您必须执行以下操作：

  1. 修改迁移计划以设置必要的属性，将迁移的容器配置为使用 gMSA。

  2. 配置托管已部署容器的目标集群。

配置目标集群以支持 gMSA

您可以在 Pod 集群中将 gMSA 作为 Pod 配置的一部分进行关联，而不是作为容器映像中的静态身份配置关联。

如需配置托管迁移的 Windows 容器的集群以支持 gMSA，您必须执行以下操作：

  1. 配置 Active Directory 以使虚拟机自动加入网域。

  2. 为 Windows Pod 和容器配置 gMSA。

详情请参阅以下内容：

将 SSL 证书存储为 Kubernetes Secret 时部署容器

我们建议您使用 Cloud Load Balancing、Ingress 或 Anthos Service Mesh 作为 HTTPS 前端来保护对已部署的容器的外部访问。通过此选项，您可以保护外部通信，而无需在集群内包含任何证书。如需了解详情，请参阅自定义迁移计划。

您还可以将安全套接字层 (SSL) 证书存储为 Kubernetes Secret，并在运行时将其装载到容器中。

如需使用 Kubernetes Secret，请执行以下操作：

  1. 使用证书和密码创建 PFX 文件。

  2. 创建用于定义网站访问权限的配置 YAML 文件：

    sites:
 - sitename: "sitename"
   sslport: 443
   pfxpath: c:\sslconfig\pfx
   password: "password"
   thumbprint: "3e858d0551fc0536f52d411dad92b680a4fad4da"

    其中：

    • sitename 指定配置为使用 SSL 的网站的名称。sites 属性可以包含多个 sitename 条目。

    • sslport 指定要监听 SSL 连接的端口（通常为 443）。

    • pfxpath 指定 PFX 文件的路径。将其配置为 pod 部署的 volumeMounts 的一部分。

    • password 指定 PFX 文件的密码。

    • thumbprint 指定 PFX 文件的 SHA-1 指纹，可通过 PowerShell 命令进行检索：

      Get-PfxCertificate -FilePath "path to pfx"

      也可以在 Windows 证书管理器中查看。

  3. 创建 Kubernetes Secret：

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

  4. 在映像的部署中创建卷装载和卷装载：

    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

    其中：

    • mountPath 是您在第 2 步中创建的配置文件中由 pfxpath 指定的相同路径。
    • M4A_CERT_YAML 是一个环境变量，指向您在第 2 步中创建的配置 YAML 文件的完整路径。
    • secret-name 是您在第 3 步中创建的 Secret 的名称。

配置 SSL

建议不要将 SSL 证书私钥存储在容器映像中，因为读取映像的任何人都可以访问这些私钥。Migrate to Containers 提供了几种处理 Windows SSL 的方法。

使用自动生成的自签名证书

默认情况下，系统会为具有 HTTPS 绑定的 Windows 容器分配一个自动生成的自签名证书，该证书会在初始化 Docker 容器时生成。此配置可让您测试已迁移的工作负载，但不能在生产环境中使用。每次运行容器时，证书都会自签名并重新生成。

推荐 - 使用 Cloud Load Balancing、Ingress 或 Anthos Service Mesh

您可以自定义迁移计划中的绑定以使用 HTTP，然后使用 Cloud Load Balancing、Ingress 或 Anthos Service Mesh 作为 HTTPS 前端来保护外部访问权限。通过此选项，您可以保护外部通信，而无需在集群内包含任何证书。

  • 如需自定义绑定关系，请在代表迁移的迁移计划中修改 site 定义，将 protocol 设置为 http：

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

然后，您可以将请求从 HTTPS 前端转发到 Windows 工作负载的 HTTP 路径和端口。

将 SSL 证书存储为 Kubernetes Secret

建议您使用 Cloud Load Balancing、Ingress 或 Anthos Service Mesh 作为 HTTPS 前端来保护外部访问权限。不过，您也可以将 SSL 证书存储为 Kubernetes Secret，并在运行时将其装载到容器中。

如需使用存储为 Kubernetes Secret 的 SSL 证书，您必须修改容器的部署映像。如需了解详情，请参阅将 SSL 证书存储为 Kubernetes Secret 时部署容器。

给 Cloud Logging 配置日志记录

Migrate to Containers 使用 LogMonitor 工具从 Windows 容器提取日志并将其转发到您的 GKE 集群。然后，这些日志会自动转发到 Cloud Logging，而 Cloud Logging 提供了一套用于监控容器的工具。

默认情况下，Migrate to Containers 允许 IIS 日志记录监控 IIS 日志，还会将应用或系统事件日志转发到 Cloud Logging。

配置日志记录

展开生成的 artifacts.zip 文件会创建若干目录，包括 m4a 目录。该目录包含每张图片的文件夹。 m4a 目录中包含您可修改以控制日志记录的 LogMonitorConfig.json 文件。

如需详细了解如何修改 LogMonitorConfig.json，请参阅编写配置文件。

设置 ACL

某些 IIS 应用要求您对文件和文件夹设置特定的访问控制列表 (ACL) 权限，以确保应用正常运行。Migrate to Containers 会自动扫描所有已迁移的 IIS 应用，并添加在来源虚拟机中定义的、适用于 IIS 账号（IUSR 账号和 IIS_IUSRS 组）的特定权限，而且还会将这些权限应用到生成的容器映像中复制的文件和目录。

由于 Windows 容器映像不支持在 Docker COPY 命令中设置 ACL，因此 ACL 是在名为 set_acls.bat 的脚本中设置的。Migrate to Containers 会在特定 Windows 应用的已生成映像的目录中自动创建 set_acls.bat。然后，当您执行 docker build 命令时，Migrate to Containers 会调用 set_acls.bat。

修改 set_acls.bat 以添加或移除自定义权限，或修改由于与特定 IIS 用户无关而未被 Migrate to Containers 检测到的权限。

该脚本使用 Windows 内置的 icacls 工具设置权限。

.NET Global Assembly Cache 简介

Migrate to Containers 会扫描源映像 .NET Global Assembly Cache (GAC)，以查找在来源机器上安装但未包含在正式映像中的 .NET 资源。任何发现的 DLL 都会被复制到 Docker 上下文中，并通过一个实用程序脚本 install_gac.ps1 作为构建目标映像的一部分进行安装。

所有 .NET 组件都将复制到 m4a\gac 目录下的 Docker 上下文中。如需从映像中移除组件，请从 m4a\gac 目录中删除它们。

COM 对象 DLL 注册

系统会自动扫描和注册公开 COM 对象的 DLL。在提取阶段，系统会扫描复制的文件以查找注册为 COM 对象的 DLL，然后将其注册到容器中。

此过程无需用户输入。但是，您可以通过添加更多要复制的 DLL，来影响此过程。如果需要，系统会依次检查并注册这些 DLL。

后续步骤