1. はじめに
Private Service Connect を使用すると、サービス プロデューサーがサービス コンシューマにサービスを提供できます。サービス プロデューサー VPC ネットワークは複数のサービス ユーザーをサポートできます。
公開サービスに接続できる Private Service Connect エンドポイントには、次の 2 種類があります。
- Private Service Connect エンドポイント（転送ルールに基づく）
このエンドポイント タイプでは、コンシューマは自身が定義した内部 IP アドレスに接続します。Private Service Connect は、ネットワーク アドレス変換（NAT）を行い、リクエストをサービス プロデューサーに転送します。
- コンシューマ HTTP(S) サービス コントロールを備えた Private Service Connect エンドポイント（グローバル外部 HTTP(S) ロードバランサに基づく）
このエンドポイント タイプでは、コンシューマは外部 IP アドレスに接続します。Private Service Connect はネットワーク エンドポイント グループを使用して、リクエストをサービス プロデューサーに転送します。
グローバル外部 HTTP(S) ロードバランサをポリシー適用ポイントとして使用することには、次の利点があります。
- サービスの名前を変更し、任意の URL にマッピングできます。
- Cloud Logging にすべてのリクエストを記録するようにロードバランサを構成できる。
- 顧客マネージド TLS 証明書を使用できます。Google マネージド証明書を使用できます。
この Codelab では、Global XLB を使用して Private Service Connect エンドポイントの Consumer HTTP(S) Service Controls を作成し、別のネットワークのサービスにプライベート アクセスする方法を学びます。この PSC パターンは、単一のプロジェクトまたは個別のプロジェクトを使用して実行できます。このラボでは、2 つの異なる VPC がある 1 つのプロジェクトを使用します。
学習内容
- グローバル XLB を使用してコンシューマ HTTP(S) Service Controls で Private Service Connect エンドポイントを作成する
- L7 XLB 接続を受け入れるために、サービス アタッチメントを介して公開されるマネージド サービスを構成する。
- SSL 証明書を作成し、TLS を終端してポート 443 でトラフィックを受け入れるように Apache ウェブサーバーを構成する。
- PSC NEG を作成します。
必要なもの
- Google Cloud プロジェクト
- インスタンスのデプロイとネットワーキング コンポーネントの構成に関する知識
2. テスト環境
作成する環境は、外部 HTTP(S) ロードバランサとコンシューマ VPC 内の PSC NEG で構成されます。プロデューサー VPC は、HTTPS で構成されたシンプルな Apache ウェブサービスをホストします。Apache ウェブサービスからバックエンド サービスを作成し、そのバックエンド サービスのフロントエンドに、PSC サービス アタッチメントで構成された内部 TCP ロードバランサを配置します。
3. 設定と要件
セルフペース型の環境設定
- Google Cloud Console にログインして、プロジェクトを新規作成するか、既存のプロジェクトを再利用します。Gmail アカウントも Google Workspace アカウントもまだお持ちでない場合は、アカウントを作成してください。
- プロジェクト名は、このプロジェクトの参加者に表示される名称です。Google API では使用されない文字列で、いつでも更新できます。
- プロジェクト ID は、すべての Google Cloud プロジェクトにおいて一意でなければならず、不変です（設定後は変更できません）。Cloud Console により一意の文字列が自動生成されます（通常は内容を意識する必要はありません）。ほとんどの Codelab では、プロジェクト ID を参照する必要があります（通常、プロジェクト ID は「
PROJECT_ID」の形式です）。好みの文字列でない場合は、別のランダムな ID を生成するか、独自の ID を試用して利用可能であるかどうかを確認することができます。プロジェクトの作成後、ID は「フリーズ」されます。 - 3 つ目の値として、一部の API が使用するプロジェクト番号があります。これら 3 つの値について詳しくは、こちらのドキュメントをご覧ください。
- 次に、Cloud のリソースや API を使用するために、Cloud Console で課金を有効にする必要があります。この Codelab の操作をすべて行って、費用が生じたとしても、少額です。このチュートリアルを終了した後に課金が発生しないようにリソースをシャットダウンするには、Codelab の最後にある「クリーンアップ」の手順を行います。Google Cloud の新規ユーザーは、300 米ドル分の無料トライアル プログラムをご利用いただけます。
Cloud Shell の起動
Google Cloud はノートパソコンからリモートで操作できますが、この Codelab では、Google Cloud Shell（Cloud 上で動作するコマンドライン環境）を使用します。
Google Cloud Console で、右上のツールバーにある Cloud Shell アイコンをクリックします。
プロビジョニングと環境への接続にはそれほど時間はかかりません。完了すると、次のように表示されます。
この仮想マシンには、必要な開発ツールがすべて用意されています。永続的なホーム ディレクトリが 5 GB 用意されており、Google Cloud で稼働します。そのため、ネットワークのパフォーマンスと認証機能が大幅に向上しています。このラボでの作業はすべて、ブラウザから実行できます。
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
5. プロデューサー VPC、サブネット、ファイアウォール ルールの設定
VPC ネットワーク
Cloud Shell から
gcloud compute networks create producer-vpc --subnet-mode custom
サブネットの作成
PSC のネットワーク アドレス変換（NAT）を行うには、プロデューサー側にサブネットが必要です。目的が PRIVATE_SERVICE_CONNECT であることに留意してください。つまり、このサブネットはワークロードのデプロイに使用できません。
Cloud Shell から
gcloud compute networks subnets create producer-nat-subnet \ --network=producer-vpc \ --region=$region \ --range=10.100.100.0/24 \ --purpose=PRIVATE_SERVICE_CONNECT
プロデューサー VPC に 2 つのサブネットをデプロイします。最初にプロデューサー サービスをデプロイし、別のリージョンで client-vm をデプロイして、TCP 内部ロードバランサのグローバル アクセス経由でサービスへの接続をテスト。
Cloud Shell から
gcloud compute networks subnets create service-subnet \
--network=producer-vpc \
--range=10.0.0.0/24 \
--region=$region
Cloud Shell から
gcloud compute networks subnets create client-subnet \
--network=producer-vpc \
--range=10.0.1.0/24 \
--region=us-east4
Cloud NAT を作成する
プロデューサー サービス用の適切なパッケージをインストールするには、Cloud NAT が必要です。
Cloud Shell から
gcloud compute routers create service-cr \ --region=$region --network=producer-vpc \ --asn=65501
Cloud Shell から
gcloud compute routers nats create service-nat-gw \ --router=service-cr \ --router-region=$region \ --nat-custom-subnet-ip-ranges=service-subnet \ --auto-allocate-nat-external-ips
ファイアウォール ルールの作成
このラボでは、IAP を使用して、作成したインスタンスに接続します。次のファイアウォール ルールを使用すると、IAP 経由でインスタンスに接続できます。IAP を使用しない場合は、この手順をスキップしてインスタンスにパブリック IP アドレスを追加し、TCP ポート 22 で 0.0.0.0/0 からの上り（内向き）を許可するファイアウォール ルールを作成できます。
IAP に VM インスタンスへの接続を許可するには、次のファイアウォール ルールを作成します。
- IAP を使用してアクセスできるようにするすべての VM インスタンスに適用します。
- IP 範囲 35.235.240.0/20 からの上り（内向き）トラフィックを許可する。この範囲には、IAP が TCP 転送に使用するすべての IP アドレスが含まれています。
Cloud Shell から
gcloud compute firewall-rules create allow-ssh-iap \
--network producer-vpc \
--allow tcp:22 \
--source-ranges=35.235.240.0/20
クライアント トラフィックはグローバル外部 HTTP(S) ロードバランサから発信されるため、ウェブサービスをホストするタグ付きの宛先サーバーへのこのトラフィックを許可するファイアウォール ルールを作成する必要があります。また、テスト用に client-subnet のファイアウォール ルールも開きます。
Cloud Shell から
gcloud compute firewall-rules create allow-xlb-client \ --network=producer-vpc \ --direction=ingress \ --allow=tcp:443 \ --target-tags=psc-service \ --source-ranges=130.211.0.0/22,35.191.0.0/16,10.0.1.0/24
Apache ウェブサービスを作成する
「PSC Service」と表示されるシンプルな Apache ウェブサービスを作成します。
インスタンス テンプレートを作成する
Cloud Shell から
gcloud compute instance-templates create producer-service-template \
--network producer-vpc \
--subnet service-subnet \
--region $region \
--no-address \
--scopes=https://www.googleapis.com/auth/cloud-platform \
--image-family=debian-10 \
--image-project=debian-cloud \
--tags=psc-service \
--metadata startup-script='#! /bin/bash
sudo apt-get update
apt-get install apache2 -y
a2ensite default-ssl
echo "PSC Service" | \
tee /var/www/html/index.html
systemctl restart apache2'
MIG のヘルスチェックを作成する
Cloud Shell から
gcloud compute health-checks create https psc-service-mig-healthcheck \
--port=443 \
--global
マネージド インスタンス グループを作成する
Cloud Shell から
gcloud compute instance-groups managed create psc-service-mig \
--region $region \
--size=2 \
--template=producer-service-template \
--health-check=psc-service-mig-healthcheck
Apache ウェブサーバーで SSL を構成する
次に、それぞれの Apache ウェブサーバーで SSL を構成する必要があります。そのためには、証明書を生成し、その証明書を Apache 構成に追加します。
この特定の PSC パターンでは、バックエンド サービスで内部 TCP/UDP（L4）ロードバランサの前面に配置する必要があるため、SSL 終端を構成する必要があります。内部 TCP/UDP ロードバランサは、ロードバランサ レイヤで SSL を終端しません。
まず、MIG の最初の VM に SSH 接続します。VM ゾーンと VM 名は環境ごとに動的に割り当てられます。コンソールで [Compute Engine] >[VM インスタンス] をクリックして、インスタンスの名前とゾーンを検索します。
Cloud Shell から
gcloud compute ssh --zone "<YOUR_VM_ZONE>" "<YOUR_MIG_VM_1>" --tunnel-through-iap --project $project
次に、OpenSSL を使用して証明書を作成します。国、都道府県、地域、組織、組織部門名、コモンネーム、メールアドレスに関する情報の入力を求められます。入力する必要がある情報は、選択した内部 FQDN であるコモンネームのみです。このラボでは、example.com を選択します。
Cloud Shell から
sudo openssl genrsa -out private-key-file.pem 2048
Cloud Shell から
cat <<'EOF' >config.txt [req] default_bits = 2048 req_extensions = extension_requirements distinguished_name = dn_requirements [extension_requirements] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectAltName = @sans_list [dn_requirements] countryName = Country Name (2 letter code) stateOrProvinceName = State or Province Name (full name) localityName = Locality Name (eg, city) 0.organizationName = Organization Name (eg, company) organizationalUnitName = Organizational Unit Name (eg, section) commonName = Common Name (e.g. server FQDN or YOUR name) emailAddress = Email Address [sans_list] DNS.1 = example.com EOF
Cloud Shell から
sudo openssl req -new -key private-key-file.pem \
-out csr.pem \
-config config.txt
Cloud Shell から
sudo openssl x509 -req \
-signkey private-key-file.pem \
-in csr.pem \
-out cert.cert \
-extfile config.txt \
-extensions extension_requirements \
-days 10
次に、Apache の構成情報を新しい証明書の詳細で更新しましょう。
sudo vi /etc/apache2/sites-enabled/default-ssl.conf
ServerAdmin の下に次の行を追加します。
ServerName example.com
VM 上の SSLCertificateFile と SSLCertificateKeyFile の場所と private-key-file.pem の場所を更新します。たとえば、次のようになります<profile> を更新してくださいディレクトリ名で置き換えます。
SSLCertificateFile /home/<profile>/cert.cert SSLCertificateKeyFile /home/<profile>/private-key-file.pem
エディタを閉じて Apache を再起動します。
sudo a2enmod ssl sudo systemctl restart apache2
インスタンスを終了し、マネージド インスタンス グループ内のもう一方のインスタンスで同じ手順を繰り返します。
6. プロデューサー サービスを作成する
次に、Service のロードバランサ コンポーネントを作成します。
ロードバランサのヘルスチェックを作成します。
Cloud Shell から
gcloud compute health-checks create https service-lb-healthcheck \
--port=443 \
--region=$region
バックエンド サービスを作成します。
Cloud Shell から
gcloud compute backend-services create psc-backend-service \
--load-balancing-scheme=internal \
--protocol=TCP \
--region=$region \
--health-checks=service-lb-healthcheck \
--health-checks-region=$region
gcloud compute backend-services add-backend psc-backend-service \
--region=$region \
--instance-group=psc-service-mig
転送ルールを作成します。転送ルールは、グローバル アクセスを使用してポート 443 で構成する必要があります。これは、この PSC パターンが機能するために必要です。
Cloud Shell から
gcloud compute forwarding-rules create producer-fr \
--region=$region \
--load-balancing-scheme=internal \
--network=producer-vpc \
--subnet=service-subnet \
--address=10.0.0.100 \
--ip-protocol=TCP \
--ports=443 \
--backend-service=psc-backend-service \
--backend-service-region=$region \
--allow-global-access
7. Service をテストする
サービス アタッチメントを作成する前に、別のリージョンにクライアントを作成して、グローバル アクセスが構成されたロードバランサと、TLS を終端するように構成された Apache サービスをテストします。
Cloud Shell から
gcloud compute instances create vm-client \
--zone=us-east4-a \
--image-family=debian-10 \
--image-project=debian-cloud \
--subnet=client-subnet \
--no-address
インスタンスに SSH 接続する。
Cloud Shell から
gcloud compute ssh \
--zone "us-east4-a" "vm-client" \
--tunnel-through-iap \
--project $project
ロードバランサ経由で 443 経由で接続し、Apache Service をテストします。
curl https://example.com:443 -k --connect-to example.com:443:10.0.0.100:443
期待される結果
PSC Service
8. サービス アタッチメントを作成する
Cloud Shell から
gcloud compute service-attachments create pscservice \
--region=$region \
--producer-forwarding-rule=producer-fr \
--connection-preference=ACCEPT-AUTOMATIC \
--nat-subnets=producer-nat-subnet
エンドポイント構成の次のステップで必要になるため、サービス アタッチメント URI をメモしておきます。これを取得するには、Cloud Shell で次のコマンドを実行します。
Cloud Shell から
gcloud compute service-attachments describe pscservice --region $region
/projects から始まる URI をコピーします
例: /projects/<YOUR_PROJECT_ID>/regions/us-central1/serviceAttachments/pscservice
9. コンシューマ VPC とサブネットの設定
VPC ネットワーク
Cloud Shell から
gcloud compute networks create consumer-vpc --subnet-mode custom
サブネットの作成
Private Service Connect ネットワーク エンドポイント グループ（NEG）がデプロイされるコンシューマ側にサブネットが必要です。
Cloud Shell から
gcloud compute networks subnets create psc-neg-subnet \ --network=consumer-vpc \ --region=$region \ --range=10.100.200.0/24 \ --purpose=private
10. Private Service Connect エンドポイントを作成して接続をテストする
ここでは、先ほど作成したサービス アタッチメントに関連付ける PSC NEG を作成し、PSC NEG をバックエンド サービスにアタッチして、バックエンド サービスを転送ルールに関連付けます。
前のステップでメモしたサービス アタッチメント URI を手元に用意します。以下の URL を実際の URI に置き換えます。
Cloud Shell から
gcloud beta compute network-endpoint-groups create xlb-psc-neg \ --network-endpoint-type=private-service-connect \ --psc-target-service=projects/<PROJECT-ID>/regions/us-central1/serviceAttachments/pscservice \ --region=$region \ --network=consumer-vpc \ --subnet=psc-neg-subnet
XLB パブリック IP アドレスを作成し、後でテストするために割り当てられた実際の IP アドレスを取得します。
Cloud Shell から
gcloud compute addresses create xlb-psc-address \ --ip-version=IPv4 --global gcloud compute addresses describe xlb-psc-address --format="get(address)" --global
次に、PSC エンドポイント（この場合は外部ロードバランサ）を作成します。
Cloud Shell から
gcloud beta compute backend-services create pscneg-backend-service \ --load-balancing-scheme=EXTERNAL_MANAGED \ --protocol=HTTPS \ --global
Cloud Shell から
gcloud beta compute backend-services add-backend pscneg-backend-service \ --network-endpoint-group=xlb-psc-neg \ --network-endpoint-group-region=$region \ --global
Cloud Shell から
gcloud beta compute url-maps create xlb-psc-map \ --default-service=pscneg-backend-service \ --global
Cloud Shell から
gcloud beta compute target-http-proxies create psc-http-proxy \ --url-map=xlb-psc-map
Cloud Shell から
gcloud beta compute forwarding-rules create xlb-psc-fr \ --load-balancing-scheme=EXTERNAL_MANAGED \ --network-tier=PREMIUM \ --address=xlb-psc-address \ --target-http-proxy=psc-http-proxy \ --ports=80 \ --global
5 ～ 7 分待ってから、xlb-psc-address に関連付けられている IP アドレスをブラウザのアドレスバーに入力します。
「PSC Service」の場合ソリューションが正しく構成されています。
11. クリーンアップ手順
単一の Cloud Shell ターミナルからラボのコンポーネントを削除する
gcloud beta compute forwarding-rules delete xlb-psc-fr --global --quiet gcloud beta compute target-http-proxies delete psc-http-proxy --quiet gcloud beta compute url-maps delete xlb-psc-map --global --quiet gcloud beta compute backend-services delete pscneg-backend-service --global --quiet gcloud compute addresses delete xlb-psc-address --global --quiet gcloud beta compute network-endpoint-groups delete xlb-psc-neg --region $region --quiet gcloud compute networks subnets delete psc-neg-subnet --region $region --quiet gcloud compute networks delete consumer-vpc --quiet gcloud compute service-attachments delete pscservice --region $region --quiet gcloud compute instances delete vm-client --zone=us-east4-a --quiet gcloud compute forwarding-rules delete producer-fr --region $region --quiet gcloud compute backend-services delete psc-backend-service --region $region --quiet gcloud compute health-checks delete service-lb-healthcheck --region $region --quiet gcloud compute instance-groups managed delete psc-service-mig --region $region --quiet gcloud compute health-checks delete psc-service-mig-healthcheck --region $region --quiet gcloud compute instance-templates delete producer-service-template --quiet gcloud compute firewall-rules delete allow-xlb-client --quiet gcloud compute firewall-rules delete allow-ssh-iap --quiet gcloud compute routers nats delete service-nat-gw –router service-cr --region $region --quiet gcloud compute routers delete service-cr --region $region --quiet gcloud compute networks subnets delete client-subnet --quiet gcloud compute networks subnets delete service-subnet --quiet gcloud compute networks subnets delete producer-nat-subnet --quiet gcloud compute networks delete producer-vpc --quiet
12. 完了
以上で、この Codelab は完了です。
学習した内容
- グローバル XLB を使用してコンシューマ HTTP(S) Service Controls で Private Service Connect エンドポイントを作成する
- L7 XLB 接続を受け入れるために、サービス アタッチメントを介して公開されるマネージド サービスを構成する。
- SSL 証明書を作成し、TLS を終端してポート 443 でトラフィックを受け入れるように Apache ウェブサーバーを構成する。
- PSC NEG を作成します。