Private Service Connect z automatyczną konfiguracją DNS

1. Wprowadzenie

Usługa Private Service Connect z automatyczną konfiguracją DNS korzysta z Service Directory i Cloud DNS, aby automatycznie tworzyć rekordy DNS zaprogramowane z adresami IP punktów końcowych Private Service Connect konsumenta.

Co utworzysz

W tym ćwiczeniu utworzysz kompleksową architekturę Private Service Connect, która ilustruje użycie automatycznego DNS, jak pokazano na rysunku 1.

Automatyczne DNS jest możliwe dzięki tym funkcjom:

1. Załącznik usługi producenta generuje automatyczny DNS, podając posiadaną domenę publiczną z flagą „–domain-names” podczas tworzenia załącznika usługi Private Service Connect.
2. Konsument definiuje nazwę punktu końcowego.
3. Automatyczny DNS tworzy zarówno strefę DNS goog-psc-default-us-central1, jak i nazwę DNS cosmopup.net, a także wpis w Service Directory składający się z nazwy punktu końcowego konsumenta.

Zaleta automatycznego DNS jest widoczna na ilustracji (4), gdzie użytkownik może komunikować się z punktem końcowym usługi za pomocą DNS, FQDN stargazer.cosmopup.net.

Rysunek 1.

Uwaga: Ćwiczenie w Codelabs zawiera kroki konfiguracji i weryfikacji oparte na przedstawionej topologii. W razie potrzeby zmodyfikuj procedurę, aby spełnić wymagania organizacji. Uprawnienia IAM nie są objęte tym ćwiczeniem.

Czego się nauczysz

• Jak utworzyć wewnętrzny system równoważenia obciążenia HTTP(S)
• Tworzenie przyłącza usługi z automatycznym DNS
• Jak utworzyć usługę producenta Private Service Connect
• Jak uzyskać dostęp do punktu końcowego klienta za pomocą automatycznego DNS

Czego potrzebujesz

• Projekt Google Cloud
• domena publiczna, której jesteś właścicielem;

2. Zanim zaczniesz

Aktualizowanie projektu, aby obsługiwał ćwiczenia z programowania

To ćwiczenie wykorzystuje $zmienne, aby ułatwić implementację konfiguracji gcloud w Cloud Shell.

W Cloud Shell wykonaj te czynności:

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectname=YOUR-PROJECT-NAME
echo $projectname

3. Konfiguracja aplikacji Producer

Tworzenie sieci VPC producenta

W Cloud Shell wykonaj te czynności:

gcloud compute networks create producer-vpc --project=$projectname --subnet-mode=custom

Utwórz podsieci producenta

W Cloud Shell wykonaj te czynności:

gcloud compute networks subnets create gce-subnet --project=$projectname --range=172.16.20.0/28 --network=producer-vpc --region=us-central1

W Cloud Shell wykonaj te czynności:

gcloud compute networks subnets create load-balancer-subnet --project=$projectname --range=172.16.10.0/28 --network=producer-vpc --region=us-central1

Zarezerwuj adres IP dla wewnętrznego systemu równoważenia obciążenia

W Cloud Shell wykonaj te czynności:

gcloud compute addresses create lb-ip \
    --region=us-central1 \
    --subnet=load-balancer-subnet \
    --purpose=GCE_ENDPOINT

Uwaga: używanie SHARED_VIP nie jest obsługiwane w przypadku Private Service Connect. Zamiast tego użyj GCE_ENDPOINT.

Wyświetlanie przydzielonego adresu IP

Aby wyświetlić przydzielony adres IP, użyj polecenia compute addresses describe.

gcloud compute addresses describe lb-ip  --region=us-central1 | grep address:

Utwórz regionalne podsieci proxy

Przydzielanie serwerów proxy odbywa się na poziomie sieci VPC, a nie systemu równoważenia obciążenia. W każdym regionie sieci wirtualnej (VPC), w którym używasz systemów równoważenia obciążenia opartych na Envoy, musisz utworzyć podsieć tylko-proxy . Jeśli w tym samym regionie i tej samej sieci VPC wdrożysz kilka systemów równoważenia obciążenia, będą one współużytkować tę samą podsieć tylko-proxy na potrzeby równoważenia obciążenia.

1. Klient nawiązuje połączenie z adresem IP i portem reguły przekierowania systemu równoważenia obciążenia.
2. Każde proxy nasłuchuje na adresie IP i porcie określonym przez regułę przekierowania odpowiedniego systemu równoważenia obciążenia. Jeden z serwerów proxy odbiera i zamyka połączenie sieciowe klienta.
3. Serwer proxy nawiązuje połączenie z odpowiednią maszyną wirtualną backendu określoną przez mapę URL i usługi backendu systemu równoważenia obciążenia.

Podsieci tylko-proxy musisz utworzyć niezależnie od tego, czy Twoja sieć VPC działa w trybie automatycznym czy niestandardowym. Podsieć tylko dla proxy musi zawierać co najmniej 64 adresy IP. Odpowiada to długości prefiksu /26 lub krótszej. Zalecany rozmiar podsieci to /23 (512 adresów tylko-proxy).

W Cloud Shell wykonaj te czynności:

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

Tworzenie podsieci NAT Private Service Connect

Utwórz co najmniej jedną dedykowaną podsieć do używania z usługą Private Service Connect. Jeśli do publikowania usługi używasz konsoli Google Cloud, możesz utworzyć podsieci w trakcie tej procedury. Utwórz podsieć w tym samym regionie co system równoważenia obciążenia usługi. Nie możesz przekonwertować zwykłej podsieci na podsieć Private Service Connect.

W Cloud Shell wykonaj te czynności:

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

Tworzenie reguł zapory sieciowej producenta

Skonfiguruj reguły zapory sieciowej, aby zezwolić na ruch tylko między podsiecią NAT Private Service Connect a podsiecią serwera proxy ILB.

W Cloud Shell wykonaj te czynności:

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

W Cloud Shell utwórz regułę zapory sieciowej fw-allow-health-check, która zezwala kontroli stanu Google Cloud na docieranie do usługi producenta (usługi backendu) na porcie 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

Utwórz regułę zezwalania na ruch przychodzący w zaporze sieciowej dla podsieci tylko dla proxy, aby umożliwić systemowi równoważenia obciążenia komunikację z instancjami backendowymi na porcie 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

Konfiguracja routera Cloud Router i NAT

W tym ćwiczeniu używamy Cloud NAT do instalowania pakietów oprogramowania, ponieważ instancja maszyny wirtualnej nie ma zewnętrznego adresu IP.

W Cloud Shell utwórz router Cloud Router.

gcloud compute routers create cloud-router-for-nat --network producer-vpc --region us-central1

W Cloud Shell utwórz bramę 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

Konfiguracja grupy instancji

W następnej sekcji utworzysz instancję Compute Engine i niezarządzaną grupę instancji. W dalszych krokach grupa instancji będzie używana jako usługa backendu systemu równoważenia obciążenia.

W Cloud Shell utwórz regionalną kontrolę stanu przekazywaną do usługi producenta.

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"

W Cloud Shell utwórz niezarządzaną grupę instancji.

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

Konfigurowanie systemu równoważenia obciążenia

W kolejnych krokach skonfigurujesz wewnętrzny system równoważenia obciążenia HTTP , który w późniejszym kroku zostanie opublikowany jako przyłącze usługi.

W Cloud Shell utwórz regionalną kontrolę stanu.

gcloud compute health-checks create http http-health-check \
    --region=us-central1 \
    --use-serving-port

W Cloud Shell utwórz usługę backendu.

 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

W Cloud Shell dodaj backendy do usługi backendu.

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

W Cloud Shell utwórz mapę URL, aby kierować przychodzące żądania do usługi backendu.

gcloud compute url-maps create l7-ilb-map \
    --default-service l7-ilb-backend-service \
    --region=us-central1

Utwórz docelowy serwer proxy HTTP.

gcloud compute target-http-proxies create l7-ilb-proxy\
    --url-map=l7-ilb-map \
    --url-map-region=us-central1 \
    --region=us-central1

Utwórz regułę przekierowania, aby kierować przychodzące żądania do serwera proxy. Do utworzenia reguły przekierowania nie używaj podsieci tylko-proxy.

 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. Weryfikowanie systemu równoważenia obciążenia

W konsoli Cloud otwórz Usługi sieciowe → Równoważenie obciążenia → Systemy równoważenia obciążenia. Zanotuj udaną kontrolę stanu usługi backendu.

Wybranie opcji „l7-ilb-map” spowoduje wyświetlenie adresu IP frontendu, który powinien być zgodny z adresem IP wyodrębnionym w poprzednim kroku, i identyfikuje usługę backendową.

5. Tworzenie przyłącza usługi Private Service Connect

Uwaga: jeśli podasz nazwę domeny, będzie ona służyć do automatycznego konfigurowania prywatnych wpisów DNS dla usług w sieci VPC konsumenta usługi. Musisz być zweryfikowanym właścicielem podanej nazwy domeny. Opublikowanie usługi się nie uda, jeśli domena nie należy do Ciebie. Aby wyświetlić i skonfigurować własność domeny, kliknij Zweryfikuj domenę. W poniższej składni jako nazwa domeny użyto cosmopup.net. Zaktualizuj konfigurację, podając autoryzowaną domenę publiczną, której jesteś właścicielem.

Tworzenie przyłącza usługi

W Cloud Shell utwórz przyłącze usługi. Pamiętaj, aby na końcu nazwy domeny dodać znak „.”.

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.

Opcjonalnie: jeśli używasz współdzielonego środowiska VPC, utwórz przyłącze usługi w projekcie usługi.

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.

Aby wyświetlić nowo utworzone przyłącze usługi, otwórz Usługi sieciowe → Private Service Connect.

Wybranie opcji published-service (opublikowana usługa) zapewnia więcej szczegółów, w tym identyfikator URI przyłącza usługi używany przez konsumenta do nawiązania połączenia Private Service Connection oraz nazwę domeny.

Szczegóły przyłącza usługi:

projects/<project name>/regions/us-central1/serviceAttachments/published-service

6. Konfiguracja konsumencka

Włączanie interfejsów API dla konsumentów

W Cloud Shell wykonaj te czynności:

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

Utwórz sieć VPC konsumenta

W Cloud Shell wykonaj te czynności:

gcloud compute networks create consumer-vpc --project=$projectname --subnet-mode=custom

Tworzenie podsieci konsumenta

W Cloud Shell utwórz podsieć dla instancji testowej.

gcloud compute networks subnets create db1-subnet --project=$projectname --range=10.20.0.0/28 --network=consumer-vpc --region=us-central1

W Cloud Shell utwórz podsieć dla punktu końcowego konsumenta.

gcloud compute networks subnets create consumer-ep-subnet --project=$projectname --range=10.10.0.0/28 --network=consumer-vpc --region=us-central1

Utwórz punkt końcowy klienta (regułę przekierowania)

W Cloud Shell utwórz statyczny adres IP, który będzie używany w punkcie końcowym klienta.

gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=consumer-ep-subnet --addresses 10.10.0.10

Aby utworzyć punkt końcowy klienta, używamy wygenerowanego wcześniej identyfikatora URI przyłącza usługi.

W Cloud Shell utwórz punkt końcowy konsumenta.

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. Sprawdzanie połączenia w sieci VPC klienta

W sieci VPC konsumenta sprawdź, czy połączenie Private Service Connect zostało utworzone, klikając Usługi sieciowe → Private Service Connect → Połączone punkty końcowe. Zwróć uwagę na utworzone wcześniej połączenie z obserwatorem gwiazd i odpowiadający mu adres IP.

Po wybraniu psc-consumer-1 wyświetlane są szczegóły, w tym identyfikator URI przyłącza usługi.

8. Sprawdzanie połączenia w sieci VPC producenta

W sieci VPC producenta sprawdź, czy połączenie Private Service Connect zostało utworzone, klikając Usługi sieciowe → Private Service Connect → Opublikowana usługa. Zwróć uwagę, że opublikowane połączenie usługi wskazuje teraz 1 regułę przekierowania (punkt końcowy połączenia).

9. Sprawdzanie automatycznej konfiguracji DNS

Sprawdźmy konfigurację DNS i katalogu usług.

Konfiguracja Cloud DNS

Otwórz Usługi sieciowe → Cloud DNS → Strefy. Strefa goog-psc-default-us-central & i nazwa DNS cosmopup.net. są generowane automatycznie.

Wyświetlanie konfiguracji DNS i katalogu usług

Wybranie nazwy strefy pozwala zobaczyć, jak Service Directory jest zintegrowany z Cloud DNS.

Konfiguracja katalogu usług

Otwórz Usługi sieciowe → Service Directory.

Czy pamiętasz nazwę punktu końcowego klienta „stargazer”? Jest ona automatycznie programowana w Service Directory, co umożliwia nam dotarcie do punktu końcowego odbiorcy za pomocą w pełni kwalifikowanej nazwy domeny stargazer.goog-psc-default–us-central1.

10. Sprawdzanie dostępu konsumenta do usługi producenta

W sieci VPC konsumenta utworzymy maszynę wirtualną, aby przetestować połączenie z opublikowaną usługą przez dostęp do punktu końcowego konsumenta stargazer.cosmopup.net.

W Cloud Shell utwórz instancję testową w sieci VPC klienta.

gcloud compute instances create db1 \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=db1-subnet \
    --no-address

Aby umożliwić IAP połączenie z instancjami maszyn wirtualnych, utwórz regułę zapory sieciowej, która:

• Dotyczy wszystkich instancji maszyn wirtualnych, które mają być dostępne przez IAP.
• Zezwala na ruch przychodzący z zakresu adresów IP 35.235.240.0/20. Ten zakres zawiera wszystkie adresy IP, których IAP używa do przekierowywania TCP.

W Cloud Shell utwórz regułę zapory sieciowej IAP.

gcloud compute firewall-rules create ssh-iap-consumer \
    --network consumer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

Zaloguj się na maszynę wirtualną konsumenta za pomocą IAP w Cloud Shell, aby sprawdzić połączenie z usługą producenta, wykonując polecenie curl. Ponów próbę, jeśli nastąpi przekroczenie limitu czasu.

gcloud compute ssh db1 --project=$projectname --zone=us-central1-a --tunnel-through-iap

Wykonaj polecenie curl, aby sprawdzić połączenie z usługą producenta. Po zweryfikowaniu zamknij maszynę wirtualną i wróć do wiersza poleceń Cloud Shell.

W Cloud Shell wykonaj polecenie curl w swojej domenie niestandardowej, na przykład stargazer.[custom-domain.com]. W danych wyjściowych poniżej wykonano polecenie curl względem adresu stargazer.cosmopup.net.

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 !!

Wyjdź z maszyny wirtualnej i wróć do wiersza poleceń Cloud Shell, aby rozpocząć zadania czyszczenia.

11. Czyszczenie danych

Usuń komponenty codelabu z Cloud Shell.

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. Gratulacje

Gratulacje. Udało Ci się skonfigurować i zweryfikować punkt końcowy Private Service Connect z automatyczną konfiguracją DNS.

Utworzono infrastrukturę producenta i dodano przyłącze usługi z rejestracją domeny publicznej. Dowiedziałeś(-aś) się, jak utworzyć punkt końcowy konsumenta w sieci VPC konsumenta, który umożliwia połączenie z usługą lokalną za pomocą automatycznie wygenerowanego DNS.

Cosmopup uważa, że ćwiczenia z programowania są świetne!!

Co dalej?

Sprawdź te ćwiczenia z programowania:

• Korzystanie z Private Service Connect do publikowania i używania usług za pomocą GKE
• Korzystanie z Private Service Connect do publikowania i używania usług
• Łączenie z usługami lokalnymi przez sieć hybrydową przy użyciu usługi Private Service Connect i wewnętrznego systemu równoważenia obciążenia serwera proxy TCP

Więcej informacji i filmy

• Omówienie Private Service Connect
• Czym jest Private Service Connect?
• Obsługiwane typy systemów równoważenia obciążenia

Dokumentacja

• Omówienie wewnętrznego systemu równoważenia obciążenia HTTP(S)
• Informacje o kontrolach stanu
• Jak opublikować usługę za pomocą Private Service Connect
• Private Service Connect – automatyczny DNS