Ta strona została przetłumaczona przez Cloud Translation API.

Private Service Connect z automatyczną konfiguracją DNS

1. Wprowadzenie

Usługa Private Service Connect z automatyczną konfiguracją DNS korzysta z Katalogu usług i Cloud DNS do automatycznego tworzenia rekordów DNS zaprogramowanych z adresami IP punktów końcowych Private Service Connect konsumenta.

Co utworzysz

W ramach tego ćwiczenia w Codelabs utworzysz kompleksową architekturę usługi Private Service Connect, która ilustruje wykorzystanie automatycznego DNS, tak jak na rys. 1.

Automatyczny DNS jest dostępny dzięki tym działaniom:

Przyłącze usługi producenta generuje automatyczny DNS przez podanie należącej do domeny publicznej atrybutu „– nazwy domen” flagi podczas tworzenia przyłącza usługi Private Service Connect.
Konsument definiuje nazwę punktu końcowego.
Automatyczny DNS tworzy zarówno strefę DNS, goog-psc-default-us-central1, jak i nazwę DNS cosmopup.net, a także wpis usługi Service Directory obejmujący nazwę punktu końcowego konsumenta.

Zaletą automatycznego DNS jest to, w którym miejscu (4) użytkownik może komunikować się z punktem końcowym konsumenta za pomocą DNS o nazwie FQDN stargazer.cosmopup.net.

Rysunek 1.

Czego się nauczysz

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

Czego potrzebujesz

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

2. Zanim zaczniesz

Zaktualizuj projekt, aby obsługiwał ćwiczenia z programowania

W tym ćwiczeniach z programowania korzystamy ze zmiennych $variables, 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 producenta

Tworzenie producenta VPC

W Cloud Shell wykonaj te czynności:

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

Tworzenie 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

Wyświetlanie przydzielonego adresu IP

Użyj polecenia „Compute addressesdescription” (podaj adresy IP), aby wyświetlić przydzielony adres IP.

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

Tworzenie regionalnych podsieci serwera proxy

Przydział serwera proxy jest na poziomie sieci VPC, a nie systemu równoważenia obciążenia. Musisz utworzyć 1 podsieć tylko-proxy w każdym regionie sieci wirtualnej (VPC), w którym używasz systemów równoważenia obciążenia opartych na Envoy. Jeśli wdrażasz wiele systemów równoważenia obciążenia w tym samym regionie i tej samej sieci VPC, na potrzeby równoważenia obciążenia będą one współdzielić tę samą podsieć tylko-proxy.

Klient nawiązuje połączenie z adresem IP i portem reguły przekierowania systemu równoważenia obciążenia.
Każdy serwer proxy nasłuchuje pod adresem IP i portem określonych przez odpowiednią regułę przekierowania systemu równoważenia obciążenia. Jeden z serwerów proxy odbiera i kończy połączenie sieciowe klienta.
Serwer proxy nawiązuje połączenie z odpowiednią maszyną wirtualną backendu określona przez mapę URL i usługi backendu systemu równoważenia obciążenia.

Podsieci tylko-proxy musisz utworzyć niezależnie od tego, czy sieć VPC działa w trybie automatycznym, czy w trybie niestandardowym. Podsieć tylko-proxy musi zawierać co najmniej 64 adresy IP. Odpowiada to długości prefiksu wynoszącej /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 usługi Private Service Connect

Utwórz co najmniej 1 dedykowaną podsieć do użycia z usługą Private Service Connect. Jeśli publikujesz usługę w konsoli Google Cloud, możesz podczas tej procedury utworzyć podsieci. 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 między podsiecią Private Service Connect NAT a podsiecią tylko serwera proxy wewnętrznego systemu równoważenia obciążenia.

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, aby umożliwić kontrolom stanu Google Cloud dotarcie 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łę zezwalającą na ruch przychodzący dla podsieci tylko-proxy, aby umożliwić systemowi równoważenia obciążenia komunikowanie się 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 Cloud Router i NAT

Usługa Cloud NAT jest używana w ramach ćwiczeń w Codelabs do instalowania pakietów oprogramowania, ponieważ instancja maszyny wirtualnej nie ma zewnętrznego adresu IP.

Utwórz router Cloud Router w Cloud Shell.

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

Utwórz w Cloud Shell 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 tej sekcji utworzysz instancję Compute Engine niezarządzana grupa instancji. W późniejszych krokach grupa instancji będzie używana jako usługa backendu systemu równoważenia obciążenia.

Utwórz w Cloud Shell regionalną kontrolę stanu przekazaną 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"

Utwórz niezarządzaną grupę instancji w 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

Konfigurowanie systemu równoważenia obciążenia

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

Utwórz regionalną kontrolę stanu w Cloud Shell.

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

Utwórz w Cloud Shell 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

Utwórz w Cloud Shell mapę adresów URL, aby kierować żądania przychodzące 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. Nie używaj podsieci tylko-proxy do tworzenia reguły przekierowania.

 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. Zwróć uwagę na pomyślną kontrolę stanu dla usługi backendu

Wybranie opcji l7-ilb-map spowoduje wyświetlenie adresu IP frontendu, który powinien być zgodny z adresem IP zarejestrowanym w poprzednim kroku. Będzie on też wskazywać usługę backendu.

5. Utwórz przyłącze usługi Private Service Connect

Tworzenie przyłącza usługi

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

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 korzystasz ze 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.

Wybierz Network Services → Private Service Connect, aby wyświetlić nowo utworzone przyłącze usługi

Wybranie opcji published-service spowoduje wyświetlenie bardziej szczegółowych informacji, w tym identyfikatora URI przyłącza usługi używanego przez konsumenta do nawiązania prywatnego połączenia usługi, nazwę domeny.

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

projects/<nazwa projektu>/regions/us-central1/serviceAttachments/published-service

6. Konfiguracja dla klientów indywidualnych

Włączanie interfejsów API dla klientów indywidualnych

W Cloud powłoka wykonuje te czynności:

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

Tworzenie sieci VPC dla klientów indywidualnych

W Cloud Shell wykonaj te czynności:

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

Tworzenie podsieci klienta

Utwórz w Cloud Shell 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

Utwórz w Cloud Shell 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

Tworzenie punktu końcowego konsumenta (reguła przekierowania)

Utwórz w Cloud Shell statyczny adres IP, który będzie używany na potrzeby punktu końcowego konsumenta.

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

Do utworzenia punktu końcowego konsumenta używamy wcześniej wygenerowanego identyfikatora URI przyłącza usługi.

Utwórz w Cloud Shell 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. Weryfikowanie połączenia w sieci VPC konsumenta

Z sieci VPC konsumenta sprawdź poprawność połączenia prywatnego, przechodząc do Network Services → Private Service Connect → Połączone punkty końcowe. Zwróć uwagę na nawiązane połączenie z obserwatorem gwiazd i odpowiadający mu adres IP, który utworzyliśmy wcześniej.

W przypadku wybrania opcji psc-consumer-1 podawane są szczegóły, w tym identyfikator URI przyłącza usługi

8. Zweryfikuj połączenie w sieci VPC producenta

Z sieci VPC producenta sprawdź, czy prywatne połączenie usługi jest udane, przechodząc do Network Services → Private Service Connect → Opublikowano usługę. Uwaga: opublikowane połączenie z usługą wskazuje teraz 1 regułę przekierowania (punkt końcowy połączenia).

9. Weryfikowanie automatycznej konfiguracji DNS

Oceńmy konfigurację DNS i Katalogu usług.

Konfiguracja Cloud DNS

Wybierz Usługi sieciowe → Cloud DNS → Strefy. Strefa goog-psc-default-us-central & nazwa DNS cosmopup.net. jest generowana automatycznie.

Wyświetlanie konfiguracji DNS i Katalogu usług

Dzięki nazwie strefy możemy zobaczyć, jak usługa Service Directory jest zintegrowana z Cloud DNS.

Konfiguracja Service Directory

Wybierz Usługi sieciowe → Katalog usług.

Czy przywrócić nazwę punktu końcowego konsumenta „stargazer”? Jest on automatycznie zaprogramowany w katalogu usług, co pozwala nam docierać do punktu końcowego klienta przy użyciu pełnej i jednoznacznej nazwy domeny stargazer.goog-psc-default–us-central1

10. Weryfikowanie dostępu konsumentów do usługi Produces

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

Utwórz w Cloud Shell instancję testową w VPC konsumenta.

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 nawiązywanie połączeń z maszynami wirtualnymi, utwórz regułę zapory sieciowej, która:

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

Utwórz w Cloud Shell 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ę do konsumenta maszyny wirtualnej za pomocą IAP w Cloud Shell, aby zweryfikować połączenie z usługą producenta przez curl. W przypadku przekroczenia limitu czasu spróbuj ponownie.

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

Wykonaj curl, aby zweryfikować połączenie z usługą producenta. Po sprawdzeniu wyjścia z maszyny wirtualnej powrót do promptu Cloud Shell

W Cloud Shell zwijaj pliki w obrębie własnej domeny, na przykład stargazer.[domena-niestandardowa.com]. W poniższych danych wyjściowych wykonywane jest skręcenie pliku 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 !!

Aby rozpocząć zadania czyszczenia, wyjdź z maszyny wirtualnej powracającej do promptu Cloud Shell

11. Czyszczenie danych

Usuń komponenty ćwiczeń z programowania 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

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

Udało Ci się utworzyć infrastrukturę producenta i dodać przyłącze usługi z rejestracją domeny publicznej. Wiesz już, jak utworzyć w sieci VPC konsumenta punkt końcowy, który umożliwi połączenie z usługą lokalną za pomocą automatycznie wygenerowanego DNS.

Private Service Connect z automatyczną konfiguracją DNS

1. Wprowadzenie

Co utworzysz

Czego się nauczysz

Czego potrzebujesz

2. Zanim zaczniesz

Zaktualizuj projekt, aby obsługiwał ćwiczenia z programowania

3. Konfiguracja producenta

Tworzenie producenta VPC

Tworzenie podsieci producenta

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

Wyświetlanie przydzielonego adresu IP

Użyj polecenia „Compute addressesdescription” (podaj adresy IP), aby wyświetlić przydzielony adres IP.

Tworzenie regionalnych podsieci serwera proxy

Tworzenie podsieci NAT usługi Private Service Connect

Tworzenie reguł zapory sieciowej producenta

Konfiguracja Cloud Router i NAT

Konfiguracja grupy instancji

Konfigurowanie systemu równoważenia obciążenia

4. Weryfikowanie systemu równoważenia obciążenia

5. Utwórz przyłącze usługi Private Service Connect

Tworzenie przyłącza usługi

6. Konfiguracja dla klientów indywidualnych

Włączanie interfejsów API dla klientów indywidualnych

Tworzenie sieci VPC dla klientów indywidualnych

Tworzenie podsieci klienta

Tworzenie punktu końcowego konsumenta (reguła przekierowania)

7. Weryfikowanie połączenia w sieci VPC konsumenta

8. Zweryfikuj połączenie w sieci VPC producenta

9. Weryfikowanie automatycznej konfiguracji DNS

10. Weryfikowanie dostępu konsumentów do usługi Produces

11. Czyszczenie danych

12. Gratulacje

Co dalej?

Więcej informacji filmy,

Dokumentacja