デプロイする Windows クラスタを準備する

このページでは、移行アーティファクトのカスタマイズが必要になるシナリオについて説明します。

始める前に

このドキュメントは、移行が完了していることを前提としています。

ターゲットクラスタに Docker レジストリへの読み取りアクセス権が付与されていることを確認する

移行処理の中で、Migrate to Containers は移行された VM を表す Docker イメージを Docker レジストリにアップロードします。こうした Docker イメージは、移行する VM のファイルとディレクトリを表します。

Docker レジストリには、次のものを使用できます。

Container Registry
基本認証をサポートする任意の Docker レジストリ

詳細については、データリポジトリの定義をご覧ください。

移行に使用していない Google Cloud プロジェクトにワークロードをデプロイする

多くの場合、環境には複数の Google Cloud プロジェクトがあります。1 つの Google Cloud プロジェクトで移行を実行した後、移行したワークロードを別のプロジェクトのクラスタにデプロイする場合は、権限が正しく構成されていることを確認する必要があります。

たとえば、プロジェクト A で移行を行います。この場合、移行したワークロードはプロジェクト A の Container Registry バケットにコピーされます。例:

gcr.io/project-a/image_name:image_tag

次に、プロジェクト B のクラスタにワークロードをデプロイします。プロジェクト B のクラスタにはプロジェクト A にイメージを pull する権限がないため、権限を正しく構成しないと、ワークロード Pod の実行に失敗します。次の形式のメッセージを含むイベントが 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 バケットへのアクセスに必要な権限を設定します。たとえば、次の gcloud storage コマンドを使用してアクセスを有効にします。

gcloud storage buckets add-iam-policy-binding gs://artifacts.project-a.appspot.com --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com --role=roles/storage.objectViewer

ターゲットクラスタへのデプロイで Container Registry を Docker レジストリとして使用する

ターゲットクラスタが Container Registry にアクセスできるようにするには、Container Registry へのアクセスに必要な認証情報を含む Kubernetes Secret を作成します。

Container Registry と Cloud Storage にアクセスするためのサービスアカウントを作成するで説明されているように、移行をデプロイするためのサービスアカウントを作成します。

このプロセスでは、m4a-install.json という名前の JSON キーファイルをダウンロードする必要があります。
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 には、サービスアカウントのメールアドレスを指定します。
次のいずれかの方法で、Kubernetes Secret を設定します。
- デフォルトの imagePullSecrets 値を次のように変更します。
```
kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "gcr-json-key"}]}'
```
- deployment_spec.yaml ファイルを編集して、spec.template.spec 定義に imagePullSecrets 値を追加します。WebSphere traditional を使用する場合、Deployment 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 に置き換えます。
secrets.yaml が存在する場合、ワークロードシークレットをデプロイします。Liberty を使用して、Tomcat ベースのワークロードと WebSphere traditional ベースのワークロード用に Secrets ファイルが作成されます。Liberty ファイルの名前は liberty-secrets.yaml です。
```
kubectl apply -f secrets.yaml
```

Docker レジストリを使用してターゲットクラスタに基本認証でデプロイする

Docker レジストリを使用して移行イメージを保存する場合は、レジストリでユーザー名とパスワードを使用した基本認証がサポートされている必要があります。Docker レジストリへの読み取り専用接続を構成する方法は多数あるため、クラスタプラットフォームと Docker レジストリに適した方法を使用する必要があります。

gMSA を使用するように移行後のワークロードを構成する

Windows IIS アプリケーションワークロードは、多くの場合 Active Directory（AD）に参加しており、ドメイン ID で操作されます。これらの VM をコンテナに移行するときに、コンテナ自体はドメインに参加せず、ホストの Kubernetes クラスタノードがドメインに参加している場合があります。

移行後のコンテナをクラスタにデプロイするときに、グループマネージドサービスアカウント（gMSA）を使用できます。gMSA を使用すると、特定のサービスアカウント ID でコンテナを実行できます。gMSA をコンテナイメージ内の静的 ID 構成ではなく、Pod 構成の一部として Kubernetes クラスタで使用します。

Migrate to Containers は、ワークロードの変換プロセスで役立ちます。Migrate to Containers は、IIS アプリケーションプールの構成を自動的に検出し、生成された移行計画に推奨事項を追加します。その後、推奨事項を評価し、特定の環境と要件に合わせて調整します。

Migrate to Containers がアプリケーションプールの構成に gMSA は必要ないと判断した場合、元のアプリケーションプール構成が維持されます。たとえば、ApplicationPoolIdentity、NetworkService、LocalSystem、LocalService などの組み込みアカウントタイプを使用している場合が該当します。

移行後の Windows コンテナで gMSA をサポートするには、次のことを行う必要があります。

移行計画を編集して必要なプロパティを設定し、gMSA を使用するように移行後のコンテナを構成する。
デプロイされたコンテナをホストするターゲットクラスタを構成する。

gMSA をサポートするようにターゲットクラスタを構成する

gMSA をコンテナイメージ内の静的 ID 構成ではなく、Pod 構成の一部として Kubernetes クラスタで使用します。

移行後の Windows コンテナをホストするクラスタで gMSA をサポートするには、次の操作が完了している必要があります。

詳しくは以下をご覧ください。

Windows コンテナ用の gMSA を作成する。
グループマネージドサービスアカウントを作成する。
Google Cloud ドキュメントの gMSA の使用。
Microsoft のドキュメントで gMSA を使用するようにアプリを構成する。

SSL 証明書を Kubernetes Secret として保存するときにコンテナをデプロイする

外部からデプロイ済みコンテナへのアクセスを保護するため、HTTPS フロントエンドとして Cloud Load Balancing、Ingress、または Cloud Service Mesh を使用することをおすすめします。この方法では、クラスタ内の証明書を使用せずに外部通信を保護できます。詳細については、移行計画のカスタマイズをご覧ください。

SSL（Secure Sockets Layer）証明書を Kubernetes Secret として保存し、実行時にコンテナにマウントすることもできます。

Kubernetes Secret を使用するには:

証明書とパスワードを含む PFX ファイルを作成します。
サイトのアクセスを定義する構成 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 には、PowerShell コマンドで取得できる PFX ファイルの SHA-1 サムプリントを指定します。
```
Get-PfxCertificate -FilePath "path to pfx"
```
  これは、Windows 証明書マネージャーでも確認できます。

Kubernetes Secret を作成します。

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

イメージのデプロイ時にボリュームとボリュームのマウントを作成します。

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、または Cloud Service Mesh を使用する

HTTP を使用するように移行計画のバインディングをカスタマイズできます。これにより、HTTPS フロントエンドとして Cloud Load Balancing、Ingress、または Cloud Service Mesh を使用して、外部アクセスを保護できます。この方法では、クラスタ内の証明書を使用せずに外部通信を保護できます。

バインディングをカスタマイズするには、移行を表す移行計画の 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 として保存する

外部アクセスを保護するため、HTTPS フロントエンドとして Cloud Load Balancing、Ingress、または Cloud Service Mesh を使用することをおすすめします。ただし、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 グループ）に適用される移行元 VM で定義されている特定の権限を追加し、生成されたコンテナイメージにコピーされたファイルとディレクトリにその権限を適用します。

Windows コンテナイメージでは Docker COPY コマンドの一部として ACL を設定できないため、ACL を set_acls.bat というスクリプトに設定します。Migrate to Containers は、特定の Windows アプリケーション用に生成されたイメージのディレクトリに set_acls.bat を自動的に作成します。Migrate to Containers は、docker build コマンドを実行すると set_acls.bat を呼び出します。

set_acls.bat を編集してカスタム権限を追加または削除するか、特定の IIS ユーザーに関連しないため Migrate to Containers で検出されなかった権限を編集します。

このスクリプトでは、Windows 組み込みの icacls ツールを使用して権限を設定します。

.NET グローバルアセンブリキャッシュについて

Migrate to Containers は、ソースマシンで公式イメージの一部として使用できない .NET リソース用のソースイメージ .NET グローバルアセンブリキャッシュ（GAC）をスキャンします。検出された DLL は、Docker コンテキストにコピーされ、ユーティリティスクリプト install_gac.ps1 によってターゲットイメージのビルドの一部としてインストールされます。

すべての .NET アセンブリは、m4a\gac ディレクトリの Docker コンテキストにコピーされます。アセンブリをイメージから削除するには、それらを m4a\gac ディレクトリから削除します。

COM オブジェクト DLL の登録

COM オブジェクトを公開する DLL が自動的にスキャンされ、登録されます。抽出段階で、コピーされたファイルがスキャンされ、COM オブジェクトとして登録されている DLL がコンテナに登録されます。

このプロセスは、ユーザーによる入力なしで実行されます。ただし、コピーする DLL を追加すると、このプロセスに影響を与えることができます。必要に応じて、これらの DLL が順番にチェックされて登録されます。

次のステップ

Windows ベースのワークロードをビルドしてデプロイする方法を学習する。