Buforuj żądania HTTP za pomocą Cloud Tasks

1. Wprowadzenie

Cloud Tasks to w pełni zarządzana usługa kolejkowania, która umożliwia zarządzanie wykonywaniem, wysyłaniem i dostarczaniem dużej liczby zadań.

Cloud Tasks umożliwia wydzielanie części pracy, zwanych zadaniami, które można wykonywać niezależnie (np. zadanie aktualizacji wpisu w bazie danych) poza głównym przepływem aplikacji i wysyłać je do asynchronicznego przetworzenia za pomocą utworzonych przez Ciebie modułów obsługi.

Przeniesione zadanie jest dodawane do kolejki, w której pozostaje do momentu pomyślnego wykonania lub niepowodzenia. W zależności od konfiguracji kolejka może też pełnić funkcję sterowania przepływem wysyłania. Kolejkę tworzysz i konfigurujesz samodzielnie, a potem jest ona zarządzana przez usługę Cloud Tasks. Po dodaniu zadań kolejka wysyła je i zapewnia, że instancje robocze niezawodnie je przetwarzają.

Oto niektóre z głównych funkcji Cloud Tasks:

Cele HTTP: dodawaj zadania kierowane do dowolnej usługi HTTP działającej w Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud Functions lub systemach lokalnych w bezpieczny sposób przy użyciu standardowego uwierzytelniania OAuth/OIDC.
Deduplikacja zadań: zadania dodane wielokrotnie zostaną wysłane tylko raz.
Gwarantowane dostarczanie: zadania są dostarczane co najmniej raz, a większość z nich dokładnie raz.
Kontrola szybkości i ponawiania: kontroluj wykonywanie zadań, ustawiając szybkość wysyłania zadań, maksymalną liczbę prób i minimalny czas oczekiwania między próbami.
Planowanie na przyszłość: możesz określić, kiedy zadanie ma zostać uruchomione.

W tym ćwiczeniu w Codelabs dowiesz się najpierw, jak utworzyć i używać zwykłej kolejki Cloud Tasks do zadań z docelowym adresem HTTP. Następnie dowiesz się, jak używać zastępowania adresu URI HTTP na poziomie kolejki i nowego interfejsu BufferTask API, aby łatwiej buforować żądania HTTP za pomocą Cloud Tasks.

Czego się nauczysz

Jak tworzyć docelowe zadania HTTP.
Jak tworzyć zadania docelowe HTTP z nowym zastąpieniem adresu URI HTTP na poziomie kolejki.
Jak zmienić zadania oczekujące za pomocą nowego zastąpienia identyfikatora URI HTTP na poziomie kolejki.
Jak łatwiej buforować żądania HTTP za pomocą nowego interfejsu BufferTask API.

2. Konfiguracja i wymagania

Samodzielne konfigurowanie środowiska

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

Nazwa projektu to wyświetlana nazwa uczestników tego projektu. Jest to ciąg znaków, który nie jest używany przez interfejsy API Google. Zawsze możesz ją zaktualizować.
Identyfikator projektu jest unikalny we wszystkich projektach Google Cloud i nie można go zmienić po ustawieniu. Konsola Cloud automatycznie generuje unikalny ciąg znaków. Zwykle nie musisz się tym przejmować. W większości ćwiczeń z programowania musisz odwoływać się do identyfikatora projektu (zwykle oznaczanego jako PROJECT_ID). Jeśli wygenerowany identyfikator Ci się nie podoba, możesz wygenerować inny losowy identyfikator. Możesz też spróbować własnej nazwy i sprawdzić, czy jest dostępna. Po tym kroku nie można go zmienić i pozostaje on taki przez cały czas trwania projektu.
Warto wiedzieć, że istnieje też trzecia wartość, numer projektu, której używają niektóre interfejsy API. Więcej informacji o tych 3 wartościach znajdziesz w dokumentacji.

Następnie musisz włączyć płatności w konsoli Cloud, aby korzystać z zasobów i interfejsów API Google Cloud. Wykonanie tego laboratorium nie będzie kosztować dużo, a może nawet nic. Aby wyłączyć zasoby i uniknąć naliczania opłat po zakończeniu tego samouczka, możesz usunąć utworzone zasoby lub projekt. Nowi użytkownicy Google Cloud mogą skorzystać z bezpłatnego okresu próbnego, w którym mają do dyspozycji środki w wysokości 300 USD.

Uruchamianie Cloud Shell

Z Google Cloud można korzystać zdalnie na laptopie, ale w tym module praktycznym będziesz używać Google Cloud Shell, czyli środowiska wiersza poleceń działającego w chmurze.

W konsoli Google Cloud kliknij ikonę Cloud Shell na pasku narzędzi w prawym górnym rogu:

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

Ta maszyna wirtualna zawiera wszystkie potrzebne narzędzia dla programistów. Zawiera również stały katalog domowy o pojemności 5 GB i działa w Google Cloud, co znacznie zwiększa wydajność sieci i usprawnia proces uwierzytelniania. Wszystkie zadania w tym laboratorium możesz wykonać w przeglądarce. Nie musisz niczego instalować.

3. Tworzenie zwykłej kolejki dla zadań docelowych HTTP

W tym pierwszym kroku dowiesz się, jak utworzyć zwykłą kolejkę Cloud Tasks i dodać do niej zadania HTTP, aby kierować je do usługi Cloud Run.

Czym są zadania docelowe HTTP?

Zadania docelowe HTTP mogą bezpiecznie kierować żądania do dowolnej usługi HTTP działającej w Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud Functions lub systemach lokalnych przy użyciu standardowej w branży autoryzacji OAuth/OIDC.

Wdrażanie usługi Cloud Run

Najpierw upewnij się, że wymagane interfejsy API są włączone:

gcloud services enable \
  cloudtasks.googleapis.com \
  run.googleapis.com

Wdróż usługę Cloud Run, która będzie służyć jako miejsce docelowe zadań HTTP:

SERVICE1=hello1
REGION=us-central1

gcloud run deploy $SERVICE1 \
  --allow-unauthenticated \
  --image=gcr.io/cloudrun/hello \
  --region=$REGION

Tworzenie kolejki w Cloud Tasks

Utwórz zwykłą kolejkę Cloud Tasks:

QUEUE1=http-queue
LOCATION=us-central1

gcloud tasks queues create $QUEUE1 --location=$LOCATION

Tymczasowo wstrzymaj kolejkę, aby obserwować tworzenie zadań HTTP:

gcloud tasks queues pause $QUEUE1 --location=$LOCATION

4. Tworzenie i testowanie zadania HTTP

W tym kroku utworzysz zadanie HTTP, które będzie kierowane do utworzonej wcześniej kolejki.

Tworzenie zadania HTTP

Zadania HTTP możesz tworzyć za pomocą gcloud:

gcloud tasks create-http-task \
    --queue=$QUEUE1 \
    --location=$LOCATION \
    --url=$SERVICE1_URL \
    --method=GET

Opcjonalnie: możesz też utworzyć zadanie HTTP za pomocą bibliotek klienta. Możesz na przykład zapoznać się z Program.cs, aby zobaczyć przykładowy kod w C#, w którym żądanie HTTP jest opakowane w Task i TaskRequest przed wysłaniem do Cloud Tasks za pomocą CloudTasksClient:

var taskRequest = new CreateTaskRequest
{
    Parent = new QueueName(projectId, location, queue).ToString(),
    Task = new Task
    {
        HttpRequest = new HttpRequest
        {
            HttpMethod = HttpMethod.Get,
            Url = url
        }
    }
};

var client = CloudTasksClient.Create();
var response = client.CreateTask(taskRequest);

Aby utworzyć zadanie i dodać je do kolejki, możesz uruchomić to polecenie w ten sposób:

dotnet run $PROJECT_ID $LOCATION $QUEUE1 $SERVICE1_URL

Testowanie zadania HTTP

Na tym etapie zadanie jest utworzone, ale nie jest jeszcze wykonywane, ponieważ kolejka jest wstrzymana. Możesz to sprawdzić, wyświetlając listę kolejek:

gcloud tasks queues list --location=$LOCATION

Kolejka powinna mieć stan PAUSED:

QUEUE_NAME  STATE
http-queue  PAUSED

Wznów kolejkę:

gcloud tasks queues resume $QUEUE --location=$LOCATION

Sprawdź logi usługi Cloud Run:

gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=$SERVICE1" --limit 1

Powinno być widoczne, że usługa Cloud Run otrzymała żądanie GET z Cloud Tasks:

httpRequest:
  latency: 0.227597158s
  protocol: HTTP/1.1
  remoteIp: 35.243.23.192
  requestMethod: GET
  requestSize: '415'
  requestUrl: https://hello1-idcwffc3yq-uc.a.run.app/
  responseSize: '5510'
  serverIp: 216.239.32.53
  status: 200
  userAgent: Google-Cloud-Tasks

5. Tworzenie kolejki z konfiguracją routingu

Z tego kroku dowiesz się, jak utworzyć kolejkę Cloud Tasks z konfiguracją routingu, aby dodać zastąpienie identyfikatora URI HTTP za pomocą funkcji konfiguracji routingu zadań na poziomie kolejki. Następnie dodasz do niej zadania HTTP, aby kierować je do pierwszej usługi Cloud Run, i zobaczysz, że konfiguracja routingu zastępuje URI, aby kierować zadania do drugiej usługi Cloud Run.

Co to jest konfiguracja kierowania zadań na poziomie kolejki?

Konfiguracja routingu zadań na poziomie kolejki zmienia routing zadań HTTP dla całej kolejki w przypadku wszystkich oczekujących i nowych zadań. Ułatwia to tworzenie zadań, ponieważ nie trzeba ustawiać celu HTTP na poziomie zadania, a większa kontrola jest przekazywana dostawcy usług, ponieważ może on ustawić cel wszystkich zadań w kolejce (np. kierować ruch do innego backendu, jeśli oryginalny backend nie działa).

Na poziomie kolejki można skonfigurować te ustawienia:

Nagłówki: nagłówki na poziomie kolejki, jeśli są określone na tym poziomie, będą wstawiać nagłówki do wszystkich zadań w kolejce.
Metoda HTTP: metoda HTTP określona na poziomie kolejki zastępuje metodę HTTP dla wszystkich zadań w kolejce.
Docelowy identyfikator URI: host, ścieżka, zapytanie, port i schemat (HTTP lub HTTPS) mogą być zastępowane indywidualnie.
Autoryzacja: konfiguracja OIDC/OAuth określona na poziomie kolejki zastąpi konfigurację OIDC/OAuth na poziomie zadania.

Wdróż drugą usługę Cloud Run

Wdróż drugą usługę Cloud Run, która będzie później służyć jako miejsce docelowe zastąpienia identyfikatora URI HTTP:

SERVICE2=hello2
REGION=us-central1

gcloud run deploy $SERVICE2 \
  --allow-unauthenticated \
  --image=gcr.io/cloudrun/hello \
  --region=$REGION

Zapisz hosta adresu URL usługi na później:

SERVICE2_URL=$(gcloud run services describe $SERVICE2 --region $REGION --format 'value(status.url)')
SERVICE2_HOST=$(echo $SERVICE2_URL | sed 's,http[s]*://,,g')

Tworzenie kolejki Cloud Tasks z konfiguracją routingu

Utwórz kolejkę z konfiguracją routingu z zastąpieniem adresu URI HTTP na drugą usługę Cloud Run.

QUEUE2=http-queue-uri-override

gcloud beta tasks queues create $QUEUE2 \
  --http-uri-override=host:$SERVICE2_HOST \
  --location=$LOCATION

Pamiętaj, że zastąpienie URI odnosi się do drugiej usługi Cloud Run. W przypadku każdego zadania HTTP dodanego do kolejki pierwotny host URI zostanie zastąpiony. Możesz wyświetlić konfigurację kolejki:

gcloud beta tasks queues describe $QUEUE2 --location=$LOCATION

Powinno być widoczne, że httpTarget ma uriOverride wskazujący hosta drugiej usługi:

httpTarget:
  uriOverride:
    host: hello2-idcwffc3yq-uc.a.run.app
    pathOverride: {}
    queryOverride: {}
...

Tymczasowo wstrzymaj kolejkę, aby obserwować tworzenie zadań HTTP:

gcloud tasks queues pause $QUEUE2 --location=$LOCATION

6. Utwórz i przetestuj zadanie HTTP dla kolejki z konfiguracją routingu

W tym kroku utworzysz zadanie HTTP, które będzie kierowane do pierwszej usługi. Zauważysz, że jego URI zostanie zastąpiony przez kolejkę, aby wskazywać drugą usługę.

Tworzenie zadania HTTP

Utwórz zadanie HTTP z adresem URL pierwszej usługi:

gcloud tasks create-http-task \
    --queue=$QUEUE2 \
    --location=$LOCATION \
    --url=$SERVICE1_URL \
    --method=GET

Testowanie zadania HTTP

Wznów kolejkę:

gcloud tasks queues resume $QUEUE2 --location=$LOCATION

Powinna się wyświetlić informacja, że druga (a nie pierwsza) usługa Cloud Run otrzymała żądanie GET HTTP z Cloud Tasks z powodu zastąpienia:

gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=$SERVICE2" --limit 1

---
httpRequest:
  latency: 0.228982142s
  protocol: HTTP/1.1
  remoteIp: 35.187.132.84
  requestMethod: GET
  requestSize: '426'
  requestUrl: https://hello2-idcwffc3yq-uc.a.run.app/
  responseSize: '5510'
  serverIp: 216.239.34.53
  status: 200
  userAgent: Google-Cloud-Tasks

7. Zmienianie oczekujących zadań za pomocą konfiguracji routingu

Możesz też użyć konfiguracji routingu, aby zmienić adres URI HTTP wszystkich zadań oczekujących w kolejce. Jest to przydatne, jeśli usługa backendu przestanie działać i chcesz szybko przekierować ruch do innej usługi. Zobaczmy, jak to działa w tym kroku.

Ponownie wstrzymaj kolejkę:

gcloud tasks queues pause $QUEUE2 --location=$LOCATION

Utwórz zadanie HTTP z adresem URL zadania google.com:

gcloud tasks create-http-task \
    --queue=$QUEUE2 \
    --location=$LOCATION \
    --url=https://www.google.com \
    --method=GET

Zadanie jest w stanie oczekiwania, ponieważ kolejka jest wstrzymana.

Teraz zaktualizuj zastąpienie URI HTTP, aby wskazywało pierwszą usługę. Spowoduje to zastąpienie hosta oczekującego zadania z google.com hostem pierwszej usługi:

SERVICE1_URL=$(gcloud run services describe $SERVICE1 --region $REGION --format 'value(status.url)')
SERVICE1_HOST=$(echo $SERVICE1_URL | sed 's,http[s]*://,,g')

gcloud beta tasks queues update $QUEUE2 \
  --http-uri-override=host:$SERVICE1_HOST \
  --location=$LOCATION

Wznów kolejkę:

gcloud tasks queues resume $QUEUE2 --location=$LOCATION

Powinna się wyświetlić informacja, że pierwsza usługa Cloud Run otrzymała żądanie GET HTTP z Cloud Tasks z powodu zastąpienia (zamiast google.com):

gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=$SERVICE1" --limit 1
---
httpRequest:
  latency: 0.228982142s
  protocol: HTTP/1.1
  remoteIp: 35.187.132.84
  requestMethod: GET
  requestSize: '426'
  requestUrl: https://hello1-idcwffc3yq-uc.a.run.app/
  responseSize: '5510'
  serverIp: 216.239.34.53
  status: 200
  userAgent: Google-Cloud-Tasks

8. Tworzenie kolejki dla interfejsu BufferTask API

Zwykle tworzysz zadania za pomocą interfejsu Tasks API w gcloud lub bibliotek klienta Listy zadań. Obciąża to aplikacje, które muszą opakowywać żądania HTTP w zadania przy użyciu bibliotek klienta, a także tworzy zależność między aplikacjami a bibliotekami klienta Tasks.

W tym kroku dowiesz się, jak wykorzystać zastąpienie adresu URI HTTP na poziomie kolejki i nowy interfejs BufferTask API, aby łatwiej tworzyć zadania docelowe HTTP, po prostu wysyłając żądanie HTTP. Każda aplikacja, która może wysyłać żądania HTTP, może teraz tworzyć zadania docelowe HTTP.

Czym jest interfejs BufferTask API?

Interfejs CreateTask API to starszy sposób tworzenia zadań. Wymaga on wysłania do interfejsu API obiektu Task ze wszystkimi wymaganymi polami.

BufferTask API to nowa funkcja, która umożliwia tworzenie zadania HTTP bez konieczności podawania konfiguracji zadania (adresu URL HTTP, nagłówków, autoryzacji), co pozwala po prostu wysłać wiadomość lub treść żądania do interfejsu Buffer API.

Ułatwia to integrację z usługami, ponieważ Cloud Tasks można teraz wdrażać przed usługą bez konieczności wprowadzania zmian w kodzie po stronie klienta. Każde dowolne żądanie HTTP wysłane do interfejsu BufferTask API zostanie opakowane jako obiekt Task i dostarczone do miejsca docelowego ustawionego na poziomie kolejki.

Aby używać interfejsu BufferTask API, kolejka musi mieć skonfigurowany docelowy identyfikator URI. Innymi słowy, funkcja Konfiguracja routingu na poziomie kolejki jest warunkiem wstępnym korzystania z interfejsu BufferTask API.

Tworzenie kolejki Cloud Tasks z konfiguracją routingu

Utwórz kolejkę z konfiguracją routingu wskazującą pierwszą usługę wdrożoną w poprzednim kroku:

SERVICE1=hello1
SERVICE1_URL=$(gcloud run services describe $SERVICE1 --region $REGION --format 'value(status.url)')
SERVICE1_HOST=$(echo $SERVICE1_URL | sed 's,http[s]*://,,g')
QUEUE3=http-queue-uri-override-buffer

gcloud beta tasks queues create $QUEUE3 \
  --http-uri-override=host:$SERVICE1_HOST \
  --location=$LOCATION

Tymczasowo wstrzymaj kolejkę, aby obserwować tworzenie zadań HTTP:

gcloud tasks queues pause $QUEUE3 --location=$LOCATION

9. Buforowanie żądań HTTP za pomocą interfejsu BufferTask API

W tym kroku utworzysz bufor prostych żądań HTTP GET lub POST za pomocą interfejsu BufferTask API. W tle Cloud Tasks opakuje te żądania HTTP w zadania HTTP z domyślnymi ustawieniami konfiguracji routingu kolejki.

Najpierw zaloguj się, aby uzyskać token dostępu i ustawić niektóre zmienne:

gcloud auth application-default login
ACCESS_TOKEN=$(gcloud auth application-default print-access-token)
PROJECT_ID=$(gcloud config get-value project)
TASKS_QUEUES_API="https://cloudtasks.googleapis.com/v2beta3/projects/$PROJECT_ID/locations/$LOCATION/queues"

Tworzenie zadania HTTP

Utwórz zadanie HTTP za pomocą interfejsu BufferTask API. Zwróć uwagę, że jest to proste żądanie HTTP GET, które nie wymaga tworzenia zadania:

curl -X GET "$TASKS_QUEUES_API/$QUEUE3/tasks:buffer" \
  -H "Authorization: Bearer $ACCESS_TOKEN"

Utwórz kolejne zadanie HTTP z metodą HTTP POST i treścią:

curl -X POST "$TASKS_QUEUES_API/$QUEUE3/tasks:buffer" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -d "{'message': 'Hello World'}"

Opcjonalnie: możesz też utworzyć zadanie HTTP za pomocą bibliotek klienta. Możesz na przykład zapoznać się z Program.cs w przykładzie w języku C#, w którym żądanie GET HTTP jest wysyłane bezpośrednio do interfejsu BufferTask API bez konieczności umieszczania go w Task lub korzystania z biblioteki klienta Cloud Tasks:

var BufferTaskApiUrl = $"https://cloudtasks.googleapis.com/v2beta3/projects/{ProjectId}/locations/{Location}/queues/{Queue}/tasks:buffer";

using (var client = new HttpClient())
{
    client.DefaultRequestHeaders.Add("Authorization", $"Bearer {AccessToken}");
    var response = await client.GetAsync(BufferTaskApiUrl);
    var content = await response.Content.ReadAsStringAsync();
    Console.WriteLine($"Response: {content}");
}

Możesz go uruchomić w ten sposób:

dotnet run $PROJECT_ID $LOCATION $QUEUE3 $ACCESS_TOKEN

Interfejs BufferTask API tworzy zadanie na podstawie żądań HTTP i dodaje adres URL z ustawień konfiguracji routingu kolejki do identyfikatora URI.

Testowanie zadania HTTP

Wznów kolejkę:

gcloud tasks queues resume $QUEUE3 --location=$LOCATION

Powinno być widoczne, że usługa Cloud Run otrzymała żądania HTTP GET i POST z Cloud Tasks:

gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=$SERVICE1" --limit 4

---
httpRequest:
  latency: 0.002279292s
  protocol: HTTP/1.1
  remoteIp: 35.243.23.42
  requestMethod: POST
  requestSize: '777'
  requestUrl: https://hello1-idcwffc3yq-uc.a.run.app/
  responseSize: '5450'
  serverIp: 216.239.32.53
  status: 200
  userAgent: Google-Cloud-Tasks
...
httpRequest:
  latency: 0.228982142s
  protocol: HTTP/1.1
  remoteIp: 35.187.132.84
  requestMethod: GET
  requestSize: '426'
  requestUrl: https://hello1-idcwffc3yq-uc.a.run.app/
  responseSize: '5510'
  serverIp: 216.239.34.53
  status: 200
  userAgent: Google-Cloud-Tasks

10. Gratulacje

Gratulacje! Codelab został ukończony.

Następnie możesz wypróbować Cloud Tasks jako bufor między Pub/Sub a Cloud Run, aby zobaczyć praktyczny przykład tego, jak te nowe funkcje Cloud Tasks mogą ułatwić tworzenie kolejki bufora między usługami.

Czyszczenie (opcjonalnie)

Aby uniknąć obciążenia konta opłatami, warto usunąć zasoby.

Jeśli nie potrzebujesz projektu, możesz go po prostu usunąć:

gcloud projects delete $PROJECT_ID

Jeśli potrzebujesz projektu, możesz usunąć poszczególne zasoby.

Usuń usługi Cloud Run:

gcloud run services delete $SERVICE1 --region $REGION
gcloud run services delete $SERVICE2 --region $REGION

Usuń kolejki Cloud Tasks:

gcloud tasks queues delete $QUEUE1 --location=$LOCATION
gcloud tasks queues delete $QUEUE2 --location=$LOCATION
gcloud tasks queues delete $QUEUE3 --location=$LOCATION

Omówione zagadnienia

Jak tworzyć docelowe zadania HTTP.
Jak tworzyć zadania docelowe HTTP z nowym zastąpieniem adresu URI HTTP na poziomie kolejki.
Jak zmienić zadania oczekujące za pomocą nowego zastąpienia identyfikatora URI HTTP na poziomie kolejki.
Jak łatwiej buforować żądania HTTP za pomocą nowego interfejsu BufferTask API.