1. はじめに
DNS の自動構成を備えた Private Service Connect は、Service Directory と Cloud DNS を使用して、コンシューマの Private Service Connect エンドポイント IP アドレスでプログラムされた DNS レコードを自動的に作成します。
作成するアプリの概要
この Codelab では、図 1 に示すような自動 DNS の使用を示す包括的な Private Service Connect アーキテクチャを構築します。
自動 DNS は、次の方法で可能になります。
- プロデューサー サービス アタッチメントは、「– domain-names」を使用して所有するパブリック ドメインを指定することで、自動 DNS を開始します。フラグ。
- コンシューマはエンドポイント名を定義します。
- 自動 DNS は、コンシューマ エンドポイント名で構成される Service Directory エントリに加えて、DNS ゾーン goog-psc-default-us-central1 と DNS 名 cosmopup.net の両方を作成します。
自動 DNS の利点は(4)に示されています。ここでは、エンドユーザーが DNS、FQDN の stargazer.cosmopup.net を介してコンシューマのエンドポイントと通信できます。
図 1
学習内容
- 内部 HTTP(S) ロードバランサの作成方法
- 自動 DNS を使用してサービス アタッチメントを作成する方法
- Private Service Connect プロデューサー サービスを確立する方法
- 自動 DNS を使用してコンシューマ エンドポイントにアクセスする方法
必要なもの
- Google Cloud プロジェクト
- 所有しているパブリック ドメイン
2. 始める前に
Codelab をサポートするようにプロジェクトを更新する
この Codelab では、Cloud Shell での gcloud 構成の実装に役立つ $variables を使用します。
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 内で fw-allow-health-check ファイアウォール ルールを作成し、Google Cloud ヘルスチェックが TCP ポート 80 でプロデューサー サービス(バックエンド サービス)に到達できるようにします。
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 アドレスは、前の手順で取得した IP アドレスと一致するはずです。また、バックエンド サービスが識別されます。
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 を選択すると、コンシューマがプライベート サービス接続を確立するために使用するサービス アタッチメント URI など、より詳細な情報が提供されます。指定します。
サービス アタッチメントの詳細:
projects/<プロジェクト名>/regions/us-central1/serviceAttachments/published-service
6. ユーザー設定
コンシューマ API を有効にする
Cloud 内で、シェルで次の処理を行います。
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 ネットワークから、コンシューマ エンドポイント stargazer.cosmopup.net にアクセスして公開サービスの接続をテストする VM を作成します。
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 を素晴らしいと思っています!
次のステップ
以下の Codelab をご覧ください。
- GKE を使用した Private Service Connect によるサービスの公開と使用
- Private Service Connect でサービスを公開して使用する
- Private Service Connect と内部 TCP プロキシ ロードバランサを使用して、ハイブリッド ネットワークでオンプレミス サービスに接続する