Zdarzenia dotyczące ćwiczeń z programowania w Cloud Run for Anthos

1. Wprowadzenie

Cloud Run umożliwia uruchamianie bezstanowych kontenerów w w pełni zarządzanym środowisku. Rozwiązanie to jest oparte na platformie open source Knative, co pozwala uruchamiać w pełni zarządzane kontenery w Cloud Run lub kontenery w klastrze Google Kubernetes Engine przy użyciu Cloud Run for Anthos.

Events for Cloud Run for Anthos ułatwia łączenie usług Cloud Run ze zdarzeniami z różnych źródeł. Umożliwia tworzenie architektur opartych na zdarzeniach, w których mikroserwisy są luźno sprzężone i rozproszone. Zajmuje się też pozyskiwaniem, przesyłaniem, zabezpieczaniem, autoryzacją i obsługą błędów związanych ze zdarzeniami, co zwiększa elastyczność programistów i odporność aplikacji.

W tym laboratorium dowiesz się więcej o zdarzeniach Cloud Run dla platformy Anthos. Dowiesz się w nim, jak nasłuchiwać zdarzeń z Cloud Pub/Sub, logów kontrolnych, Cloud Storage i Cloud Scheduler oraz jak tworzyć i przetwarzać zdarzenia niestandardowe.

Czego się nauczysz

Długoterminowa wizja zdarzeń Cloud Run dla platformy Anthos
Obecny stan zdarzeń Cloud Run dla platformy Anthos
Tworzenie ujścia Cloud Run
Tworzenie aktywatora zdarzeń dla Cloud Pub/Sub
Tworzenie aktywatora zdarzeń dla dzienników kontrolnych
Tworzenie aktywatora zdarzeń dla Cloud Storage
Tworzenie aktywatora zdarzeń dla Cloud Scheduler
Generowanie i wykorzystywanie zdarzeń niestandardowych

2. Długoterminowa wizja

Wraz z wdrażaniem architektury bezserwerowej zdarzenia stają się integralną częścią komunikacji między odłączonymi mikroserwisami. Zdarzenia Cloud Run dla platformy Anthos sprawiają, że zdarzenia są traktowane jako podstawowy element oferty Cloud Run dla platformy Anthos, dzięki czemu łatwo jest tworzyć bezserwerowe aplikacje oparte na zdarzeniach.

Events for Cloud Run for Anthos umożliwia niezawodne, bezpieczne i skalowalne asynchroniczne dostarczanie zdarzeń ze źródeł zdarzeń w pakietach lub utworzonych przez aplikację do odbiorców w klastrze i poza nim.

Źródła Google Cloud	Źródła zdarzeń, które są usługami należącymi do Google Cloud
Źródła Google	Źródła zdarzeń, które są usługami Google, takimi jak Gmail, Hangouts, Android Management i inne.
Źródła niestandardowe	Źródła zdarzeń, które nie są produktami Google i są tworzone przez użytkowników. Mogą to być opracowane przez użytkownika źródła Knative lub dowolna inna aplikacja działająca w klastrze, która może generować zdarzenie Cloud Event.
Źródła zewnętrzne	Źródła zdarzeń, które nie należą do Google ani do użytkowników. Obejmuje to popularne źródła zdarzeń, takie jak Github, SAP, Datadog, Pagerduty itp., które są własnością dostawców zewnętrznych, partnerów lub społeczności OSS i są przez nich utrzymywane.

Zdarzenia są normalizowane do formatu CloudEvents v1.0, aby zapewnić interoperacyjność między usługami. CloudEvents to niezależna od dostawcy otwarta specyfikacja opisująca dane zdarzeń w popularnych formatach, która umożliwia interoperacyjność między usługami, platformami i systemami.

Usługa Events for Cloud Run jest zgodna z Knative Eventing i umożliwia przenoszenie kontenerów do i z innych implementacji opartych na Knative. Zapewnia to spójne, niezależne od chmury środowisko do deklaratywnego łączenia producentów zdarzeń z ich konsumentami.

3. Bieżący stan

Ta wersja podglądowa to pierwsza wersja, która zawiera wstępny zestaw funkcji długoterminowych.

Aby umożliwić użytkownikom tworzenie aplikacji bezserwerowych opartych na zdarzeniach, skupiamy się na 2 aspektach:

zapewnia szeroki ekosystem źródeł Google Cloud, który umożliwia usługom Cloud Run w klastrze Anthos reagowanie na zdarzenia z usług Google Cloud;

Początkowo zdarzenia ze źródeł Google Cloud są dostarczane za pomocą logów kontrolnych Cloud (CAL), co umożliwia korzystanie z szerokiej gamy źródeł zdarzeń. Opóźnienie i dostępność dostarczania zdarzeń z tych źródeł są powiązane z opóźnieniem i dostępnością logów kontrolnych Cloud. Za każdym razem, gdy publikowane jest zdarzenie ze źródła Google Cloud, tworzony jest odpowiedni wpis logu kontrolnego Cloud.
Oprócz logów kontrolnych Cloud usługa ta obsługuje też wykorzystywanie zdarzeń z Cloud Storage, Cloud Pub/Sub i Cloud Scheduler. Będziemy rozszerzać ten ekosystem źródeł o kolejne źródła najwyższej jakości, gdy będziemy zdobywać więcej informacji o ścieżkach użytkowników i ich opiniach.

Umożliwia aplikacjom i usługom użytkowników emitowanie zdarzeń niestandardowych przez publikowanie ich pod adresem URL brokera w klastrze ograniczonym do przestrzeni nazw.

Podstawowy mechanizm dostarczania korzysta z tematów i subskrypcji Cloud Pub/Sub, które są widoczne w projektach klientów. Dlatego funkcja ta zapewnia takie same gwarancje dostawy jak Cloud Pub/Sub.

Aktywator zdarzeń umożliwia subskrybowanie zdarzeń, dzięki czemu zdarzenia pasujące do filtra aktywatora są dostarczane do miejsca docelowego (lub odbiornika), na które wskazuje aktywator.

Wszystkie zdarzenia są dostarczane w formacie Cloud Events v1.0, co zapewnia interoperacyjność między usługami.

Będziemy stopniowo zwiększać wartość tej usługi aż do momentu jej udostępnienia i po nim.

4. 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 tego projektu. Możesz użyć dowolnej nazwy, o ile przestrzegasz konwencji nazewnictwa. W każdej chwili możesz ją zmienić.
Identyfikator projektu musi być unikalny we wszystkich projektach Google Cloud i jest niezmienny (nie można go zmienić po ustawieniu). Konsola Cloud automatycznie generuje unikalny ciąg znaków. Zwykle nie musisz się nim przejmować. W większości Codelabs musisz odwoływać się do identyfikatora projektu (zwykle oznaczanego jako PROJECT_ID), więc jeśli Ci się nie podoba, wygeneruj inny losowy identyfikator lub spróbuj użyć własnego i sprawdź, czy jest dostępny. Po utworzeniu projektu jest on „zamrażany”.

Następnie musisz włączyć rozliczenia w konsoli Cloud, aby korzystać z zasobów Google Cloud.

Ukończenie tego laboratorium nie powinno wiązać się z dużymi kosztami, a nawet z żadnymi. Wykonaj instrukcje z sekcji „Czyszczenie”, w której znajdziesz informacje o tym, jak wyłączyć zasoby, aby uniknąć naliczenia opłat po zakończeniu tego samouczka. 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 GCP 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 module możesz wykonać w przeglądarce.

5. Włączanie interfejsów API, ustawianie strefy i platformy

Skonfiguruj identyfikator projektu i zainstaluj komponenty wersji alfa

W Cloud Shell zmienna GOOGLE_CLOUD_PROJECT powinna być już ustawiona na identyfikator projektu. Jeśli nie, upewnij się, że jest ustawiony, a gcloud jest skonfigurowany z tym identyfikatorem projektu:

export GOOGLE_CLOUD_PROJECT=your-project-id
gcloud config set project ${GOOGLE_CLOUD_PROJECT}

Sprawdź, czy komponent gcloud w wersji alfa jest zainstalowany:

gcloud components install alpha

Włącz interfejsy API

Włącz wszystkie niezbędne usługi:

gcloud services enable cloudapis.googleapis.com 
gcloud services enable container.googleapis.com 
gcloud services enable containerregistry.googleapis.com
gcloud services enable cloudbuild.googleapis.com

Ustawianie strefy i platformy

Zanim utworzysz klaster GKE z Cloud Run Events, ustaw nazwę klastra, strefę i platformę. Na przykład ustawimy nazwę i strefę na events-cluster i europe-west1-b, a platformę na gke,.

W Cloud Shell:

export CLUSTER_NAME=events-cluster
export CLUSTER_ZONE=europe-west1-b

gcloud config set run/cluster ${CLUSTER_NAME}
gcloud config set run/cluster_location ${CLUSTER_ZONE}
gcloud config set run/platform gke

Możesz sprawdzić, czy konfiguracja jest ustawiona:

gcloud config list

...
[run]
cluster = events-cluster
cluster_location = europe-west1-b
platform = gke

6. Tworzenie klastra GKE z Cloud Run Events

Utwórz klaster GKE z Kubernetes w wersji ≥ 1.15.9-gke.26 z włączonymi tymi dodatkami: CloudRun, HttpLoadBalancing, HorizontalPodAutoscaling:

gcloud beta container clusters create ${CLUSTER_NAME} \
  --addons=HttpLoadBalancing,HorizontalPodAutoscaling,CloudRun \
  --machine-type=n1-standard-4 \
  --enable-autoscaling --min-nodes=3 --max-nodes=10 \
  --no-issue-client-certificate --num-nodes=3 --image-type=cos \
  --enable-stackdriver-kubernetes \
  --scopes=cloud-platform,logging-write,monitoring-write,pubsub \
  --zone ${CLUSTER_ZONE} \
  --release-channel=rapid

7. Konfigurowanie zdarzeń Cloud Run (płaszczyzna sterowania)

Zdarzenia Cloud Run mają platformę sterującą i platformę danych, które należy skonfigurować osobno. Aby skonfigurować platformę sterującą:

W Cloud Shell:

gcloud beta events init

Spowoduje to zainicjowanie obsługi zdarzeń i utworzenie kilku potrzebnych kont usługi. Gdy pojawi się pytanie o utworzenie konta usługi, wybierz „Tak”.

Na tym etapie platforma sterująca powinna być prawidłowo zainicjowana. Powinny być widoczne 4 pody z symbolem

Running status, 2 (controller-xxx-xxx i webhook-xxx-xxx) w przestrzeni nazw cloud-run-events i 2 (eventing-controller-xxx-xxx i eventing-webhook-xxx-xxx) w przestrzeni nazw knative-eventing. Możesz to sprawdzić, wykonując te polecenia:

kubectl get pods -n cloud-run-events

NAME                         READY   STATUS    RESTARTS   AGE
controller-9cc679b67-2952n   1/1     Running   0          22s
webhook-8576c4cfcb-dhz82     1/1     Running   0          16m

kubectl get pods -n knative-eventing

NAME                                   READY   STATUS    RESTARTS   AGE
eventing-controller-77f46f6cf8-kj9ck   1/1     Running   0          17m
eventing-webhook-5bc787965f-hcmwg      1/1     Running   0          17m

8. Konfigurowanie zdarzeń Cloud Run (płaszczyzna danych)

Następnie skonfiguruj płaszczyznę danych w przestrzeniach nazw użytkowników. Tworzy brokera z odpowiednimi uprawnieniami do odczytu i zapisu w Pub/Sub.

W Cloud Shell ustaw zmienną środowiskową NAMESPACE dla przestrzeni nazw, której chcesz używać w przypadku swoich obiektów. Możesz ustawić wartość default, jeśli chcesz użyć domyślnej przestrzeni nazw, jak pokazano poniżej:

export NAMESPACE=default

Pamiętaj, że jeśli podana przestrzeń nazw nie istnieje (tzn. nie jest domyślna), musisz ją utworzyć:

kubectl create namespace ${NAMESPACE}

Zainicjuj przestrzeń nazw za pomocą domyślnego klucza tajnego:

gcloud beta events namespaces init ${NAMESPACE} --copy-default-secret

Utwórz brokera domyślnego w przestrzeni nazw:

gcloud beta events brokers create default --namespace ${NAMESPACE}

Sprawdź, czy broker został utworzony. Pamiętaj, że przygotowanie brokera może potrwać kilka sekund:

kubectl get broker -n ${NAMESPACE}

NAME      READY   REASON   URL
default   True             http://default-brokercell-ingress.cloud-run-events.svc.cluster.local/default/default

9. Odkrywanie wydarzeń

Możesz sprawdzić, jakie są zarejestrowane źródła, jakie typy zdarzeń mogą emitować i jak skonfigurować reguły, aby je wykorzystywać.

Aby wyświetlić listę różnych typów zdarzeń:

gcloud beta events types list

Aby dowiedzieć się więcej o poszczególnych typach zdarzeń:

gcloud beta events types describe google.cloud.pubsub.topic.v1.messagePublished

10. Tworzenie ujścia Cloud Run

Jako miejsce docelowe zdarzeń wdróż usługę Cloud Run, która rejestruje zawartość otrzymanego zdarzenia CloudEvent.

Możesz użyć event_display Knative, który jest już skompilowany, a jego obraz kontenera został utworzony w ramach wersji Knative. Szczegóły obrazu kontenera możesz zobaczyć w pliku event-display.yaml:

...
containers:
  - image: gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display@sha256:8da2440b62a5c077d9882ed50397730e84d07037b1c8a3e40ff6b89c37332b27

Wdróż w Cloud Run

Wdróż skonteneryzowaną aplikację w Cloud Run:

export SERVICE_NAME=event-display
gcloud run deploy ${SERVICE_NAME} \
  --namespace=${NAMESPACE} \
  --image gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display@sha256:8da2440b62a5c077d9882ed50397730e84d07037b1c8a3e40ff6b89c37332b27

Kiedy operacja zostanie wykonana, w wierszu poleceń wyświetli się URL usługi. Możesz teraz zobaczyć wdrożony kontener, otwierając URL usługi w dowolnym oknie przeglądarki.

11. Tworzenie aktywatora zdarzeń dla Cloud Pub/Sub

Jednym ze sposobów otrzymywania zdarzeń jest Cloud Pub/Sub. Aplikacje niestandardowe mogą publikować wiadomości w Cloud Pub/Sub, a wiadomości te mogą być dostarczane do miejsc docelowych Google Cloud Run za pomocą usługi Events for Cloud Run.

Tworzenie tematu

Najpierw utwórz temat Cloud Pub/Sub. Ciąg TOPIC_ID możesz zastąpić wybraną przez siebie niepowtarzalną nazwą tematu:

export TOPIC_ID=cr-gke-topic
gcloud pubsub topics create ${TOPIC_ID}

Tworzenie aktywatora

Zanim utworzysz aktywator, zapoznaj się ze szczegółami parametrów, których będziesz potrzebować do skonstruowania aktywatora zdarzeń z Cloud Pub/Sub:

gcloud beta events types describe google.cloud.pubsub.topic.v1.messagePublished

Utwórz aktywator, który będzie filtrować zdarzenia publikowane w temacie Cloud Pub/Sub wdrożonej usługi Cloud Run:

gcloud beta events triggers create trigger-pubsub \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type google.cloud.pubsub.topic.v1.messagePublished \
  --parameters topic=${TOPIC_ID}

Testowanie aktywatora

Aby sprawdzić, czy aktywator został utworzony, wyświetl listę wszystkich aktywatorów:

gcloud beta events triggers list

Może minąć do 10 minut, zanim utworzony aktywator zostanie rozpowszechniony i zacznie filtrować zdarzenia.

Aby zasymulować wysyłanie wiadomości przez aplikację niestandardową, możesz użyć gcloud, aby wywołać zdarzenie:

gcloud pubsub topics publish ${TOPIC_ID} --message="Hello there"

Utworzone przez nas ujście Cloud Run rejestruje treść wiadomości przychodzącej. Możesz to sprawdzić w sekcji Logi instancji Cloud Run:

Pamiętaj, że „Hello there” będzie zakodowane w formacie base64, ponieważ zostało wysłane przez Pub/Sub. Jeśli chcesz zobaczyć oryginalną wysłaną wiadomość, musisz ją zdekodować.

Usuń aktywator

Opcjonalnie po zakończeniu testowania możesz usunąć regułę.

gcloud beta events triggers delete trigger-pubsub --namespace ${NAMESPACE}

12. Tworzenie aktywatora zdarzeń dla dzienników kontrolnych

Skonfigurujesz aktywator, który będzie nasłuchiwać zdarzeń z logów kontrolnych. W dziennikach kontrolnych będziesz szukać zdarzeń związanych z tworzeniem tematów Pub/Sub.

Włączanie logów kontrolnych

Aby otrzymywać zdarzenia z usługi, musisz włączyć logi kontrolne. W Cloud Console w menu w lewym górnym rogu kliknij IAM & Admin > Audit Logs. Na liście usług sprawdź Google Cloud Pub/Sub:

Po prawej stronie sprawdź, czy wybrane są opcje Administracja, Odczyt i Zapis. Kliknij Zapisz:

Testowanie logów kontrolnych

Aby dowiedzieć się, jakie parametry musisz skonfigurować, aby utworzyć rzeczywisty aktywator, wykonaj rzeczywistą operację.

Na przykład utwórz temat Pub/Sub:

gcloud pubsub topics create cre-gke-topic1

Sprawdźmy teraz, jaki log kontrolny wygenerowała ta aktualizacja. W Cloud Console w menu w lewym górnym rogu kliknij Logging > Logs Viewer.

W sekcji Query Builder, wybierz Cloud Pub/Sub Topic i kliknij Add:

Po uruchomieniu zapytania zobaczysz logi tematów Pub/Sub. Jeden z nich powinien wyglądać tak: google.pubsub.v1.Publisher.CreateTopic

Zwróć uwagę na serviceName, methodName i resourceName. Użyjemy ich do utworzenia reguły.

Tworzenie aktywatora

Możesz teraz utworzyć wyzwalacz zdarzeń dla logów kontrolnych.

Więcej informacji o parametrach, których będziesz potrzebować do utworzenia reguły dla zdarzeń pochodzących ze źródeł Google Cloud, uzyskasz, uruchamiając to polecenie:

gcloud beta events types describe google.cloud.audit.log.v1.written

Utwórz wyzwalacz z odpowiednimi filtrami:

gcloud beta events triggers create trigger-auditlog \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type=google.cloud.audit.log.v1.written \
  --parameters serviceName=pubsub.googleapis.com \
  --parameters methodName=google.pubsub.v1.Publisher.CreateTopic

Testowanie aktywatora

Wyświetl listę wszystkich aktywatorów, aby sprawdzić, czy aktywator został utworzony:

gcloud beta events triggers list

Poczekaj do 10 minut, aż utworzenie aktywatora zostanie rozpropagowane i zacznie on filtrować zdarzenia. Gdy będzie gotowy, będzie filtrować zdarzenia tworzenia i wysyłać je do usługi. Możesz teraz wywołać zdarzenie.

Utwórz kolejny temat Pub/Sub, tak jak wcześniej:

gcloud pubsub topics create cre-gke-topic2

Jeśli sprawdzisz logi usługi Cloud Run w konsoli Google Cloud, zobaczysz otrzymane zdarzenie:

Usuwanie wyzwalacza i tematów

Opcjonalnie po zakończeniu testowania możesz usunąć aktywator:

gcloud beta events triggers delete trigger-auditlog

Usuń też tematy:

gcloud pubsub topics delete cre-gke-topic1 cre-gke-topic2

13. Tworzenie aktywatora zdarzeń dla Cloud Storage

Skonfigurujesz aktywator, który będzie nasłuchiwać zdarzeń z Cloud Storage.

Utwórz zasobnik

Najpierw utwórz zasobnik Cloud Storage w tym samym regionie co wdrożona usługa Cloud Run. Ciąg BUCKET_NAME możesz zastąpić wybraną przez siebie niepowtarzalną nazwą:

export BUCKET_NAME=[new bucket name]
export REGION=europe-west1

gsutil mb -p $(gcloud config get-value project) \
  -l $REGION \
  gs://$BUCKET_NAME/

Konfigurowanie uprawnień w Cloud Storage

Zanim utworzysz aktywator, musisz przyznać domyślnemu kontu usługi Cloud Storage uprawnienia do publikowania w Pub/Sub.

Najpierw musisz znaleźć konto usługi, którego Cloud Storage używa do publikowania w Pub/Sub. Aby uzyskać konto usługi, możesz wykonać czynności opisane w artykule Uzyskiwanie konta usługi Cloud Storage lub użyć tego polecenia:

curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://storage.googleapis.com/storage/v1/projects/$(gcloud config get-value project)/serviceAccount"

Konto usługi powinno być wymienione w sekcji email_address.

Załóżmy, że znalezione powyżej konto usługi to service-XYZ@gs-project-accounts.iam.gserviceaccount.com. Ustaw je jako zmienną środowiskową:

export GCS_SERVICE_ACCOUNT=service-XYZ@gs-project-accounts.iam.gserviceaccount.com

Następnie przyznaj temu kontu usługi uprawnienia do publikowania w Pub/Sub:

gcloud projects add-iam-policy-binding ${GOOGLE_CLOUD_PROJECT} \
  --member=serviceAccount:${GCS_SERVICE_ACCOUNT} \
  --role roles/pubsub.publisher

Tworzenie aktywatora

Możesz teraz utworzyć aktywator zdarzeń dla zdarzeń Cloud Storage.

Więcej informacji o parametrach, których będziesz potrzebować do utworzenia reguły:

gcloud beta events types describe google.cloud.storage.object.v1.finalized

Utwórz wyzwalacz z odpowiednimi filtrami:

gcloud beta events triggers create trigger-storage \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type=google.cloud.storage.object.v1.finalized \
  --parameters bucket=${BUCKET_NAME}

Testowanie aktywatora

Wyświetl listę wszystkich aktywatorów, aby sprawdzić, czy aktywator został utworzony:

gcloud beta events triggers list

Poczekaj do 10 minut, aż utworzenie aktywatora zostanie rozpropagowane i zacznie on filtrować zdarzenia. Gdy będzie gotowy, będzie filtrować zdarzenia tworzenia i wysyłać je do usługi.

Możesz teraz wywołać zdarzenie.

Prześlij losowy plik do zasobnika Cloud Storage:

echo "Hello World" > random.txt
gsutil cp random.txt gs://${BUCKET_NAME}/random.txt

Jeśli sprawdzisz logi usługi Cloud Run w konsoli Google Cloud, zobaczysz otrzymane zdarzenie:

Usuń aktywator

Opcjonalnie po zakończeniu testowania możesz usunąć aktywator:

gcloud beta events triggers delete trigger-storage

14. Tworzenie aktywatora zdarzeń dla Cloud Scheduler

Skonfigurujesz aktywator, który będzie nasłuchiwać zdarzeń z usługi Cloud Scheduler.

Tworzenie aplikacji App Engine

Usługa Cloud Scheduler wymaga obecnie utworzenia aplikacji App Engine. Wybierz lokalizację App Engine i utwórz aplikację:

export APP_ENGINE_LOCATION=europe-west
gcloud app create --region=${APP_ENGINE_LOCATION}

Utwórz aktywator

Więcej informacji o parametrach, których będziesz potrzebować do utworzenia reguły dla zdarzeń pochodzących ze źródeł Google Cloud, uzyskasz, uruchamiając to polecenie:

gcloud beta events types describe google.cloud.scheduler.job.v1.executed

Wybierz lokalizację Cloud Scheduler, w której chcesz utworzyć harmonogram:

export SCHEDULER_LOCATION=europe-west1

Utwórz regułę, która będzie tworzyć zadanie wykonywane co minutę w Google Cloud Scheduler i wywoływać usługę docelową:

gcloud beta events triggers create trigger-scheduler \
  --namespace ${NAMESPACE} \
  --target-service=${SERVICE_NAME} \
  --type=google.cloud.scheduler.job.v1.executed \
  --parameters location=${SCHEDULER_LOCATION} \
  --parameters schedule="* * * * *" \
  --parameters data="trigger-scheduler-data"

Testowanie aktywatora

Wyświetl listę wszystkich aktywatorów, aby sprawdzić, czy aktywator został utworzony:

gcloud beta events triggers list

Poczekaj do 10 minut, aż utworzenie aktywatora zostanie rozpropagowane i zacznie on filtrować zdarzenia. Gdy będzie gotowy, będzie filtrować zdarzenia tworzenia i wysyłać je do usługi.

Jeśli sprawdzisz logi usługi Cloud Run w konsoli Google Cloud, zobaczysz otrzymane zdarzenie.

Usuń aktywator

Opcjonalnie po zakończeniu testowania możesz usunąć aktywator:

gcloud beta events triggers delete trigger-scheduler

15. Zdarzenia niestandardowe (punkt końcowy brokera)

W tej części Codelabs utworzysz i wykorzystasz zdarzenia niestandardowe za pomocą brokera.

Tworzenie podu Curl do generowania zdarzeń

Zdarzenia są zwykle tworzone automatycznie. W tym kroku użyjesz jednak curl, aby ręcznie wysyłać poszczególne zdarzenia i sprawdzać, jak są one odbierane przez odpowiedniego odbiorcę.

Aby utworzyć poda, który będzie pełnił rolę producenta zdarzeń, uruchom to polecenie:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: curl
  name: curl
  namespace: $NAMESPACE
spec:
  containers:
  - image: radial/busyboxplus:curl
    imagePullPolicy: IfNotPresent
    name: curl
    resources: {}
    stdin: true
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    tty: true
EOF

Sprawdź, czy pod curl działa prawidłowo. Powinien się wyświetlić pod o nazwie curl z wartością Status=Running:

kubectl get pod curl -n ${NAMESPACE}

Tworzenie aktywatora

Utworzysz aktywator z filtrem określonego typu CloudEvents (w tym przypadku alpha-type), który będzie emitowany. Pamiętaj, że obsługiwane jest filtrowanie dopasowania ścisłego dowolnej liczby atrybutów CloudEvents, a także rozszerzeń. Jeśli filtr ustawia wiele atrybutów, aby aktywator odfiltrował dane zdarzenie, musi ono mieć wszystkie te atrybuty. Jeśli nie określisz filtra, w usłudze będą odbierane wszystkie zdarzenia.

Utwórz aktywator:

gcloud beta events triggers create trigger-custom \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type=alpha-type \
  --custom-type

Testowanie aktywatora

Wyświetl listę wszystkich aktywatorów, aby sprawdzić, czy aktywator został utworzony:

gcloud beta events triggers list

Utwórz zdarzenie, wysyłając żądanie HTTP do brokera. Aby przypomnieć sobie adres URL brokera, wykonaj to działanie:

kubectl get brokers -n ${NAMESPACE}

NAME      READY   REASON   URL
default   True             http://default-broker.<NAMESPACE>.svc.cluster.local

Połącz się przez SSH z utworzonym wcześniej podem curl:

kubectl --namespace ${NAMESPACE} attach curl -it

Połączenie SSH z pode zostało nawiązane. Możesz teraz wysłać żądanie HTTP. Pojawi się prośba podobna do tej poniżej:

Defaulting container name to curl.
Use 'kubectl describe pod/curl -n default' to see all of the containers in this pod.
If you don't see a command prompt, try pressing enter.
[ root@curl:/ ]$

Aby utworzyć wydarzenie:

curl -v "<BROKER-URL>" \
-X POST \
-H "Ce-Id: my-id" \
-H "Ce-Specversion: 1.0" \
-H "Ce-Type: alpha-type" \
-H "Ce-Source: my-source" \
-H "Content-Type: application/json" \
-d '{"msg":"send-cloudevents-to-broker"}'

Jeśli zdarzenie zostało odebrane, otrzymasz odpowiedź HTTP 202 Accepted. Zakończ sesję SSH, wpisując Ctrl + D.

Sprawdź, czy opublikowane zdarzenie zostało wysłane, przeglądając logi usługi Cloud Run:

kubectl logs --selector serving.knative.dev/service=$SERVICE_NAME \
 -c user-container -n $NAMESPACE --tail=100

Usuń aktywator

Opcjonalnie po zakończeniu testowania możesz usunąć aktywator:

gcloud beta events triggers delete trigger-custom

16. Gratulacje!

Gratulujemy ukończenia ćwiczenia.

Omówione zagadnienia

Długoterminowa wizja zdarzeń Cloud Run dla platformy Anthos
Obecny stan zdarzeń Cloud Run dla platformy Anthos
Tworzenie ujścia Cloud Run
Tworzenie aktywatora zdarzeń dla Cloud Pub/Sub
Tworzenie aktywatora zdarzeń dla dzienników kontrolnych
Tworzenie aktywatora zdarzeń dla Cloud Storage
Tworzenie aktywatora zdarzeń dla Cloud Scheduler
Generowanie i wykorzystywanie zdarzeń niestandardowych