コンテナイメージの再ビルドを自動化してベースイメージの更新を同期する

Cloud Workstations では、ワークステーション用のカスタムイメージを作成して使用できます。カスタムイメージが使用されたら、ベースイメージで利用可能な修正とアップデートを pull するためにカスタムイメージの再構築を自動化すると便利です。

このチュートリアルでは、カスタムワークステーションイメージにセキュリティアップデートとパッチを確実に適用するための自動パイプラインを構築する方法を説明します。

目標

このチュートリアルでは、次の手順に沿ってベースイメージの自動パイプラインを構築します。

Artifact Registry リポジトリを作成して、カスタムイメージを保存およびスキャンします。
イメージ構成を保存するために Google Cloud を使用して GitHub を構成します。
Cloud Build トリガーを作成して、Artifact Registry へのカスタムイメージの作成とデプロイを自動化します。
定期的にビルドを開始するように Cloud Scheduler を構成します。
自動プロセスの結果を確認します。

費用

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

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

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

始める前に

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

Google Cloud Console の [プロジェクトセレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

プロジェクトセレクタに移動

Google Cloud プロジェクトで課金が有効になっていることを確認します。

Artifact Registry, Container Scanning API, Cloud Build, and Cloud Scheduler API を有効にします。

API を有効にする

Google Cloud CLI をインストールします。

gcloud CLI を初期化するには:

gcloud init

Google Cloud Console の [プロジェクトセレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

プロジェクトセレクタに移動

Google Cloud プロジェクトで課金が有効になっていることを確認します。

Artifact Registry, Container Scanning API, Cloud Build, and Cloud Scheduler API を有効にします。

API を有効にする

Google Cloud CLI をインストールします。

gcloud CLI を初期化するには:

gcloud init

環境の準備

次に進む前に、必ず次の環境変数を設定してください。

使用する予定のクラウドプロジェクトのプロジェクト ID を設定します。
```
PROJECT_ID=$PROJECT_ID
```
リポジトリを保存する予定の GitHub ユーザー名を設定します。
```
GITHUB_USER=$GITHUB_ID
```
プロセスで使用する PROJECT_NUMBER 変数と REGION 変数を設定します。
```
PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \
    --format='value(projectNumber)')

REGION=$REGION
```
上記の例では、$REGION を、使用するリージョン名（us-central1 など）に置き換えます。

使用可能なリージョンの詳細については、Cloud Workstations のロケーションをご覧ください。

Artifact Registry リポジトリを作成する

このチュートリアルでは、Artifact Registry を使用してイメージを保存およびスキャンします。

次のコマンドを使用してリポジトリを作成します。

gcloud artifacts repositories create custom-images \
      --repository-format=docker \
      --location=$REGION \
      --description="Docker repository"

$REGION は、使用するリージョン名に置き換えます。

Artifact Registry にアクセスするときに gcloud CLI 認証情報を使用するように Docker を構成します。
```
gcloud auth configure-docker $REGION-docker.pkg.dev
```
注: なお、この構成では、自動コンテナスキャンも有効になります。これにより、脆弱性スキャンが提供されますが、スキャンされるイメージごとに追加料金がかかります。料金の詳細をご覧ください。
Artifact Analysis をオフにするには、次のコマンドを実行します。
```
gcloud services disable containerscanning.googleapis.com
```

GitHub リポジトリを構成する

実際には、カスタムイメージの Dockerfile を Git リポジトリに保持しておきます。自動プロセスは、ビルドプロセス中にそのリポジトリにアクセスして、関連する構成ファイルと Dockerfile を pull します。

サンプルリポジトリをフォークする

コンテナ定義を提供するサンプルリポジトリをフォークする手順は次のとおりです。

software-delivery-workshop リポジトリの新しいフォークを作成するには、このリンクをクリックします。
プロンプトが表示されたら、GitHub にログインします。
GitHub ユーザー名をオーナーとして選択します。リポジトリ名は software-delivery-workshop と表示されます。
[フォークを作成] をクリックし、処理が完了するまで数秒待ちます。

Cloud Build を GitHub に接続する

次に、組み込みの GitHub 接続機能を使用して、そのリポジトリを Cloud Build に接続します。GitHub リポジトリへのリンクをクリックして、プロセスを完了する手順に従います。ウィザードの最後のステップでトリガーを作成する必要はありません。後でコマンドラインから行うことができるため、最後のステップはスキップできます。

Cloud Build を GitHub repository リポジトリに接続します。

別の Git リポジトリソリューションを使用している場合は、手順に従って Cloud Build を GitLab に接続するか、Bitbucket に接続することもできます。

Cloud Build トリガーを作成する

サンプルリポジトリには、コンテナ定義と、コンテナイメージのビルドに使用される Cloud Build 構成が含まれています。このステップでは、Labs/cloudbuild-scheduled-jobs/code-oss-java フォルダの cloudbuild.yaml ファイルにある手順を実行する Cloud Build トリガーを作成します。

gcloud builds triggers create manual \
    --name=custom-image-trigger \
    --repo=$GITHUB_USER/software-delivery-workshop \
    --repo-type=GITHUB \
    --branch=main \
    --build-config=labs/cloudbuild-scheduled-jobs/code-oss-java/cloudbuild.yaml \
    --substitutions=_REGION=$REGION,_AR_REPO_NAME=custom-images,_AR_IMAGE_NAME=code-oss-java,_IMAGE_DIR=labs/cloudbuild-scheduled-jobs/code-oss-java

TRIGGER_ID=$(gcloud builds triggers list \
    --filter=name="custom-image-trigger" --format="value(id)")

この例では、以下の構成を行います。

gcloud CLI コマンドによって、2 行目の name フラグで示されているように、custom-image-trigger という名前の Cloud Build 内の手動トリガーが作成されます。
次の 3 行には、ソース GitHub リポジトリに関連するフラグが含まれています。
- リポジトリへのパス
- リポジトリのタイプ
- ビルドする Git ブランチ
build-config フラグは、Git リポジトリの Cloud Build ファイルへのパスを示します。
ジョブを動的にするには、substitutions フラグを使用します。このジョブでは、コマンドは次の変数を渡します。
- リージョン、$_REGION
- Artifact Registry のリポジトリ名、$_AR_REPO_NAME
- コンテナイメージ名、$_AR_IMAGE_NAME
- ビルドする Dockerfile の場所、$_IMAGE_DIR
これらの変数がプロセスでどのように使用されるかについては、cloudbuild.yaml ファイルをご覧ください。
トリガーが作成されると、トリガーの一意の名前が取得され、後で使用するために $TRIGGER_ID 環境変数に格納されます。

Cloud Scheduler を構成する

最新の更新とパッチでイメージが最新の状態であることを確認するには、Cloud Scheduler を使用して、設定された頻度で Cloud Build トリガーを実行します。このチュートリアルでは、ジョブは毎日実行されます。実際には、最新の更新が確実に含まれるように、組織のニーズに合った頻度に設定してください。

Cloud Build トリガーを呼び出すために必要なロールをデフォルトのサービスアカウントに付与します。

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:$PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role="roles/cloudbuild.builds.editor"

Artifact Registry にイメージをアップロードするために必要なロールを Cloud Build サービスアカウントに付与します。

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
    --role="roles/artifactregistry.admin"

次のコマンドを使用して、Cloud Scheduler ジョブを作成します。

gcloud scheduler jobs create http run-build \
    --schedule='0 1 * * *' \
    --uri=https://cloudbuild.googleapis.com/v1/projects/$PROJECT_ID/locations/global/triggers/$TRIGGER_ID:run \
    --location=us-central1 \
    --oauth-service-account-email=$PROJECT_NUMBER-compute@developer.gserviceaccount.com \
    --oauth-token-scope=https://www.googleapis.com/auth/cloud-platform

ジョブは毎日 1 回実行されるように設定されています。ただし、機能をすぐにテストするには、Cloud Scheduler からジョブを手動で実行します。

Cloud Scheduler に移動
1. [Cloud Scheduler] ページで、先ほど作成した run-build のエントリを見つけます。
2. [アクション] 列で、その行の [詳細] その他オプションメニューをクリックします。
3. システムを手動でテストするには、[ジョブ実行を強制] をクリックします。
4. コマンドが正常に実行されたら、Cloud Build の履歴ページに切り替えて進行状況を確認します。
  
  Cloud Build 履歴に移動

結果を確認する

セットアッププロセスの一環として Container Scanning API を有効にしたため、Artifact Registry は自動的にイメージをスキャンしてセキュリティの脆弱性を検出します。

脆弱性を確認するには:

Artifact Registry リポジトリのページを開きます。

Artifact Registry リポジトリに移動
[リポジトリ] リストで、リポジトリをクリックします。
イメージ名をクリックします。各イメージダイジェストの脆弱性の合計が [脆弱性] 列に表示されます。
イメージで検出された脆弱性の一覧を表示するには、[脆弱性] 列のリンクをクリックします。脆弱性リストには、重大度、修正プログラムが入手可能かどうか、脆弱性が存在するパッケージの名前が表示されます。

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

Google Cloud アカウントに対して、このページで使用したリソースについての課金が行われないようにするには、不要になったリソースを忘れずに削除してください。

Google Cloud コンソールまたは gcloud CLI から Google Cloud プロジェクトを削除するには:

コンソール

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

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

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

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
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.

gcloud

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

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

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

ワークステーションクラスタ、ワークステーション構成、ワークステーションなどの他のリソースの削除の詳細については、リソースを削除するをご覧ください。

次のステップ

使用可能な事前構成されたベースイメージのリストを確認する。
コンテナイメージをカスタマイズする。
使用可能なマシンタイプを確認する。
セキュリティのベストプラクティスを設定する。
Google Cloud に関するリファレンスアーキテクチャ、図、ベストプラクティスを確認する。Cloud アーキテクチャセンターをご覧ください。

コンテナ イメージの再ビルドを自動化してベースイメージの更新を同期する

目標

費用

始める前に

環境の準備

Artifact Registry リポジトリを作成する

GitHub リポジトリを構成する

サンプル リポジトリをフォークする

Cloud Build を GitHub に接続する

Cloud Build トリガーを作成する

Cloud Scheduler を構成する

結果を確認する

クリーンアップ

コンソール

gcloud

次のステップ

コンテナイメージの再ビルドを自動化してベースイメージの更新を同期する

サンプルリポジトリをフォークする