デプロイする Windows クラスタを準備する
このページでは、デプロイ用の Windows クラスタを準備する方法について説明します。
始める前に
- 移行を完了し、アーティファクトが生成された状態にする。
- ワークロードをデプロイするクラスタを作成する。詳細については、Windows クラスタの作成をご覧ください。
kubectlを設定してクラスタに接続する。
Docker レジストリを選択して設定する
デプロイの一環として、コンテナの Docker イメージをビルドし、Docker レジストリにアップロードします。
Docker レジストリには、次のものを使用できます。
Artifact Registry
基本認証をサポートする任意の Docker レジストリ
デプロイ クラスタと同じプロジェクトで Artifact Registry を使用することをおすすめします。GKE はデフォルトでレジストリにアクセスできます。詳細については、GKE との統合の要件をご覧ください。
非公開 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 ベースのワークロードをビルドしてデプロイする方法を学習する。