Codelab zu Ereignissen für Cloud Run for Anthos

1. Einführung

Mit Cloud Run können Sie zustandslose Container in einer vollständig verwalteten Umgebung ausführen. Es basiert auf dem Open-Source-Projekt Knative. Damit können Sie Container wahlweise vollständig verwaltet mit Cloud Run oder in Ihrem Google Kubernetes Engine-Cluster mit Cloud Run for Anthos ausführen.

Mit Events for Cloud Run for Anthos lassen sich Cloud Run-Dienste ganz einfach mit Ereignissen aus verschiedenen Quellen verbinden. Damit können Sie ereignisgesteuerte Architekturen erstellen, in denen Mikrodienste lose gekoppelt und verteilt sind. Außerdem werden die Aufnahme, Bereitstellung, Sicherheit, Autorisierung und Fehlerbehandlung von Ereignissen für Sie übernommen, was die Agilität von Entwicklern und die Ausfallsicherheit von Anwendungen verbessert.

In diesem Codelab erfahren Sie mehr über Events for Cloud Run for Anthos. Sie lernen, wie Sie Ereignisse aus Cloud Pub/Sub, Audit-Logs, Cloud Storage und Cloud Scheduler überwachen und benutzerdefinierte Ereignisse erstellen/nutzen.

Lerninhalte

Langfristige Vision von Events for Cloud Run for Anthos
Aktueller Status von Events for Cloud Run for Anthos
Cloud Run-Senken erstellen
Ereignistrigger für Cloud Pub/Sub erstellen
Ereignistrigger für Audit-Logs erstellen
Ereignistrigger für Cloud Storage erstellen
Ereignistrigger für Cloud Scheduler erstellen
Benutzerdefinierte Ereignisse erstellen und verarbeiten

2. Langfristige Vision

Mit der Einführung der serverlosen Architektur werden Ereignisse zu einem integralen Bestandteil der Kommunikation zwischen entkoppelten Mikrodiensten. Mit Events for Cloud Run for Anthos werden Ereignisse zu einem wichtigen Bestandteil des Cloud Run for Anthos-Angebots, sodass es einfach ist, ereignisgesteuerte serverlose Anwendungen zu entwickeln.

Events for Cloud Run for Anthos ermöglicht die zuverlässige, sichere und skalierbare asynchrone Ereignisübermittlung von verpackten oder von Apps erstellten Ereignisquellen an Cluster- und Off-Cluster-Consumer.

Google Cloud-Quellen	Ereignisquellen, die Google Cloud-Produkte sind
Google-Quellen	Ereignisquellen, die Google-Produkte wie Gmail, Hangouts und Android Management sind
Benutzerdefinierte Quellen	Ereignisquellen, die keine Google-Produkte sind und von Endnutzern selbst erstellt werden. Das können von Nutzern entwickelte Knative-Quellen oder andere Anwendungen sein, die auf dem Cluster ausgeführt werden und ein Cloud-Ereignis erzeugen können.
Drittanbieterquellen	Ereignisquellen, die weder Google noch Endnutzern gehören. Dazu gehören beliebte Ereignisquellen wie GitHub, SAP, Datadog und PagerDuty, die von Drittanbietern, Partnern oder OSS-Communities verwaltet werden.

Ereignisse werden für die dienstübergreifende Interoperabilität im CloudEvents-Format v1.0 normalisiert. CloudEvents ist eine anbieterneutrale offene Spezifikation, die Ereignisdaten in gängigen Formaten beschreibt und die Interoperabilität zwischen Diensten, Plattformen und Systemen ermöglicht.

Events for Cloud Run entspricht Knative Eventing und ermöglicht die Portierung von Containern zu und von anderen Knative-basierten Implementierungen. So wird ein einheitliches, cloudunabhängiges Framework für die deklarative Verbindung von Ereignis-Producern mit Ereignis-Consumern bereitgestellt.

3. Aktueller Status

Diese Vorschau ist die erste Version, die eine erste Reihe der langfristigen Funktionen bietet.

Damit Nutzer ereignisgesteuerte serverlose Anwendungen erstellen können, konzentrieren wir uns zunächst auf zwei Bereiche:

Ein breites Ökosystem von Google Cloud-Quellen bereitstellen, mit denen Cloud Run-Dienste im Anthos-Cluster auf Ereignisse von Google Cloud-Diensten reagieren können.

Anfangs werden Ereignisse aus Google Cloud-Quellen über Cloud-Audit-Logs (CAL) bereitgestellt, wodurch eine Vielzahl von Ereignisquellen möglich ist. Die Latenz und Verfügbarkeit der Ereignisübermittlung aus diesen Quellen sind an die von Cloud-Audit-Logs gebunden. Immer wenn ein Ereignis aus einer Google Cloud-Quelle veröffentlicht wird, wird ein entsprechender Cloud-Audit-Logeintrag erstellt.
Neben Cloud-Audit-Logs werden Ereignisse aus Cloud Storage, Cloud Pub/Sub und Cloud Scheduler unterstützt. Wir werden dieses Ökosystem von Quellen weiter ausbauen und weitere erstklassige Quellen hinzufügen, sobald wir mehr über Nutzeraktionen und Feedback erfahren.

Endnutzeranwendungen und ‑dienste können benutzerdefinierte Ereignisse ausgeben, indem sie in einer Broker-URL auf Clusterebene mit Namespace-Bereich veröffentlicht werden.

Der zugrunde liegende Zustellungsmechanismus verwendet Cloud Pub/Sub-Themen und -Abos, die in den Projekten der Kunden sichtbar sind. Daher bietet die Funktion dieselben Zustellgarantien wie Cloud Pub/Sub.

Mit Event Trigger können Sie Ereignisse abonnieren, sodass Ereignisse, die dem Triggerfilter entsprechen, an das Ziel (oder die Senke) gesendet werden, auf das der Trigger verweist.

Alle Ereignisse werden im CloudEvents-Format v1.0 für die dienstübergreifende Interoperabilität bereitgestellt.

Wir werden bis zur allgemeinen Verfügbarkeit und darüber hinaus iterativ immer mehr Mehrwert bieten.

4. Einrichtung und Anforderungen

Umgebung zum selbstbestimmten Lernen einrichten

Melden Sie sich in der Cloud Console an und erstellen Sie ein neues Projekt oder verwenden Sie ein vorhandenes Projekt. Wenn Sie noch kein Gmail- oder Google Workspace-Konto haben, müssen Sie eines erstellen.

Der Projektname ist der Anzeigename für dieses Projekt. Solange Sie die Namenskonventionen einhalten, können Sie alles verwenden, was Sie möchten, und es jederzeit aktualisieren.
Die Projekt-ID muss für alle Google Cloud-Projekte eindeutig sein und ist unveränderlich (kann nach dem Festlegen nicht mehr geändert werden). In der Cloud Console wird automatisch ein eindeutiger String generiert. Normalerweise ist es nicht wichtig, wie dieser String aussieht. In den meisten Codelabs müssen Sie auf die Projekt-ID verweisen (die in der Regel als PROJECT_ID angegeben wird). Wenn Ihnen die ID nicht gefällt, können Sie eine andere zufällige ID generieren oder eine eigene ID ausprobieren und sehen, ob sie verfügbar ist. Sobald das Projekt erstellt wurde, wird es „eingefroren“.

Als Nächstes müssen Sie die Abrechnung in der Cloud Console aktivieren, um Google Cloud-Ressourcen verwenden zu können.

Die Durchführung dieses Codelabs sollte keine oder nur geringe Kosten verursachen. Folgen Sie bitte der Anleitung im Abschnitt „Bereinigen“, in der Sie erfahren, wie Sie Ressourcen herunterfahren können, damit nach Abschluss dieser Anleitung keine Gebühren anfallen. Neue Nutzer von Google Cloud kommen für das Programm für kostenlose Testversionen mit einem Guthaben von 300$ infrage.

Cloud Shell starten

Während Sie Google Cloud von Ihrem Laptop aus per Fernzugriff nutzen können, wird in diesem Codelab Google Cloud Shell verwendet, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.

Klicken Sie in der GCP Console oben rechts in der Symbolleiste auf das Cloud Shell-Symbol:

Die Bereitstellung und Verbindung mit der Umgebung sollte nur wenige Augenblicke dauern. Anschließend sehen Sie in etwa Folgendes:

Diese virtuelle Maschine verfügt über sämtliche Entwicklertools, die Sie benötigen. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft in Google Cloud, was die Netzwerkleistung und Authentifizierung erheblich verbessert. Für dieses Lab benötigen Sie lediglich einen Browser.

5. APIs aktivieren, Zone und Plattform festlegen

Projekt-ID einrichten und Alphakomponenten installieren

In Cloud Shell sollte GOOGLE_CLOUD_PROJECT bereits auf Ihre Projekt-ID festgelegt sein. Falls nicht, müssen Sie sie festlegen und gcloud mit dieser Projekt-ID konfigurieren:

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

Prüfen Sie, ob die gcloud-Komponente für Alpha installiert ist:

gcloud components install alpha

APIs aktivieren

Aktivieren Sie alle erforderlichen Dienste:

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

Zone und Plattform festlegen

Bevor Sie einen GKE-Cluster mit Cloud Run Events erstellen, legen Sie den Clusternamen, die Zone und die Plattform fest. Im folgenden Beispiel werden Name und Zone auf events-cluster und europe-west1-b und die Plattform auf gke, festgelegt.

In 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

So prüfen Sie, ob die Konfiguration festgelegt ist:

gcloud config list

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

6. GKE-Cluster mit Cloud Run Events erstellen

Erstellen Sie einen GKE-Cluster mit Kubernetes >= 1.15.9-gke.26 und den folgenden aktivierten Add-ons: 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. Cloud Run Events (Steuerungsebene) einrichten

Cloud Run Events haben eine Steuerungsebene und eine Datenebene, die separat eingerichtet werden müssen. So richten Sie die Steuerungsebene ein:

In Cloud Shell:

gcloud beta events init

Dadurch wird das Eventing initialisiert und eine Reihe erforderlicher Dienstkonten werden erstellt. Wählen Sie unbedingt „Ja“ aus, wenn Sie aufgefordert werden, ein Dienstkonto zu erstellen.

An diesem Punkt sollte die Steuerungsebene richtig initialisiert sein. Sie sollten vier Pods mit

Running-Status, 2 (controller-xxx-xxx und webhook-xxx-xxx) im Namespace cloud-run-events und 2 (eventing-controller-xxx-xxx und eventing-webhook-xxx-xxx) im Namespace knative-eventing. Mit den folgenden Befehlen können Sie dies prüfen:

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. Cloud Run Events (Datenebene) einrichten

Als Nächstes richten Sie die Datenebene in den Nutzer-Namespaces ein. Dadurch wird ein Broker mit den entsprechenden Berechtigungen zum Lesen/Schreiben aus/in Pub/Sub erstellt.

Legen Sie in Cloud Shell eine Umgebungsvariable NAMESPACE für den Namespace fest, den Sie für Ihre Objekte verwenden möchten. Sie können ihn auf default festlegen, wenn Sie den Standard-Namespace verwenden möchten, wie unten dargestellt:

export NAMESPACE=default

Wenn der angegebene Namespace nicht vorhanden ist (d.h. nicht der Standard-Namespace), müssen Sie ihn erstellen:

kubectl create namespace ${NAMESPACE}

Initialisieren Sie den Namespace mit dem Standard-Secret:

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

Erstellen Sie einen Standardbroker im Namespace:

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

Prüfen Sie, ob der Broker erstellt wurde. Es kann einige Sekunden dauern, bis der Broker bereit ist:

kubectl get broker -n ${NAMESPACE}

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

9. Ereignisse entdecken

Sie können herausfinden, welche Quellen registriert sind, welche Arten von Ereignissen sie ausgeben können und wie Sie Trigger konfigurieren, um sie zu nutzen.

So rufen Sie die Liste der verschiedenen Ereignistypen auf:

gcloud beta events types list

So rufen Sie weitere Informationen zu den einzelnen Ereignistypen auf:

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

10. Cloud Run-Senke erstellen

Stellen Sie als Ereignissenke einen Cloud Run-Dienst bereit, der den Inhalt des empfangenen CloudEvents protokolliert.

Sie können die bereits kompilierte event_display von Knative verwenden, deren Container-Image im Rahmen der Knative-Version erstellt wurde. Die Details des Container-Images finden Sie in event-display.yaml:

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

In Cloud Run bereitstellen

Stellen Sie die Containeranwendung in Cloud Run bereit:

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

Bei Erfolg wird in der Befehlszeile die Dienst-URL angezeigt. Sie können jetzt den bereitgestellten Container aufrufen, indem Sie die Dienst-URL in einem beliebigen Browserfenster öffnen.

11. Ereignistrigger für Cloud Pub/Sub erstellen

Cloud Pub/Sub bietet eine Möglichkeit, Ereignisse zu empfangen. Benutzerdefinierte Anwendungen können Nachrichten in Cloud Pub/Sub veröffentlichen. Diese Nachrichten können über Events for Cloud Run an Google Cloud Run-Senken übermittelt werden.

Thema erstellen

Erstellen Sie zuerst ein Cloud Pub/Sub-Thema. Sie können TOPIC_ID durch einen eindeutigen Themennamen Ihrer Wahl ersetzen:

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

Trigger erstellen

Bevor Sie den Trigger erstellen, rufen Sie weitere Informationen zu den Parametern ab, die Sie zum Erstellen eines Triggers für Ereignisse aus Cloud Pub/Sub benötigen:

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

Erstellen Sie einen Trigger, um Ereignisse zu filtern, die im Cloud Pub/Sub-Thema für unseren bereitgestellten Cloud Run-Dienst veröffentlicht werden:

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

Trigger testen

Sie können prüfen, ob der Trigger erstellt wurde, indem Sie alle Trigger auflisten:

gcloud beta events triggers list

Es kann bis zu 10 Minuten dauern, bis die Triggererstellung weitergegeben wurde und der Trigger mit dem Filtern von Ereignissen beginnt.

Um zu simulieren, dass eine benutzerdefinierte Anwendung eine Nachricht sendet, können Sie mit gcloud ein Ereignis auslösen:

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

Die von uns erstellte Cloud Run-Senke protokolliert den Text der eingehenden Nachricht. Sie können dies im Abschnitt „Logs“ Ihrer Cloud Run-Instanz sehen:

Beachten Sie, dass „Hello there“ base64-codiert wird, da es von Pub/Sub gesendet wurde. Sie müssen es also decodieren, wenn Sie die ursprüngliche Nachricht sehen möchten.

Trigger löschen

Optional können Sie den Trigger löschen, wenn Sie mit dem Testen fertig sind.

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

12. Ereignistrigger für Audit-Logs erstellen

Sie richten einen Trigger ein, um Ereignisse aus Audit-Logs zu überwachen. Genauer gesagt suchen Sie in Audit-Logs nach Ereignissen zum Erstellen von Pub/Sub-Themen.

Audit-Logs aktivieren

Damit Sie Ereignisse von einem Dienst erhalten, müssen Sie Audit-Logs aktivieren. Wählen Sie in der Cloud Console im Menü links oben die Option IAM & Admin > Audit Logs aus. Setzen Sie in der Liste der Dienste ein Häkchen bei Google Cloud Pub/Sub:

Achten Sie darauf, dass auf der rechten Seite „Administrator“, „Lesen“ und „Schreiben“ ausgewählt sind. Klicken Sie auf „Speichern“:

Audit-Logs testen

Sie erfahren, wie Sie die Parameter identifizieren, die Sie zum Einrichten eines tatsächlichen Triggers benötigen, und wie Sie einen tatsächlichen Vorgang ausführen.

Erstellen Sie beispielsweise ein Pub/Sub-Thema:

gcloud pubsub topics create cre-gke-topic1

Sehen wir uns nun an, welche Art von Audit-Log durch dieses Update generiert wurde. Wählen Sie in der Cloud Console im Menü links oben die Option Logging > Logs Viewer aus.

Wählen Sie unter Query Builder, die Option Cloud Pub/Sub Topic aus und klicken Sie auf Add:

Nachdem Sie die Abfrage ausgeführt haben, werden Logs für Pub/Sub-Themen angezeigt. Eines davon sollte google.pubsub.v1.Publisher.CreateTopic sein:

Achten Sie auf die serviceName, methodName und resourceName. Sie brauchen diese beim Erstellen des Triggers.

Trigger erstellen

Sie können jetzt einen Ereignistrigger für Audit-Logs erstellen.

Mit dem folgenden Befehl können Sie weitere Informationen zu den Parametern abrufen, die Sie zum Erstellen eines Triggers für Ereignisse aus Google Cloud-Quellen benötigen:

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

Erstellen Sie den Trigger mit den richtigen Filtern:

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

Trigger testen

Rufen Sie eine Liste aller Trigger auf, um zu prüfen, ob der Trigger erfolgreich erstellt wurde:

gcloud beta events triggers list

Warten Sie bis zu 10 Minuten, bis die Triggererstellung weitergegeben wurde und der Trigger mit dem Filtern von Ereignissen beginnt. Sobald er bereit ist, filtert er die „create“-Ereignisse und sendet sie an den Dienst. Sie können jetzt ein Ereignis auslösen.

Erstellen Sie ein weiteres Pub/Sub-Thema, wie Sie es bereits getan haben:

gcloud pubsub topics create cre-gke-topic2

Wenn Sie die Logs des Cloud Run-Dienstes in der Cloud Console aufrufen, sollten Sie das empfangene Ereignis sehen:

Trigger und Themen löschen

Nachdem Sie den Test abgeschlossen haben, können Sie den Trigger löschen:

gcloud beta events triggers delete trigger-auditlog

Lösche auch die folgenden Themen:

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

13. Ereignistrigger für Cloud Storage erstellen

Sie richten einen Trigger ein, um Ereignisse aus Cloud Storage zu überwachen.

Bucket erstellen

Erstellen Sie zuerst einen Cloud Storage-Bucket in derselben Region wie der bereitgestellte Cloud Run-Dienst. Sie können BUCKET_NAME durch einen eindeutigen Namen Ihrer Wahl ersetzen:

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

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

Cloud Storage-Berechtigungen einrichten

Bevor Sie einen Trigger erstellen, müssen Sie dem Standarddienstkonto für Cloud Storage die Berechtigung zum Veröffentlichen in Pub/Sub erteilen.

Zuerst müssen Sie das Dienstkonto finden, das Cloud Storage zum Veröffentlichen in Pub/Sub verwendet. Sie können das Dienstkonto mit der Anleitung unter Cloud Storage-Dienstkonto abrufen abrufen oder den folgenden Befehl verwenden:

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

Das Dienstkonto sollte unter email_address aufgeführt sein.

Angenommen, das Dienstkonto, das Sie oben gefunden haben, ist service-XYZ@gs-project-accounts.iam.gserviceaccount.com. Legen Sie es als Umgebungsvariable fest:

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

Gewähren Sie diesem Dienstkonto dann die Berechtigung zum Veröffentlichen in Pub/Sub:

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

Trigger erstellen

Sie können jetzt einen Ereignistrigger für Cloud Storage-Ereignisse erstellen.

Hier finden Sie weitere Informationen zu den Parametern, die Sie zum Erstellen des Triggers benötigen:

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

Erstellen Sie den Trigger mit den richtigen Filtern:

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

Trigger testen

Rufen Sie eine Liste aller Trigger auf, um zu prüfen, ob der Trigger erfolgreich erstellt wurde:

gcloud beta events triggers list

Sie können jetzt ein Ereignis auslösen.

Laden Sie eine beliebige Datei in den Cloud Storage-Bucket hoch:

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

Wenn Sie die Logs des Cloud Run-Dienstes in der Cloud Console aufrufen, sollten Sie das empfangene Ereignis sehen:

Trigger löschen

Nachdem Sie den Test abgeschlossen haben, können Sie den Trigger löschen:

gcloud beta events triggers delete trigger-storage

14. Ereignistrigger für Cloud Scheduler erstellen

Sie richten einen Trigger ein, um Ereignisse aus Cloud Scheduler zu überwachen.

App Engine-Anwendung erstellen

Derzeit müssen Nutzer eine App Engine-Anwendung erstellen, um Cloud Scheduler verwenden zu können. Wählen Sie einen App Engine-Standort aus und erstellen Sie die App:

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

Trigger erstellen

Mit dem folgenden Befehl können Sie weitere Informationen zu den Parametern abrufen, die Sie zum Erstellen eines Triggers für Ereignisse aus Google Cloud-Quellen benötigen:

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

Wählen Sie einen Cloud Scheduler-Standort aus, um den Scheduler zu erstellen:

export SCHEDULER_LOCATION=europe-west1

Erstellen Sie einen Trigger, mit dem ein Job erstellt wird, der jede Minute in Google Cloud Scheduler ausgeführt wird und den Zieldienst aufruft:

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"

Trigger testen

Rufen Sie eine Liste aller Trigger auf, um zu prüfen, ob der Trigger erfolgreich erstellt wurde:

gcloud beta events triggers list

Wenn Sie die Logs des Cloud Run-Dienstes in der Cloud Console aufrufen, sollte das empfangene Ereignis zu sehen sein.

Trigger löschen

Nachdem Sie den Test abgeschlossen haben, können Sie den Trigger löschen:

gcloud beta events triggers delete trigger-scheduler

15. Benutzerdefinierte Ereignisse (Broker-Endpunkt)

In diesem Teil des Codelabs erstellen und verarbeiten Sie benutzerdefinierte Ereignisse mit dem Broker.

Curl-Pod zum Erstellen von Ereignissen erstellen

Ereignisse werden in der Regel programmatisch erstellt. In diesem Schritt verwenden Sie jedoch curl, um einzelne Ereignisse manuell zu senden und zu sehen, wie diese Ereignisse vom richtigen Empfänger empfangen werden.

Führen Sie den folgenden Befehl aus, um einen Pod zu erstellen, der als Ereignis-Producer fungiert:

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

Prüfen Sie, ob der curl-Pod richtig funktioniert. Sie sollten einen Pod namens curl mit Status=Running sehen:

kubectl get pod curl -n ${NAMESPACE}

Trigger erstellen

Sie erstellen einen Trigger mit einem Filter für den jeweiligen CloudEvents-Typ (in diesem Fall alpha-type), den Sie ausgeben. Beachten Sie, dass das Filtern mit exakter Übereinstimmung anhand einer beliebigen Anzahl von CloudEvents-Attributen sowie Erweiterungen unterstützt wird. Wenn für Ihren Filter mehrere Attribute festgelegt sind, muss ein Ereignis alle Attribute haben, damit es vom Trigger gefiltert wird. Wenn Sie keinen Filter angeben, werden alle Ereignisse in Ihrem Dienst empfangen.

Erstellen Sie den Trigger:

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

Trigger testen

Rufen Sie eine Liste aller Trigger auf, um zu prüfen, ob der Trigger erfolgreich erstellt wurde:

gcloud beta events triggers list

Erstellen Sie ein Ereignis, indem Sie eine HTTP-Anfrage an den Broker senden. Rufen Sie die Broker-URL mit dem folgenden Befehl auf:

kubectl get brokers -n ${NAMESPACE}

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

Stellen Sie eine SSH-Verbindung zum Pod curl her, den Sie zuvor erstellt haben:

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

Sie haben eine SSH-Verbindung zum Pod hergestellt und können jetzt eine HTTP-Anfrage senden. Es wird eine Meldung ähnlich der folgenden angezeigt:

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:/ ]$

So erstellen Sie ein Ereignis:

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"}'

Wenn das Ereignis empfangen wurde, erhalten Sie eine HTTP 202 Accepted-Antwort. Beenden Sie die SSH-Sitzung mit Ctrl + D.

Prüfen Sie anhand der Logs des Cloud Run-Dienstes, ob das veröffentlichte Ereignis gesendet wurde:

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

Trigger löschen

Nachdem Sie den Test abgeschlossen haben, können Sie den Trigger löschen:

gcloud beta events triggers delete trigger-custom

16. Glückwunsch!

Herzlichen Glückwunsch zum Abschluss des Codelabs.

Behandelte Themen

Langfristige Vision von Events for Cloud Run for Anthos
Aktueller Status von Events for Cloud Run for Anthos
Cloud Run-Senken erstellen
Ereignistrigger für Cloud Pub/Sub erstellen
Ereignistrigger für Audit-Logs erstellen
Ereignistrigger für Cloud Storage erstellen
Ereignistrigger für Cloud Scheduler erstellen
Benutzerdefinierte Ereignisse erstellen und verarbeiten