1. Wprowadzenie
Cloud Run umożliwia uruchamianie bezstanowych kontenerów w środowisku w pełni zarządzanym. Zostało ono stworzone na podstawie oprogramowania open source Knative, co pozwala uruchamiać w pełni zarządzane kontenery w Cloud Run lub kontenery w klastrze Google Kubernetes Engine za pomocą Cloud Run for Anthos.
Zdarzenia dla Cloud Run dla platformy Anthos ułatwiają łą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, dostarczaniem, bezpieczeństwem, autoryzacją i obsługą błędów, co zwiększa elastyczność programistów oraz odporność aplikacji.
Z tego ćwiczenia w Codelabs dowiesz się więcej o zdarzeniach w Cloud Run for Anthos. Dokładniej rzecz ujmując, będziesz nasłuchiwać zdarzeń z Cloud Pub/Sub, logów kontrolnych, Cloud Storage, Cloud Scheduler oraz dowiedzieć się, jak tworzyć i wykorzystywać zdarzenia niestandardowe.
Czego się nauczysz
- Długoterminowa wizja zdarzeń w Cloud Run for Anthos
- Bieżący stan zdarzeń w Cloud Run for Anthos
- Tworzenie ujścia w Cloud Run
- Tworzenie aktywatora zdarzeń dla Cloud Pub/Sub
- Tworzenie aktywatora zdarzeń dla logów kontrolnych
- Tworzenie aktywatora zdarzeń dla Cloud Storage
- Tworzenie aktywatora zdarzeń dla usługi Cloud Scheduler
- Generuj i wykorzystuj zdarzenia niestandardowe
2. Wizja długoterminowa
Wprowadzamy architekturę bezserwerową, więc zdarzenia stają się integralną częścią sposobu komunikacji odłączonych mikroserwisów. Zdarzenia dla Cloud Run dla platformy Anthos sprawiają, że zdarzenia stają się głównym elementem oferty Cloud Run for Anthos, co ułatwia tworzenie bezserwerowych aplikacji opartych na zdarzeniach.
Zdarzenia w Cloud Run for Anthos umożliwiają niezawodne, bezpieczne i skalowalne asynchroniczne dostarczanie zdarzeń ze źródeł w pakietach lub utworzonych przez aplikację do konsumentów znajdujących się w klastrze i poza klastrami.
Źródła Google Cloud | Źródła zdarzeń będące usługami należącymi do Google Cloud |
Źródła Google | Źródła zdarzeń będące usługami Google, np. Gmail, Hangouts czy Zarządzanie urządzeniami z Androidem |
Źródła niestandardowe | źródła zdarzeń, które nie są usługami Google i są tworzone przez użytkowników; Mogą to być stworzone przez użytkowników Knative serving lub inne aplikacje działające w klastrze, które mogą generować zdarzenia w chmurze. |
Źródła zewnętrzne | Źródła zdarzeń, które nie są własnością Google ani użytkownika. Obejmuje to popularne źródła zdarzeń, takie jak GitHub, SAP, Datadog czy Pagerduty, które należą do zewnętrznych dostawców, partnerów lub społeczności OSS i są przez nie obsługiwane. |
Zdarzenia są znormalizowane do formatu CloudEvents v1.0, aby zapewnić interoperacyjność między usługami. CloudEvents to otwarta specyfikacja otwarta przez dostawcę, która opisuje dane zdarzeń w typowych formatach, umożliwiając interoperacyjność między usługami, platformami i systemami.
Zdarzenia w Cloud Run są zgodne z zasadami Knative Eventing i umożliwiają przenoszenie kontenerów do innych implementacji opartych na Knative. W ten sposób zapewniamy spójną, niezależną od chmury platformę dla deklaratywnych rozwiązań, które umożliwiają producentom skomunikowanie się z konsumentami.
3. Bieżący stan
Jest to pierwsza wersja, która zawiera początkowy zestaw długoterminowych funkcji.
Aby umożliwić użytkownikom tworzenie bezserwerowych aplikacji opartych na zdarzeniach, skupiamy się na 2 etapach:
- Zapewniają szeroki ekosystem źródeł Google Cloud, dzięki którym usługi Cloud Run w klastrze Anthos mogą reagować na zdarzenia z usług Google Cloud.
- Zdarzenia ze źródeł Google Cloud są początkowo dostarczane za pomocą logów kontrolnych Cloud (CAL), co zapewnia szeroką gamę źródeł zdarzeń. Czas oczekiwania i dostępność dostarczania zdarzeń z tych źródeł są powiązane z logami kontrolnymi Cloud. Po opublikowaniu zdarzenia ze źródła Google Cloud tworzony jest odpowiedni wpis w logu kontrolnym Cloud.
- Oprócz logów kontrolnych Cloud dostępna jest pierwsza klasa obsługa zdarzeń z usług Cloud Storage, Cloud Pub/Sub i Cloud Scheduler. Będziemy dalej rozbudowywać ten ekosystem źródeł o kolejne źródła pierwszej klasy w miarę uzyskiwania kolejnych danych z doświadczenia i opinii użytkowników.
- Włącz wysyłanie zdarzeń niestandardowych przez aplikacje i usługi użytkowników, publikując je pod adresem URL lokalnego brokera do klastra o zakresie na poziomie przestrzeni nazw.
Podstawowy mechanizm dostarczania używa tematów i subskrypcji Cloud Pub/Sub, które są widoczne w sekcji w projektach AI. Dlatego ta funkcja zapewnia te same gwarancje dostarczania co Cloud Pub/Sub.
Aktywator zdarzeń umożliwia subskrybowanie zdarzeń, dzięki czemu zdarzenia pasujące do filtra reguły są dostarczane do miejsca docelowego (lub ujścia), do którego wskazuje reguła.
Wszystkie zdarzenia są dostarczane w formacie zdarzeń w chmurze v1.0, co zapewnia interoperacyjność między usługami.
Nadal będziemy zwiększać wartość stopniowo, aż do poziomu GA i innych obszarów.
4. 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 to Twoja wyświetlana nazwa tego projektu. Jeśli przestrzegasz konwencji nazewnictwa, możesz używać dowolnych nazw i w każdej chwili je zmienić.
- Identyfikator projektu musi być unikalny we wszystkich projektach Google Cloud i nie można go zmienić (po ustawieniu nie można go zmienić). Konsola Cloud 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 kod lub wypróbuj swój własny i sprawdź, czy jest dostępny. Potem urządzenie jest „zawieszone”. po utworzeniu projektu.
- Następnie musisz włączyć płatności w Cloud Console, aby korzystać z zasobów Google Cloud.
Ukończenie tego ćwiczenia z programowania nie powinno kosztować zbyt wiele. Postępuj zgodnie z instrukcjami podanymi w sekcji „Czyszczenie” W tym samouczku znajdziesz wskazówki, jak wyłączyć zasoby, aby uniknąć naliczania opłat. 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 Cloud.
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.
5. Włącz interfejsy API, ustaw strefę i platformę
Skonfiguruj identyfikator projektu i zainstaluj komponenty w wersji alfa
W Cloud Shell parametr GOOGLE_CLOUD_PROJECT powinien już być ustawiony na identyfikator Twojego projektu. Jeśli nie, upewnij się, że jest ustawiony, a w gcloud jest skonfigurowany ten identyfikator projektu:
export GOOGLE_CLOUD_PROJECT=your-project-id
gcloud config set project ${GOOGLE_CLOUD_PROJECT}
Upewnij się, że jest zainstalowany komponent gcloud dla wersji alfa:
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 ze zdarzeniami Cloud Run, ustaw nazwę klastra, jego strefę i platformę. W tym przykładzie ustawiliśmy nazwę i strefę na events-cluster i europe-west1-b, a platforma to 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 ze zdarzeniami Cloud Run
Utwórz klaster GKE z zainstalowanym systemem Kubernetes >= 1.15.9-gke.26 z włączonymi 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. Skonfiguruj zdarzenia Cloud Run (platforma sterująca)
Zdarzenia Cloud Run mają platformę sterującą i platformę danych, które należy skonfigurować oddzielnie. Aby skonfigurować platformę sterującą:
W Cloud Shell:
gcloud beta events init
Spowoduje to zainicjowanie obsługi zdarzeń i utworzenie wymaganej liczby kont usługi. Upewnij się, że masz wybraną opcję „Tak”. gdy pojawi się prośba o utworzenie konta usługi.
W tym momencie platforma sterująca powinna być prawidłowo zainicjowana. Powinny się wyświetlić 4 pody z atrybutem
Stan funkcji Running, stan 2 (controller-xxx-xxx i webhook-xxx-xxx) w przestrzeni nazw cloud-run-events oraz 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 (platforma danych)
Następnym krokiem jest skonfigurowanie obszaru danych w przestrzeniach nazw użytkownika. Spowoduje to utworzenie brokera z odpowiednimi uprawnieniami do odczytu/zapisu z/do Pub/Sub.
W Cloud Shell ustaw zmienną środowiskową NAMESPACE dla przestrzeni nazw, której chcesz używać na potrzeby obiektów. Możesz ustawić wartość default, jeśli chcesz używać domyślnej przestrzeni nazw w następujący sposób:
export NAMESPACE=default
Pamiętaj, że jeśli podana przestrzeń nazw nie istnieje (tzn. przestrzeń nazw nie jest domyślna), musisz ją utworzyć:
kubectl create namespace ${NAMESPACE}
Zainicjuj przestrzeń nazw za pomocą domyślnego obiektu tajnego:
gcloud beta events namespaces init ${NAMESPACE} --copy-default-secret
Utwórz domyślnego brokera w przestrzeni nazw:
gcloud beta events brokers create default --namespace ${NAMESPACE}
Sprawdź, czy broker został utworzony. Pamiętaj, że może minąć kilka sekund, zanim broker będzie gotowy:
kubectl get broker -n ${NAMESPACE}
NAME READY REASON URL
default True http://default-brokercell-ingress.cloud-run-events.svc.cluster.local/default/default
9. Wykrywanie zdarzeń
Możesz dowiedzieć się, co to są zarejestrowane źródła, jakie zdarzenia mogą generować i jak skonfigurować aktywatory, aby z nich korzystać.
Aby wyświetlić listę różnych typów zdarzeń:
gcloud beta events types list
Aby uzyskać więcej informacji o poszczególnych typach zdarzeń:
gcloud beta events types describe google.cloud.pubsub.topic.v1.messagePublished
10. Tworzenie ujścia w Cloud Run
Jako ujście zdarzeń wdróż usługę Cloud Run, która rejestruje zawartość odbieranego zdarzenia CloudEvent.
Możesz użyć już skompilowanego parametru event_display Knative i obrazu kontenera utworzonego w ramach wersji Knative. Szczegóły obrazu kontenera znajdziesz w pliku event-display.yaml:
... containers: - image: gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display@sha256:8da2440b62a5c077d9882ed50397730e84d07037b1c8a3e40ff6b89c37332b27
Wdrażanie 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 odbierania zdarzeń jest Cloud Pub/Sub. Aplikacje niestandardowe mogą publikować wiadomości w Cloud Pub/Sub, które mogą być dostarczane do ujść Google Cloud Run za pomocą zdarzeń Cloud Run.
Tworzenie tematu
Najpierw utwórz temat Cloud Pub/Sub. Ciąg TOPIC_ID możesz zastąpić preferowaną nazwą tematu:
export TOPIC_ID=cr-gke-topic
gcloud pubsub topics create ${TOPIC_ID}
Tworzenie aktywatora
Zanim utworzysz aktywator, dowiedz się więcej o parametrach potrzebnych do utworzenia aktywatora dla zdarzeń z Cloud Pub/Sub:
gcloud beta events types describe google.cloud.pubsub.topic.v1.messagePublished
Utwórz aktywator do filtrowania zdarzeń opublikowanych w temacie Cloud Pub/Sub w naszej wdrożonej usłudze 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 reguły
Aby sprawdzić, czy reguła została utworzona, wyświetl listę wszystkich wyzwalaczy:
gcloud beta events triggers list
Może minąć do 10 minut, zanim utworzenie reguły zostanie rozpowszechnione i rozpocznie się filtrowanie zdarzeń.
Aby symulować wysyłanie wiadomości przez aplikację niestandardową, możesz użyć polecenia gcloud do wywołania zdarzenia:
gcloud pubsub topics publish ${TOPIC_ID} --message="Hello there"
Utworzony przez nas ujście Cloud Run rejestruje treść wiadomości przychodzącej. Możesz to zobaczyć w sekcji Logi instancji Cloud Run:
Zwróć uwagę na komunikat „Cześć”, będzie zakodowany w formacie base64 w taki sposób, w jaki został wysłany przez Pub/Sub i trzeba będzie go zdekodować, aby zobaczyć wysłaną oryginalnie wiadomość.
Usuwanie reguły
Opcjonalnie po zakończeniu testów możesz usunąć aktywator.
gcloud beta events triggers delete trigger-pubsub --namespace ${NAMESPACE}
12. Tworzenie aktywatora zdarzeń dla logów kontrolnych
Skonfigurujesz aktywator, który będzie nasłuchiwać zdarzeń z logów kontrolnych. Dokładniej rzecz ujmując, w logach kontrolnych będziesz szukać zdarzeń tworzenia tematu Pub/Sub.
Włącz logi kontrolne
Aby otrzymywać zdarzenia z usługi, musisz włączyć logi kontrolne. W Cloud Console wybierz IAM & Admin > Audit Logs w menu w lewym górnym rogu. Na liście usług zaznacz Google Cloud Pub/Sub:
Po prawej stronie wybierz Administracja, Odczyt i zapis. Kliknij Zapisz:
Testowanie logów kontrolnych
Aby dowiedzieć się, jak zidentyfikować parametry, musisz skonfigurować rzeczywistą regułę, wykonując rzeczywistą operację.
Na przykład utwórz temat Pub/Sub:
gcloud pubsub topics create cre-gke-topic1
Zobaczmy teraz, jakiego rodzaju dziennik kontrolny został wygenerowany w ramach tej aktualizacji. W Cloud Console wybierz Logging > Logs Viewer w menu w lewym górnym rogu.
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 mieć stan google.pubsub.v1.Publisher.CreateTopic:
Zwróć uwagę na serviceName, methodName i resourceName. Wykorzystamy je przy tworzeniu reguł.
Tworzenie aktywatora
Teraz możesz utworzyć aktywator zdarzeń dla logów kontrolnych.
Więcej informacji o parametrach potrzebnych do utworzenia aktywatora zdarzeń ze źródeł Google Cloud możesz uzyskać, uruchamiając to polecenie:
gcloud beta events types describe google.cloud.audit.log.v1.written
Utwórz regułę 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 reguły
Wyświetl wszystkie aktywatory, aby potwierdzić, że aktywator został utworzony:
gcloud beta events triggers list
Poczekaj do 10 minut na rozpowszechnienie tworzenia reguły i rozpoczęcie filtrowania zdarzeń. Gdy wszystko będzie gotowe, przefiltruje zdarzenia tworzenia i wyśle je do usługi. Teraz możesz uruchomić zdarzenie.
Utwórz kolejny temat Pub/Sub, tak jak poprzednio:
gcloud pubsub topics create cre-gke-topic2
Jeśli sprawdzisz logi usługi Cloud Run w konsoli Cloud, powinno być tam widoczne otrzymane zdarzenie:
Usuwanie reguły i tematów
Opcjonalnie po zakończeniu testów 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 do nasłuchiwania zdarzeń z Cloud Storage.
Tworzenie zasobnika
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ć preferowaną nazwą:
export BUCKET_NAME=[new bucket name] export REGION=europe-west1 gsutil mb -p $(gcloud config get-value project) \ -l $REGION \ gs://$BUCKET_NAME/
Skonfiguruj uprawnienia Cloud Storage
Zanim utworzysz aktywator, musisz nadać domyślnemu kontu usługi uprawnienia do publikowania w Pub/Sub w Cloud Storage.
Najpierw musisz znaleźć konto usługi, którego Cloud Storage używa do publikowania w Pub/Sub. Możesz wykonać czynności opisane w artykule Uzyskiwanie konta usługi Cloud Storage albo 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 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
Teraz możesz utworzyć aktywator zdarzeń dla zdarzeń Cloud Storage.
Więcej informacji o parametrach potrzebnych do utworzenia reguły:
gcloud beta events types describe google.cloud.storage.object.v1.finalized
Utwórz regułę 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 reguły
Wyświetl wszystkie aktywatory, aby potwierdzić, że aktywator został utworzony:
gcloud beta events triggers list
Poczekaj do 10 minut na rozpowszechnienie tworzenia reguły i rozpoczęcie filtrowania zdarzeń. Gdy wszystko będzie gotowe, przefiltruje zdarzenia tworzenia i wyśle je do usługi.
Teraz możesz uruchomić 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 Cloud, powinno być tam widoczne otrzymane zdarzenie:
Usuwanie reguły
Opcjonalnie po zakończeniu testów możesz usunąć aktywator:
gcloud beta events triggers delete trigger-storage
14. Tworzenie aktywatora zdarzeń dla usługi Cloud Scheduler
Skonfigurujesz aktywator do nasłuchiwania zdarzeń z usługi Cloud Scheduler.
Tworzenie aplikacji App Engine
Usługa Cloud Scheduler wymaga obecnie od użytkowników 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 potrzebnych do utworzenia aktywatora zdarzeń ze źródeł Google Cloud możesz uzyskać, uruchamiając to polecenie:
gcloud beta events types describe google.cloud.scheduler.job.v1.executed
Wybierz lokalizację usługi Cloud Scheduler, aby utworzyć algorytm szeregowania:
export SCHEDULER_LOCATION=europe-west1
Utwórz aktywator, który utworzy zadanie do wykonania co minutę w usłudze Google Cloud Scheduler i wywoła 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 reguły
Wyświetl wszystkie aktywatory, aby potwierdzić, że aktywator został utworzony:
gcloud beta events triggers list
Poczekaj do 10 minut na rozpowszechnienie tworzenia reguły i rozpoczęcie filtrowania zdarzeń. Gdy wszystko będzie gotowe, przefiltruje zdarzenia tworzenia i wyśle je do usługi.
Powinien pojawić się odebrane zdarzenie, jeśli sprawdzisz logi usługi Cloud Run w konsoli Cloud.
Usuwanie reguły
Opcjonalnie po zakończeniu testów możesz usunąć aktywator:
gcloud beta events triggers delete trigger-scheduler
15. Zdarzenia niestandardowe (punkt końcowy brokera)
W tej części ćwiczenia w Codelabs będziesz tworzyć i wykorzystywać zdarzenia niestandardowe za pomocą brokera.
Utwórz poda Curl do generowania zdarzeń
Wydarzenia są zwykle tworzone automatycznie. W tym kroku użyjesz jednak usługi curl, aby ręcznie wysyłać poszczególne zdarzenia i sprawdzić, jak są one odbierane przez odpowiednich klientów.
Aby utworzyć poda działającego jako producent 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 pojawić się blok o nazwie curl z wartością Status=Running:
kubectl get pod curl -n ${NAMESPACE}
Tworzenie aktywatora
Utworzysz aktywator z filtrem konkretnego typu CloudEvents (w tym przypadku alpha-type), który będzie emitowany. Pamiętaj, że obsługiwane jest filtrowanie dopasowania ścisłego według dowolnej liczby atrybutów CloudEvents oraz rozszerzeń. Jeśli filtr ustawia wiele atrybutów, zdarzenie musi mieć wszystkie atrybuty, aby reguła mogła je filtrować. Jeśli natomiast nie określisz filtra, wszystkie zdarzenia będą odbierane w usłudze.
Utwórz regułę:
gcloud beta events triggers create trigger-custom \
--namespace ${NAMESPACE} \
--target-service ${SERVICE_NAME} \
--type=alpha-type \
--custom-type
Testowanie reguły
Wyświetl wszystkie aktywatory, aby potwierdzić, że aktywator został utworzony:
gcloud beta events triggers list
Utwórz zdarzenie, wysyłając żądanie HTTP do brokera. Przypomnij sobie adres URL brokera, uruchamiając to polecenie:
kubectl get brokers -n ${NAMESPACE}
NAME READY REASON URL
default True http://default-broker.<NAMESPACE>.svc.cluster.local
Połącz się z utworzonym wcześniej podem curl przez SSH:
kubectl --namespace ${NAMESPACE} attach curl -it
Udało Ci się połączyć z podem przez SSH i możesz teraz wysłać żądanie HTTP. Wyświetli się prompt podobny do tego 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:/ ]$
Tworzenie wydarzenia:
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 wydarzenie zostało odebrane, otrzymasz odpowiedź HTTP 202 Accepted. Zakończ sesję SSH za pomocą dodatku Ctrl + D
Sprawdź w logach usługi Cloud Run, czy opublikowane zdarzenie zostało wysłane:
kubectl logs --selector serving.knative.dev/service=$SERVICE_NAME \ -c user-container -n $NAMESPACE --tail=100
Usuwanie reguły
Opcjonalnie po zakończeniu testów możesz usunąć aktywator:
gcloud beta events triggers delete trigger-custom
16. Gratulacje!
Gratulujemy ukończenia ćwiczeń z programowania.
Omówione zagadnienia
- Długoterminowa wizja zdarzeń w Cloud Run for Anthos
- Bieżący stan zdarzeń w Cloud Run for Anthos
- Tworzenie ujścia w Cloud Run
- Tworzenie aktywatora zdarzeń dla Cloud Pub/Sub
- Tworzenie aktywatora zdarzeń dla logów kontrolnych
- Tworzenie aktywatora zdarzeń dla Cloud Storage
- Tworzenie aktywatora zdarzeń dla usługi Cloud Scheduler
- Generuj i wykorzystuj zdarzenia niestandardowe