GSP449

概要

このラボでは、Cloud SQL Proxy コンテナをサイドカー コンテナとして使って、Kubernetes Engine 内のアプリケーションを Cloud SQL インスタンスに簡単に接続する方法について学習します。Kubernetes Engine クラスタと Cloud SQL Postgres インスタンスをデプロイし、Cloud SQL Proxy コンテナを使ってこれらが通信できるようにします。

このラボでは Cloud SQL Proxy コンテナを使って Cloud SQL インスタンスに接続する方法を主に説明しますが、このコンセプト自体は API アクセスを必要とするすべての Google Cloud マネージド サービスに共通するものです。

このラボは、プロキシ コンテナを経由して Cloud SQL を使う方法をわかりやすく学ぶために GKE Helmsman のエンジニアによって作成されました。このデモは、GitHub の gke-networking-demos ページでご覧いただけます。アセットへのコントリビューションにぜひご協力ください。

学習内容

このラボでは、次の方法について学びます。

• Kubernetes Engine ノードにおいて権限のないサービス アカウントを使用する不正なアクセスからデータベースを保護する
• Kubernetes Engine で実行されるコンテナに対して、権限のあるサービス アカウントの認証情報を設定する
• Cloud SQL インスタンスに接続する処理をオフロードし、アプリケーションの開発時に必要なインフラストラクチャについての知識を減らすために、Cloud SQL Proxy を利用する

権限のないサービス アカウント

すべての Kubernetes Engine ノードにはデフォルトの Compute Engine サービス アカウントが割り当てられます。このサービス アカウントの権限は比較的高く、多くの Google Cloud サービスを利用できます。作成したソフトウェアには、それを実行する Compute Engine インスタンスに割り当てられた認証情報が引き継がれます。これは Cloud SDK がそう設定されているためです。

デフォルトの Compute Engine サービス アカウントほど多くの権限を必要としないコンテナもあるので、最小限の権限だけを持つサービス アカウントを Kubernetes Engine ノードに割り当てた後、コンテナごとに必要な（最小限の）権限を持つサービス アカウントを作成する必要があります。

コンテナ内の権限のあるサービス アカウント

サービス アカウント認証情報の取得先は次の 2 つしかありません。

1. ホスト インスタンス（ここでは取り上げません）
2. 認証情報ファイル

このラボでは Kubernetes Engine で実行されるコンテナに認証情報ファイルを取得して、必要な権限をアプリケーションに付与する方法を説明します。

Cloud SQL Proxy

Cloud SQL Proxy を使うと、Cloud SQL インスタンスへの接続を作成し、これを維持する作業を Cloud SQL Proxy プロセスにオフロードできます。こうすると、アプリケーションが接続を細かく扱う必要がなくなり、シークレットの管理が簡略化されます。Cloud SQL Proxy は、同じ Kubernetes Engine Pod 内でアプリケーション コンテナとともに実行できる Docker コンテナとして、パッケージ化されたうえで提供されています。

アーキテクチャ

アプリケーションとサイドカー コンテナは、Kubernetes Engine クラスタ内の唯一のノードで実行される単一の Kubernetes（k8s）Pod にデプロイします。アプリケーションは、ローカルホストでリッスンする Cloud SQL Proxy プロセスを介して Cloud SQL インスタンスと通信します。

k8s マニフェストによって、2 つのコンテナ、pgAdmin および Cloud SQL Proxy を持つ単一レプリカの Deployment オブジェクトが作成されます。Kubernetes Engine クラスタにインストールされる 2 つのシークレットは、Cloud SQL インスタンス接続情報とサービス アカウント鍵認証情報ファイルです。これらは Cloud SQL Proxy コンテナの Cloud SQL API 呼び出しに使われます。

アプリケーションに Cloud SQL への接続処理を作成する必要もなければ、何かを API に公開する必要もありません。Cloud SQL Proxy プロセスが、アプリケーションに代わってその処理を引き受けます。Cloud SQL Proxy コンテナが Pod 内で「サイドカー」コンテナとして実行されることに注意する必要があります。

設定と要件

[ラボを開始] ボタンをクリックする前に

こちらの手順をお読みください。ラボの時間は記録されており、一時停止することはできません。[ラボを開始] をクリックするとスタートするタイマーは、Google Cloud のリソースを利用できる時間を示しています。

このハンズオンラボでは、シミュレーションやデモ環境ではなく、実際のクラウド環境を使ってご自身でラボのアクティビティを行うことができます。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。

このラボを完了するためには、下記が必要です。

• 標準的なインターネット ブラウザ（Chrome を推奨）

注: このラボの実行には、シークレット モードまたはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウント間の競合を防ぎ、個人アカウントに追加料金が発生することを防ぎます。

• ラボを完了するために十分な時間を確保してください。ラボをいったん開始すると一時停止することはできません。

注: すでに個人の Google Cloud アカウントやプロジェクトをお持ちの場合でも、このラボでは使用しないでください。アカウントへの追加料金が発生する可能性があります。

ラボを開始して Google Cloud コンソールにログインする方法

1. [ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。 左側の [ラボの詳細] パネルには、以下が表示されます。

   • [Google Cloud コンソールを開く] ボタン
   • 残り時間
   • このラボで使用する必要がある一時的な認証情報
   • このラボを行うために必要なその他の情報（ある場合）

2. [Google Cloud コンソールを開く] をクリックします（Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウでリンクを開く] を選択します）。

   ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。

   ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。

   注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。

3. 必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。

   {{{user_0.username | "Username"}}}

   [ラボの詳細] パネルでも [ユーザー名] を確認できます。

4. [次へ] をクリックします。

5. 以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。

   {{{user_0.password | "Password"}}}

   [ラボの詳細] パネルでも [パスワード] を確認できます。

6. [次へ] をクリックします。

   重要: ラボで提供された認証情報を使用する必要があります。Google Cloud アカウントの認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

7. その後次のように進みます。

   • 利用規約に同意してください。
   • 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
   • 無料トライアルには登録しないでください。

その後、このタブで Google Cloud コンソールが開きます。

注: Google Cloud のプロダクトやサービスのリストを含むメニューを表示するには、左上のナビゲーション メニューをクリックします。

Cloud Shell をアクティブにする

Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。

1. Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする」アイコン をクリックします。

接続した時点で認証が完了しており、プロジェクトに各自の PROJECT_ID が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。

2. （省略可）次のコマンドを使用すると、有効なアカウント名を一覧表示できます。

gcloud auth list

3. [承認] をクリックします。

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

出力:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. （省略可）次のコマンドを使用すると、プロジェクト ID を一覧表示できます。

gcloud config list project

出力:

[core] project = <project_ID>

出力例:

[core] project = qwiklabs-gcp-44776a13dea667a6 注: Google Cloud における gcloud ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。

リージョンとゾーンを設定する

一部の Compute Engine リソースは、リージョン内やゾーン内に存在します。リージョンとは、リソースを実行できる特定の地理的位置です。1 つのリージョンには 1 つ以上のゾーンがあります。

リージョンとゾーンについてのドキュメントで、リージョンとゾーンの詳細と一覧をご確認ください。

次のコマンドを実行して、ラボのリージョンとゾーンを設定します（最適なリージョンとゾーンを使用できます）。

gcloud config set compute/region {{{ project_0.default_region | REGION }}} gcloud config set compute/zone {{{ project_0.default_zone | ZONE }}}

デモをコピーする

1. 次のコマンドを実行して、このラボのファイルをコピーします。

gsutil cp gs://spls/gsp449/gke-cloud-sql-postgres-demo.tar.gz . tar -xzvf gke-cloud-sql-postgres-demo.tar.gz

2. このラボのディレクトリに移動します。

cd gke-cloud-sql-postgres-demo

タスク 1. デプロイ

デプロイは完全に自動化されています。デプロイするスクリプトには次の順序でパラメータを指定します。

• Cloud SQL インスタンスのユーザー名
• pgAdmin コンソールのユーザー名
• USER_PASSWORD - Postgres インスタンスにログインするためのパスワード
• PG_ADMIN_CONSOLE_PASSWORD - pgAdmin UI にログインするためのパスワード

1. Cloud SQL インスタンスには任意のユーザー名を作成でき、pgAdmin コンソールには任意のメールアドレスを使用できます。ここでは、「dbadmin」と、受講者用の仮メールアドレスを使用します。

2. 受講者アカウントを変数に保存します。

PG_EMAIL=$(gcloud config get-value account)

3. 次のようにしてスクリプトをデプロイし、2 つのユーザー名を作成します。出力時に dbadmin と $PG_EMAIL（ご利用の student@qwiklabs.net アカウント）のパスワードを作成するよう求められます。

./create.sh dbadmin $PG_EMAIL

このパスワードはラボで再度使うので、難しい文字列にする必要はありません。

デプロイ中に create.sh によって次のスクリプトが実行されます。

• enable_apis.sh - Kubernetes Engine API と Cloud SQL Admin API を有効にします。
• postgres_instance.sh - Cloud SQL インスタンスと他の Postgres ユーザーを作成します。gcloud が Cloud SQL インスタンスの作成を待機した末にタイムアウトになるため、スクリプトの完了が手動でポーリングされることに注意してください。
• service_account.sh - Cloud SQL Proxy コンテナのサービス アカウントと認証情報ファイルを作成します。
• cluster.sh - Kubernetes Engine クラスタを作成します。
• configs_and_secrets.sh - Kubernetes Engine シークレット、認証情報を含む configMap、Cloud SQL インスタンスの接続文字列を作成します。
• pgadmin_deployment.sh - pgAdmin4 Pod を作成します。

注: Cloud SQL インスタンスのデプロイには、最大 10 分かかることがあります。 自動デプロイ スクリプトの実行時にエラーが発生した場合、リージョンとゾーンの変数が設定されていることを確認してから、create.sh スクリプトを再実行してみてください。

次に、ロードバランサを使用して Pod を順番に公開し、インスタンスに接続した後、完了したら不正アクセスを防ぐためにサービスを削除します。

4. 次のコマンドを実行して Pod ID を取得します。

POD_ID=$(kubectl --namespace default get pods -o name | cut -d '/' -f 2)

5. ロードバランサ経由で Pod を公開します。

kubectl expose pod $POD_ID --port=80 --type=LoadBalancer

6. サービス IP アドレスを取得します。

kubectl get svc

出力:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 443/TCP 96m SVC_NAME LoadBalancer 80:31789/TCP 45m 注: pgAdmin サービスの外部 IP アドレスが表示されるまで、前のコマンドを繰り返し実行します。

7. Cloud コンソールで、ナビゲーションメニュー > [SQL] に移動し、[インスタンス ID] をクリックします。

8. 左側のメニューで、[接続] をクリックし、[ネットワーキング] をクリックします。

9. [パブリック IP] ボックスがオンになった状態で、[ネットワークを追加] をクリックします。

10. ネットワークに名前を付け、公開アクセス権を付与します。

0.0.0.0/0

11. [完了] をクリックします。

12. [保存] をクリックします。

13. ブラウザで新しいタブを開き、pgAdmin の <SVC_IP> を使用して pgAdmin に接続します。

http://<SVC_IP>

14. 以下の情報を使用して pgAdmin UI にログインします。

• [Email Address] フィールドには <PGADMIN_USERNAME>（student@qwiklabs.net 仮アカウント）
• 先ほど定義した <PG_ADMIN_CONSOLE_PASSWORD>

注: 受講者用フルアカウントがわからない場合は、Cloud Shell で gcloud config get-value account を実行し、出力をコピーしてください。

15. Cloud コンソールで SQL ページに戻ります。[概要] タブをクリックします。

16. パブリック IP アドレスをコピーします。

17. pgAdmin コンソールの左側のペインで、[Servers] をクリックし、[Add New Server] をクリックします。

18. [General] タブで、サーバーに名前を付け、[Connection] タブをクリックします。

19. 先ほど作成した <DATABASE_USER_NAME>（dbadmin）と <USER_PASSWORD> を使用して、127.0.0.1:5432 に接続します。

• Host name: コピーしたパブリック IP アドレスを貼り付けます。
• Username: <DATABASE_USER_NAME>（dbadmin）
• Password: 自分で作成した <USER_PASSWORD>

20. [Save] をクリックします。

完了したタスクをテストする

[進行状況を確認] をクリックして、実行したタスクを確認します。完全に自動化されたデプロイによって必要なリソースが正常に作成されている場合は、評価スコアが表示されます。

完全に自動化されたデプロイによって必要なリソースを作成する

タスク 2. 検証

検証は完全に自動化されています。検証スクリプトは Cloud SQL インスタンス、Kubernetes Engine クラスタ、動作中の Pod が存在するかどうかをチェックします。デプロイのスクリプトが完了した後に、これらのリソースが存在していなければなりません。

• Cloud Shell で上記の 3 つのデプロイを検証するには、次のコマンドを実行します。

make validate

このスクリプトには INSTANCE_NAME パラメータ（既存の Cloud SQL インスタンスの名前）を指定します。

成功すると、出力は次のようになります。

Cloud SQL instance exists GKE cluster exists pgAdmin4 Deployment object exists

タスク 3. 破棄

破棄は完全に自動化されています。破棄スクリプトを実行すると、デプロイ スクリプトで作成されたリソースが完全に削除されます。

1. 破棄するには、次のコマンドを実行します。

make teardown

このスクリプトには INSTANCE_NAME パラメータ（既存の Cloud SQL インスタンスの名前）を指定します。

teardown.sh によって、次のスクリプトが実行されます。

• delete_resources.sh - Cloud SQL インスタンス以外をすべて削除します。
• delete_instance.sh - Cloud SQL インスタンスを削除します。

タスク 4. 独自の環境でのトラブルシューティング

Cloud SQL インスタンスの作成で次のエラーが表示された場合:

is the subject of a conflict: The instance or operation is not in an appropriate state to handle the request.

解決策

削除したインスタンスのインスタンス名は、削除してから最長 1 週間は再利用できません。詳細については、インスタンスを削除するをご覧ください。

お疲れさまでした

Cloud SQL Proxy コンテナをサイドカー コンテナとして使って、Kubernetes Engine 内のアプリケーションを Cloud SQL インスタンスに接続しました。その後、Kubernetes Engine クラスタと Cloud SQL Postgres インスタンスをデプロイし、Cloud SQL Proxy コンテナを使ってこれらが通信できるようにしました。

クエストを完了する

このセルフペース ラボは、「Google Kubernetes Engine Best Practices」クエストの一部です。クエストとは学習プログラムを構成する一連のラボのことで、完了すると成果が認められて上のようなバッジが贈られます。バッジは公開して、オンライン レジュメやソーシャル メディア アカウントにリンクできます。受講可能な全クエストについては、Google Cloud Skills Boost カタログをご覧ください。

次のステップと詳細情報

複数のプラットフォームに対応するコンテナ化されたアプリケーションをデプロイするための Kubernetes のインストール手順

マニュアルの最終更新日: 2023 年 10 月 16 日

ラボの最終テスト日: 2023 年 10 月 17 日

Copyright 2024 Google LLC. 本ソフトウェアは「現状有姿」で提供されており、いかなる使用および目的に関しても保証および表明は伴いません。本ソフトウェアのご利用には、Google との契約が適用されます。