Windows Server マルチアーキテクチャイメージのビルド

Standard

このチュートリアルでは、複数の Windows Server バージョンをターゲットとするイメージをビルドする際のバージョニングの複雑度を管理する方法について説明します。Windows Server コンテナには、複数の Windows Server ホストバージョンでコンテナが実行されることを回避するためのバージョンの互換性に関する要件が存在します。ただし、Windows Server の Docker では、複数の Windows Server バージョンで実行できるマルチアーキテクチャ（またはマルチプラットフォーム）コンテナイメージがサポートされています。

マルチアーキテクチャイメージを使用することで、イメージを再ビルドして Pod 仕様を変更することなく、Google Kubernetes Engine（GKE）Windows Server のノードプールを任意の Windows Server バージョンにアップグレードできます。次に例を示します。

GKE バージョン 1.15 は Windows Server 1809 をサポートしています
GKE バージョン 1.16 は Windows Server 1909 をサポートしています

ある GKE バージョンからそれ以降のバージョンに自動的にアップグレードするには、Windows ワークロードのマルチアーキテクチャイメージをビルドする必要があります。マルチアーキテクチャイメージをビルドするには、Windows Server のバージョンごとにイメージをビルドしてから、Windows Server の各バージョンに対してそれらのイメージを参照するマニフェストを作成する必要があります。イメージの作成とビルドのプロセスを完全に制御する必要がある場合は、イメージを手動で作成できます。または、Cloud Build を使用して Windows Server マルチアーキテクチャイメージを自動的にビルドすることもできます。

目標

このチュートリアルでは、Windows Server マルチアーキテクチャイメージを手動で作成する、または Cloud Build を使用して作成する方法について説明します。

イメージを手動でビルドします。
- Long-Term Servicing Channel（LTSC）や Semi-Annual Channel（SAC）など、Windows Server のさまざまなバージョンやタイプで 2 つの Docker イメージを作成します。
- Windows Server VM を作成します。
- マニフェストを作成し、レジストリに push します。
Cloud Build を使用してイメージをビルドします。
- プロジェクトを作成し、API を有効にして、権限を付与することによって、環境を準備します。
- アプリケーション、Dockerfile、ビルドファイルを作成します。
- コマンドを実行して、イメージをビルドします。

費用

このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。

始める前に

作業を始める前に、次のタスクを完了済みであることを確認してください。

Google Cloud CLI をインストールして gcloud コマンドを実行します。
Docker をインストールしてコンテナをビルドします。
Go をインストールして Windows Server バイナリをビルドします。
このチュートリアルでは、リポジトリとして Artifact Registry を使用します。Docker リポジトリを作成済みであることを確認します。

マルチアーキテクチャイメージの手動ビルド

マルチアーキテクチャイメージを手動でビルドすると、必要な Windows Server バージョンが含まれるイメージを柔軟にビルドできます。マルチアーキテクチャイメージを手動でビルドする手順は次のとおりです。

LTSC 2019 Docker シングルアーキテクチャイメージを作成します。Docker イメージ作成の詳細については、Windows Server アプリケーションのデプロイをご覧ください。例: us-docker.pkg.dev/my-project/docker-repo/foo:1.0-2019
LTSC 2022 Docker シングルアーキテクチャイメージを作成します。例: us-docker.pkg.dev/my-project/docker-repo/foo:1.0-2022
SAC 20H2 Docker シングルアーキテクチャイメージを作成します。例: us-docker.pkg.dev/my-project/docker-repo/foo:1.0-20h2
Windows Server VM を作成します（バージョン 20H2 など）。Windows Server VM の使用に関するクイックスタートをご覧ください。
RDP を使用して VM に接続します。
次の手順で、PowerShell ウィンドウを開いてコマンドを実行します。
docker manifest 試験運用版機能を有効にします。Docker マニフェストは、レジストリに push するイメージのリストです。
```
PS C:\> $env:DOCKER_CLI_EXPERIMENTAL = 'enabled'
```

マルチアーキテクチャマニフェストを作成します。

docker manifest create `
  REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/foo:1.0 `
  REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/foo:1.0-2019 `
  REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/foo:1.0-2022 `
  REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/foo:1.0-20h2

新しく作成したマルチアーキテクチャイメージマニフェストを Artifact Registry リポジトリに push します。
```
 docker manifest push `
   REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/foo:1.0
```
マルチアーキテクチャイメージが正常にビルドされて push されたことを確認するには、REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/foo に移動し、対象のイメージをクリックします。3 つのイメージが表示されます。
- foo:1.0-2019
- foo:1.0-2022
- foo:1.0-20h2
- foo:1.0

Pod 仕様でマルチアーキテクチャイメージ REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/foo:1.0 を参照できるようになりました。これにより、GKE Windows ノードプールの自動アップグレードを安全に使用できます。

Cloud Build gke-windows-builder を使用したマルチアーキテクチャイメージのビルド

手動のビルドステップを簡単にするために、OSS gke-windows-builder をベースとした gke-windows-builder を使用できます。Cloud Build で gke-windows-builder を使用して、Windows Server マルチアーキテクチャイメージを自動的にビルドできます。リリースされた際にサポート対象の新しい Windows SAC と LTSC が含まれるように、GKE がビルダーを更新します。このビルダーを使用するもう 1 つの利点は、イメージをビルドするために Powershell を使用して独自の Windows VM を作成する必要がないことです。Windows VM は、Cloud Build 内でコマンドを実行する Docker コンテナに置き換えられます。

ビルダーの動作を理解できるように、この例の手順に沿って「hello world」のマルチアーキテクチャイメージをビルドします。次の手順は、Linux サーバーまたは Windows サーバーで行えます。

環境の準備

環境を準備するには、次の手順を行います。

作業用マシンにワークスペースディレクトリを作成します（例: ~/gke-windows-builder/hello-world）。
このチュートリアル用のプロジェクトを作成するか選択します。
プロジェクトに対して課金が有効になっていることを確認します。
Compute Engine、Cloud Build、Artifact Registry の各 API をプロジェクトで使用できるようにします。gke-windows-builder が Cloud Build を使用して呼び出され、その結果として得られるマルチアーキテクチャコンテナイメージが Artifact Registry に push されます。ビルダーで Windows Server VM を作成、管理するには、Compute Engine が必要です。
```
gcloud services enable compute.googleapis.com cloudbuild.googleapis.com \
  artifactregistry.googleapis.com cloudbuild.googleapis.com
```

Google Cloud CLI を使用して、Cloud Build サービスアカウントに次の Identity and Access Management（IAM）ロールを付与します。

変数を設定します。

export PROJECT=$(gcloud info --format='value(config.project)')
export MEMBER=$(gcloud projects describe $PROJECT --format 'value(projectNumber)')@cloudbuild.gserviceaccount.com

ロールを割り当てます。ビルダーで Windows Server VM を作成して、ワークスペースを Cloud Storage バケットにコピーする場合や、Docker イメージをビルドして Artifact Registry に push できるようにネットワークを構成する場合は、以下のロールが必要です。

gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:$MEMBER --role='roles/compute.instanceAdmin'
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:$MEMBER --role='roles/iam.serviceAccountUser'
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:$MEMBER --role='roles/compute.networkViewer'
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:$MEMBER --role='roles/storage.admin'
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:$MEMBER --role='roles/artifactregistry.writer'

allow-winrm-ingress という名前のファイアウォールルールを追加して、WinRM が Windows Server VM に接続して Docker ビルドを実行することを許可します。

注: ファイアウォールルール名は allow-winrm-ingress にする必要があります。これは、gke-windows-builder がこの特定の名前を使用して、このファイアウォールルールが存在するかどうかを確認するためです。
```
gcloud compute firewall-rules create allow-winrm-ingress --allow=tcp:5986 --direction=INGRESS
```
プロジェクトの Artifact Registry に Docker リポジトリを作成します。Artifact Registry で Docker リポジトリを使用したことがない場合は、まず Docker のクイックスタートを済ませます。次のコマンドを実行してリポジトリを作成します。
```
gcloud artifacts repositories create REPOSITORY \
  --repository-format=docker --location=REGISTRY_REGION \
  --description="Docker repository"
```
次のように置き換えます。
- REPOSITORY: 名前（例: windows-multi-arch-images）。
- REGISTRY_REGION: 有効な Artifact Registry のロケーション。

ワークスペースでの hello.exe バイナリの作成

このチュートリアルでは、Go で記述されたシンプルな「hello world」アプリケーションを作成します。サンプルアプリのコードは GitHub にに掲載されています。

次のコマンドを使用して、このチュートリアルのサンプルコードが含まれるリポジトリのクローンをローカルマシンに作成します。
```
 git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
 cd kubernetes-engine-samples/windows/windows-multi-arch
```
hello.go ファイルに「Hello World」というテキストが出力されます。
```
package main

import "fmt"

func main() {
	fmt.Println("Hello World!")
}
```
hello.exe バイナリを生成します。
```
GOOS=windows go build hello.go
```

ワークスペースに hello.exe バイナリが表示されます。

Dockerfile を作成し、ワークスペースでファイルをビルドする

このセクションでは、Dockerfile を使用してシングルアーキテクチャの Windows Server の各イメージをビルドし、ビルドファイルを使用して Cloud Build をトリガーします。このビルドでは、シングルアーキテクチャイメージがマルチアーキテクチャのイメージに統合されます。

Dockerfile は、Docker がイメージを作成するための指示が記載されたテキストドキュメントです。gke-windows-builder は、WINDOWS_VERSION をイメージのビルド対象である Windows Server バージョンに置き換えます。たとえば、Windows Server 20H2 で docker build -t multi-arch-helloworld:latest_20h2 --build-arg WINDOWS_VERSION=20H2 . を実行します。
```
ARG WINDOWS_VERSION=
FROM mcr.microsoft.com/windows/servercore:${WINDOWS_VERSION}
COPY hello.exe /hello.exe
USER ContainerUser
ENTRYPOINT ["hello.exe"]
```

Dockerfile が格納されているのと同じディレクトリ内の cloudbuild.yaml ファイルは、ビルド構成ファイルです。<REPOSITORY> と <REGISTRY_REGION> は、前の手順で作成した Artifact Registry リポジトリの名前とリージョンに置き換えます。ビルド時に、自動的に $PROJECT_ID がプロジェクト ID に置き換えられます。

timeout: 3600s
steps:
- name: 'us-docker.pkg.dev/gke-windows-tools/docker-repo/gke-windows-builder:latest'
  args:
  - --container-image-name
  # Replace <REGISTRY_REGION> and <REPOSITORY>.
  - '<REGISTRY_REGION>-docker.pkg.dev/$PROJECT_ID/<REPOSITORY>/multiarch-helloworld:latest'
  # Specify specific variants of images to be built. Or, remove the following 2 lines to default to all available variants.
  - --versions
  - '20H2,ltsc2019'

イメージのビルド

これで、イメージをビルドしてログを表示し、ビルドが成功したことを確認できるようになりました。

イメージをビルドするには、次のコマンドを実行します。
```
gcloud builds submit --config=cloudbuild.yaml .
```
注: このコマンドの実行には数分かかります。

ログは、次の例のように表示されます。ログの最後の行に、ビルドが成功したことが示されます。

Creating temporary tarball archive of 2 file(s) totalling 492 bytes before compression.
Uploading tarball of [.] to [gs://PROJECT_ID_cloudbuild/source/1600082502.509759-b949721a922d462c94a75da9be9f1181.tgz]
Created [https://cloudbuild.googleapis.com/v1/projects/PROJECT_ID/builds/ec333452-1301-47e8-90e2-716aeb2f5650].
Logs are available at [https://console.cloud.google.com/cloud-build/builds/ec333452-1301-47e8-90e2-716aeb2f5650?project=840737568665].
------------------------ REMOTE BUILD OUTPUT---------------------------------------
...
...

Created manifest list REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/multiarch-helloworld:latest
sha256:3ecbbc9f5144f358f81f7c7f1a7e28f069c98423d59c40eaff72bf184af0be02
2020/09/14 11:34:25 Instance: 35.184.178.49 shut down successfully
PUSH
DONE
-----------------------------------------------------------------------------------

ID                                    CREATE_TIME                DURATION  SOURCE                                                                                      IMAGES  STATUS
ec333452-1301-47e8-90e2-716aeb2f5650  2020-09-14T11:21:43+00:00  12M43S    gs://PROJECT_ID_cloudbuild/source/1600082502.509759-b949721a922d462c94a75da9be9f1181.tgz  -                 SUCCESS

ビルド構成ファイルを使用してイメージをビルドし、ビルドしたイメージを REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/multiarch-helloworld:latest で Artifact Registry に push しました。

イメージのデプロイ

マルチアーキテクチャ Windows イメージをクラスタにデプロイするには、Windows Server アプリケーションのデプロイをご覧になり、イメージをデプロイする方法を確認してください。

gke-windows-builder の高度な使用方法

gke-windows-builder の動作は、cloudbuild.yaml ビルド構成ファイルの args セクションにフラグを追加することでカスタマイズできます。このセクションでは、一般的な動作のフラグの一部について説明しますが、網羅的なリストではありません。gke-windows-builder がサポートするフラグの完全なリストを表示するには、Linux サーバーまたは Cloud Shell で次のコマンドを実行します。

docker run -it us-docker.pkg.dev/gke-windows-tools/docker-repo/gke-windows-builder:latest --help

ビルドを高速化するには、Windows インスタンスのより大きなマシンタイプを使用します。

  - --machineType
  - 'n1-standard-8'

GKE がサポートするすべての Windows バージョン用にイメージをビルドする代わりに、--versions フラグを使用して、ビルド対象の Windows Server の特定のバージョンを選択できます。

  - --versions
  - '20H2,ltsc2019'

ワークスペースに多くのファイルがある場合、WinRM ではなく Cloud Storage を介してワークスペースをコピーするようにビルダーを構成すると、イメージビルドの信頼性が向上します。プロジェクトで gs://{your project}_builder などのバケットを作成してから、--workspace-bucket フラグを設定します。

  - --workspace-bucket
  - '{your project}_builder'

共有 VPC サービスプロジェクトで Windows ビルダーインスタンスを実行するには、次のフラグを使用してインスタンスのネットワーク設定を制御します。

  - --subnetwork-project
  - 'shared-vpc-host-project'
  - --subnetwork
  - 'host-project-subnet-shared-with-service-project'

クリーンアップ

チュートリアルが終了したら、作成したリソースをクリーンアップして、割り当ての使用を停止し、課金されないようにできます。次のセクションで、リソースを削除または無効にする方法を説明します。

イメージの削除

Artifact Registry の multiarch-helloworld イメージを削除するには、イメージの削除をご覧ください。

プロジェクトの削除

課金をなくす最も簡単な方法は、チュートリアル用に作成したプロジェクトを削除することです。

プロジェクトを削除するには:

注意: プロジェクトを削除すると、次のような影響があります。

プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
カスタムプロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタムプロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のアーキテクチャ、チュートリアル、クイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにすることができます。

Google Cloud コンソールで、[リソースの管理] ページに移動します。
[リソースの管理] に移動
プロジェクトリストで、削除するプロジェクトを選択し、[削除] をクリックします。
ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

次のステップ

Kubernetes Engine のチュートリアルを調べる。
Google Cloud に関するリファレンスアーキテクチャ、図、ベストプラクティスを確認する。Cloud アーキテクチャセンターをご覧ください。