このチュートリアルは、自動継続的インテグレーション（CI）パイプラインをビルドして、Google Cloud でマルチアーキテクチャのコンテナ イメージをビルドする方法を説明するシリーズのパート 2 です。
このチュートリアルでは、Cloud Build と Container Registry を使用してマルチアーキテクチャ コンテナ イメージをビルドするためのパイプラインを実装します。このチュートリアルでは、このシリーズのパート 1 のマルチアーキテクチャ コンテナ イメージ ビルド パイプラインの実装セクションで説明されているマルチアーキテクチャ ビルド戦略を例示します。
たとえば、一連のモノのインターネット（IoT）デバイスを管理するとします。IoT ソリューションに関して新しい要件が発生した場合に、新しいハードウェア デバイスが必要になります。新しいデバイスのハードウェア アーキテクチャが既存のものと異なる場合は、ビルド パイプラインを変更して新しいアーキテクチャをサポートする必要があります。
このシリーズは、コンテナ イメージをビルドするための複雑なパイプラインの簡素化と合理化、またそれらのパイプラインを拡張してマルチアーキテクチャ イメージのビルドを担当する IT プロフェッショナルを対象としています。
このチュートリアルは、以下の基本知識をお持ちであることを前提としています。
- Terraform: Google Cloud にインフラストラクチャを作成します。
- Google Cloud CLI: Google Cloud でプラットフォーム タスクを実行するために使用します。
- Cloud Shell: このチュートリアルでコマンドを実行するために使用します。このチュートリアルで使用するツールはすべて、Cloud Shell にプリインストールされています。
- Cloud Build: CI パイプラインを設定します。
- Docker: コンテナ管理プラットフォームとして使用します。
- Container Registry: ビルドプロセスによって生成されたコンテナ イメージを保存するために使用します。
このチュートリアルでは、Terraform を使用して、パイプラインをプロビジョニングして構成し、コンテナ イメージをビルドするのに必要なリソースを設定します。
アーキテクチャ
次の図は、このチュートリアルでコンテナ イメージをビルドするために作成するパイプラインのワークフローを示しています。
コンテナ イメージのソースコードが変更されると、Cloud Build によりマルチアーキテクチャ コンテナ イメージがビルドされます。ビルドが完了すると、マルチアーキテクチャ コンテナ イメージが Container Registry に保存されます。
目標
- Terraform を使用して、Google Cloud でコンテナ イメージをビルドするためのパイプラインをプロビジョニングします。
- コンテナ イメージのソースコードを変更して、新しいビルドをトリガーします。
- Container Registry に保存されているコンテナ イメージを検査します。
費用
このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。
料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。
始める前に
-
Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。
このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。
環境の準備
このチュートリアルでは、すべてのコマンドを Cloud Shell で実行します。
-
Google Cloud コンソールで、「Cloud Shell をアクティブにする」をクリックします。
Google Cloud コンソールの下部で Cloud Shell セッションが開始し、コマンドライン プロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。
サンプルコード リポジトリのクローンを作成します。
cd "$HOME" git clone \ https://github.com/GoogleCloudPlatform/solutions-build-multi-architecture-images-tutorial.gitアプリケーションのデフォルト認証情報を生成します。
gcloud auth application-default login --quiet出力は次のようになります。
Go to the following link in your browser: https://accounts.google.com/o/oauth2/auth?code_challenge=... Enter verification code:ブラウザ ウィンドウで、アプリケーションのデフォルト認証情報（前のステップ）の生成出力に表示される URL を開きます。
[許可] を選択して続行します。
画面上のコードをコピーして、Cloud Shell に入力します。
出力は次のようになります。
/tmp/tmp.xxxxxxxxxx/application_default_credentials.json
application_default_credentials.jsonファイルへのパスをメモします。このパスは、次の手順で環境変数を設定するときに使用します。
環境変数を設定する
このチュートリアルに必要なインフラストラクチャをプロビジョニングする前に、次の環境変数を初期化してエクスポートする必要があります。
Cloud Shell で、Terraform がリソースをプロビジョニングする際に使用する Google Cloud サービス アカウントの名前を格納する環境変数を作成します。
export TF_SERVICE_ACCOUNT_NAME=tf-service-accountTerraform が状態の保存に使用する Google Cloud プロジェクト ID を格納する環境変数を作成します。
export TF_STATE_PROJECT=${DEVSHELL_PROJECT_ID}Terraform が状態ファイルを保存するために使用する Cloud Storage バケットを格納する環境変数を作成します。
export TF_STATE_BUCKET=tf-state-bucket-${TF_STATE_PROJECT}コンテナ イメージのビルド パイプラインのリソースを含む Google Cloud プロジェクト ID を格納する環境変数を作成します。
export GOOGLE_CLOUD_PROJECT=${DEVSHELL_PROJECT_ID}デフォルトの Google Cloud アプリケーションのデフォルト認証情報へのパスを格納する環境変数を作成します。これは、前のセクションでメモした値です。
export GOOGLE_APPLICATION_CREDENTIALS=PATH
次のように置き換えます。
PATH:application_default_credentials.jsonファイルのパス。
環境のプロビジョニング
generate-tf-backend.sh シェル スクリプトを実行して、Terraform バックエンド構成、必要な Google Cloud サービス アカウント、Terraform リモート ステート情報を保存する Cloud Storage バケットを生成します。
Cloud Shell で、ビルド環境をプロビジョニングします。
cd $HOME/solutions-build-multi-architecture-images-tutorial/ ./generate-tf-backend.shスクリプトはべき等であり、複数回実行しても安全です。
スクリプトを初めて実行して成功すると、出力は次のようになります。
Generating the descriptor to hold backend data in terraform/backend.tf terraform { backend "gcs" { bucket = "tf-state-bucket-project-id" prefix = "terraform/state" } }
ビルド パイプラインの作成
Terraform テンプレート ファイル terraform/main.tf は、このチュートリアル用に作成されるリソースを定義します。この記述ファイルで Terraform を実行すると、次の Google Cloud リソースが作成されます。
- コンテナ イメージ記述子と Cloud Build ビルド構成ファイルを保存する Cloud Source Repositories コード リポジトリ。
- ソースコードが変更されるたびに Cloud Build がメッセージを公開する Pub/Sub トピック。
- マルチアーキテクチャ コンテナ イメージをビルドする Cloud Build のビルド。
- コンテナ イメージを保存するための Container Registry リポジトリ。
Cloud Shell で、次の操作を行います。
Terraform の作業ディレクトリを初期化するため、terraform init コマンドを実行します。
cd terraform terraform init（省略可）Terraform で適用される変更を確認するため、terraform plan コマンドを実行します。
terraform plan出力は、Terraform が Google Cloud 環境でリソースをプロビジョニングするために実行すると想定されるすべてのアクションのリストです。すべてのアクションの概要は次のようになります。
Plan: 8 to add, 0 to change, 0 to destroy.
追加アクションの合計数は 8 であり、変更および削除は行われていません。
terraform apply コマンドを実行して、Google Cloud プロジェクトにリソースを作成します。
terraform applyコマンドの実行を続けるには、「
yes」と入力します。
Cloud Source Repositories にソースファイルを push する
ビルド パイプラインでビルドを実行するには、Dockerfile と Cloud Build 構成ファイルを Cloud Source Repositories のソースコード リポジトリに保存する必要があります。
Cloud Shell で、ソース リポジトリのクローンを作成します。
cd $HOME gcloud source repos clone cross-buildDockerfile と Cloud Build 構成ファイルをソースコード リポジトリにコピーします。
cp -r "$HOME"/solutions-build-multi-architecture-images-tutorial/terraform/cloud-build/. "$HOME"/cross-buildソースコード リポジトリ内のファイルを commit して push します。
cd "$HOME"/cross-build git add . git commit -m "Initial commit" git push
結果を検査する
Cloud Build ジョブの実行中と完了後に、Cloud Build のビルド履歴ページで各ビルドステップの実行を検査できます。
Cloud Build ビルド
[ビルド履歴] ページでは、次の図に示すように、ビルドステップの概要と各ステップの実行に要した時間を確認できます。
ビルドステップを開くと、そのステップの出力が表示されます。たとえば、前の図の buildx inspect ステップのビルドの詳細は、プラットフォームがサポートするさまざまなターゲット プラットフォーム アーキテクチャを示しています。
12 Name: mybuilder0 13 Endpoint: unix:///var/run/docker.sock 14 Status: running 15 Platforms: linux/amd64, linux/arm64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
4 番目のステップのビルドの詳細は、各ターゲット アーキテクチャのビルドの出力を示しています。
#8 0.268 I am running on linux/amd64, building for linux/amd64 #12 0.628 I am running on linux/amd64, building for linux/arm/v7 #10 0.279 I am running on linux/amd64, building for linux/arm/v6 #14 0.252 I am running on linux/amd64, building for linux/arm64
Container Registry のイメージ マニフェスト
ビルドが完了したら、次の図に示すように、Google Cloud コンソールの Container Registry [イメージ] ページでイメージ マニフェストを調べることができます。
リポジトリ リストで [test] リポジトリを開くと、次の図のように [test] リポジトリに属するすべてのコンテナ イメージのバージョンが表示されます。
[latest] タグが付けられているイメージを開くと、[ダイジェストの詳細] ページが開き、次の図に示すようにイメージに関する詳細情報が表示されます。
[ダイジェストの詳細] ページで、[マニフェスト] セクションを展開し、ビルドによって作成されたすべてのターゲット アーキテクチャがファイル内に記述されていることを確認できます。次の例をご覧ください。
{
"mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
"schemaVersion": 2,
"manifests": [
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"digest": "sha256:839024acb1038509e3bc66f3744857840951d0d512be54fd6670ea1e8babdcb6",
"size": 735,
"platform": {
"architecture": "amd64",
"os": "linux"
}
},
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"digest": "sha256:33489767c29efb805e446a61d91cc55e042d3cfadcd186d9a1c8698f2f12309d",
"size": 735,
"platform": {
"architecture": "arm64",
"os": "linux"
}
},
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"digest": "sha256:f1958815778ca8c83d324bad3fc68a9e3e9d5ea48b5bb27a8aca7d8da20cf8d4",
"size": 735,
"platform": {
"architecture": "arm",
"os": "linux",
"variant": "v7"
}
}
]
}
Cloud Shell から直接イメージ マニフェストを表示することもできます。
Cloud Shell で、イメージ マニフェストを表示します。
DOCKER_CLI_EXPERIMENTAL=enabled docker manifest inspect gcr.io/"${DEVSHELL_PROJECT_ID}"/test:latest出力は、[ダイジェストの詳細] ページで展開できるマニフェスト ファイルと同じです。
ビルド パイプラインからの継続的デプロイの構成
新しいハードウェア アーキテクチャのコンテナ イメージをビルドするには、新しいターゲット アーキテクチャを追加してビルド構成ファイルを変更します。変更を commit して Cloud Source Repositories のソース リポジトリに push すると、Cloud Build が新しいビルドを開始します。ビルドは、新しく追加されたハードウェア アーキテクチャのサポートを含む、マルチアーキテクチャ コンテナ イメージの新しいバージョンを生成します。
Cloud Shell で、新しいターゲット プラットフォームをビルド構成ファイルに追加します。
cd "$HOME"/cross-build sed -i -e 's/linux\/arm\/v7/linux\/arm\/v7,linux\/386/g' build-docker-image-trigger.yaml変更を commit してソースコード リポジトリに push します。
git add . git commit -m "add a new target platform" git push最新のマニフェストを表示して、新しいターゲット プラットフォームが最新のコンテナ イメージの一部であることを確認します。
DOCKER_CLI_EXPERIMENTAL=enabled docker manifest inspect gcr.io/${DEVSHELL_PROJECT_ID}/test:latest次の出力のように、新しく追加されたターゲット プラットフォームがマニフェスト ファイルにあることを確認します。
{ "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json", "schemaVersion": 2, "manifests": [ { "mediaType": "application/vnd.docker.distribution.manifest.v2+json", "digest": "sha256:bc80d063fccb4c370df9b505cbf4f8a814a366d99644de09ebee98af2ef0ff63", "size": 735, "platform": { "architecture": "amd64", "os": "linux" } }, { "mediaType": "application/vnd.docker.distribution.manifest.v2+json", "digest": "sha256:be10e4f01f529149815ebad7eb09edaa84ebef5b7d70d51f7d1acb5ceb1f61cd", "size": 735, "platform": { "architecture": "arm64", "os": "linux" } }, { "mediaType": "application/vnd.docker.distribution.manifest.v2+json", "digest": "sha256:f6ba5d5d3bc1ea0177e669517ea15a0d4fb97c06c7eca338afa43734d87af779", "size": 735, "platform": { "architecture": "arm", "os": "linux", "variant": "v7" } }, { "mediaType": "application/vnd.docker.distribution.manifest.v2+json", "digest": "sha256:a3c34621cca10974026f8ad0782af78539cd7bb0ebfa0082a27b2c3ed4418ca0", "size": 735, "platform": { "architecture": "386", "os": "linux" } } ] }
クリーンアップ
課金を停止する最も簡単な方法は、チュートリアル用に作成した Google Cloud プロジェクトを削除することです。また、リソースを個別に削除することもできます。
プロジェクトの削除
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
個々のリソースを削除する
このチュートリアルで使用したプロジェクトを保持する場合は、次の手順を実施して、このチュートリアルで作成したリソースを削除します。
Cloud Shell で、コンテナ イメージを削除します。
gcloud container images delete gcr.io/${DEVSHELL_PROJECT_ID}/test --quietTerraform を使用してプロビジョニングしたリソースを削除します。
cd $HOME/solutions-build-multi-architecture-images-tutorial/terraform terraform destroy「
yes」と入力して削除を確定します。
次のステップ
- IoT デバイス向けのマルチアーキテクチャ コンテナ イメージを読む。
- Terraform、Cloud Build、GitOps を使用してインフラストラクチャをコードとして管理する方法を学習する。
- DevOps の詳細について、DevOps ページで確認する。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。