このページは Cloud Translation API によって翻訳されました。

学習プログラム: モノリスを GKE アプリに変換する - モジュラーアプリをコンテナ化する

標準

これは、モノリシックアプリをモジュール化してコンテナ化する方法を学習する学習プログラムの 4 番目のチュートリアルです。

この学習プログラムは、次のチュートリアルで構成されています。

前のチュートリアル（モジュラー型のアプリをコンテナ化できるように準備する）では、Cymbal Books アプリのモジュラーバージョンをコンテナ化できるように準備するために必要な変更を確認しました。このチュートリアルでは、アプリをコンテナ化します。

料金

このチュートリアルでは費用は発生しません。ただし、このシリーズの次のチュートリアルの手順に沿って操作すると、Google Cloud アカウントに料金が発生します。費用が発生するのは、GKE を有効にして Cymbal Books アプリを GKE クラスタにデプロイしたときです。これらの費用には、料金ページで説明されている GKE のクラスタごとの料金と、Compute Engine VM の実行料金が含まれます。

不要な料金が発生しないように、このチュートリアルの完了後に GKE を無効にするか、プロジェクトを削除してください。

始める前に

このチュートリアルを開始する前に、シリーズの前のチュートリアルを完了していることを確認してください。シリーズ全体の概要と特定のチュートリアルへのリンクについては、学習プログラム: モノリスを GKE アプリに変換する - 概要をご覧ください。

環境の設定

このセクションでは、モジュラーアプリをコンテナ化する環境を設定します。具体的には、次の手順を行います。

Google Cloud プロジェクトを選択または作成する
必要な API を有効にする
Cloud Shell を Google Cloud プロジェクトに接続する
デフォルトの環境変数を設定する
Artifact Registry にリポジトリを作成する
Artifact Registry 用に Docker を構成する
チュートリアルのコードを取得する

Google Cloud プロジェクトを選択または作成する

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector
Make sure that billing is enabled for your Google Cloud project.

必要な API を有効にする

Google Cloud プロジェクトでコンテナイメージと Kubernetes を操作するには、次の API を有効にする必要があります。

Artifact Registry API: この API は、コンテナイメージを保存して管理するためのサービスである Artifact Registry を有効にします。
Kubernetes Engine API: この API は GKE へのアクセスを提供します。

これらの API を有効にするには、 Google Cloud コンソールで API を有効にするをご覧ください。

Cloud Shell を Google Cloud プロジェクトに接続する

Google Cloud プロジェクトを設定したら、Cloud Shell インスタンスを起動して、 Google Cloudプロジェクトに接続する必要があります。Cloud Shell は、ブラウザからプロジェクトのリソースを直接作成して管理できるコマンドラインツールです。Cloud Shell には、gcloud CLI と kubectl CLI の 2 つの重要なツールがプリインストールされています。このチュートリアルでは、gcloud CLI を使用して Google Cloud を操作します。次のチュートリアルでは、kubectl CLI を使用して GKE で実行される Cymbal Books アプリを管理します。

Cloud Shell インスタンスを Google Cloud プロジェクトに接続する手順は次のとおりです。

Google Cloud コンソールに移動します。

Google Cloud コンソール
コンソールで、[Cloud Shell をアクティブにする]（）ボタンをクリックします。

コンソールの下部にあるフレーム内で Cloud Shell セッションが開きます。
Google Cloud CLI で次のコマンドを使用して、デフォルトプロジェクトを設定します。
```
gcloud config set project PROJECT_ID
```
PROJECT_ID は、前のセクション（プロジェクトを選択または作成する Google Cloud ）で作成または選択したプロジェクトのプロジェクト ID に置き換えます。プロジェクト ID は、プロジェクトを Google Cloudの他のすべてのプロジェクトと区別する一意の文字列です。プロジェクト ID を確認するには、プロジェクトセレクタに移動します。このページで、各 Google Cloudプロジェクトのプロジェクト ID を確認できます。

デフォルトの環境変数を設定する

このチュートリアル全体で実行するコマンドを簡略化するために、Cloud Shell でいくつかの環境変数を設定します。これらの変数には、プロジェクト ID、リポジトリリージョン、イメージタグなどの値が格納されます。これらの変数を定義すると、値を毎回再入力または置き換えるのではなく、変数名（$REPOSITORY_NAME など）を参照して、複数のコマンドで再利用できます。このアプローチにより、チュートリアルがわかりやすくなり、エラーのリスクが軽減されます。

Cloud Shell を使用して環境を設定するには、次の操作を行います。

export PROJECT_ID=$(gcloud config get project)
export REPOSITORY_REGION=REPOSITORY_REGION
export REPOSITORY_NAME=REPOSITORY_NAME
export REPOSITORY_DESCRIPTION="REPOSITORY_DESCRIPTION"
export TAG=TAG

次のように置き換えます。

REPOSITORY_REGION: Artifact Registry リポジトリをホストするリージョン。たとえば、us-central1（アイオワ）、us-west1（オレゴン）、europe-west1（ベルギー）などです。リージョンの完全なリストについては、リージョンとゾーンをご覧ください。
REPOSITORY_NAME: リポジトリの名前。例: book-review-service-repo
REPOSITORY_DESCRIPTION: リポジトリの目的の簡単な説明。例: "Repository for storing Docker images for the book review service"
TAG: イメージに適用するタグ。タグは、コンテナイメージの特定のバージョンに適用できるラベルです。次のようなタグ命名規則を使用すると、イメージのさまざまなバージョンを明確に示せます。
- v1
- v1.2.3
- 説明タグ（feature-x-dev など）
- 環境を示すタグ（test など）

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

次に、Artifact Registry にリポジトリを作成します。リポジトリは、コンテナイメージを保存するストレージの場所です。コンテナイメージをビルドするときは、後で Kubernetes クラスタにデプロイできるように、イメージを保存する場所が必要です。Artifact Registry を使用すると、 Google Cloud プロジェクト内でこれらのリポジトリを作成して管理できます。

Artifact Registry にリポジトリを作成するには、次のコマンドを実行します。

gcloud artifacts repositories create ${REPOSITORY_NAME} \
    --repository-format=docker \
    --location=${REPOSITORY_REGION} \
    --description="${REPOSITORY_DESCRIPTION}"

コマンドの出力が成功すると、次のようになります。

Waiting for operation [...] to complete...done.
Created repository [book-review-service-repo].

Artifact Registry 用に Docker を構成する

次に、Google Cloudの Artifact Registry と安全に通信できるように Docker を構成します。Docker は、さまざまな環境でソフトウェアをパッケージ化して一貫した方法で実行するために使用できるツールです。Docker の仕組みについては、次のセクションで詳しく説明します。現時点では、Artifact Registry に接続できるように構成する必要があります。

この方法で Docker を構成しないと、コンテナイメージを Artifact Registry に push できません（このチュートリアルの後半で実行するタスク）。また、Artifact Registry からコンテナイメージを pull して GKE クラスタにデプロイすることもできません（次のチュートリアルで実行するタスク）。

Artifact Registry で認証するように Docker を構成するには、次のコマンドを実行します。

gcloud auth configure-docker ${REPOSITORY_REGION}-docker.pkg.dev

チュートリアルコードを取得する

Cloud Shell 環境が構成されたので、Cloud Shell 内でチュートリアルコードをダウンロードする必要があります。以前にローカルマシンでリポジトリのクローンを作成した場合でも、Cloud Shell インスタンスで再度クローンを作成する必要があります。

ローカルマシンでこのチュートリアルを完了することもできますが、Docker、kubectl、gcloud CLI などのツールを手動でインストールして構成する必要があります。Cloud Shell にはこれらのツールがすべて事前構成されているため、Cloud Shell を使用する方が簡単です。

Cloud Shell インスタンスで、次のコマンドを実行して GitHub リポジトリのクローンを作成します。

git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples.git

コンテナ化の基本: コンテナイメージ、コンテナ、Dockerfile

環境を設定してコンテナ化されたコードをダウンロードしたので、アプリをコンテナ化する準備が整いました。アプリのコンテナ化では、Dockerfile を使用して、Cymbal Books の各モジュール（ホームページ、書籍の詳細、画像、書籍のレビュー）をコンテナイメージにパッケージ化します。アプリケーションが GKE クラスタにデプロイされると、Kubernetes はこれらのコンテナイメージを使用して、クラスタで実行中のコンテナを作成します。

以降のセクションでは、これらのコンセプトについて詳しく説明します。

コンテナ化とは

コンテナ化では、モジュールとそのすべての依存関係（ライブラリや構成ファイルなど）がコンテナイメージと呼ばれる単位にパッケージ化されます。デベロッパーは、このコンテナイメージを使用して、デベロッパーのノートパソコンからテストサーバーや本番環境の Kubernetes クラスタまで、あらゆる環境でコンテナを作成して実行します。

コンテナイメージとは

コンテナイメージには、アプリケーションの実行に必要なすべてのファイルが含まれています。これらのファイルには、アプリケーションコード自体、システムライブラリ、ランタイム環境（Python インタープリタなど）、静的データ、その他の依存関係が含まれます。

このチュートリアルでは、書籍レビューアプリの各モジュールのコンテナイメージを作成します。

コンテナとは

コンテナは、コンテナイメージのコードが実行される分離された環境です。コンテナを作成するには、開発中のテストに docker run コマンドを使用する方法と、コンテナイメージを Kubernetes クラスタにデプロイする方法の 2 つがあります。

コンテナ化された Cymbal Books アプリでは、モジュラーアプリの各モジュールが独自のコンテナで実行されます。

ホームページコンテナはホームページモジュールを実行し、/ へのリクエストを処理します。
書籍の詳細コンテナは書籍の詳細モジュールを実行し、/book/1 や /book/3 などのエンドポイントのデータを処理します。
書籍レビューコンテナは書籍レビューモジュールを実行し、/book/2/reviews などのエンドポイントへのリクエストを管理します。
images コンテナは images モジュールを実行し、/images/fungi_frontier.jpg などのエンドポイントに書籍の表紙画像を提供します。

コンテナの主な利点は、必要に応じて Kubernetes が自動的にコンテナを作成できることです。たとえば、多数のユーザーが書籍のレビューを読んでいる場合、Kubernetes は追加の書籍レビューコンテナを起動して負荷を処理できます。

コンテナを使用しないモジュラーアプリでスケーリングを実装するには、モジュールの新しいインスタンスを起動してトラフィックを分散するカスタムコードを作成する必要があります。Kubernetes では、このスケーリング機能が組み込まれているため、カスタムスケーリングコードを記述する必要はありません。

Dockerfile とは

Dockerfile は、モジュールをコンテナイメージにパッケージ化する方法を定義するスクリプトです。このチュートリアルでは、Dockerfile を作成する必要はありません。Dockerfile は、先ほどクローンを作成した GitHub リポジトリにすでに用意されています。kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/ のローカルコピーの各モジュールのディレクトリには、独自の Dockerfile が含まれています。

たとえば、home_app モジュールの Dockerfile は、Cloud Shell インスタンスの kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/home_app/Dockerfile にあります。この Dockerfile は次のようになります。

# Dockerfile for home_app
FROM python:3.9-slim #line 1
WORKDIR /app #line 2
COPY requirements.txt . #line 3
RUN pip install --no-cache-dir -r requirements.txt #line 4
COPY home_app.py . #line 5
COPY templates/ ./templates/ #line 6
COPY static/ ./static/ #line 7
CMD ["python", "home_app.py"] #line 8

この Dockerfile は、次の手順で home_app モジュールのコンテナイメージを作成します。

1 行目: FROM python:3.9-slim は、Python 3.9 インタープリタとその必要なファイルをコンテナイメージにダウンロードします。これらのファイルにより、モジュールを実行できます。
2 行目: WORKDIR /app は、コンテナ内に /app というディレクトリを作成し、このディレクトリを現在の作業ディレクトリとして設定します。コンテナ内で実行されるすべてのコマンドは、このディレクトリ内で実行されます。
3 行目と 4 行目: COPY requirements.txt . は、ローカルマシンからコンテナイメージの /app ディレクトリに requirements.txt ファイルをコピーします。requirements.txt ファイルには、home_app.py に必要なすべての Python ライブラリがリストされています。RUN pip install 行は、これらのライブラリをコンテナイメージにインストールします。
5 ～ 7 行目: これらの行に記述されている COPY コマンドは、モジュールのコード（home_app.py）とそのサポートファイル（テンプレートと静的アセット）をコンテナイメージ内の /app ディレクトリにコピーします。
8 行目: CMD は、コンテナの起動時に Docker が実行するデフォルトのコマンドを指定します。この Dockerfile では、CMD ["python", "home_app.py"] は、コンテナの起動時に Python インタープリタを使用して home_app.py モジュールを自動的に実行するように Docker に指示します。

コンテナ化によってデータ分離を厳格に適用する方法

前のセクションで説明した Dockerfile の 5 ～ 7 行目は、コンテナ化によって、アプリのモジュール化されたバージョンよりも厳格なデータ分離を適用できることを示しています。前のチュートリアルの各モジュールに必要なデータのみへのアクセス権を付与するセクションで、アプリのモジュール化されたバージョンではデータが個別のディレクトリに整理されるものの、モジュールは同じファイルシステムを共有しており、相互のデータにアクセスできる可能性があることを学習しました。

ここでは、アプリのコンテナ化されたバージョンで、各モジュールのコンテナに必要なファイルのみが含まれています。たとえば、home_app モジュールが書籍レビューデータにアクセスする必要がない場合、そのデータは home_app コンテナ内に存在しません。デフォルトでは、コンテナは別のコンテナのファイルにアクセスできません。ただし、明示的にアクセスするように構成されている場合は除きます。これにより、各モジュールが完全に分離され、誤ったデータアクセスや不正なデータアクセスを防ぐことができます。

次のセクションでは、docker build コマンドが Dockerfile を入力として受け取り、Dockerfile の指示に従ってコンテナイメージを作成する方法について説明します。

Docker を使用してコンテナイメージをビルドする

このセクションでは、書籍レビューモジュールごとに Docker コンテナイメージをビルドし、Artifact Registry リポジトリに push します。これらのコンテナイメージは、次のチュートリアルで Kubernetes に Cymbal Books サンプルアプリをデプロイして実行するために使用します。

コンテナ化されたアプリケーションのルートディレクトリに移動します。
```
cd kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/
```

docker build コマンドを使用してコンテナイメージを作成します。

docker build -t ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/home-app:${TAG} ./home_app
docker build -t ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-details-app:${TAG} ./book_details_app
docker build -t ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-reviews-app:${TAG} ./book_reviews_app
docker build -t ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/images-app:${TAG} ./images_app

Cloud Shell インスタンス内でビルドされたコンテナイメージを表示します。
```
docker images
```
次のイメージがリストに表示されていることを確認します。
- home-app
- book-details-app
- book-reviews-app
- images-app
4 つのイメージがすべて一覧表示されていれば、コンテナイメージは正常に作成されています。

Cloud Shell でコンテナをテストする

コンテナイメージが正しくビルドされていることを確認するには、コンテナとして実行し、Cloud Shell でエンドポイントをテストします。

book_details_app、book_reviews_app、images_app コンテナは相互に通信する必要がないため、個別にテストできます。ただし、home_app は http://book-details-service:8081 などのサービス名を使用する他のコンテナを見つけるように構成されているため、Docker を使用して home_app コンテナをテストすることは困難です。

各コンテナの IP アドレスを見つけて、サービス名の代わりにそれらを使用するように home_app を構成することで、home_app コンテナをテストすることはできますが、このアプローチには多くの労力が必要です。代わりに、アプリケーションを Kubernetes クラスタにデプロイするまで home_app コンテナのテストを延期することをおすすめします。アプリがクラスタに配置されたら、ホームモジュールが正しく動作しているかどうかを確認できます。

コンテナをテストする手順は次のとおりです。

book_details_app、book_reviews_app、images_app コンテナを起動します。

docker run -d -p 8081:8080 ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-details-app:${TAG}
docker run -d -p 8082:8080 ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-reviews-app:${TAG}
docker run -d -p 8083:8080 ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/images-app:${TAG}

すべてのアクティブなコンテナを一覧表示して、コンテナが実行されていることを確認します。

docker ps

このコマンドの出力には、実行中の 3 つのコンテナがステータス Up で表示されます。

CONTAINER ID   IMAGE                PORTS                        STATUS
a1b2c3d4e5f6   REGION/.../details   0.0.0.0:8081->8080/tcp       Up
g7h8i9j0k1l2   REGION/.../reviews   0.0.0.0:8082->8080/tcp       Up
m3n4o5p6q7r8   REGION/.../images    0.0.0.0:8083->8080/tcp       Up

book_details_app コンテナのエンドポイントをテストするには、次の curl コマンドを使用します。

curl http://localhost:8081/books
curl http://localhost:8081/book/1
curl http://localhost:8081/book/2
curl http://localhost:8081/book/3

これらの各コマンドは、JSON 形式でデータを返します。たとえば、curl http://localhost:8081/book/1 コマンドの出力は次のようになります。

{"author":"Aria Clockwork","description":"In a world where time is a tangible substance, a young clockmaker discovers she can manipulate the fabric of time itself, leading to unforeseen consequences in her steampunk-inspired city.","id":1,"image_url":"zephyrs_timepiece.jpg","title":"Zephyr's Timepiece","year":2023}

次の curl コマンドを使用して、book_reviews_app コンテナから書籍のレビューを取得します。
```
curl http://localhost:8082/book/1/reviews
```
このコマンドは、書籍 1 の 20 件のレビューのリストを JSON 形式で返します。リスト内の 1 件のレビューの例を次に示します。
```
{
"content": "The concept of time as a tangible substance is brilliantly explored in 'Zephyr's Timepiece'.",
"rating": 5
}
```
images_app コンテナをテストします。
1. [**Web Preview**] ボタンをクリックします。
2. [ポートを変更] を選択し、「8083」と入力します。ブラウザウィンドウが開き、次のような URL が表示されます。
```
https://8083-your-instance-id.cs-your-region.cloudshell.dev/?authuser=0
```
3. URL の末尾にある ?authuser=0 を削除し、画像ファイルへのパス（/images/fungi_frontier.jpg など）を追加します。次に例を示します。
```
https://8083-your-instance-id.cs-your-region.cloudshell.dev/images/fungi_frontier.jpg
```
  ブラウザに書籍「Fungi Frontier」の表紙画像が表示されます。
テストが完了したら、コンテナを停止してリソースを解放します。
1. 実行中のコンテナを一覧表示し、コンテナ ID を確認します。
```
docker ps
```
2. 各コンテナを停止します。
```
docker stop CONTAINER_ID
```
  CONTAINER_ID は、停止するコンテナの ID に置き換えます。

コンテナイメージを Artifact Registry に push する

アプリを Kubernetes クラスタにデプロイする前に、コンテナイメージをクラスタがアクセスできる場所に保存する必要があります。この手順では、前の手順で作成した Artifact Registry リポジトリにイメージを push します。次のチュートリアルでは、Artifact Registry リポジトリから GKE クラスタにこれらのイメージをデプロイします。

コンテナイメージを Artifact Registry に push するには、次のコマンドを実行します。

docker push ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/home-app:${TAG}
docker push ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-details-app:${TAG}
docker push ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-reviews-app:${TAG}
docker push ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/images-app:${TAG}

イメージを push したら、イメージを一覧表示して、イメージが正常にアップロードされたことを確認します。

gcloud artifacts docker images list ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}

出力は次のようになります。

Listing items under project ${PROJECT_ID}, location ${REPOSITORY_REGION}, repository ${REPOSITORY_NAME}.

IMAGE: ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-details-app
DIGEST: sha256:f7b78f44d70f2eedf7f7d4dc72c36070e7c0dd05daa5f473e1ebcfd1d44b95b1
CREATE_TIME: 2024-11-14T00:38:53
UPDATE_TIME: 2024-11-14T00:38:53
SIZE: 52260143

IMAGE: ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-reviews-app
DIGEST: sha256:875ac8d94ef54db2ff637e49ad2d1c50291087623718b854a34ad657748fac86
CREATE_TIME: 2024-11-14T00:39:04
UPDATE_TIME: 2024-11-14T00:39:04
SIZE: 52262041

IMAGE: ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/home-app
DIGEST: sha256:70ddc54ffd683e2525d87ee0451804d273868c7143d0c2a75ce423502c10638a
CREATE_TIME: 2024-11-14T00:33:56
UPDATE_TIME: 2024-11-14T00:33:56
SIZE: 52262412

IMAGE: ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/images-app
DIGEST: sha256:790f0d8c2f83b09dc3b431c4c04d7dc68254fecc76c48f00a83babc2a5dc0484
CREATE_TIME: 2024-11-14T00:39:15
UPDATE_TIME: 2024-11-14T00:39:15
SIZE: 53020815

出力には、各画像に関する次の詳細情報が含まれます。

IMAGE: リポジトリパスとイメージ名。
DIGEST: イメージの一意の識別子。
CREATE_TIME または UPDATE_TIME: イメージが作成された時刻または最後に変更された時刻。
SIZE: 画像のサイズ（バイト単位）。

コンテナイメージのパスを使用して Kubernetes マニフェストを更新する

前のチュートリアルコンテナ化用にモジュール式アプリを準備するで学習したように、Kubernetes マニフェストは、Kubernetes クラスタでアプリを実行する方法を定義する YAML ファイルです。これには、次のような詳細が含まれます。

アプリのモジュール（home-app、book-details-app など）
コンテナイメージのパス
リソース上限などの構成の詳細
モジュール間でリクエストをルーティングするためのサービス定義

このセクションでは、前のチュートリアルで確認したのと同じマニフェストファイルを更新します。このファイルは kubernetes-manifest.yaml で、画像パスのプレースホルダ値が含まれています。これらのプレースホルダは、前のセクションで Artifact Registry リポジトリに push したコンテナイメージの実際のパスに置き換える必要があります。

kubernetes-manifest.yaml Kubernetes マニフェストファイルを更新する手順は次のとおりです。

Cloud Shell で、Kubernetes マニフェストファイル kubernetes-manifest.yaml を含む containerized/ ディレクトリに移動します。
```
cd kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/
```
テキストエディタで kubernetes-manifest.yaml ファイルを開きます。
```
vim kubernetes-manifest.yaml
```
次のようなプレースホルダを含む image フィールドを探します。
```
image: REPOSITORY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/home-app:TAG
```
各プレースホルダを、Artifact Registry に push したコンテナイメージの実際のパスに置き換えます。
- REPOSITORY_REGION: Artifact Registry でリポジトリを作成したときに指定したリージョン。
- PROJECT_ID: Google Cloud プロジェクト ID。プロジェクトセレクタページで確認できます。
- REPOSITORY_NAME: リポジトリの名前。Artifact Registry でリポジトリを作成したときに指定したものです。例: book-review-service-repo
- TAG: コンテナイメージをビルドしたときに選択したタグ。
これらの置換を行った後のパスは次のようになります。
```
image:us-west1-docker.pkg.dev/your-project-id/book-review-service-repo/home-app:v1
```
すべてのコンテナイメージのパスを更新します。
- home-app
- book-details-app
- book-reviews-app
- images-app
パスを更新したら、マニフェストファイルを保存してエディタを閉じます。たとえば、vim を使用している場合は、Esc キーを押してコマンドモードに入り、「wq」と入力して Enter キーを押して保存して終了します。

これで、Kubernetes マニフェストが、Artifact Registry リポジトリのコンテナイメージを Kubernetes クラスタにデプロイするように構成されました。

概要

このチュートリアルでは、次のタスクを実行して、モジュール式の Cymbal Books アプリを Kubernetes クラスタへのデプロイ用に準備しました。

Google Cloud プロジェクトを設定し、環境用に Cloud Shell を構成した。
各アプリモジュールについて提供された Dockerfile を確認しました。
Docker を使用してアプリモジュールのコンテナイメージをビルドしました。
Cloud Shell でコンテナをテストして、その機能を確認しました。
コンテナイメージを Artifact Registry に push して保存しました。
Artifact Registry の正しいコンテナイメージパスを使用するように Kubernetes マニフェストを更新しました。

次のステップ

次のチュートリアルアプリを GKE クラスタにデプロイするでは、コンテナ化されたアプリケーションを GKE クラスタにデプロイします。