エッジにクラスタをデプロイする

このチュートリアルでは、ベアメタル上の Google Distributed Cloud（ソフトウェアのみ）と Config Sync によって Kubernetes クラスタをエッジに大規模にデプロイする、すぐに利用できるソリューションを紹介します。このチュートリアルは、プラットフォーム オペレーターとデベロッパーを対象としています。このドキュメントを読む前に、次のテクノロジーとコンセプトについて理解しておいてください。

このチュートリアルでは、Compute Engine 仮想マシン（VM）を使用して、エッジにデプロイされたノードとエッジ ワークロード（サンプル POS アプリケーション）をエミュレートします。Google Distributed Cloud（ソフトウェアのみ）と Config Sync により、エッジクラスタを一元管理して制御します。Config Sync によって GitHub から新しい構成が動的に pull され、ポリシーと構成がクラスタに適用されます。

エッジデプロイ アーキテクチャ

小売店のエッジデプロイは、一般的なベアメタル クラスタのデプロイで使用されるアーキテクチャを説明する良い方法です。

小売店の実店舗は、企業の事業部門と消費者の間の最も近い接点です。店舗内のソフトウェア システムは、企業の中央管理システムから隔離して、ワークロードを実行し、更新をタイムリーに受け取り、重要な指標を報告する必要があります。また、将来により多くの店舗に拡張できるように設計する必要があります。いずれのベアメタル クラスタをデプロイした場合も、店舗向けソフトウェア システムに関するこのような要件をすべて満たせますが、エッジ プロファイルを使用すれば、小売店の店頭のようにハードウェア リソースが限られた環境でのデプロイという重要なユースケースに対応できます。

次の図は、エッジ プロファイルを使用するベアメタル クラスタを小売店にデプロイする例を示しています。

小売店にデプロイされた、エッジ プロファイルを使用するベアメタル クラスタ

上の図は、一般的な小売店舗を示しています。店舗には、カードリーダー、POS マシン、カメラ、プリンタなどのスマート デバイスがあります。また、3 つの物理コンピューティング ハードウェア デバイス（Node 1、Node 2、Node 3 という名前）が中央のネットワーク スイッチに接続されています。したがって、3 つのコンピューティング デバイスはレイヤ 2 ネットワークを介して相互に接続されています。このように互いにネットワーク接続されたコンピューティング デバイスにより、ベアメタル インフラストラクチャが構成されます。各コンピューティング デバイス内では Google Distributed Cloud ソフトウェアが実行されています。また、独自のディスク ストレージがあり、高可用性を実現するためにデバイス間でのデータ レプリケーションが構成されています。

この図は、ベアメタル クラスタのデプロイの一部である、次の主要なコンポーネントも示しています。

  • MetalLB とマークされたコンポーネントは、バンドル型ロードバランサです。

  • Config Sync コンポーネントにより、クラスタの状態をソース リポジトリと同期できます。これは強く推奨されるオプションのアドオンであり、個別にインストールして構成する必要があります。Config Sync と別の命名法を設定する方法の詳細については、Config Sync のドキュメントをご覧ください。

  • 図の上部で店舗ロケーションの外側に示されているルート リポジトリと名前空間リポジトリは、2 つのソース リポジトリを表します。

    クラスタへの変更は、これらの中央のソース リポジトリに push されます。さまざまなエッジ ロケーションにデプロイされたクラスタは、ソース リポジトリから更新を pull します。図ではこの動作が、デバイスで実行されるクラスタ内の Config Sync コンポーネントと 2 つのリポジトリを結ぶ矢印で示されています。

  • クラスタの一部として示されているもう 1 つの重要なコンポーネントは、GDC 上の VM ランタイムです。GDC 上の VM ランタイムを使用すると、コンテナ化を必要とせずに、クラスタ内で既存の VM ベースのワークロードを実行できます。GDC 上の VM ランタイムのドキュメントでは、GDC 上の VM ランタイムを有効にして VM ワークロードをクラスタにデプロイする方法について説明しています。

  • アプリケーションとマークされたコンポーネントは、小売店がクラスタにデプロイしたソフトウェアを示します。たとえば、小売店のキオスクで見られる POS アプリケーションがあります。

図の下部にあるボックスは小売店内のさまざまなデバイス（キオスク、タブレット、カメラなど）を表しており、そのすべては中央のネットワーク スイッチに接続されています。クラスタ内で実行されているアプリケーションは、店舗内のローカル ネットワーク経由でこれらのデバイスにアクセスできます。

次のセクションでは、Google Cloud の Compute Engine VM を使用してこの小売店のデプロイをエミュレートする様子を説明します。この後のチュートリアルでは、このエミュレーションを使ってベアメタル クラスタを試します。

Google Cloudでエミュレートしたエッジデプロイ

次の図は、このチュートリアルのためにGoogle Cloud で設定するすべての内容を示しています。この図は、前のセクションにある小売店の図と対応しており、POS アプリケーションがデプロイされたエッジ ロケーションをエミュレートするデプロイを表しています。このアーキテクチャでは、このチュートリアルで使用するサンプル POS アプリケーションのワークロードも示されています。クラスタ内の POS アプリケーションには、ウェブブラウザをキオスクとして使用してアクセスします。

POS アプリケーションのアーキテクチャと、このアプリケーションを Compute Engine VM で実行されるクラスタ内にデプロイする方法

上図の 3 つの Compute Engine 仮想マシン（VM）は、一般的なエッジ ロケーションにある物理ハードウェア（またはノード）を表します。このハードウェアがネットワーク スイッチと接続されることによって、ベアメタル インフラストラクチャが構成されます。 Google Cloudでエミュレートした環境では、これらの VM は Google Cloud プロジェクトのデフォルトの Virtual Private Cloud（VPC）ネットワークを介して相互に接続されています。

一般的なベアメタル クラスタのインストールでは、独自のロードバランサを構成できます。ただし、このチュートリアルでは外部ロードバランサを設定する代わりにバンドル型 MetalLB ロードバランサを使用します。バンドル型 MetalLB ロードバランサには、ノード間のレイヤ 2 ネットワーク接続が必要です。このため、デフォルトの Virtual Private Cloud（VPC）ネットワーク上に VxLAN オーバーレイ ネットワークを作成することで、Compute Engine VM 間のレイヤ 2 接続を可能にします。

「L2 オーバーレイ ネットワーク（VxLAN）」と表示された長方形の中に、3 つの Compute Engine VM 内で実行されているソフトウェア コンポーネントが示されています。この長方形には、Kubernetes Namespace を含むクラスタ デプロイが含まれています。この Kubernetes Namespace 内のすべてのコンポーネントにより、クラスタにデプロイされる POS アプリケーションが構成されます。POS アプリケーションには、API サーバー、在庫管理、決済処理用の 3 つのマイクロサービスがあります。これらのコンポーネントが 1 つに合わさって、前のセクションのエッジデプロイ アーキテクチャ図で示した「アプリケーション」を表しています。

クラスタのバンドル型 MetalLB ロードバランサには、VM の外部から直接アクセスできません。この図では、NGINX リバース プロキシを構成して VM 内で実行することで、Compute Engine VM に着信したトラフィックをロードバランサにルーティングしています。これは、 Google Cloudの Compute Engine VM を使用してエッジノードをエミュレートするというこのチュートリアルの目的を実現するための回避策にすぎません。実際のエッジ ロケーションでは、適切なネットワーク構成によってこの処理を実現できます。

目標

  1. Compute Engine VM を使用して、エッジ ロケーションで実行されているベアメタル インフラストラクチャをエミュレートします。
  2. Google Distributed Cloud を使用して、エミュレートしたエッジ インフラストラクチャでクラスタを作成します。
  3. クラスタを Google Cloudに接続して登録します。
  4. クラスタにサンプル POS アプリケーションのワークロードをデプロイします。
  5. Google Cloud コンソールにより、エッジ ロケーションで動作する POS アプリケーションを確認してモニタリングします。
  6. Config Sync を使用して、クラスタで実行される POS アプリケーションを更新します。

始める前に

  1. Google Cloud コンソールのプロジェクト セレクタ ページで、 Google Cloud プロジェクトを選択または作成します。

    プロジェクトの選択に移動

  2. Cloud プロジェクトに対して課金が有効になっていることを確認します。詳しくは、プロジェクトで課金が有効になっているかどうかを確認する方法をご覧ください。

  3. Google Cloud CLI をインストールして初期化します。

Anthos サンプル リポジトリをフォークしてクローンを作成する

このチュートリアルで使用されるスクリプトはすべて、anthos-samples リポジトリに格納されています。/anthos-bm-edge-deployment/acm-config-sink の下のフォルダ構造は、Config Sync で想定される構造に従って編成されています。次の手順に進む前に、このリポジトリを自分の GitHub アカウントにクローンします。

  1. GitHub のアカウントを持っていない場合は、GitHub でアカウントを作成します。

  2. Config Sync の構成で使用する個人用のアクセス トークンを作成します。これは、クラスタの Config Sync コンポーネントが、新しい変更を同期しようとするときに GitHub アカウントで認証するために必要です。

    1. public_repo スコープのみを選択します。
    2. 作成したアクセス トークンは、後で使用できるように安全な場所に保管します。

  3. anthos-samples リポジトリを自分の GitHub アカウントにフォークします。

    1. anthos-samples リポジトリに移動します。
    2. ページの右上にあるフォーク アイコンをクリックします。
    3. リポジトリのフォーク先の GitHub ユーザー アカウントをクリックします。フォークされた anthos-samples リポジトリのバージョンのページに自動的にリダイレクトされます。

  4. ローカル環境でターミナルを開きます。

  5. 次のコマンドを実行して、フォークされたリポジトリのクローンを作成します。ここで、GITHUB_USERNAME は GitHub アカウントのユーザー名です。

    git clone https://github.com/GITHUB_USERNAME/anthos-samples
cd anthos-samples/anthos-bm-edge-deployment

ワークステーション環境を設定する

このドキュメントで説明するエッジデプロイを完了するには、インターネットにアクセスできる 1 つのワークステーションと、次のツールのインストールが必要です。

このセクションで構成したワークステーションで、チュートリアルのコマンドをすべて実行します。

  1. ワークステーション上で、新しいシェル インスタンスで環境変数を初期化します。

    export PROJECT_ID="PROJECT_ID"
export REGION="us-central1"
export ZONE="us-central1-a"

# port on the admin Compute Engine instance you use to set up an nginx proxy
# this allows to reach the workloads inside the cluster via the VM IP
export PROXY_PORT="8082"

# should be a multiple of 3 since N/3 clusters are created with each having 3 nodes
export GCE_COUNT="3"

# url to the fork of: https://github.com/GoogleCloudPlatform/anthos-samples
export ROOT_REPO_URL="https://github.com/GITHUB_USERNAME/anthos-samples"

# this is the username used to authenticate to your fork of this repository
export SCM_TOKEN_USER="GITHUB_USERNAME"

# access token created in the earlier step
export SCM_TOKEN_TOKEN="ACCESS_TOKEN"

    次の値を置き換えます。

    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • GITHUB_USERNAME: GitHub のユーザー名。
    • ACCESS_TOKEN: GitHub リポジトリ用に作成した個人用アクセス トークン。

    他の環境変数にはデフォルト値を使用します。これについては、以下の各セクションで説明します。

  2. ワークステーションで Google Cloud CLI を初期化します。

    gcloud config set project "${PROJECT_ID}"
gcloud services enable compute.googleapis.com

gcloud config set compute/region "${REGION}"
gcloud config set compute/zone "${ZONE}"

  3. ワークステーション上で、Compute Engine インスタンス用の Google Cloud サービス アカウントを作成します。次のスクリプトは、新しい Google サービス アカウント用の JSON キーファイルを <REPO_ROOT>/anthos-bm-edge-deployment/build-artifacts/consumer-edge-gsa.json として作成します。また、Cloud Key Management Service のキーリングと、SSH 秘密鍵の暗号化用の鍵も設定します。

    ./scripts/create-primary-gsa.sh

    次のサンプルはスクリプトの一部です。スクリプト全体を表示するには、[GitHub で表示] をクリックします。

    # ...
EXISTS=$(gcloud iam service-accounts list \
  --filter="email=${GSA_EMAIL}" \
  --format="value(name, disabled)" \
  --project="${PROJECT_ID}")

if [[ -z "${EXISTS}" ]]; then
  echo "GSA [${GSA_EMAIL}]does not exist, creating it"

  # GSA does NOT exist, create
  gcloud iam service-accounts create ${GSA_NAME} \
    --description="GSA used on each Target machine to make gcloud commands" \
    --display-name="target-machine-gsa" \
    --project "${PROJECT_ID}"
else
  if [[ "${EXISTS}" =~ .*"disabled".* ]]; then
    # Found GSA is disabled, enable
    gcloud iam service-accounts enable "${GSA_EMAIL}" --project "${PROJECT_ID}"
  fi
  # otherwise, no need to do anything
fi
# ...

Compute Engine インスタンスをプロビジョニングする

このセクションでは、Google Distributed Cloud（ソフトウェアのみ）をインストールする Compute Engine VM を作成します。また、インストール セクションに進む前に VM への接続を確認します。

  1. ワークステーションで、Compute Engine インスタンス間の通信に使用される SSH 認証鍵を作成します。

    ssh-keygen -f ./build-artifacts/consumer-edge-machine

  2. Cloud Key Management Service を使用して SSH 秘密鍵を暗号化します。

    gcloud kms encrypt \
    --key gdc-ssh-key \
    --keyring gdc-ce-keyring \
    --location global \
    --plaintext-file build-artifacts/consumer-edge-machine \
    --ciphertext-file build-artifacts/consumer-edge-machine.encrypted

  3. 環境構成ファイル .envrc を生成し、source コマンドによって実行します。作成された .envrc ファイルを検査し、環境変数が正しい値に置き換えられていることを確認します。

    envsubst < templates/envrc-template.sh > .envrc
source .envrc

    templates/envrc-template.sh ファイル内の環境変数を置き換えることによって生成された .envrc ファイルの例を以下に示します。更新された行はハイライト表示されています。 

    # GSA Key used for provisioning (result of running ./scripts/create-primary-gsa.sh)
LOCAL_GSA_FILE=$(pwd)/build-artifacts/consumer-edge-gsa.json
export LOCAL_GSA_FILE
# GCP Project ID
export PROJECT_ID="abm-edge-project"
# Bucket to store cluster snapshot information
export SNAPSHOT_GCS="abm-edge-project-cluster-snapshots"

# GCP Project Region (Adjust as desired)
export REGION="us-central1"
# GCP Project Zone (Adjust as desired)
export ZONE="us-central1-a"

# Gitlab Personal Access Token credentials (generated in Quick Start step 2)
export SCM_TOKEN_USER="LarryPage"
export SCM_TOKEN_TOKEN="oo901Sp-FHuzmz__dgl0393atkf69c8L"

# Default Root Repo setup for multiple locations
export ROOT_REPO_URL="https://github.com/LarryPage/anthos-samples"
export ROOT_REPO_BRANCH="main"
export ROOT_REPO_DIR="/anthos-bm-edge-deployment/acm-config-sink"

# OIDC Configuration (off by default)
export OIDC_CLIENT_ID="" # Optional, requires GCP API setup work
export OIDC_CLIENT_SECRET="" # Optional
export OIDC_USER="" # Optional
export OIDC_ENABLED="false" # Flip to true IF implementing OIDC on cluster

  4. Compute Engine インスタンスを作成する

    ./scripts/cloud/create-cloud-gce-baseline.sh -c "$GCE_COUNT" | \
    tee ./build-artifacts/gce-info

Ansible を使用してベアメタル クラスタをインストールする

このガイドで使用するスクリプトは、3 つの Compute Engine インスタンスからなるグループの単位でクラスタを作成します。作成されるクラスタの数は、GCE_COUNT 環境変数によって制御されます。たとえば、環境変数 GCE_COUNT を 6 に設定すると、それぞれ 3 つのインスタンスを持つ 2 つのクラスタが作成されます。デフォルトでは、GCE_COUNT 環境変数は 3 に設定されています。したがって、このガイドでは、3 個の Compute Engine インスタンスを持つ 1 つのクラスタが作成されます。これらの VM インスタンスは、接頭辞 cnuc- の後に数字を付けた名前となっています。各クラスタの最初の VM インスタンスは、インストールをトリガーする管理ワークステーションとして機能します。クラスタには管理ワークステーション VM と同じ名前が付けられます（例: cnuc-1、cnuc-4、cnuc-7）。

Ansible ハンドブックでは次の処理を行います。

  • docker、bmctl、gcloud、nomos などの必要なツールを使用して Compute Engine インスタンスを構成します。
  • 構成した Compute Engine インスタンスにベアメタル クラスタをインストールします。
  • cnuc-1 というスタンドアロン クラスタを作成します。
  • cnuc-1 クラスタを Google Cloudに登録します。
  • Config Sync を cnuc-1 クラスタにインストールします。
  • フォークしたリポジトリの anthos-bm-edge-deployment/acm-config-sink にあるクラスタ構成と同期するように Config Sync を構成します。
  • クラスタの Login token を生成します。

以下の設定手順を完了して、インストール プロセスを開始します。

  1. ワークステーションで、インストールに使用する Docker イメージを作成します。このイメージには、Ansible、Python、Google Cloud CLI など、インストール プロセスに必要なすべてのツールが含まれています。

    gcloud builds submit --config docker-build/cloudbuild.yaml docker-build/

    ビルドが正常に実行されると、次のような出力が生成されます。

    ...
latest: digest: sha256:99ded20d221a0b2bcd8edf3372c8b1f85d6c1737988b240dd28ea1291f8b151a size: 4498
DONE
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ID                                    CREATE_TIME                DURATION  SOURCE                                                                                         IMAGES                                                  STATUS
2238baa2-1f41-440e-a157-c65900b7666b  2022-08-17T19:28:57+00:00  6M53S     gs://my_project_cloudbuild/source/1660764535.808019-69238d8c870044f0b4b2bde77a16111d.tgz  gcr.io/my_project/consumer-edge-install (+1 more)  SUCCESS

  2. テンプレートから Ansible インベントリ ファイルを生成します。

    envsubst < templates/inventory-cloud-example.yaml > inventory/gcp.yaml

  3. 先ほどビルドされたイメージから Docker コンテナを起動するインストール スクリプトを実行します。スクリプトは内部で Docker を使用して、現在の作業ディレクトリへのボリューム マウントを持つコンテナを生成します。このスクリプトが正常に完了すると、作成した Docker コンテナ内にいるはずです。このコンテナ内から Ansible のインストールをトリガーします。

    ./install.sh

    スクリプトが正常に実行されると、次のような出力が生成されます。

    ...
Check the values above and if correct, do you want to proceed? (y/N): y
Starting the installation
Pulling docker install image...

==============================
Starting the docker container. You will need to run the following 2 commands (cut-copy-paste)
==============================
1: ./scripts/health-check.sh
2: ansible-playbook all-full-install.yaml -i inventory
3: Type 'exit' to exit the Docker shell after installation
==============================
Thank you for using the quick helper script!
(you are now inside the Docker shell)

  4. Docker コンテナ内から、Compute Engine インスタンスへのアクセスを確認します。

    ./scripts/health-check.sh

    スクリプトが正常に実行されると、次のような出力が生成されます。

    ...
cnuc-2 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}
cnuc-3 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}
cnuc-1 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}

  5. Docker コンテナ内から、Compute Engine インスタンスにベアメタル クラスタをインストールするための Ansible Playbook を実行します。

    完了すると、クラスタの Login Token が画面に表示されます。

    ansible-playbook all-full-install.yaml -i inventory | tee ./build-artifacts/ansible-run.log

    インストールが正常に完了すると、次のような出力が生成されます。

    ...
TASK [abm-login-token : Display login token] **************************************************************************
ok: [cnuc-1] => {
    "msg": "eyJhbGciOiJSUzI1NiIsImtpZCI6Imk2X3duZ3BzckQyWmszb09sZHFMN0FoWU9mV1kzOWNGZzMyb0x2WlMyalkifQ.eymljZS1hY2NvdW
iZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImVkZ2Etc2EtdG9rZW4tc2R4MmQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2Nvd
4CwanGlof6s-fbu8"
}
skipping: [cnuc-2]
skipping: [cnuc-3]

PLAY RECAP ***********************************************************************************************************
cnuc-1                     : ok=205  changed=156  unreachable=0    failed=0    skipped=48   rescued=0    ignored=12
cnuc-2                     : ok=128  changed=99   unreachable=0    failed=0    skipped=108  rescued=0    ignored=2
cnuc-3                     : ok=128  changed=99   unreachable=0    failed=0    skipped=108  rescued=0    ignored=2

Google Cloud コンソールでクラスタにログインする

Ansible Playbook の実行が完了すると、スタンドアロン クラスタが Compute Engine VM 内にインストールされています。また、このクラスタは Connect Agent によってGoogle Cloudに登録されています。ただし、このクラスタの詳細を確認するには、 Google Cloud コンソールからクラスタにログインする必要があります。

クラスタにログインする手順は次のとおりです。

  1. 前のセクションの Ansible Playbook の出力からトークンをコピーします。

  2. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動し、コピーしたトークンを使用して cnuc-1 クラスタにログインします。

    [Kubernetes クラスタ] ページに移動

    1. クラスタのリストで、cnuc-1 クラスタの横にある [アクション] をクリックし、[ログイン] をクリックします。
    2. [トークン] を選択し、コピーしたトークンを貼り付けます。
    3. [ログイン] をクリックします。
  3. Google Cloud コンソールで、[機能] セクションの [構成] ページに移動します。

    [構成] に移動

    4. [パッケージ] タブで、クラスタ テーブルの [同期ステータス] 列を確認します。ステータスが [同期済み] であることを確認します。[同期済み] のステータスは、Config Sync によって GitHub 構成ファイルがデプロイ済みクラスタ cnuc-1 と正常に同期していることを示します。

s

外部トラフィック用のプロキシを構成する

前の手順でインストールしたクラスタは、MetalLB というバンドル型ロードバランサを使用します。このロードバランサ サービスには、Virtual Private Cloud（VPC）IP アドレスからのみアクセスできます。外部 IP から受信したトラフィックをこのバンドル型ロードバランサに転送するには、管理ホスト（cnuc-1）でリバース プロキシ サービスを設定します。このリバース プロキシ サービスにより、管理ホスト（cnuc-1）の外部 IP 経由で POS アプリケーションの API サーバーにアクセスできます。

前の手順でインストール スクリプトを実行したときに、NGINX がサンプル構成ファイルとともに管理ホストにインストールされています。ロードバランサ サービスの IP アドレスを使用するようにこのファイルを更新してから、NGINX を再起動します。

  1. ワークステーションで、SSH を使用して管理ワークステーションにログインします。

    ssh -F ./build-artifacts/ssh-config abm-admin@cnuc-1

  2. 管理ワークステーション内から、API サーバー ロードバランサ サービスにトラフィックをルーティングするように NGINX リバース プロキシを設定します。この Kubernetes Service（LoadBalancer タイプ）の IP アドレスを取得します。

    ABM_INTERNAL_IP=$(kubectl get services api-server-lb -n pos | awk '{print $4}' | tail -n 1)

  3. 取得した IP アドレスでテンプレートの構成ファイルを更新します。

    sudo sh -c "sed 's/<K8_LB_IP>/${ABM_INTERNAL_IP}/g' \
    /etc/nginx/nginx.conf.template > /etc/nginx/nginx.conf"

  4. NGINX を再起動して、新しい構成が適用されていることを確認します。

    sudo systemctl restart nginx

  5. NGINX サーバーのステータスが「active (running)」になっていることを確認します。

    sudo systemctl status nginx

    NGINX が正常に実行されていると、次のような出力が表示されます。

    ● nginx.service - A high performance web server and a reverse proxy server
    Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
    Active: active (running) since Fri 2021-09-17 02:41:01 UTC; 2s ago
    Docs: man:nginx(8)
    Process: 92571 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 92572 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Main PID: 92573 (nginx)
    Tasks: 17 (limit: 72331)
    Memory: 13.2M
    CGroup: /system.slice/nginx.service
            ├─92573 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
            ├─92574 nginx: worker process
            ├─92575 nginx: worker process
            ├─92577 nginx: ....
            ...
            ...

  6. SSH セッションを終了して管理ワークステーションに移動します。

    exit

  7. シェル セッションを終了して Docker コンテナに移動します。管理インスタンスを終了した後も、インストールに使用した Docker コンテナ内にいます。

    exit

POS アプリケーションにアクセスする

設定した外部プロキシにより、クラスタ内で実行されているアプリケーションにアクセスできます。サンプル POS アプリケーションにアクセスする手順は次のとおりです。

  1. ワークステーションで、管理 Compute Engine インスタンスの外部 IP アドレスを取得し、POS アプリケーションの UI にアクセスします。

    EXTERNAL_IP=$(gcloud compute instances list \
    --project ${PROJECT_ID} \
    --filter="name:cnuc-1" \
    --format="get(networkInterfaces[0].accessConfigs[0].natIP)")
echo "Point the browser to: ${EXTERNAL_IP}:${PROXY_PORT}"

    スクリプトが正常に実行されると、次のような出力が生成されます。

    Point the browser to: 34.134.194.84:8082

  2. ウェブブラウザを開いて、前のコマンドの出力に表示された IP アドレスに移動します。次のスクリーンショットの例に示すように、サンプルの POS アプリケーションにアクセスしてテストできます。

    POS アプリケーションのバージョン 1 をデプロイしました

Config Sync を使用して API サーバーを更新する

ルート リポジトリ内の構成ファイルを更新することで、サンプル アプリケーションを新しいバージョンにアップグレードできます。Config Sync によって更新が検出され、クラスタに自動的に変更が行われます。この例のルート リポジトリは、このガイドの冒頭でクローンを作成した anthos-samples リポジトリです。サンプル POS アプリケーションで新しいバージョンへのアップグレードをデプロイする方法については、次の手順をご覧ください。

  1. ワークステーションで、image フィールドを更新して、API Server のバージョンを v1 から v2 に変更します。この Deployment の YAML 構成は、anthos-bm-edge-deployment/acm-config-sink/namespaces/pos/api-server.yaml ファイルにあります。

    containers:
- name: api-server
  image: us-docker.pkg.dev/anthos-dpe-abm-edge-pos/abm-edge-pos-images/api-server:v1

  2. 変更を追加して commit した後、フォークしたリポジトリに push します。

    git add acm-config-sink/namespaces/pos/api-server.yaml
git commit -m "chore: updated api-server version to v2"
git push

  3. Google Cloud コンソールで [Config Sync] ページに移動し、[Config Sync のステータス] を確認します。ステータスが [同期済み] であることを確認します。

    [Config Sync] ページに移動

  4. Google Cloud コンソールで Kubernetes Engine の [ワークロード] ページに移動し、Deployment が更新されていることを確認します。

    Kubernetes Engine の [ワークロード] ページに移動

  5. [デプロイ] のステータスが [OK] になったら、前のセクションの IP アドレスにブラウザでアクセスして POS アプリケーションを表示します。次の例のスクリーンショットに示されているように、タイトルに記載されているバージョンは「V2」であり、アプリケーションの変更がデプロイされたことを示しています。

    POS アプリケーションのバージョン 2 をデプロイしました。

    変更を確認するには、ブラウザタブのハード更新が必要になる場合があります。

クリーンアップ

Google Cloud で不要な料金が発生しないようにするため、このチュートリアルが終了したら、使用したリソースを削除します。これらのリソースを手動で削除するか、 Google Cloud プロジェクトを削除することですべてのリソースを削除できます。また、ローカル ワークステーションで行った変更をクリーンアップすることもおすすめします。

ローカル ワークステーション

インストール スクリプトによる変更をクリアするには、次のファイルを更新する必要があります。

  • /etc/hosts ファイルに追加された Compute Engine VM の IP アドレスを削除します。
  • ~/.ssh/config ファイルから cnuc-* の SSH 構成を削除します。
  • Compute Engine VM フィンガープリントを ~/.ssh/known_hosts ファイルから削除します。

プロジェクトを削除する

このチュートリアル専用の Google Cloud プロジェクトを作成した場合は、 Google Cloud コンソールからそのプロジェクトを削除します。

  • 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.

    • 手動

    この手順で既存のプロジェクトを使用した場合は、次の操作を行います。

    • 名前が cnuc- で始まるすべての Kubernetes クラスタの登録を解除します。
    • 名前が cnuc- で始まるすべての Compute Engine VM を削除します。
    • 名前が abm-edge-boot で始まる Cloud Storage バケットを削除します。
    • ファイアウォール ルール allow-pod-ingress と allow-pod-egress を削除します。
    • Secret Manager のシークレット install-pub-key を削除します。

    次のステップ

    このガイドの内容を拡張して、エッジ ロケーションをもう 1 つ追加できます。GCE_COUNT 環境変数を 6 に設定し、前のセクションと同じ手順を再実行することで、3 つの Compute Engine インスタンス（cnuc-4、cnuc-5、cnuc-6）と 1 つのスタンドアロン クラスタ（cnuc-4）を新たに作成します。

    また、フォークしたリポジトリでクラスタ構成の更新を試行することもできます。ClusterSelector を使用して、2 つのクラスタ（cnuc-1 と cnuc-4）に POS アプリケーションの別々のバージョンを選択的に適用します。

    このガイドの各ステップ、関連するスクリプトの詳細については、anthos-samples リポジトリをご覧ください。