1. はじめに
DNS の自動構成を使用する Private Service Connect は、Service Directory と Cloud DNS を使用して、コンシューマの Private Service Connect エンドポイント IP アドレスでプログラムされた DNS レコードを自動的に作成します。
作成するアプリの概要
この Codelab では、図 1 に示すように、自動 DNS の使用を示す包括的な Private Service Connect アーキテクチャを構築します。
自動 DNS は、次の機能によって実現されます。
- プロデューサー サービス アタッチメントは、Private Service Connect サービス アタッチメントを作成するときに、所有するパブリック ドメインに「–domain-names」フラグを指定することで、自動 DNS を開始します。
- コンシューマがエンドポイント名を定義します。
- 自動 DNS では、DNS ゾーン goog-psc-default-us-central1 と DNS 名 cosmopup.net の両方が作成され、コンシューマ エンドポイント名で構成される Service Directory エントリも作成されます。
DNS の自動化のメリットは、エンドユーザーが DNS FQDN stargazer.cosmopup.net を介してコンシューマ エンドポイントと通信できる(4)点にあります。
図 1
学習内容
- 内部 HTTP(S) ロードバランサを作成する方法
- DNS 自動設定を使用してサービス アタッチメントを作成する方法
- Private Service Connect プロデューサー サービスを確立する方法
- 自動 DNS を使用してコンシューマ エンドポイントにアクセスする方法
必要なもの
- Google Cloud プロジェクト
- 所有しているパブリック ドメイン
2. 始める前に
Codelab をサポートするようにプロジェクトを更新する
この Codelab では、$variables を使用して、Cloud Shell での gcloud 構成の実装を支援します。
Cloud Shell で次の操作を行います。
gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectname=YOUR-PROJECT-NAME
echo $projectname
3. プロデューサーの設定
プロデューサー VPC を作成する
Cloud Shell で次の操作を行います。
gcloud compute networks create producer-vpc --project=$projectname --subnet-mode=custom
プロデューサー サブネットを作成する
Cloud Shell で次の操作を行います。
gcloud compute networks subnets create gce-subnet --project=$projectname --range=172.16.20.0/28 --network=producer-vpc --region=us-central1
Cloud Shell で次の操作を行います。
gcloud compute networks subnets create load-balancer-subnet --project=$projectname --range=172.16.10.0/28 --network=producer-vpc --region=us-central1
内部ロードバランサの IP アドレスを予約する
Cloud Shell で次の操作を行います。
gcloud compute addresses create lb-ip \
--region=us-central1 \
--subnet=load-balancer-subnet \
--purpose=GCE_ENDPOINT
割り振られた IP アドレスを表示する
compute addresses describe コマンドを使用して、割り振られた IP アドレスを表示します。
gcloud compute addresses describe lb-ip --region=us-central1 | grep address:
リージョン プロキシ サブネットを作成する
プロキシの割り当ては、ロードバランサ レベルではなく VPC ネットワーク レベルで行われます。Envoy ベースのロードバランサを使用する仮想ネットワーク(VPC)の各リージョンに、プロキシ専用サブネット を 1 つ作成する必要があります。同じリージョンおよび同じ VPC ネットワーク内に複数のロードバランサをデプロイすると、ロード バランシング用に同じプロキシ専用サブネットが共有されます。
- クライアントは、ロードバランサの転送ルールの IP アドレスとポートに接続します。
- 各プロキシは、対応するロードバランサの転送ルールで指定された IP アドレスとポートでリッスンします。いずれかのプロキシがクライアントのネットワーク接続を受信して終了します。
- プロキシは、ロードバランサの URL マップとバックエンド サービスによって決定された適切なバックエンド VM への接続を確立します。
VPC ネットワークが自動モードかカスタムモードかに関係なく、プロキシ専用サブネットを作成する必要があります。プロキシ専用サブネットでは 64 個以上の IP アドレスを指定する必要があります。これは、/26 以下のプレフィックス長に対応します。推奨されるサブネット サイズは /23(512 個のプロキシ専用アドレス)です。
Cloud Shell で次の操作を行います。
gcloud compute networks subnets create proxy-subnet-us-central \
--purpose=REGIONAL_MANAGED_PROXY \
--role=ACTIVE \
--region=us-central1 \
--network=producer-vpc \
--range=172.16.0.0/23
Private Service Connect NAT サブネットを作成する
Private Service Connect で使用する 1 つ以上の専用サブネットを作成します。Google Cloud コンソールを使用してサービスを公開する場合は、その手順でサブネットを作成できます。サービスのロードバランサと同じリージョンにサブネットを作成します。通常のサブネットを Private Service Connect サブネットに変換することはできません。
Cloud Shell で次の操作を行います。
gcloud compute networks subnets create psc-nat-subnet \
--project $projectname \
--network producer-vpc \
--region us-central1 \
--range 100.100.10.0/24 \
--purpose PRIVATE_SERVICE_CONNECT
プロデューサーのファイアウォール ルールを作成する
Private Service Connect NAT サブネットと ILB プロキシ専用サブネット間のトラフィックを許可するように ファイアウォール ルールを構成します。
Cloud Shell で次の操作を行います。
gcloud compute --project=$projectname firewall-rules create allow-to-ingress-nat-subnet --direction=INGRESS --priority=1000 --network=producer-vpc --action=ALLOW --rules=all --source-ranges=100.100.10.0/24
Cloud Shell で、Google Cloud ヘルスチェックが TCP ポート 80 でプロデューサー サービス(バックエンド サービス)に到達できるように、fw-allow-health-check ファイアウォール ルールを作成します。
gcloud compute firewall-rules create fw-allow-health-check \
--network=producer-vpc \
--action=allow \
--direction=ingress \
--source-ranges=130.211.0.0/22,35.191.0.0/16 \
--rules=tcp:80
ロードバランサが TCP ポート 80 でバックエンド インスタンスと通信できるように、プロキシ専用サブネットの上り(内向き)許可ファイアウォール ルールを作成します。
gcloud compute firewall-rules create fw-allow-proxy-only-subnet \
--network=producer-vpc \
--action=allow \
--direction=ingress \
--source-ranges=172.16.0.0/23 \
--rules=tcp:80
Cloud Router と NAT の構成
VM インスタンスに外部 IP アドレスがないため、この Codelab ではソフトウェア パッケージのインストールに Cloud NAT を使用します。
Cloud Shell で、Cloud Router を作成します。
gcloud compute routers create cloud-router-for-nat --network producer-vpc --region us-central1
Cloud Shell で NAT ゲートウェイを作成します。
gcloud compute routers nats create cloud-nat-us-central1 --router=cloud-router-for-nat --auto-allocate-nat-external-ips --nat-all-subnet-ip-ranges --region us-central1
インスタンス グループの構成
次のセクションでは、Compute Engine インスタンスと非マネージド インスタンス グループを作成します。後の手順で、このインスタンス グループをロードバランサのバックエンド サービスとして使用します。
Cloud Shell で、プロデューサー サービスに渡されるリージョン ヘルスチェックを作成します。
gcloud compute instances create app-server-1 \
--project=$projectname \
--machine-type=e2-micro \
--image-family debian-10 \
--no-address \
--image-project debian-cloud \
--zone us-central1-a \
--subnet=gce-subnet \
--metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo service apache2 restart
echo 'Welcome to App-Server-1 !!' | tee /var/www/html/index.html
EOF"
Cloud Shell で、非マネージド インスタンス グループを作成します。
gcloud compute instance-groups unmanaged create psc-instance-group --zone=us-central1-a
gcloud compute instance-groups unmanaged set-named-ports psc-instance-group --project=$projectname --zone=us-central1-a --named-ports=http:80
gcloud compute instance-groups unmanaged add-instances psc-instance-group --zone=us-central1-a --instances=app-server-1
ロードバランサを構成する
次の手順では、後でサービス アタッチメントとして公開する内部 HTTP ロードバランサ を構成します。
Cloud Shell で、リージョン ヘルスチェックを作成します。
gcloud compute health-checks create http http-health-check \
--region=us-central1 \
--use-serving-port
Cloud Shell で、バックエンド サービスを作成します。
gcloud compute backend-services create l7-ilb-backend-service \
--load-balancing-scheme=INTERNAL_MANAGED \
--protocol=HTTP \
--health-checks=http-health-check \
--health-checks-region=us-central1 \
--region=us-central1
Cloud Shell で、バックエンド サービスにバックエンドを追加します。
gcloud compute backend-services add-backend l7-ilb-backend-service \
--balancing-mode=UTILIZATION \
--instance-group=psc-instance-group \
--instance-group-zone=us-central1-a \
--region=us-central1
Cloud Shell で、受信リクエストをバックエンド サービスに転送する URL マップを作成します。
gcloud compute url-maps create l7-ilb-map \
--default-service l7-ilb-backend-service \
--region=us-central1
HTTP ターゲット プロキシを作成します。
gcloud compute target-http-proxies create l7-ilb-proxy\
--url-map=l7-ilb-map \
--url-map-region=us-central1 \
--region=us-central1
受信リクエストをプロキシに転送する転送ルールを作成します。転送ルールの作成には、プロキシ専用サブネットを使用しないでください。
gcloud compute forwarding-rules create l7-ilb-forwarding-rule \
--load-balancing-scheme=INTERNAL_MANAGED \
--network=producer-vpc \
--subnet=load-balancer-subnet \
--address=lb-ip \
--ports=80 \
--region=us-central1 \
--target-http-proxy=l7-ilb-proxy \
--target-http-proxy-region=us-central1
4. ロードバランサを検証する
Cloud コンソールで、[ネットワーク サービス] > [ロード バランシング] > [ロードバランサ] に移動します。バックエンド サービスへのヘルスチェックが成功したことをメモします。
「l7-ilb-map」を選択すると、フロントエンド IP アドレスが返されます。この IP アドレスは、前の手順で grep した IP アドレスと一致し、バックエンド Service を識別します。
5. Private Service Connect サービス アタッチメントを作成する
サービス アタッチメントを作成する
Cloud Shell で、サービス アタッチメントを作成します。ドメイン名の末尾に「.」を付けてください。
gcloud compute service-attachments create published-service --region=us-central1 --producer-forwarding-rule=l7-ilb-forwarding-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet --domain-names=cosmopup.net.
省略可: 共有 VPC を使用する場合は、サービス プロジェクトにサービス アタッチメントを作成します。
gcloud compute service-attachments create published-service --region=us-central1 --producer-forwarding-rule=l7-ilb-forwarding-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/us-central1/subnetworks/psc-nat-subnet --domain-names=cosmopup.net.
[ネットワーク サービス → Private Service Connect] に移動して、新しく作成されたサービス アタッチメントを表示します。
[published-service] を選択すると、コンシューマが Private Service 接続を確立するために使用するサービス アタッチメント URI やドメイン名など、詳細が表示されます。
サービス アタッチメントの詳細:
projects/<project name>/regions/us-central1/serviceAttachments/published-service
6. コンシューマの設定
コンシューマ API を有効にする
Cloud Shell で次の操作を行います。
gcloud services enable dns.googleapis.com
gcloud services enable servicedirectory.googleapis.com
コンシューマ VPC ネットワークを作成する
Cloud Shell で次の操作を行います。
gcloud compute networks create consumer-vpc --project=$projectname --subnet-mode=custom
コンシューマ サブネットを作成する
Cloud Shell で、テスト インスタンスのサブネットを作成します。
gcloud compute networks subnets create db1-subnet --project=$projectname --range=10.20.0.0/28 --network=consumer-vpc --region=us-central1
Cloud Shell で、コンシューマ エンドポイントのサブネットを作成します。
gcloud compute networks subnets create consumer-ep-subnet --project=$projectname --range=10.10.0.0/28 --network=consumer-vpc --region=us-central1
コンシューマ エンドポイント(転送ルール)を作成する
Cloud Shell で、コンシューマ エンドポイントに使用する静的 IP アドレスを作成します。
gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=consumer-ep-subnet --addresses 10.10.0.10
前に生成したサービス アタッチメント URI を使用して、コンシューマ エンドポイントを作成します。
Cloud Shell で、コンシューマ エンドポイントを作成します。
gcloud compute forwarding-rules create stargazer --region=us-central1 --network=consumer-vpc --address=psc-consumer-ip-1 --target-service-attachment=projects/$projectname/regions/us-central1/serviceAttachments/published-service
7. コンシューマの VPC ネットワークで接続を確認します。
コンシューマの VPC ネットワークで、[ネットワーク サービス → Private Service Connect → 接続済みエンドポイント] に移動して、Private Service 接続が正常に完了したことを確認します。確立された Stargazer 接続と、前に作成した対応する IP アドレスをメモします。
psc-consumer-1 を選択すると、サービス アタッチメント URI などの詳細が表示されます。
8. プロデューサーの VPC ネットワーク内の接続を確認します。
プロデューサーの VPC ネットワークで、[ネットワーク サービス] → [Private Service Connect] → [公開サービス] に移動して、限定公開サービス接続が正常に完了したことを確認します。公開サービス接続に転送ルール(接続エンドポイント)が 1 つ表示されている点に注意してください。
9. DNS の自動構成を検証する
DNS と Service Directory の構成を評価しましょう。
Cloud DNS の構成
[ネットワーク サービス] > [Cloud DNS] > [ゾーン] に移動します。ゾーン goog-psc-default-us-central と DNS 名 cosmopup.net が自動的に生成されます。
DNS と Service Directory の構成を表示する
ゾーン名を選択すると、Service Directory が Cloud DNS とどのように統合されているかを確認できます。
Service Directory の構成
[ネットワーク サービス] → [Service Directory] に移動します。
コンシューマ エンドポイント名「stargazer」を思い出してください。これは Service Directory で自動的にプログラムされ、FQDN stargazer.goog-psc-default–us-central1 を使用してコンシューマ エンドポイントにアクセスできます。
10. プロデューサー サービスへのコンシューマのアクセス権を確認する
コンシューマの VPC ネットワークから VM を作成し、コンシューマ エンドポイント stargazer.cosmopup.net にアクセスして、公開されたサービスの接続をテストします。
Cloud Shell で、コンシューマ VPC にテスト インスタンスを作成します。
gcloud compute instances create db1 \
--zone=us-central1-a \
--image-family=debian-10 \
--image-project=debian-cloud \
--subnet=db1-subnet \
--no-address
IAP に VM インスタンスへの接続を許可するには、次のファイアウォール ルールを作成します。
- IAP を使用してアクセス可能にするすべての VM インスタンスに適用します。
- IP 範囲 35.235.240.0/20 からの上り(内向き)トラフィックを許可します。この範囲には、IAP が TCP 転送に使用するすべての IP アドレスが含まれています。
Cloud Shell で、IAP ファイアウォール ルールを作成します。
gcloud compute firewall-rules create ssh-iap-consumer \
--network consumer-vpc \
--allow tcp:22 \
--source-ranges=35.235.240.0/20
Cloud Shell で IAP を使用して consumer-vm にログインし、curl を実行してプロデューサー サービスへの接続を確認します。タイムアウトが発生した場合は再試行します。
gcloud compute ssh db1 --project=$projectname --zone=us-central1-a --tunnel-through-iap
プロデューサー サービスへの接続を検証する curl を実行します。検証が完了したら、VM を終了して Cloud Shell プロンプトに戻ります。
Cloud Shell で、カスタム ドメイン(stargazer.[custom-domain.com] など)に対して curl を実行します。次の出力では、stargazer.cosmopup.net に対して curl が実行されています。
user@db1:~$ curl -v stargazer.cosmopup.net
* Trying 10.10.0.10...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55d3aa8190f0)
* Connected to stargazer.cosmopup.net (10.10.0.10) port 80 (#0)
> GET / HTTP/1.1
> Host: stargazer.cosmopup.net
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 200 OK
< date: Thu, 22 Dec 2022 00:16:25 GMT
< server: Apache/2.4.38 (Debian)
< last-modified: Wed, 21 Dec 2022 20:26:32 GMT
< etag: "1b-5f05c5e43a083"
< accept-ranges: bytes
< content-length: 27
< content-type: text/html
< via: 1.1 google
<
Welcome to App-Server-1 !!
VM を終了して Cloud Shell プロンプトに戻り、クリーンアップ タスクを開始します。
11. クリーンアップ
Cloud Shell で、Codelab コンポーネントを削除します。
gcloud compute forwarding-rules delete stargazer --region=us-central1 --quiet
gcloud compute instances delete db1 --zone=us-central1-a --quiet
gcloud compute addresses delete psc-consumer-ip-1 --region=us-central1 --quiet
gcloud compute networks subnets delete consumer-ep-subnet db1-subnet --region=us-central1 --quiet
gcloud compute firewall-rules delete ssh-iap-consumer --quiet
gcloud compute networks delete consumer-vpc --quiet
gcloud compute service-attachments delete published-service --region=us-central1 --quiet
gcloud compute forwarding-rules delete l7-ilb-forwarding-rule --region=us-central1 --quiet
gcloud compute target-http-proxies delete l7-ilb-proxy --region=us-central1 --quiet
gcloud compute url-maps delete l7-ilb-map --region=us-central1 --quiet
gcloud compute backend-services delete l7-ilb-backend-service --region=us-central1 --quiet
gcloud compute instance-groups unmanaged delete psc-instance-group --zone=us-central1-a --quiet
gcloud compute instances delete app-server-1 --zone=us-central1-a --quiet
gcloud compute firewall-rules delete allow-to-ingress-nat-subnet fw-allow-health-check fw-allow-proxy-only-subnet --quiet
gcloud compute addresses delete lb-ip --region=us-central1 --quiet
gcloud compute networks subnets delete gce-subnet load-balancer-subnet psc-nat-subnet proxy-subnet-us-central --region=us-central1 --quiet
gcloud compute routers delete cloud-router-for-nat --region=us-central1 --quiet
gcloud compute networks delete producer-vpc --quiet
12. 完了
これで、DNS の自動構成を使用して Private Service Connect エンドポイントを正常に構成して検証できました。
プロデューサー インフラストラクチャを作成し、パブリック ドメイン登録を使用してサービス アタッチメントを追加しました。自動生成された DNS を使用してオンプレミス サービスへの接続を許可するコンシューマ VPC ネットワークにコンシューマ エンドポイントを作成する方法について学習しました。
Cosmopup はコードラボが大好きです。
次のステップ
以下の Codelab をご覧ください。
- GKE を使用した Private Service Connect によるサービスの公開と使用
- Private Service Connect でサービスを公開して使用する
- Private Service Connect と内部 TCP プロキシ ロードバランサを使用して、ハイブリッド ネットワーキング経由でオンプレミス サービスに接続する