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

Cloud Workstations では、ワークステーション用のカスタム イメージを作成して使用できます。カスタム イメージの使用後は、ベースイメージで利用可能な修正と更新を pull するために、カスタム イメージの再ビルドを自動化すると便利です。

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

環境を準備する

続行する前に、次の環境変数を設定してください。

  1. 使用する予定のクラウド プロジェクトのプロジェクト ID を設定します。

    PROJECT_ID=$PROJECT_ID

  2. リポジトリを保存する GitHub ユーザー名を設定します。

    GITHUB_USER=$GITHUB_ID

  3. プロセスで使用する PROJECT_NUMBER 変数と REGION 変数を設定します。

    PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \
    --format='value(projectNumber)')

REGION=$REGION

    前の例で、$REGION は使用する予定のリージョン名（us-central1 など）に置き換えます。

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

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

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

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

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

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

  2. 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 を取得します。

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

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

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

Cloud Build を GitHub に接続する

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

別の 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 リポジトリに関連するフラグが含まれています。
  • 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 トリガーを実行します。このチュートリアルでは、ジョブは毎日実行されます。実際には、組織のニーズに合わせてこの頻度を設定し、常に最新の更新が含まれるようにします。

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

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

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

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

  3. 次のコマンドを使用して 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

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

    Cloud Scheduler に移動

    1. Cloud Scheduler ページで、先ほど作成した「run-build」という名前のエントリを見つけます。
    2. [アクション] 列で、対象の行の more_vert [その他] オプション メニューをクリックします。
    3. [ジョブの実行を強制する] をクリックして、システムを手動でテストします。

    4. コマンドが正常に実行されたら、Cloud Build の履歴ページに切り替えて進行状況を確認します。

      Cloud Build 履歴に移動

結果を確認する

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

脆弱性を確認するには:

  1. Artifact Registry の [リポジトリ] ページを開きます。

    [Artifact Registry リポジトリ] に移動

  2. リポジトリ リストで、リポジトリをクリックします。

  3. イメージ名をクリックします。各イメージ ダイジェストの脆弱性の総数が、[脆弱性] 列に表示されます。

    サンプル イメージ名が表示されている Artifact Registry リポジトリ ページ

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

    脆弱性のサンプルリストが表示された Artifact Registry の [脆弱性] ページ