Łącz się z usługami lokalnymi przez sieć hybrydową z użyciem usługi Private Service Connect i hybrydowej grupy punktów końcowych sieci z wewnętrznym systemem równoważenia obciążenia HTTP(s)

1. Wprowadzenie

Cloud Load Balancing obsługuje równoważenie obciążenia ruchem do punktów końcowych, które wykraczają poza Google Cloud, takich jak lokalne centra danych i inne chmury publiczne, do których można dotrzeć za pomocą połączenia hybrydowego.

Strategia hybrydowa to praktyczne rozwiązanie, które pozwala dostosowywać się do zmieniających się wymagań rynku i stopniowo modernizować aplikacje. Może to być tymczasowe wdrożenie hybrydowe, które umożliwi migrację do nowoczesnego rozwiązania działającego w chmurze, lub stały element infrastruktury informatycznej organizacji.

Konfigurowanie hybrydowego równoważenia obciążenia umożliwia też korzystanie z zalet funkcji sieciowych Cloud Load Balancing w przypadku usług działających w infrastrukturze poza Google Cloud.

Jeśli chcesz udostępnić usługę hybrydową w innych sieciach VPC, możesz użyć Private Service Connect do opublikowania usługi. Umieszczając przyłącze usługi przed wewnętrznym regionalnym systemem równoważenia obciążenia HTTP(S),możesz umożliwić klientom z innych sieci VPC dostęp do usług hybrydowych działających w środowiskach lokalnych lub innych środowiskach chmurowych.

Co utworzysz

W tym ćwiczeniu utworzysz wewnętrzny system równoważenia obciążenia HTTP(S) z połączeniem hybrydowym z usługą lokalną za pomocą grupy punktów końcowych sieci. Sieć VPC klienta będzie mogła komunikować się z usługą lokalną za pomocą portów 80. Port 443 nie jest objęty zakresem tego ćwiczenia.

Czego się nauczysz

Jak utworzyć wewnętrzny system równoważenia obciążenia HTTP(S) z backendem w postaci hybrydowej grupy punktów końcowych sieci
Jak utworzyć producenta usługi Private Service Connect (przyłącze usługi) i konsumenta (regułę przekierowania)

Czego potrzebujesz

Ustanowione sieci hybrydowe, np.sieć VPN o wysokiej dostępności, Interconnect, SW-WAN
Projekt Google Cloud

Nawiązywanie połączeń hybrydowych

Środowiska Google Cloud oraz lokalne lub inne środowiska chmurowe muszą być połączone za pomocą połączenia hybrydowego, które wykorzystuje przyłącza VLAN Cloud Interconnect lub tunele Cloud VPN z routerem Cloud Router. Zalecamy używanie połączenia o wysokiej dostępności.

Router Cloud Router z włączonym globalnym routingiem dynamicznym dowiaduje się o konkretnym punkcie końcowym za pomocą protokołu BGP i programuje go w sieci VPC w Google Cloud. Regionalne dynamiczne przekierowywanie nie jest obsługiwane. Trasy statyczne również nie są obsługiwane.

Sieć VPC Google Cloud, której używasz do konfigurowania Cloud Interconnect lub Cloud VPN, jest tą samą siecią, której używasz do konfigurowania wdrożenia hybrydowego równoważenia obciążenia. Sprawdź, czy zakresy CIDR podsieci sieci VPC nie powodują konfliktu z zakresami CIDR sieci zdalnych. Gdy adresy IP pokrywają się, trasy podsieci mają wyższy priorytet niż połączenia zdalne.

Instrukcje znajdziesz poniżej:

Niestandardowe rozgłaszanie tras

Podsieci poniżej wymagają niestandardowego rozgłaszania z routera Cloud Router do sieci lokalnej, co zapewnia aktualizację reguł zapory sieciowej w sieci lokalnej.

Podsieć	Opis
172.16.0.0/23	Podsieć proxy używana do bezpośredniej komunikacji z usługą lokalną.
130.211.0.0/22, 35.191.0.0/16	Google Cloud Health Check

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]
psclab=YOUR-PROJECT-NAME
echo $psclab

3. Konfiguracja aplikacji Producer

Utwórz sieć VPC producenta

W Cloud Shell wykonaj te czynności:

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

Utwórz podsieci producenta

W Cloud Shell wykonaj te czynności:

gcloud compute networks subnets create subnet-201 --project=$psclab --range=10.10.1.0/24 --network=producer-vpc --region=us-central1

gcloud compute networks subnets create subnet-202 --project=$psclab --range=10.20.1.0/24 --network=producer-vpc --region=us-central1

Rezerwowanie adresu IP dla wewnętrznego systemu równoważenia obciążenia

W Cloud Shell wykonaj te czynności. Używanie SHARED_VIP nie jest obsługiwane w przypadku usługi Private Service Connect. Zamiast tego użyj GCE_ENDPOINT.

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

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 podsieci regionalnego serwera 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.

Klient nawiązuje połączenie z adresem IP i portem reguły przekierowania systemu równoważenia obciążenia.
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.
Serwer proxy nawiązuje połączenie z odpowiednią maszyną wirtualną backendu lub punktem końcowym w grupie NEG, zgodnie z mapą URL i usługami backendu systemu równoważenia obciążenia.

Podsieci tylko-proxy musisz utworzyć niezależnie od tego, czy Twoja sieć jest 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 --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 punktami końcowymi Private Service Connect a przyłączem usługi. W tym ćwiczeniu utworzono regułę zapory sieciowej ruchu przychodzącego, która zezwala podsieci NAT 100.100.10.0/24 na dostęp do przyłącza usługi Private Service Connect (wewnętrznego systemu równoważenia obciążenia).

W Cloud Shell wykonaj te czynności:

gcloud compute --project=$psclab 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łę fw-allow-health-check, która umożliwi kontroli stanu Google Cloud dotarcie do usługi lokalnej (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łę zapory sieciowej zezwalającą na ruch przychodzący 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

Konfigurowanie grupy punktów końcowych sieci z hybrydową łącznością

Podczas tworzenia sieciowego punktu końcowego użyj STREFY,która minimalizuje odległość geograficzną między Google Cloud a Twoim środowiskiem lokalnym lub innym środowiskiem Cloud. Jeśli na przykład hostujesz usługę w środowisku lokalnym we Frankfurcie w Niemczech, podczas tworzenia sieci NEG możesz określić strefę Google Cloud europe-west3-a.

Jeśli korzystasz z usługi Cloud Interconnect, STREFA użyta do utworzenia NEG powinna znajdować się w tym samym regionie, w którym skonfigurowano przyłącze połączenia międzysieciowego Cloud Interconnect.

Listę dostępnych regionów i stref znajdziesz w dokumentacji Compute Engine: dostępne regiony i strefy.

W Cloud Shell utwórz grupę punktów końcowych sieci połączonych hybrydowo za pomocą polecenia gcloud compute network-endpoint-groups create.

gcloud compute network-endpoint-groups create on-prem-service-neg \
    --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
    --zone=us-central1-a \
    --network=producer-vpc

W Cloud Shell dodaj lokalny punkt końcowy IP:Port do hybrydowej grupy punktów końcowych sieci.

gcloud compute network-endpoint-groups update on-prem-service-neg \
    --zone=us-central1-a \
    --add-endpoint="ip=192.168.1.5,port=80"

Konfigurowanie systemu równoważenia obciążenia

W tych krokach skonfigurujesz system równoważenia obciążenia (regułę przekierowania) i powiążesz go z grupą punktów końcowych sieci.

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

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

W Cloud Shell utwórz usługę backendu dla lokalnego backendu korzystającego z hybrydowej grupy NEG.

 gcloud compute backend-services create on-premise-service-backend \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --protocol=HTTP \
      --health-checks=http-health-check \
      --health-checks-region=us-central1 \
      --region=us-central1

W Cloud Shell dodaj backend hybrydowej grupy NEG do usługi backendu. W przypadku parametru RATE wpisz maksymalną wartość RATE, jaką powinien obsługiwać backend.

gcloud compute backend-services add-backend on-premise-service-backend \
    --region=us-central1 \
    --balancing-mode=RATE \
    --max-rate-per-endpoint=100 \
    --network-endpoint-group=on-prem-service-neg \
    --network-endpoint-group-zone=us-central1-a

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

gcloud compute url-maps create on-prem-svc-url-map \
    --default-service on-premise-service-backend \
    --region=us-central1

Utwórz docelowy serwer proxy HTTP

gcloud compute target-http-proxies create proxy-subnet-us-central\
    --url-map=on-prem-svc-url-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 http-hybrid-neg-fwd-rule \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=producer-vpc \
      --subnet=subnet-202 \
      --address=lb-ip \
      --ports=80 \
      --region=us-central1 \
      --target-http-proxy=proxy-subnet-us-central \
      --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ę, że wartość 1 NEG jest „zielona”, co oznacza, że test stanu usługi lokalnej został przeprowadzony pomyślnie.

Wybranie opcji ‘on-premise-svc-url-map' powoduje wyświetlenie adresu IP frontendu i identyfikację usługi backendu.

5. Wyświetlanie zapamiętanych tras z lokalnego środowiska

Otwórz Sieć VPC → Trasy. Zwróć uwagę na podsieć usługi lokalnej 192.168.1.0/27.

6. Sprawdzanie połączenia z usługą lokalną

W sieci VPC producentów utworzymy maszynę wirtualną, aby przetestować połączenie z usługą lokalną. Następnie skonfigurujemy przyłącze usługi.

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

gcloud compute instances create test-box-us-central1 \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-201 \
    --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 instancję testową w sieci VPC producenta.

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

Zaloguj się w Cloud Shell na test-box-us-central1 za pomocą IAP, aby sprawdzić łączność z usługą lokalną, wykonując polecenie curl względem adresu IP systemu równoważenia obciążenia. Ponów próbę, jeśli nastąpi przekroczenie limitu czasu.

gcloud compute ssh test-box-us-central1 --project=$psclab --zone=us-central1-a --tunnel-through-iap

Wykonaj polecenie curl, aby sprawdzić połączenie z usługą lokalną. Po zweryfikowaniu zamknij maszynę wirtualną i wróć do wiersza poleceń Cloud Shell. Zastąp adres IP wewnętrznego systemu równoważenia obciążenia adresem IP z danych wyjściowych z kroku 4.

user@test-box-us-central1:~$ curl -v 10.20.1.2
* Expire in 0 ms for 6 (transfer 0x55b7725c10f0)
*   Trying 10.20.1.2...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b7725c10f0)
* Connected to 10.20.1.2 (10.20.1.2) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.20.1.2
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< content-type: text/html; charset=utf-8
< accept-ranges: bytes
< etag: "3380914763"
< last-modified: Mon, 05 Dec 2022 15:10:56 GMT
< expires: Mon, 12 Dec 2022 03:17:20 GMT
< cache-control: max-age=0
< content-length: 37
< date: Mon, 12 Dec 2022 03:17:20 GMT
< server: lighttpd/1.4.53
< via: 1.1 google
< 
Welcome to my on-premise service!!

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

W kolejnych krokach utworzymy przyłącze usługi. Po sparowaniu go z punktem końcowym konsumenta uzyskamy dostęp do usługi lokalnej bez konieczności korzystania z połączenia równorzędnego VPC.

Utwórz połączenie z usługą

W Cloud Shell utwórz połączenie z usługą.

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=http-hybrid-neg-fwd-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet

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

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=http-hybrid-neg-fwd-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/<region>/subnetworks/<natsubnet>

Weryfikowanie załącznika usługi TCP

gcloud compute service-attachments describe service-1 --region us-central1

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

Kliknięcie Service-1 spowoduje wyświetlenie większej liczby szczegółów, w tym identyfikatora URI przyłącza usługi używanego przez konsumenta do nawiązania połączenia Private Service Connection. Zapisz URI, ponieważ będzie on potrzebny w dalszym kroku.

Szczegóły przyłącza usługi: projects/<projectname>/regions/us-central1/serviceAttachments/service-1

8. Konfiguracja konsumencka

Tworzenie sieci VPC konsumenta

W Cloud Shell wykonaj te czynności:

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

Tworzenie podsieci konsumenta

W Cloud Shell utwórz podsieć GCE.

gcloud compute networks subnets create subnet-101 --project=$psclab --range=10.100.1.0/24 --network=consumer-vpc --region=us-central1

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

gcloud compute networks subnets create subnet-102 --project=$psclab --range=10.100.2.0/24 --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 jako punkt końcowy klienta.

gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10

Użyjmy wygenerowanego wcześniej identyfikatora URI przyłącza usługi, aby utworzyć punkt końcowy klienta.

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

gcloud compute forwarding-rules create psc-consumer-1 --region=us-central1 --network=consumer-vpc --address=psc-consumer-ip-1 --target-service-attachment=projects/$psclab/regions/us-central1/serviceAttachments/service-1

9. Weryfikacja usługi Private Service Connect konsumenta – sieć VPC konsumenta

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 psc-consumer-1 i odpowiadający mu adres IP.

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

10. Weryfikowanie usługi Private Service Connect konsumenta – sieć 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 połączenie opublikowanej usługi 1 wskazuje teraz 1 regułę przekierowania (punkt końcowy połączenia).

11. Tworzenie prywatnej strefy DNS i rekordu A

Utwórz prywatną strefę DNS mapowaną na punkt końcowy połączenia PSC, aby umożliwić bezproblemowy dostęp do usługi producenta z dowolnego hosta w sieci VPC.

Z Cloud Shell

gcloud dns --project=$psclab managed-zones create codelab-zone --description="" --dns-name="codelab.net." --visibility="private" --networks="consumer-vpc"

gcloud dns --project=$psclab record-sets create service1.codelab.net. --zone="codelab-zone" --type="A" --ttl="300" --rrdatas="10.100.2.10"

12. Sprawdzanie dostępu konsumenta do usługi producenta za pomocą maszyny wirtualnej

W sieci VPC konsumentów utworzymy maszynę wirtualną, aby przetestować połączenie z usługą lokalną, uzyskując dostęp do punktu końcowego konsumenta service1.codelabs.net.

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

gcloud compute instances create consumer-vm \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-101 \
    --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 instancję testową w sieci VPC klienta.

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

Zaloguj się na maszynie wirtualnej consumer-vm za pomocą IAP w Cloud Shell, aby sprawdzić połączenie z usługą lokalną, wykonując polecenie curl względem usługi DNS FQDN service1.codelab.net. Jeśli wystąpi przekroczenie limitu czasu, spróbuj ponownie.

gcloud compute ssh consumer-vm --project=$psclab --zone=us-central1-a --tunnel-through-iap

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

W Cloud Shell wykonaj polecenie curl.

$ curl -v service1.codelab.net
*   Trying 10.100.2.10...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5650fc3390f0)
* Connected to service1.codelab.net (10.100.2.10) port 80 (#0)
> GET / HTTP/1.1
> Host: service1.codelab.net
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Accept-Ranges: bytes
< ETag: "3380914763"
< Last-Modified: Mon, 05 Dec 2022 15:10:56 GMT
< Expires: Mon, 05 Dec 2022 15:15:41 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:15:41 GMT
< Server: lighttpd/1.4.53
< 
Welcome to my on-premise service!!

Poniżej znajduje się przykładowy zrzut z usługi lokalnej. Zwróć uwagę, że adres IP źródła 172.16.0.13 pochodzi z zakresu podsieci serwera proxy 172.16.0.0/23.

13. Zwalnianie miejsca w aplikacji Producer

Usuwanie komponentów Producer

W Cloud Shell usuń instancje testowe w sieci VPC producenta.

gcloud compute instances delete test-box-us-central1 --zone=us-central1-a --quiet

gcloud compute service-attachments delete service-1 --region=us-central1 --quiet 

gcloud compute forwarding-rules delete http-hybrid-neg-fwd-rule --region=us-central1 --quiet

gcloud compute target-http-proxies delete proxy-subnet-us-central --region=us-central1 --quiet

gcloud compute url-maps delete on-prem-svc-url-map --region=us-central1 --quiet

gcloud compute backend-services delete on-premise-service-backend --region=us-central1 --quiet

gcloud compute network-endpoint-groups delete on-prem-service-neg --zone=us-central1-a --quiet

gcloud compute addresses delete lb-ip --region=us-central1 --quiet

gcloud compute networks subnets delete psc-nat-subnet subnet-201 subnet-202 proxy-subnet-us-central --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap fw-allow-proxy-only-subnet allow-to-ingress-nat-subnet fw-allow-health-check --quiet

gcloud compute health-checks delete http-health-check --region=us-central1 --quiet

gcloud compute networks delete producer-vpc --quiet

14. Zwalnianie miejsca na dane konsumenta

Usuwanie komponentów konsumenta

W Cloud Shell usuń instancje testowe w sieci VPC konsumenta.

gcloud compute instances delete consumer-vm --zone=us-central1-a --quiet

gcloud compute forwarding-rules delete psc-consumer-1 --region=us-central1 --quiet

gcloud compute addresses delete psc-consumer-ip-1 --region=us-central1 --quiet

gcloud compute networks subnets delete subnet-101 subnet-102 --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap-consumer --quiet

gcloud dns record-sets delete service1.codelab.net --type=A --zone=codelab-zone --quiet

gcloud dns managed-zones delete codelab-zone --quiet 

gcloud compute networks delete consumer-vpc --quiet

15. Gratulacje

Gratulacje. Udało Ci się skonfigurować i zweryfikować usługę Private Service Connect z wewnętrznym systemem równoważenia obciążenia HTTP(S).

Infrastruktura producenta została utworzona, a w sieci VPC producenta dodano przyłącze usługi wskazujące usługę lokalną. Dowiedzieliśmy się, jak utworzyć punkt końcowy konsumenta w sieci VPC konsumenta, który umożliwia połączenie z usługą lokalną.

Co dalej?

Sprawdź te ćwiczenia z programowania:

Łącz się z usługami lokalnymi przez sieć hybrydową z użyciem usługi Private Service Connect i hybrydowej grupy punktów końcowych sieci z wewnętrznym systemem równoważenia obciążenia HTTP(s)

1. Wprowadzenie

Co utworzysz

Czego się nauczysz

Czego potrzebujesz

Nawiązywanie połączeń hybrydowych

Niestandardowe rozgłaszanie tras

2. Zanim zaczniesz

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

3. Konfiguracja aplikacji Producer

Utwórz sieć VPC producenta

Utwórz podsieci producenta

Rezerwowanie adresu IP dla wewnętrznego systemu równoważenia obciążenia

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

Utwórz podsieci regionalnego serwera proxy

Tworzenie podsieci NAT Private Service Connect

Tworzenie reguł zapory sieciowej producenta

Konfigurowanie grupy punktów końcowych sieci z hybrydową łącznością

Konfigurowanie systemu równoważenia obciążenia

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

5. Wyświetlanie zapamiętanych tras z lokalnego środowiska

6. Sprawdzanie połączenia z usługą lokalną

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

Utwórz połączenie z usługą

8. Konfiguracja konsumencka

Tworzenie sieci VPC konsumenta

Tworzenie podsieci konsumenta

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

9. Weryfikacja usługi Private Service Connect konsumenta – sieć VPC konsumenta

10. Weryfikowanie usługi Private Service Connect konsumenta – sieć VPC producenta

11. Tworzenie prywatnej strefy DNS i rekordu A

12. Sprawdzanie dostępu konsumenta do usługi producenta za pomocą maszyny wirtualnej

Poniżej znajduje się przykładowy zrzut z usługi lokalnej. Zwróć uwagę, że adres IP źródła 172.16.0.13 pochodzi z zakresu podsieci serwera proxy 172.16.0.0/23.

13. Zwalnianie miejsca w aplikacji Producer

Usuwanie komponentów Producer

14. Zwalnianie miejsca na dane konsumenta

Usuwanie komponentów konsumenta

15. Gratulacje

Co dalej?

Więcej informacji i filmy

Dokumentacja