概要

このラボでは、暗号化された構成情報と、暗号化されていない構成情報を設定します。暗号化された構成情報は Secret として保存され、暗号化されていない構成情報は ConfigMap として保存されます。

この方法を使用することで、構成情報をコードベースにハードコードすることを回避できます。Secret に含まれる API キーなどの認証情報は、GitHub などのコード リポジトリには保存しないでください（暗号化して保存することもできますが、その場合でも個別に保存することをおすすめします）。

目標

このラボでは、次のタスクを行う方法について学びます。

• kubectl コマンドとマニフェスト ファイルを使用して Secret を作成する。
• kubectl コマンドとマニフェスト ファイルを使用して ConfigMap を作成する。
• 環境変数またはマウントされた Volume を使用して、コンテナで Secret を使用する。
• 環境変数またはマウントされた Volume を使用して、コンテナで ConfigMap を使用する。

ラボの設定

Qwiklabs にアクセスする

各ラボでは、新しい Google Cloud プロジェクトとリソースセットを一定時間無料で利用できます。

1. Qwiklabs にシークレット ウィンドウでログインします。

2. ラボのアクセス時間（例: 1:15:00）に注意し、時間内に完了できるようにしてください。
   一時停止機能はありません。必要な場合はやり直せますが、最初からになります。

3. 準備ができたら、[ラボを開始] をクリックします。

4. ラボの認証情報（ユーザー名とパスワード）をメモしておきます。この情報は、Google Cloud Console にログインする際に使用します。

5. [Google Console を開く] をクリックします。

6. [別のアカウントを使用] をクリックし、このラボの認証情報をコピーしてプロンプトに貼り付けます。
   他の認証情報を使用すると、エラーが発生したり、料金の請求が発生したりします。

7. 利用規約に同意し、再設定用のリソースページをスキップします。

最初のログイン手順を完了すると、プロジェクト ダッシュボードが表示されます。

Google Cloud Shell の有効化

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

Google Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。

1. Google Cloud コンソールで、右上のツールバーにある [Cloud Shell をアクティブにする] ボタンをクリックします。

   

2. [続行] をクリックします。

環境がプロビジョニングされ、接続されるまでしばらく待ちます。接続した時点で認証が完了しており、プロジェクトに各自のプロジェクト ID が設定されます。次に例を示します。

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

• 次のコマンドを使用すると、有効なアカウント名を一覧表示できます。

gcloud auth list

出力:

Credentialed accounts: - @.com (active)

出力例:

Credentialed accounts: - google1623327_student@qwiklabs.net

• 次のコマンドを使用すると、プロジェクト ID を一覧表示できます。

gcloud config list project

出力:

[core] project =

出力例:

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

タスク 1. Secret を操作する

このタスクでは、Google Cloud サービスにアクセスできるように Google Cloud でコンテナを認証します。Cloud Pub/Sub のトピックとサブスクリプションを設定し、GKE 内で実行されているコンテナから Cloud Pub/Sub のトピックへのアクセスを試行して、アクセス リクエストが失敗することを確認します。

Pub/Sub のトピックに適切にアクセスするには、認証情報を持つサービス アカウントを作成し、Kubernetes の Secret を介して認証情報を渡します。

権限が付与されていないサービス アカウントを用意する

1. Google Cloud コンソールのナビゲーション メニュー（）で、[IAM と管理] > [サービス アカウント] をクリックします。
2. [+ サービス アカウントを作成] をクリックします。
3. [サービス アカウント名] テキスト ボックスに「no-permissions」と入力します。
4. [作成して続行] をクリックします。
5. [続行] をクリックし、[完了] をクリックします。
6. 一覧で no-permissions サービス アカウントを見つけ、関連付けられているメールアドレスをコピーして、後で使用できるようにテキスト ファイルに保存します。

GKE クラスタを作成する

このクラスタを作成する際、先ほど作成したサービス アカウントを指定します。適切な権限を持つサービス アカウントが必要であることを確認するために、まず、他の Google Cloud サービスに対する権限を持たないサービス アカウントを使用します。権限がないため、このサービス アカウントではこの後デプロイする Cloud Pub/Sub テスト アプリケーションに接続できません。この後、ラボ内でこの点を解決します。

1. Cloud Shell で次のコマンドを入力して、Google Cloud ゾーンとクラスタ名の環境変数を作成します。これらの環境変数は、このラボ用のクラスタを作成するために使われます。

export my_zone={{{ project_0.default_zone | ZONE }}} export my_cluster=standard-cluster-1

2. kubectl コマンドライン ツールのタブ補完を次のように構成します。

source <(kubectl completion bash)

3. Cloud Shell で次のコマンドを入力して、サービス アカウント名を格納する環境変数を設定します。[MY-SERVICE-ACCOUNT-EMAIL] は、先ほど作成したサービス アカウントのメールアドレスに置き換えます。

export my_service_account=[MY-SERVICE-ACCOUNT-EMAIL]

例:

export my_service_account=no-permissions@qwiklabs-gcp-4ee5983fdd675469.iam.gserviceaccount.com

4. Cloud Shell で次のコマンドを入力して、Kubernetes クラスタを作成します。

gcloud container clusters create $my_cluster \ --num-nodes 2 --zone $my_zone \ --service-account=$my_service_account 注: クラスタのデプロイが完了するまで数分待つ必要があります。

5. kubectl がクラスタにアクセスできるよう構成します。

gcloud container clusters get-credentials $my_cluster --zone $my_zone

Cloud Pub/Sub を設定し、トピックから読み込むアプリケーションをデプロイする

1. Cloud Shell で次のコマンドを入力して、Pub/Sub コンポーネントを格納する環境変数を設定します。

export my_pubsub_topic=echo export my_pubsub_subscription=echo-read

2. 次の gcloud コマンドを実行して、echo という Cloud Pub/Sub トピックと、そのトピックに関連付けられた echo-read というサブスクリプションを作成します。

gcloud pubsub topics create $my_pubsub_topic gcloud pubsub subscriptions create $my_pubsub_subscription \ --topic=$my_pubsub_topic

Cloud Pub/Sub トピックからの読み取りを行うアプリケーションをデプロイする

Cloud Pub/Sub トピックから読み取れるコンテナが含まれる Deployment を作成します。Cloud Pub/Sub トピックにサブスクライブし、トピックを読み込むには特定の権限が必要です。そのため、Cloud Pub/Sub に正常に接続できるように、このコンテナには認証情報が必要です。

pubsub.yaml という Deployment マニフェスト ファイルが用意されています。

apiVersion: apps/v1 kind: Deployment metadata: name: pubsub spec: selector: matchLabels: app: pubsub template: metadata: labels: app: pubsub spec: containers: - name: subscriber image: gcr.io/google-samples/pubsub-sample:v1

1. Cloud Shell で次のコマンドを入力して、ラボの Cloud Shell にリポジトリのクローンを作成します。

git clone https://github.com/GoogleCloudPlatform/training-data-analyst

2. 作業ディレクトリへのショートカットとしてソフトリンクを作成します。

ln -s ~/training-data-analyst/courses/ak8s/v1.1 ~/ak8s

3. このラボのサンプル ファイルが含まれているディレクトリに移動します。

cd ~/ak8s/Secrets/

4. アプリケーションをデプロイします。

kubectl apply -f pubsub.yaml

5. アプリケーションがデプロイされたら、次のコマンドを実行して Pod に対してクエリを実行します。

kubectl get pods -l app=pubsub

このコマンドを実行すると Pod のリストがフィルタされ、app: pubsub と一致するラベルを持つ Pod のみが含まれます。

出力:

NAME READY STATUS RESTARTS AGE pubsub-74d4d96ddb-lqkt8 0/1 CrashLoopBackOff 0 6s 注: 1 分ほど待つ必要があります。アプリケーションが起動しようとしますが、正常に動作しません。

6. もう一度 Pod を一覧表示します。

kubectl get pods -l app=pubsub

出力:

NAME READY STATUS RESTARTS AGE pubsub-74d4d96ddb-lqkt8 0/1 Error 4 2m

Pod のステータスを確認してください。エラーが発生し、何度か再起動しています。

7. 次のコマンドを実行して、Pod のログを調べます。

kubectl logs -l app=pubsub

ログの最後に次のようなエラー メッセージが表示されます。これは、アプリケーションが Cloud Pub/Sub サービスに対してクエリを実行する権限を持っていないことを示しています。

StatusCode.PERMISSION_DENIED, User not authorized to perform this action.

サービス アカウントの認証情報を作成する

新しいサービス アカウントを作成し、テスト アプリケーションで使用する Pub/Sub サブスクリプションへのアクセス権を付与します。GKE クラスタノードのサービス アカウントを変更するのではなく、サービス アカウント用の JSON キーを生成し、Kubernetes の Secret を使用してその JSON キーを安全に Pod に渡します。

1. Google Cloud Console のナビゲーション メニューで、[IAM と管理] > [サービス アカウント] をクリックします。
2. [+ サービス アカウントを作成] をクリックします。
3. [サービス アカウント名] に「pubsub-app」と入力し、[作成して続行] をクリックします。
4. [ロールを選択] プルダウンリストで、[Pub/Sub] > [Pub/Sub サブスクライバー] を選択します。
5. ロールが一覧表示されていることを確認して [続行] をクリックし、[完了] をクリックします。
6. サービス アカウントの概要画面で、[pubsub-app] サービス アカウントの右側にあるその他アイコンをクリックし、[鍵を管理] を選択します。
7. プルダウンで [鍵を追加] をクリックし、[新しい鍵を作成] を選択します。
8. 鍵のタイプとして [JSON] を選択し、[作成] をクリックします。
9. サービス アカウントの認証情報を含む JSON キーファイルがパソコンにダウンロードされ、画面下部のダウンロード バーに表示されます。このキーファイルを使用してサンプル アプリケーションを構成し、Cloud Pub/Sub API を認証します。
10. [閉じる] をクリックします。
11. ハードドライブ上で、ダウンロードした JSON キーを見つけ、ファイル名を credentials.json に変更します。

認証情報を Secret としてインポートする

1. Cloud Shell のツールバーで「その他」アイコン（）をクリックし、その他のオプションを表示します。

2. [アップロード] をクリックしてローカルマシンから Cloud Shell VM に credentials.json ファイルをアップロードし、[アップロード] をクリックします。
3. Cloud Shell で次のコマンドを入力して、ファイルがアップロードされたことを確認します。

ls ~/

アップロードされた認証情報ファイル、および先ほどクローンを作成したラボ用ファイルのディレクトリが表示されます。

4. 次のコマンドを実行して、credentials.json キーファイルを pubsub-key という Kubernetes の Secret に保存します。

kubectl create secret generic pubsub-key \ --from-file=key.json=$HOME/credentials.json

このコマンドを実行すると、pubsub-key という Secret が作成されます。この Secret には、Google Cloud コンソールからダウンロードした秘密鍵の内容が入った key.json の値が格納されています。

5. credentials.json ファイルをパソコンから削除します。

rm -rf ~/credentials.json

Secret でアプリケーションを構成する

次の変更が行われるように Deployment を更新します。

• Pod の仕様に Volume を追加します。この Volume には Secret が含まれます。
• Secret の Volume はアプリケーション コンテナ内にマウントされます。
• Secret の Volume のマウント内にあるキーファイルを参照するように GOOGLE_APPLICATION_CREDENTIALS 環境変数が設定されます。

GOOGLE_APPLICATION_CREDENTIALS 環境変数は、Google Cloud クライアント ライブラリ（この例では Python 用の Cloud Pub/Sub クライアント）によって自動的に認識されます。

pubsub-secret.yaml という更新済みの Deployment ファイルが用意されています。

apiVersion: apps/v1 kind: Deployment metadata: name: pubsub spec: selector: matchLabels: app: pubsub template: metadata: labels: app: pubsub spec: volumes: - name: google-cloud-key secret: secretName: pubsub-key containers: - name: subscriber image: gcr.io/google-samples/pubsub-sample:v1 volumeMounts: - name: google-cloud-key mountPath: /var/secrets/google env: - name: GOOGLE_APPLICATION_CREDENTIALS value: /var/secrets/google/key.json

1. pubsub-secret.yaml 構成ファイルをデプロイします。

kubectl apply -f pubsub-secret.yaml

2. 構成をデプロイしたら、次のコマンドを実行して Pod のステータスを表示します。

kubectl get pods -l app=pubsub

Pod のステータスが Running になるはずです。ステータスの表示が変更されるまでに数秒かかる場合があります。

出力:

NAME READY STATUS RESTARTS AGE pubsub-c4f48b868-xk27w 1/1 Running 0 35s

Cloud Pub/Sub メッセージの受信をテストする

1. アプリケーションの構成が完了した後は、このラボで先ほど作成した Cloud Pub/Sub トピックにメッセージを公開します。

gcloud pubsub topics publish $my_pubsub_topic --message="Hello, world!"

出力（実際のメッセージ ID は異なります）:

messageIds: - '328977244395410'

数秒以内にアプリケーションによってメッセージが取得され、出力ストリームに出力されます。

2. 次のコマンドを実行して、デプロイ済みの Pod のログを調べます。

kubectl logs -l app=pubsub

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

出力:

Pulling messages from Pub/Sub subscription... [2018-12-17 22:01:06.860378] Received message: ID=328977244395410 Data=b'Hello, world!' [2018-12-17 22:01:06.860736] Processing: 328977244395410 [2018-12-17 22:01:09.863973] Processed: 328977244395410

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。

Secret を操作する

タスク 2. ConfigMap を使用する

ConfigMap は実行時に、構成ファイル、コマンドライン引数、環境変数、ポート番号、および構成に関するその他のアーティファクトを Pod のコンテナやシステム コンポーネントにバインドします。

ConfigMap を使用することで、Pod やコンポーネントから構成を分離できます。ただし、ConfigMap は暗号化されないので、認証情報の格納には適していません。この点が Secret と ConfigMap の違いです。Secret は暗号化されますから、認証情報などの機密情報の格納により適しています。

ConfigMap は、ポート番号などの一般的な構成情報の格納に適しています。

kubectl コマンドを使用して ConfigMap を作成する

kubectl を使用して ConfigMap を作成します。その際、kubectl create configmap [NAME] [DATA] のパターンを使用し、ファイル用のフラグ（--from-file）またはリテラル用のフラグ（--from-literal）を追加します。

1. まず、次の kubectl コマンドでシンプルなリテラルを指定します。

kubectl create configmap sample --from-literal=message=hello

2. 次のコマンドを実行して、Kubernetes に取り込まれた ConfigMap の情報を確認します。

kubectl describe configmaps sample

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

出力:

Name: sample Namespace: default Labels: <none> Annotations: <none> Data ==== message: ---- hello Events: <none>

次に、ファイルから ConfigMap を作成します。サンプルデータが入った sample2.properties ファイルが用意されています。

message2=world foo=bar meaningOfLife=42

3. 次のコマンドを実行して、sample2.properties から ConfigMap を作成します。

kubectl create configmap sample2 --from-file=sample2.properties

4. 次のコマンドを実行して、Kubernetes に取り込まれた ConfigMap の情報を確認します。

kubectl describe configmaps sample2

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

出力:

Name: sample2 Namespace: default Labels: <none> Annotations: <none> Data ==== sample2.properties: ---- message2=world foo=bar meaningOfLife=42 Events: <none>

マニフェスト ファイルを使用して ConfigMap を作成する

YAML 構成ファイルを使用して ConfigMap を作成することもできます。config-map-3.yaml ファイルには、sample3 という ConfigMap の定義が含まれます。後でこの ConfigMap を使用して、コンテナ内のデータを公開する 2 つの方法をデモで見ていきます。

apiVersion: v1 data: airspeed: africanOrEuropean meme: testAllTheThings kind: ConfigMap metadata: name: sample3 namespace: default selfLink: /api/v1/namespaces/default/configmaps/sample3

1. 次のように YAML ファイルから ConfigMap を作成します。

kubectl apply -f config-map-3.yaml

2. 次のコマンドを実行して、Kubernetes に取り込まれた ConfigMap の情報を確認します。

kubectl describe configmaps sample3

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

出力:

Name: sample3 Namespace: default Labels: <none> Annotations: <none> Data ==== airspeed: ---- africanOrEuropean meme: ---- testAllTheThings Events: <none>

これで、機密ではない、暗号化されていない構成情報がアプリケーションから適切に分離され、クラスタで利用できるようになりました。このタスクでは、3 つの異なる方法で ConfigMap を使用して、さまざまなオプションのデモを行いました。ただし、通常は 1 つの方法のみを使用します。最も一般的なのは YAML 構成ファイルを使用する方法です。構成ファイルでは保存した値のレコードを使用できるため、同じプロセスを簡単に繰り返せます。

次に、アプリケーションからこの情報にアクセスする方法を学習します。

環境変数を使用してコンテナで ConfigMap を使用する

環境変数を使用してコンテナ内部から ConfigMap にアクセスするには、Pod の定義を更新して 1 つ以上の configMapKeyRefs を含める必要があります。

pubsub-configmap.yaml ファイルは、Cloud Pub/Sub のデモ Deployment の更新版です。ConfigMap からコンテナの中に環境変数をインポートする目的で、このファイルの末尾に次の env: 設定が追加されています。

- name: INSIGHTS valueFrom: configMapKeyRef: name: sample3 key: meme

1. 次のコマンドを実行して、更新済みの構成ファイルを再適用します。

kubectl apply -f pubsub-configmap.yaml

これで、アプリケーションから INSIGHTS という環境変数にアクセスできるようになりました。この環境変数の値は testAllTheThings です。

2. 環境変数に正しい値が設定されていることを確認するには、Pod へのシェルアクセスを取得する必要があり、Pod の名前が必要になります。次のコマンドを実行して Pod 名を取得します。

kubectl get pods

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

出力:

NAME READY STATUS RESTARTS AGE pubsub-77df8f8c6-krfl2 1/1 Running 0 4m

3. 次のコマンドを実行してシェル セッションを開始します。[MY-POD-NAME] は実際の Pod 名に置き換えます。

kubectl exec -it [MY-POD-NAME] -- sh

例:

kubectl exec -it pubsub-77df8f8c6-krfl2 -- sh

4. 次のコマンドを実行して、環境変数の一覧を出力します。

printenv

INSIGHTS=testAllTheThings が一覧に表示されます。

5. 次のコマンドを実行して、コンテナのシェル セッションを終了します。

exit

マウントされたボリュームを使用してコンテナで ConfigMap を使用する

環境変数に保存する代わりに、またはそれに加えて、ConfigMap のデータを Volume に入力できます。

この Deployment には、先ほどこのタスクで作成した sample-3 という ConfigMap も、Pod の仕様で config-3 という Volume として追加されます。config-3 Volume が、パス /etc/config でコンテナ内にマウントされます。環境変数を使用して ConfigMap をインポートする元の方法も構成されます。

pubsub-configmap2.yaml という更新された Deployment ファイルが用意されています。

apiVersion: apps/v1 kind: Deployment metadata: name: pubsub spec: selector: matchLabels: app: pubsub template: metadata: labels: app: pubsub spec: volumes: - name: google-cloud-key secret: secretName: pubsub-key - name: config-3 configMap: name: sample3 containers: - name: subscriber image: gcr.io/google-samples/pubsub-sample:v1 volumeMounts: - name: google-cloud-key mountPath: /var/secrets/google - name: config-3 mountPath: /etc/config env: - name: GOOGLE_APPLICATION_CREDENTIALS value: /var/secrets/google/key.json - name: INSIGHTS valueFrom: configMapKeyRef: name: sample3 key: meme

1. 更新済みの構成ファイルを次のように再適用します。

kubectl apply -f pubsub-configmap2.yaml

2. コンテナのシェル セッションに再接続して、ConfigMap 内の値にアクセスできるか確認します。Pod 名が変更されているため、次のコマンドを実行して Pod 名を取得します。

kubectl get pods

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

出力:

NAME READY STATUS RESTARTS AGE pubsub-747cf8c545-ngsrf 1/1 Running 0 30s pubsub-df6bc7b87-vb8cz 1/1 Terminating 0 4m

3. 次のコマンドを実行してシェル セッションを開始します。[MY-POD-NAME] は実際の Pod 名に置き換えます。

kubectl exec -it [MY-POD-NAME] -- sh

例:

kubectl exec -it pubsub-747cf8c545-ngsrf -- sh

4. 適切なフォルダに移動します。

cd /etc/config

5. フォルダ内のファイルを一覧表示します。

sample3 からキーとしてファイル名が表示されます。

ls

出力:

airspeed meme

6. 次のコマンドを実行して、1 つのファイルの内容を表示します。

cat airspeed

出力:

africanOrEuropean# 注: airspeed の値には改行が含まれていなかったので、返された値の末尾にコマンド プロンプト（\# 記号）があります。

7. 次のコマンドを実行して、コンテナのシェルを終了します。

exit

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。

ConfigMap を使用する

ラボを終了する

ラボが完了したら、[ラボを終了] をクリックします。ラボで使用したリソースが Google Cloud Skills Boost から削除され、アカウントの情報も消去されます。

ラボの評価を求めるダイアログが表示されたら、星の数を選択してコメントを入力し、[送信] をクリックします。

星の数は、それぞれ次の評価を表します。

• 星 1 つ = 非常に不満
• 星 2 つ = 不満
• 星 3 つ = どちらともいえない
• 星 4 つ = 満足
• 星 5 つ = 非常に満足

フィードバックを送信しない場合は、ダイアログ ボックスを閉じてください。

フィードバックやご提案の送信、修正が必要な箇所をご報告いただく際は、[サポート] タブをご利用ください。

Copyright 2020 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。