Private Service Connect - PSC バックエンドを使用してプロデューサーサービスにアクセスする

1. はじめに

Private Service Connect を使用すると、サービスプロデューサーは 1 つの VPC ネットワークから別の VPC ネットワークにサービスをプライベートに公開できます。コンシューマーは、PSC エンドポイントまたは PSC バックエンドのいずれかを介してプロデューサーサービスにアクセスできます。

この Codelab では、PSC バックエンドに焦点を当てます。PSC バックエンドは、Google Cloud プロキシロードバランサ（アプリケーションまたはネットワーク）と組み合わせて使用されます。PSC バックエンドを使用すると、次のようなコンシューマー側の制御をより細かく行うことができます。

より深いオブザーバビリティとロギング
Cloud Armor の統合
カスタム URL
高度なトラフィック管理
カスタム TLS 証明書

この Codelab では、グローバル外部アプリケーションロードバランサを使用して Private Service Connect バックエンドを作成し、別のネットワークのプロデューサーサービスに非公開でアクセスする方法について説明します。

学習内容

グローバル外部アプリケーションロードバランサに関連付けられた PSC バックエンドを作成して構成する
Apache マネージドウェブサービスを構成し、サービスアタッチメントを介して PSC サービスとして公開する
内部アプリケーションロードバランサと外部アプリケーションロードバランサで SSL を終了する SSL 証明書を作成する
PSC サービスにアクセスするように Cloud DNS 一般公開ゾーンを構成する

必要なもの

オーナー権限を持つ Google Cloud プロジェクト

2. テスト環境

作成する環境は、コンシューマー VPC とプロデューサー VPC で構成されます。プロデューサー VPC には、オープンソースの Apache ウェブサービスを構築するインスタンステンプレートからマネージドインスタンスグループをデプロイします。また、サービスがローカルで正しく機能することを確認するために、テスト VM をデプロイします。Apache サービスをサービスアタッチメント経由で PSC プロデューサーサービスとして公開します。

コンシューマー VPC には、Apache サービスを指す PSC バックエンドサービスを含むグローバル外部アプリケーションロードバランサをデプロイします。次に、一般公開インターネットで PSC サービスにアクセスするように一般公開 DNS ゾーンを設定します。

3. 設定と要件

セルフペース型の環境設定

Google Cloud Console にログインして、プロジェクトを新規作成するか、既存のプロジェクトを再利用します。Gmail アカウントも Google Workspace アカウントもまだお持ちでない場合は、アカウントを作成してください。

プロジェクト名は、このプロジェクトの参加者に表示される名称です。Google API では使用されない文字列です。いつでも更新できます。
プロジェクト ID は、すべての Google Cloud プロジェクトにおいて一意でなければならず、不変です（設定後は変更できません）。Cloud コンソールでは一意の文字列が自動生成されます。通常は、この内容を意識する必要はありません。ほとんどの Codelab では、プロジェクト ID（通常は PROJECT_ID と識別されます）を参照する必要があります。生成された ID が好みではない場合は、ランダムに別の ID を生成できます。または、ご自身で試して、利用可能かどうかを確認することもできます。このステップ以降は変更できず、プロジェクトを通して同じ ID になります。
なお、3 つ目の値として、一部の API が使用するプロジェクト番号があります。これら 3 つの値について詳しくは、こちらのドキュメントをご覧ください。

次に、Cloud のリソースや API を使用するために、Cloud コンソールで課金を有効にする必要があります。この Codelab の操作をすべて行って、費用が生じたとしても、少額です。このチュートリアルの終了後に請求が発生しないようにリソースをシャットダウンするには、作成したリソースを削除するか、プロジェクトを削除します。Google Cloud の新規ユーザーは、300 米ドル分の無料トライアルプログラムをご利用いただけます。

Cloud Shell を起動する

Google Cloud はノートパソコンからリモートで操作できますが、この Codelab では、Google Cloud Shell（Cloud 上で動作するコマンドライン環境）を使用します。

Google Cloud Console で、右上のツールバーにある Cloud Shell アイコンをクリックします。

プロビジョニングと環境への接続にはそれほど時間はかかりません。完了すると、次のように表示されます。

この仮想マシンには、必要な開発ツールがすべて用意されています。永続的なホームディレクトリが 5 GB 用意されており、Google Cloud で稼働します。そのため、ネットワークのパフォーマンスと認証機能が大幅に向上しています。この Codelab での作業はすべて、ブラウザ内から実行できます。インストールは不要です。

4. 始める前に

API を有効にする

Cloud Shell で、プロジェクト ID が設定されていることを確認します。

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
export project=YOUR-PROJECT-NAME
export region=us-central1
echo $project
echo $region

必要なサービスをすべて有効にする

gcloud services enable compute.googleapis.com
gcloud services enable servicedirectory.googleapis.com
gcloud services enable dns.googleapis.com

5. プロデューサー VPC の設定

VPC ネットワークの作成

Cloud Shell から

gcloud compute networks create producer-vpc --subnet-mode custom

サブネットを作成する

2 つの汎用サブネットが producer-vpc にデプロイされます。service-subnet は、Apache ウェブサービス VM とロードバランサ転送ルールのデプロイに使用されます。test-client-subnet は別のリージョンに配置され、グローバルアクセスが有効になっている Apache サービスをテストする VM のデプロイに使用されます。

Cloud Shell から

gcloud compute networks subnets create service-subnet \
    --network=producer-vpc \
    --range=10.0.0.0/28 \
    --region=$region

Cloud Shell から

gcloud compute networks subnets create test-client-subnet \
    --network=producer-vpc \
    --range=10.0.1.0/28 \
    --region=us-east4

また、リージョン内部アプリケーションロードバランサで使用するプロキシ専用サブネットもデプロイする必要があります。

Cloud Shell から

gcloud compute networks subnets create central-proxy-subnet \
    --network=producer-vpc \
    --range=10.100.101.0/24 \
    --region=$region \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE

PSC サービスがデプロイされると、一意のサービスごとに、サービスアタッチメントに関連付ける対応する PSC NAT サブネットが必要になります。このサブネットのサイズは、想定される接続エンドポイントの数に応じて適切に設定する必要があります。

Cloud Shell から

gcloud compute networks subnets create psc-nat-subnet \
    --network=producer-vpc \
    --region=$region \
    --range=10.100.100.0/24 \
    --purpose=PRIVATE_SERVICE_CONNECT

Cloud NAT を作成する

プロデューサーサービス用の適切なパッケージをインストールするには、Cloud NAT が必要です。

Cloud Shell から

gcloud compute routers create central-cr \
    --network=producer-vpc \
    --region=$region

Cloud Shell から

gcloud compute routers nats create central-nat \
    --router=central-cr \
    --region=$region \
    --nat-all-subnet-ip-ranges \
    --auto-allocate-nat-external-ips

ネットワークファイアウォールのポリシーとルールを作成する

Cloud Shell から

gcloud compute network-firewall-policies create producer-vpc-policy --global

gcloud compute network-firewall-policies associations create \
    --firewall-policy producer-vpc-policy \
    --network producer-vpc \
    --name network-producer-vpc \
    --global-firewall-policy

IAP に VM インスタンスへの接続を許可するには、次のファイアウォールルールを作成します。

IAP を使用してアクセス可能にするすべての VM インスタンスに適用されます。
IP 範囲 35.235.240.0/20 からの上り（内向き）トラフィックを許可します。この範囲には、IAP が TCP 転送に使用するすべての IP アドレスが含まれています。

Cloud Shell から

gcloud compute network-firewall-policies rules create 1000 \
    --action ALLOW \
    --firewall-policy producer-vpc-policy \
    --description "SSH with IAP" \
    --direction INGRESS \
    --src-ip-ranges 35.235.240.0/20 \
    --layer4-configs tcp:22  \
    --global-firewall-policy

ロードバランサプロキシ専用サブネット（2000）から送信されるロードバランサバックエンドへの上り（内向き）トラフィックを許可する 2 つの追加のファイアウォールルールと、バックエンドインスタンスでロードバランサヘルスチェックを許可するルール（2001）が必要です。

Cloud Shell から

gcloud compute network-firewall-policies rules create 2000 \
    --action ALLOW \
    --firewall-policy producer-vpc-policy \
    --description "allow traffic from load balancer proxy subnet" \
    --direction INGRESS \
    --src-ip-ranges 10.100.101.0/24 \
    --layer4-configs tcp:443 \
    --global-firewall-policy


gcloud compute network-firewall-policies rules create 2001 \
    --action ALLOW \
    --firewall-policy producer-vpc-policy \
    --description "allow load balancer health checks" \
    --direction INGRESS \
    --src-ip-ranges 130.211.0.0/22,35.191.0.0/16 \
    --layer4-configs tcp:443 \
    --global-firewall-policy

6. Apache ウェブサービスを作成する

「PSC Service」と表示する簡単な Apache ウェブサービスを作成します。

インスタンステンプレートを作成する

Cloud Shell から

gcloud compute instance-templates create apache-service-template \
    --network producer-vpc \
    --subnet service-subnet \
    --region $region \
    --no-address \
    --metadata startup-script='#! /bin/bash
    sudo apt-get update
    apt-get install apache2 -y
    a2enmod ssl
    sudo a2ensite default-ssl
    echo "PSC Service" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

MIG のヘルスチェックを作成する

Cloud Shell から

gcloud compute health-checks create https service-mig-healthcheck \
    --port=443 \
    --global

マネージドインスタンスグループを作成する

Cloud Shell から

gcloud compute instance-groups managed create psc-service-mig \
    --region $region \
    --size=2 \
    --template=apache-service-template \
    --health-check=service-mig-healthcheck

gcloud compute instance-groups managed set-named-ports psc-service-mig \
    --named-ports=https:443 \
    --region=$region

7. 自己署名証明書を作成する

こちらの手順 1 を完了して、自己署名証明書を作成します。すべてのコマンドは Cloud Shell で実行できます。ステップ 1 が完了したら、この場所に戻ります。共通名が example.com で構成されている必要があります。

ロードバランサに関連付ける証明書リソースを作成します。証明書と秘密鍵のパラメータは、実際のファイル名に置き換えてください。

Cloud Shell から

gcloud compute ssl-certificates create producer-service-cert \
    --certificate=<your-producer-certfile.cert> \
    --private-key=<your-producer-keyfile.pem> \
    --region=$region

8. 内部リージョンアプリケーションロードバランサを作成する

次に、サービスのロードバランサコンポーネントを作成します。ここでは内部リージョンアプリケーションロードバランサを使用していますが、任意の Google Cloud 内部ロードバランサを使用することもできます。TLS の処理については、適切なロードバランサのドキュメントをご覧ください。

ロードバランサの転送ルールに使用する内部 IP アドレスを作成し、サービスへのテスト呼び出しを行うときに使用する IP をメモします。

Cloud Shell から

gcloud compute addresses create apache-service-ip \
 --region=$region \
 --subnet=service-subnet

gcloud compute addresses describe apache-service-ip \
   --format="get(address)" \
   --region=$region

ロードバランサのヘルスチェックを作成します。

Cloud Shell から

gcloud compute health-checks create https lb-apache-service-hc \
    --region=$region \
    --port-name=https

バックエンドサービスを作成します。

Cloud Shell から

gcloud compute backend-services create apache-bes\
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTPS \
  --port-name=https \
  --health-checks=lb-apache-service-hc \
  --health-checks-region=$region \
  --region=$region


gcloud compute backend-services add-backend apache-bes \
  --balancing-mode=UTILIZATION \
  --instance-group=psc-service-mig \
  --region=$region

URL マップを作成します。

Cloud Shell から

gcloud compute url-maps create producer-url-map \
  --default-service=apache-bes \
  --region=$region

ターゲット HTTPS プロキシを作成します。

Cloud Shell から

gcloud compute target-https-proxies create https-proxy \
  --url-map=producer-url-map \
  --region=$region \
  --ssl-certificates=producer-service-cert

転送ルールを作成します。

Cloud Shell から

gcloud compute forwarding-rules create apache-fr \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=producer-vpc \
  --subnet=service-subnet \
  --address=apache-service-ip \
  --ports=443 \
  --region=$region \
  --target-https-proxy=https-proxy \
  --target-https-proxy-region=$region \
  --allow-global-access

9. テスト VM を作成してサービスをローカルでテストする

サービスアタッチメントを作成する前に、別のリージョンにテストクライアント VM を作成して、ロードバランサがグローバルアクセスと TLS で正しく構成されていることをテストします。

Cloud Shell から

gcloud compute instances create vm-client \
    --zone=us-east4-a \
    --subnet=test-client-subnet \
    --no-address

プロビジョニングが完了するまで 1 分ほど待ってから、インスタンスに SSH 接続します。

Cloud Shell から

gcloud compute ssh \
    --zone "us-east4-a" "vm-client" \
    --tunnel-through-iap \
    --project $project

ロードバランサ経由で 443 経由で接続して、Apache サービスをテストします。内部 IP アドレスは、先ほど予約してメモしたものです。

curl https://example.com:443 -k --connect-to example.com:443:<YOUR-INTERNAL-IP>:443

予想される結果

PSC Service

VM を終了します。

vm-client から

exit

10. サービスアタッチメントを作成する

この例では、このプロジェクトからの PSC 接続のみを許可するようにサービスアタッチメントを構成します。これは、1 つ以上の特定のプロジェクトまたはネットワークを受け入れるように構成できますが、両方を受け入れることはできません。最大接続数の上限を 5 に設定しました。プロジェクトまたはネットワークごとに上限を設定する必要があります。

Cloud Shell から

gcloud compute service-attachments create apache-service-attachment \
    --region=$region \
    --producer-forwarding-rule=apache-fr \
    --connection-preference=ACCEPT_MANUAL \
    --consumer-accept-list=$project=5 \
    --nat-subnets=psc-nat-subnet

次のステップで PSC バックエンド構成に必要になるため、サービスアタッチメント URI（selfLink）をメモしておきます。Cloud Shell で次のコマンドを実行すると、取得できます。

Cloud Shell から

gcloud compute service-attachments describe apache-service-attachment \
    --region $region

projects から始まる URI をコピーします。

例: projects/$project/regions/$region/serviceAttachments/apache-service-attachment

11. コンシューマー VPC の設定

VPC ネットワークを作成する

Cloud Shell から

gcloud compute networks create consumer-vpc --subnet-mode custom

サブネットの作成

Private Service Connect ネットワークエンドポイントグループ（NEG）がデプロイされるコンシューマー側にサブネットが必要です。

Cloud Shell から

gcloud compute networks subnets create consumer-subnet \
    --network=consumer-vpc \
    --region=$region \
    --range=10.0.0.0/28

12. 外部 IP を予約し、コンシューマー側の自己署名証明書を作成する

外部 IP

ロードバランサの転送ルールで後で使用する外部静的 IP アドレスを作成し、Cloud Shell 変数に IP アドレスをキャプチャします。

Cloud Shell から

gcloud compute addresses create external-psc-ip \
    --network-tier=PREMIUM \
    --ip-version=IPV4 \
    --global

export externalip=$(gcloud compute addresses describe external-psc-ip \
    --format="get(address)" \
    --global)

echo $externalip

コンシューマー自己署名証明書

こちらの手順 1 をもう一度実行して、自己署名証明書を作成します。すべてのコマンドは Cloud Shell で実行できます。ステップ 1 が完了したら、この場所に戻ります。独自のパブリック DNS ゾーンを所有する代わりに、nip.io というオープンソースのパブリックワイルドカード DNS サービスを使用します。PSC サービスのパブリック URL は、構成した外部 IP アドレスを使用します。共通名には <YOUR-EXTERNAL-IP.nip.io> を構成する必要があります

外部ロードバランサに関連付ける証明書リソースを作成します。証明書と秘密鍵のパラメータは、実際のファイル名に置き換えてください。

Cloud Shell から

gcloud compute ssl-certificates create consumer-service-cert \
    --certificate=<your-consumer-certfile.cert> \
    --private-key=<your-consumer-keyfile.pem> \
    --global

13. ロードバランサコンポーネントを作成する

PSC NEG をバックエンドサービスとして新しく作成したサービスアタッチメントに接続するグローバル外部アプリケーションロードバランサを作成します。

前の手順でメモしたサービスアタッチメント URI を用意します。下の psc-target-service を URI に置き換えます。

Cloud Shell から

gcloud compute network-endpoint-groups create apache-psc-neg \
--network-endpoint-type=private-service-connect \
--psc-target-service=projects/$project/regions/$region/serviceAttachments/apache-service-attachment \
--region=$region \
--network=consumer-vpc \
--subnet=consumer-subnet

バックエンドサービスを作成します。

Cloud Shell から

gcloud compute backend-services create apache-pscneg-bes \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTPS \
    --global

gcloud compute backend-services add-backend apache-pscneg-bes \
    --network-endpoint-group=apache-psc-neg \
    --network-endpoint-group-region=$region \
    --global

URL マップを作成する

Cloud Shell から

gcloud compute url-maps create consumer-url-map \
    --default-service=apache-pscneg-bes \
    --global

ターゲット HTTPS プロキシを作成します。

Cloud Shell から

gcloud compute target-https-proxies create psc-https-proxy \
    --url-map=consumer-url-map \
    --ssl-certificates=consumer-service-cert

転送ルールを作成する

Cloud Shell から

gcloud compute forwarding-rules create external-fr \
  --load-balancing-scheme=EXTERNAL_MANAGED \
  --network-tier=PREMIUM \
  --address=external-psc-ip \
  --global \
  --target-https-proxy=psc-https-proxy \
  --ports=443

14. 一般公開 DNS ゾーンを作成する

Cloud Shell から

gcloud dns managed-zones create "psc-service" \
    --dns-name=$externalip.nip.io. \
    --description="public dns for psc service" \
    --visibility=public

Cloud Shell から

gcloud dns record-sets transaction start \
   --zone="psc-service"

gcloud dns record-sets transaction add $externalip \
   --name=$externalip.nip.io \
   --ttl=300 \
   --type=A \
   --zone="psc-service"

gcloud dns record-sets transaction execute \
   --zone="psc-service"

15. コンシューマー PSC 接続をテストする

公開 DNS が伝播するまで 7 ～ 10 分待ってからテストします。

Cloud Shell から

curl https://$externalip.nip.io -k

ブラウザまたはデスクトップターミナルに https://<YOUR-EXTERNAL-IP>.nip.io と入力して、ブラウザからテストすることもできます。

予想される結果

PSC Service

16. クリーンアップ手順

単一の Cloud Shell ターミナルからラボコンポーネントを削除する

gcloud dns record-sets delete $externalip.nip.io --zone="psc-service" --type=A -q

gcloud dns managed-zones delete "psc-service" -q

gcloud compute forwarding-rules delete external-fr --global -q 

gcloud compute target-https-proxies delete psc-https-proxy -q

gcloud compute url-maps delete consumer-url-map --global -q

gcloud compute backend-services delete apache-pscneg-bes --global -q

gcloud compute network-endpoint-groups delete apache-psc-neg --region=$region -q

gcloud compute ssl-certificates delete consumer-service-cert --global -q

gcloud compute addresses delete external-psc-ip --global -q

gcloud compute networks subnets delete consumer-subnet --region $region -q

gcloud compute networks delete consumer-vpc -q

gcloud compute instances delete vm-client --zone=us-east4-a -q

gcloud compute service-attachments delete apache-service-attachment --region $region -q

gcloud compute forwarding-rules delete apache-fr --region $region -q

gcloud compute target-https-proxies delete https-proxy --region $region -q

gcloud compute url-maps delete producer-url-map --region $region -q

gcloud compute backend-services delete apache-bes --region $region -q

gcloud compute health-checks delete lb-apache-service-hc --region $region -q

gcloud compute addresses delete apache-service-ip --region $region -q

gcloud compute ssl-certificates delete producer-service-cert --region $region -q

gcloud compute instance-groups managed delete psc-service-mig --region $region -q

gcloud compute health-checks delete service-mig-healthcheck --global -q

gcloud compute instance-templates delete apache-service-template -q

gcloud compute network-firewall-policies rules delete 2001 --firewall-policy producer-vpc-policy --global-firewall-policy -q

gcloud compute network-firewall-policies rules delete 2000 --firewall-policy producer-vpc-policy --global-firewall-policy -q

gcloud compute network-firewall-policies rules delete 1000 --firewall-policy producer-vpc-policy --global-firewall-policy -q

gcloud compute network-firewall-policies associations delete --firewall-policy=producer-vpc-policy  --name=network-producer-vpc --global-firewall-policy -q

gcloud compute network-firewall-policies delete producer-vpc-policy --global -q

gcloud compute routers nats delete central-nat --router=central-cr --region $region -q

gcloud compute routers delete central-cr --region $region -q

gcloud compute networks subnets delete psc-nat-subnet --region $region -q

gcloud compute networks subnets delete service-subnet --region $region -q

gcloud compute networks subnets delete test-client-subnet --region us-east4 -q 

gcloud compute networks subnets delete central-proxy-subnet --region $region -q

gcloud compute networks delete producer-vpc -q

17. 完了

以上で、この Codelab は完了です。

学習した内容

グローバル外部アプリケーションロードバランサに関連付けられた PSC バックエンドを作成して構成する
Apache マネージドウェブサービスを構成し、サービスアタッチメントを介して PSC サービスとして公開する
内部アプリケーションロードバランサと外部アプリケーションロードバランサで SSL を終了する SSL 証明書を作成する
PSC サービスにアクセスするように Cloud DNS 一般公開ゾーンを構成する

Private Service Connect - PSC バックエンドを使用してプロデューサー サービスにアクセスする

1. はじめに

学習内容

必要なもの

2. テスト環境

3. 設定と要件

セルフペース型の環境設定

Cloud Shell を起動する

4. 始める前に

API を有効にする

5. プロデューサー VPC の設定

VPC ネットワークの作成

サブネットを作成する

Cloud NAT を作成する

ネットワーク ファイアウォールのポリシーとルールを作成する

6. Apache ウェブサービスを作成する

インスタンス テンプレートを作成する

MIG のヘルスチェックを作成する

マネージド インスタンス グループを作成する

7. 自己署名証明書を作成する

8. 内部リージョン アプリケーション ロードバランサを作成する

9. テスト VM を作成してサービスをローカルでテストする

10. サービス アタッチメントを作成する

11. コンシューマー VPC の設定

VPC ネットワークを作成する

サブネットの作成

12. 外部 IP を予約し、コンシューマー側の自己署名証明書を作成する

外部 IP

コンシューマー自己署名証明書

13. ロードバランサ コンポーネントを作成する

14. 一般公開 DNS ゾーンを作成する

15. コンシューマー PSC 接続をテストする

16. クリーンアップ手順

17. 完了

学習した内容

Private Service Connect - PSC バックエンドを使用してプロデューサーサービスにアクセスする

ネットワークファイアウォールのポリシーとルールを作成する

インスタンステンプレートを作成する

マネージドインスタンスグループを作成する

8. 内部リージョンアプリケーションロードバランサを作成する

10. サービスアタッチメントを作成する

13. ロードバランサコンポーネントを作成する