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

Zewnętrzny system równoważenia obciążenia HTTPs z zaawansowanymi funkcjami zarządzania ruchem (Envoy) z programowania

1. Wprowadzenie

Witamy w zewnętrznym systemie równoważenia obciążenia HTTP z zaawansowanym zarządzaniem ruchem (Envoy).

Najnowsza wersja zewnętrznego systemu równoważenia obciążenia HTTP(S) z zaawansowanym zarządzaniem ruchem zawiera wszystkie funkcje naszego klasycznego globalnego zewnętrznego systemu równoważenia obciążenia HTTP(S), ale zawiera też stale rosnącą listę funkcji zaawansowanego zarządzania ruchem. Niektóre z tych funkcji są nowe w naszych systemach równoważenia obciążenia, a niektóre zapewniają rozszerzone funkcje dotychczasowych. Częściowa lista tych funkcji obejmuje:

Czego się nauczysz

Jak skonfigurować zarządzaną grupę instancji i powiązane reguły VPC i zapory sieciowej
Jak korzystać z zaawansowanych funkcji zarządzania ruchem w nowym systemie równoważenia obciążenia
Jak sprawdzić, czy zaawansowane funkcje zarządzania ruchem działają zgodnie z oczekiwaniami.

Czego potrzebujesz

Podstawowa znajomość sieci i znajomości protokołu HTTP
Podstawowa wiedza na temat wiersza poleceń systemu Unix/Linux.

Topologia ćwiczeń z programowania przypadek użycia

Rysunek 1. Topologia routingu systemu równoważenia obciążenia HTTP

W trakcie tego modułu dotyczącego kodu skonfigurujesz 3 zarządzane grupy instancji – 1 na wschodzie, zachodzie i centralnie. Utworzysz globalny zewnętrzny system równoważenia obciążenia HTTPS. System równoważenia obciążenia będzie wykorzystywać kilka funkcji z listy zaawansowanych możliwości obsługiwanych przez system równoważenia obciążenia oparty na envoy. Po wdrożeniu wygenerujesz symulowane obciążenie i sprawdzisz, czy ustawione przez Ciebie konfiguracje działają prawidłowo.

2. Konfiguracja i wymagania

Samodzielne konfigurowanie środowiska

Zaloguj się w konsoli Google Cloud i utwórz nowy projekt lub wykorzystaj już istniejący. Jeśli nie masz jeszcze konta Gmail ani Google Workspace, musisz je utworzyć.

Nazwa projektu jest wyświetlaną nazwą uczestników tego projektu. To ciąg znaków, który nie jest używany przez interfejsy API Google i w każdej chwili możesz go zaktualizować.
Identyfikator projektu musi być unikalny we wszystkich projektach Google Cloud i nie można go zmienić (nie można go zmienić po ustawieniu). Cloud Console automatycznie wygeneruje unikalny ciąg znaków. zwykle nieważne, co ona jest. W większości ćwiczeń w Codelabs musisz odwoływać się do identyfikatora projektu (który zwykle nazywa się PROJECT_ID), więc jeśli Ci się nie podoba, wygeneruj kolejny losowy projekt lub wypróbuj swój własny identyfikator i sprawdź, czy jest dostępny. Potem urządzenie jest „zawieszone”. po utworzeniu projektu.
Występuje trzecia wartość – numer projektu – używany przez niektóre interfejsy API. Więcej informacji o wszystkich 3 wartościach znajdziesz w dokumentacji.

Następnie musisz włączyć płatności w konsoli Cloud, aby móc korzystać z zasobów i interfejsów API Cloud. Ukończenie tego ćwiczenia z programowania nie powinno kosztować zbyt wiele. Aby wyłączyć zasoby, aby nie naliczać opłat po zakończeniu tego samouczka, wykonaj czynności „wyczyść” znajdziesz na końcu tego ćwiczenia. Nowi użytkownicy Google Cloud mogą skorzystać z programu bezpłatnego okresu próbnego o wartości 300 USD.

Uruchamianie Cloud Shell

Google Cloud można obsługiwać zdalnie z laptopa, ale w ramach tego ćwiczenia z programowania wykorzystasz Google Cloud Shell – środowisko wiersza poleceń działające w chmurze.

W konsoli GCP kliknij ikonę Cloud Shell na górnym pasku narzędzi:

Uzyskanie dostępu do środowiska i połączenie się z nim powinno zająć tylko kilka chwil. Po zakończeniu powinno pojawić się coś takiego:

Ta maszyna wirtualna ma wszystkie potrzebne narzędzia dla programistów. Zawiera stały katalog domowy o pojemności 5 GB i działa w Google Cloud, znacząco zwiększając wydajność sieci i uwierzytelnianie. Wszystkie zadania w tym module możesz wykonać w przeglądarce.

Zanim zaczniesz

Sprawdź w Cloud Shell, czy identyfikator projektu jest skonfigurowany

gcloud config list project

gcloud config set project [NAZWA-TWOJEGO-PROJEKTU]

PROJECT_ID=[YOUR-PROJECT-NAME]

echo $IDENTYFIKATOR_PROJEKTU

włączyć interfejsy API,

Włącz wszystkie niezbędne usługi

gcloud services enable compute.googleapis.com
gcloud services enable logging.googleapis.com
gcloud services enable monitoring.googleapis.com

3. Tworzenie sieci VPC

Tworzenie sieci VPC

Z Cloud Shell

gcloud compute networks create httplbs --subnet-mode=auto

Wyniki

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/httplbs].
NAME: httplbs
SUBNET_MODE: AUTO
BGP_ROUTING_MODE: REGIONAL
IPV4_RANGE:
GATEWAY_IPV4:

Tworzenie reguł zapory sieciowej VPC

Po utworzeniu sieci VPC utworzysz reguły zapory sieciowej. Reguła zapory sieciowej będzie używana do zezwalania wszystkim adresom IP na dostęp do zewnętrznego adresu IP witryny testowej na porcie 80 w przypadku ruchu HTTP.

Z Cloud Shell

gcloud compute firewall-rules create httplb-allow-http-rule \
--allow tcp:80 \
--network httplbs \
--source-ranges 0.0.0.0/0 \
--priority 700

Wyniki

Creating firewall...working..Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls/httplb-allow-http-rule].
Creating firewall...done.
NAME: httplb-allow-http-rule
NETWORK: httplbs
DIRECTION: INGRESS
PRIORITY: 700
ALLOW: tcp:80
DENY:
DISABLED: False

4. Konfigurowanie zarządzanych grup instancji

Musisz skonfigurować zarządzane grupy instancji, które zawierają wzorce zasobów backendu używanych przez system równoważenia obciążenia HTTP. Najpierw utworzymy szablony instancji, które definiują konfigurację maszyn wirtualnych do tworzenia w każdym regionie. Następnie dla backendu w każdym regionie utworzymy zarządzaną grupę instancji, która odwołuje się do szablonu instancji.

Zarządzane grupy instancji mogą mieć zakres strefowy lub regionalny. W tym ćwiczeniu utworzymy 3 regionalne zarządzane grupy instancji – jedną w us-east1, jedną w us-west1 i jedną w us-central1.

W tej sekcji możesz zobaczyć utworzony wcześniej skrypt startowy, do którego odwołamy się podczas tworzenia instancji. Ten skrypt startowy instaluje i włącza funkcje serwera WWW, które posłużą do symulowania aplikacji internetowej. Możesz swobodnie zapoznać się z tym skryptem.

Tworzenie szablonów instancji wschodnich, zachodnich i centralnych

Pierwszym krokiem jest utworzenie szablonu instancji us-east-1.

Z Cloud Shell

gcloud compute instance-templates create us-east1-template \
   --region=us-east1 \
   --network=httplbs \
   --tags=http-server, \
   --image-family=debian-9 \
   --image-project=debian-cloud \
   --metadata=startup-script='#! /bin/bash
     apt-get update
     apt-get install apache2 -y
     a2ensite default-ssl
     a2enmod ssl
     vm_hostname="$(curl -H "Metadata-Flavor:Google" \
     http://169.254.169.254/computeMetadata/v1/instance/name)"
     echo "Page served from: $vm_hostname" | \
     tee /var/www/html/index.html
     systemctl restart apache2'

Wyniki

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates/us-east1-template].
NAME: us-east1-template
MACHINE_TYPE: n1-standard-1
PREEMPTIBLE:
CREATION_TIMESTAMP: 2021-11-11T11:02:37.511-08:00

Następnym krokiem jest utworzenie szablonu instancji us-west-1.

Z Cloud Shell

gcloud compute instance-templates create us-west1-template \
   --region=us-west1 \
   --network=httplbs \
   --tags=http-server, \
   --image-family=debian-9 \
   --image-project=debian-cloud \
   --metadata=startup-script='#! /bin/bash
     apt-get update
     apt-get install apache2 -y
     a2ensite default-ssl
     a2enmod ssl
     vm_hostname="$(curl -H "Metadata-Flavor:Google" \
     http://169.254.169.254/computeMetadata/v1/instance/name)"
     echo "Page served from: $vm_hostname" | \
     tee /var/www/html/index.html
     systemctl restart apache2'

Wyniki

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates/us-west1-template].
NAME: us-west1-template
MACHINE_TYPE: n1-standard-1
PREEMPTIBLE:
CREATION_TIMESTAMP: 2021-11-11T11:03:08.577-08:00

Następnym krokiem jest utworzenie szablonu instancji us-central-1.

Z Cloud Shell

gcloud compute instance-templates create us-central1-template \
   --region=us-central1 \
   --network=httplbs \
   --tags=http-server, \
   --image-family=debian-9 \
   --image-project=debian-cloud \
   --metadata=startup-script='#! /bin/bash
     apt-get update
     apt-get install apache2 -y
     a2ensite default-ssl
     a2enmod ssl
     vm_hostname="$(curl -H "Metadata-Flavor:Google" \
     http://169.254.169.254/computeMetadata/v1/instance/name)"
     echo "Page served from: $vm_hostname" | \
     tee /var/www/html/index.html
     systemctl restart apache2'

Wyniki

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates/us-central1-template].
NAME: us-central1-template
MACHINE_TYPE: n1-standard-1
PREEMPTIBLE:
CREATION_TIMESTAMP: 2021-11-11T11:03:44.179-08:00

Teraz możesz sprawdzić, czy szablony instancji zostały utworzone, za pomocą tego polecenia gcloud:

Z Cloud Shell

gcloud compute instance-templates list

Wyniki

NAME                  MACHINE_TYPE   PREEMPTIBLE  CREATION_TIMESTAMP
us-central1-template   n1-standard-1         2021-11-09T09:25:37.263-08:00
us-east1-template      n1-standard-1         2021-11-09T09:24:35.275-08:00
us-west1-template      n1-standard-1         2021-11-09T09:25:08.016-08:00

Tworzenie zarządzanych grup instancji w kierunku wschodnim, zachodnim i centralnym

Teraz musimy utworzyć zarządzaną grupę instancji na podstawie utworzonych wcześniej szablonów instancji.

Z Cloud Shell

gcloud compute instance-groups managed create us-east1-mig \
--base-instance-name=us-east1-mig \
--size=1 \
--template=us-east1-template \
--zone=us-east1-b

Wyniki

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-east1-b/instanceGroupManagers/us-east1-mig].
NAME: us-east1-mig
LOCATION: us-east1-b
SCOPE: zone
BASE_INSTANCE_NAME: us-east1-mig
SIZE: 0
TARGET_SIZE: 1
INSTANCE_TEMPLATE: us-east1-template
AUTOSCALED: no

Z Cloud Shell

gcloud compute instance-groups managed create us-west1-mig \
--base-instance-name=us-west1-mig \
--size=1 \
--template=us-west1-template \
--zone=us-west1-a

Wyniki

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroupManagers/us-west1-mig].
NAME: us-west1-mig
LOCATION: us-west1-a
SCOPE: zone
BASE_INSTANCE_NAME: us-west1-mig
SIZE: 0
TARGET_SIZE: 1
INSTANCE_TEMPLATE: us-west1-template
AUTOSCALED: no

Z Cloud Shell

gcloud compute instance-groups managed create us-central1-mig \
--base-instance-name=us-central1-mig \
--size=1 \
--template=us-central1-template \
--zone=us-central1-a

Wyniki

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-central1-a/instanceGroupManagers/us-central1-mig].
NAME: us-central1-mig
LOCATION: us-central1-a
SCOPE: zone
BASE_INSTANCE_NAME: us-central1-mig
SIZE: 0
TARGET_SIZE: 1
INSTANCE_TEMPLATE: us-central1-template
AUTOSCALED: no

Możemy sprawdzić, czy grupy instancji zostały utworzone za pomocą tego polecenia gcloud:

Z Cloud Shell

gcloud compute instance-groups list

Wyniki

NAME                  LOCATION      SCOPE   NETWORK         MANAGED INSTANCES
us-central1-mig       us-central1   zone    httplbs          Yes      1
us-west1-mig          us-west1      zone    httplbs          Yes      1
us-east1-mig          us-east1      zone    httplbs          Yes      1

Sprawdzanie działania serwera WWW

Każda instancja jest skonfigurowana do uruchamiania serwera WWW Apache z prostym skryptem PHP renderującym:

Aby sprawdzić, czy Twoje serwery WWW działają poprawnie, otwórz Compute Engine -> Instancje maszyn wirtualnych. Sprawdź, czy nowe instancje (np. us-east1-mig-xxx) zostały utworzone zgodnie z definicjami grup instancji.

Wyślij do niej żądanie sieciowe, by sprawdzić, czy serwer WWW działa (uruchomienie może chwilę potrwać). Na stronie „Instancje maszyn wirtualnych” w sekcji Compute Engine wybierz instancję utworzoną przez Twoją grupę instancji i kliknij jej zewnętrzny (publiczny) adres IP.

Możesz też przejść w przeglądarce pod adres http://<adres_IP>

5. Konfigurowanie systemu równoważenia obciążenia

Tworzenie kontroli stanu

Najpierw musimy utworzyć podstawową kontrolę stanu, aby upewnić się, że nasze usługi działają prawidłowo. Tworzymy podstawową kontrolę stanu, dostępnych jest wiele bardziej zaawansowanych ustawień.

Z Cloud Shell

gcloud compute health-checks create http http-basic-check \
    --port 80

Zarezerwuj zewnętrzny adres IP

Aby to zrobić, zarezerwuj globalnie dostępny statyczny adres IP, który zostanie później podłączony do systemu równoważenia obciążenia.

Z Cloud Shell

gcloud compute addresses create lb-ipv4-2 \
    --ip-version=IPV4 \
    --global

Pamiętaj, aby zapisać zarezerwowany adres IP.

gcloud compute addresses describe lb-ipv4-2 \
    --format="get(address)" \
    --global

Tworzenie usług backendu

Teraz musimy utworzyć usługę backendu dla każdej z utworzonych wcześniej zarządzanych grup instancji. Jedna dla Wschodu, Zachodu i Środka.

Tworzę usługę backendu dla zarządzanej grupy instancji na wschód.

Z Cloud Shell

gcloud beta compute backend-services create east-backend-service \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --port-name=http \
    --health-checks=http-basic-check \
    --global

Tworzę usługę backendu dla zarządzanej grupy instancji na Zachodzie.

Z Cloud Shell

gcloud beta compute backend-services create west-backend-service \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --port-name=http \
    --health-checks=http-basic-check \
    --global

Tworzę usługę backendu dla centralnej zarządzanej grupy instancji.

Z Cloud Shell

gcloud beta compute backend-services create central-backend-service \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --port-name=http \
    --health-checks=http-basic-check \
    --global

Dodawanie zarządzanych grup instancji do usług backendu

Po utworzeniu odpowiednich usług backendu dla każdego klastra aplikacji musimy dodać utworzone wcześniej zarządzane grupy instancji do każdej usługi backendu.

Dodaj zarządzaną grupę instancji w regionie do usługi backendu.

Z Cloud Shell

gcloud beta compute backend-services add-backend east-backend-service \
    --balancing-mode='UTILIZATION' \
    --instance-group=us-east1-mig \
    --instance-group-zone=us-east1-b \
    --global

Dodanie zarządzanej grupy instancji West do usługi backendu.

Z Cloud Shell

gcloud beta compute backend-services add-backend west-backend-service \
    --balancing-mode='UTILIZATION' \
    --instance-group=us-west1-mig \
    --instance-group-zone=us-west1-a \
    --global

Dodanie zarządzanej grupy instancji West do usługi backendu.

Z Cloud Shell

gcloud beta compute backend-services add-backend central-backend-service \
    --balancing-mode='UTILIZATION' \
    --instance-group=us-central1-mig \
    --instance-group-zone=us-central1-a \
    --global

Tworzenie mapy URL

Na mapie URL będą działać zaawansowane funkcje zarządzania ruchem dostępne w tym module. Musimy utworzyć plik .yaml, który będzie zawierał konfigurację. W pliku .yaml utworzyliśmy dopasowanie prefiksu w katalogu /roundrobbin, więc te konfiguracje będą miały wpływ tylko na dopasowywanie ruchu do pliku /roundrobbin. Określiliśmy, że 50% ruchu powinno być kierowane do usługi east-backend-service, a 50% – do usługi west-backend. Dodatkowo dodaliśmy wartość nagłówka odpowiedzi {test}, która będzie widoczna we wszystkich odpowiedziach. Ponadto dodaliśmy, że cały ruch powinien być dublowany do usługi central-backend. Ruch jest duplikowany i wysyłany tutaj tylko do testów.

Zapisz przykład jako plik .yaml na komputerze.

defaultService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/east-backend-service
kind: compute #urlMap
name: web-map-http
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/east-backend-service
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: /roundrobbin
    priority: 2
    headerAction:
        responseHeadersToAdd:
          - headerName: test
            headerValue: value
            replace: True
    routeAction:
        weightedBackendServices:
        - backendService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/east-backend-service
          weight: 50
        - backendService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/west-backend-service
          weight: 50
        retryPolicy:
            retryConditions: ['502', '504']
            numRetries: 3
            perTryTimeout:
                seconds: 1
                nanos: 50
        requestMirrorPolicy:
          backendService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/central-backend-service

Utwórz mapę URL importującą dokument z Twojego komputera. Ścieżka źródłowa będzie się różnić w zależności od miejsca zapisania pliku .yaml.

Z Cloud Shell

gcloud beta compute url-maps import web-map-http \
   --source /Users/[USERNAME]/Documents/Codelab/lbconfig.yaml \
   --global

Tworzenie frontendu HTTP

Ostatnim krokiem przy tworzeniu systemu równoważenia obciążenia jest utworzenie frontendu. Spowoduje to zmapowanie wcześniej zarezerwowanego adresu IP na utworzoną mapę URL systemu równoważenia obciążenia.

Z Cloud Shell

gcloud beta compute target-http-proxies create http-lb-proxy-adv \
    --url-map=web-map-http

Następnie musisz utworzyć globalną regułę przekierowania, która mapuje zarezerwowany wcześniej adres IP na serwer proxy HTTP.

Z Cloud Shell

gcloud beta compute forwarding-rules create http-content-rule \
    --load-balancing-scheme EXTERNAL_MANAGED \
    --address=lb-ipv4-2 \
    --global \
    --target-http-proxy=http-lb-proxy-adv \
    --ports=80

6. Sprawdzanie, czy zaawansowane funkcje związane z ruchem działają

Aby sprawdzić, czy zaimplementowana funkcja podziału ruchu działa, musisz wygenerować obciążenie. W tym celu utworzymy nową maszynę wirtualną, aby symulować obciążenie.

Tworzenie reguły zapory sieciowej zezwalającej na dostęp SSH

Aby połączyć się z maszyną wirtualną przez SSH, najpierw wygenerujemy ruch z Twojego konta, więc musisz utworzyć regułę zapory sieciowej, która przepuszcza ruch SSH do tej maszyny wirtualnej.

Z Cloud Shell

gcloud compute firewall-rules create fw-allow-ssh \
    --network=httplbs \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

Wyniki

NAME          NETWORK  DIRECTION  PRIORITY  ALLOW   DENY  DISABLED
fw-allow-ssh  httplbs  INGRESS    1000      tcp:22        False

Tworzenie maszyny Siege

Teraz utworzysz siege-vm, który będzie służyć do generowania obciążenia.

Z Cloud Shell

gcloud compute instances create siege-vm \
    --network=httplbs \
    --zone=us-east4-c \
    --machine-type=e2-medium \
    --tags=allow-ssh,http-server \
    --metadata=startup-script='sudo apt-get -y install siege'

Wyniki

NAME     ZONE        MACHINE_TYPE INTERNAL_IP  EXTERNAL_IP    STATUS
siege-vm us-east4-c  e2-medium    10.150.0.3   34.85.218.119  RUNNING

Następnie możesz połączyć się z utworzoną maszyną wirtualną przez SSH. Po utworzeniu kliknij SSH, aby uruchomić terminal i nawiązać połączenie.

Po nawiązaniu połączenia uruchom następujące polecenie, aby wygenerować obciążenie. Użyj wcześniej zarezerwowanego adresu IP dla zewnętrznego systemu równoważenia obciążenia HTTP.

Z Cloud Shell

siege -c 250 http://$lb-ipv4-2/roundrobbin

Wyniki

New configuration template added to /home/cloudcurriculumdeveloper/.siege
Run siege -C to view the current settings in that file
[alert] Zip encoding disabled; siege requires zlib support to enable it: No such file or directory
** SIEGE 4.0.2
** Preparing 250 concurrent users for battle.
The server is now under siege...

Sprawdź rozkład obciążenia

Siege jest już uruchomiony, więc należy sprawdzić, czy ruch jest równomiernie rozkładany między wschodnie i zachodnie grupy instancji. Możesz też sprawdzić, czy powielanie ruchu działa i czy ruch jest wysyłany do centralnej zarządzanej grupy instancji.

W menu nawigacyjnym konsoli Cloud kliknij Usługi sieciowe > Równoważenie obciążenia. Kliknij Backendy. Kliknij menu zaawansowane, tak jak na zrzucie ekranu poniżej.

Przejdź na kartę Usługi backendu i wybierz usługę east-backend-service

Możesz w czasie rzeczywistym wyświetlać podział ruchu do tej zarządzanej grupy instancji. Zwróć uwagę na stawkę. Możesz ją za chwilę porównać z usługą West-backend.

W podobny sposób przejdź do usługi west-backend-service. Trzeba też obserwować ruch przepływający do tej usługi. Częstotliwość powinna być podobna do tej w usłudze east-backend, ponieważ został skonfigurowany podział ruchu 50/50 razy.

Aby sprawdzić, czy utworzona zasada dublowania ruchu działa, musisz sprawdzić wykorzystanie grupy instancji zarządzanej przez usługę central-backend-service. Aby to zrobić, przejdź do Compute Engine, Compute Engine, grup instancji i wybierz us-central1-mig. Następnie przejdź na kartę monitorowania.

Zobaczysz wykresy pokazujące, że ruch został zduplikowany do tej zarządzanej grupy instancji.

Zatrzymaj oblężenie

Po udowodnieniu, że zaawansowany podział ruchu działa, czas zaprzestać oblężenia. Aby to zrobić, wróć do terminala SSH instancji siege-vm i naciśnij CTRL+C, co spowoduje zatrzymanie siege.

Sprawdzanie poprawności wysyłanego nagłówka odpowiedzi

Przed wyczyszczeniem możesz szybko sprawdzić, czy system równoważenia obciążenia HTTP wysyła odpowiedni nagłówek odpowiedzi. Został on skonfigurowany tak, aby wysyłał test nagłówka z wartością treści. Uruchomienie polecenia curl z Cloud Shell zwróci oczekiwaną odpowiedź.

Z Cloud Shell

curl -svo /dev/null http://lb-ipv4-2/roundrobbin

Wyniki

*   Trying lb-ipv4-2..
* TCP_NODELAY set
* Connected to  lb-ipv4-2 ( lb-ipv4-2) port 80 (#0)
> GET /roundrobbin HTTP/1.1
> Host:  lb-ipv4-2
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< date: Wed, 10 Nov 2021 17:05:27 GMT
< server: envoy
< Content-Length: 273
< content-type: text/html; charset=iso-8859-1
< via: 1.1 google
< test: value
<
{ [273 bytes data]
* Connection #0 to host 34.149.2.26 left intact
* Closing connection 0

7. Czyszczenie modułu

Skoro mamy już środowisko laboratoryjne, czas go zniszczyć. Aby usunąć środowisko testowe, uruchom te polecenia.

Z Cloud Shell

gcloud compute instances delete siege-vm

gcloud alpha compute forwarding-rules delete http-content-rule --global
gcloud alpha compute target-http-proxies delete http-lb-proxy-adv
gcloud alpha compute url-maps delete web-map-http
gcloud alpha compute backend-services delete east-backend-service --global
gcloud alpha compute backend-services delete west-backend-service --global
gcloud alpha compute backend-services delete central-backend-service --global

gcloud compute addresses delete lb-ipv4-2 --global
gcloud compute health-checks delete http-basic-check 

gcloud compute instance-groups managed delete us-east1-mig --zone us-east1-b
gcloud compute instance-groups managed delete us-west1-mig --zone us-west1-a
gcloud compute instance-groups managed delete us-central1-mig --zone us-central1-a

gcloud compute instance-templates delete "us-east1-template" 
gcloud compute instance-templates delete "us-west1-template" 
gcloud compute instance-templates delete "us-central1-template" 

gcloud compute firewall-rules delete httplb-allow-http-rule
gcloud compute firewall-rules delete fw-allow-ssh

gcloud compute networks delete httplbs

8. Gratulacje!

Udało Ci się ukończyć ćwiczenie z programowania dotyczące zewnętrznego systemu równoważenia obciążenia HTTPs w ramach zaawansowanego zarządzania ruchem (Envoy).

Omówione zagadnienia

Jak skonfigurować zarządzaną grupę instancji i powiązane reguły VPC i zapory sieciowej
Jak korzystać z zaawansowanych funkcji zarządzania ruchem w nowym systemie równoważenia obciążenia
Jak sprawdzić, czy zaawansowane funkcje zarządzania ruchem działają zgodnie z oczekiwaniami.

Dalsze kroki

Wypróbuj inne zaawansowane funkcje routingu, takie jak przepisywanie adresów URL czy dodawanie nagłówków CORS ( link)