Diese Seite wurde von der Cloud Translation API übersetzt.

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-Tool Knative und ermöglicht Ihnen, Container wahlweise vollständig verwaltet mit Cloud Run oder in einem Google Kubernetes Engine-Cluster mit Cloud Run for Anthos auszuführen.

Mit Events for Cloud Run for Anthos können Sie Cloud Run-Dienste ganz einfach mit Ereignissen aus einer Vielzahl von Quellen verbinden. Damit können Sie ereignisgesteuerte Architekturen erstellen, in denen Mikrodienste lose miteinander verknüpft und verteilt sind. Außerdem übernimmt er die Ereignisaufnahme, -bereitstellung, -sicherheit, -autorisierung und -behebung für Sie, was die Agilität der Entwickler und die Ausfallsicherheit von Anwendungen verbessert.

In diesem Codelab lernen Sie Ereignisse für Cloud Run for Anthos kennen. Genauer gesagt, überwachen Sie Ereignisse aus Cloud Pub/Sub, Audit-Logs, Cloud Storage und Cloud Scheduler und erfahren, wie Sie benutzerdefinierte Ereignisse erstellen/verwenden.

Lerninhalte

Langfristige Vision von Events for Cloud Run for Anthos
Aktueller Status von Ereignissen für Cloud Run for Anthos
Cloud Run-Senke 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 Sehfähigkeit

Mit dem Umstieg auf eine serverlose Architektur werden Ereignisse zu einem wichtigen Bestandteil der Kommunikation entkoppelter Mikrodienste. Mit Events for Cloud Run for Anthos sind Ereignisse ein wichtiger Bestandteil des Cloud Run for Anthos-Angebots, sodass sich ereignisgesteuerte serverlose Anwendungen ganz einfach erstellen lassen.

Events for Cloud Run for Anthos ermöglicht die zuverlässige, sichere und skalierbare asynchrone Ereignisübermittlung von gepackten oder in Apps erstellten Ereignisquellen an Nutzer im und außerhalb des Clusters.

Google Cloud-Quellen	Ereignisquellen, die Produkte von Google Cloud sind
Google-Quellen	Ereignisquellen, die Google-Produkte wie Gmail, Hangouts und Android Management umfassen
Benutzerdefinierte Quellen	Ereignisquellen, die keine Produkte von Google sind und von Endnutzern selbst erstellt werden. Dabei kann es sich um vom Nutzer entwickelte Knative Quellen oder eine beliebige andere im Cluster ausgeführte Anwendung handeln, die ein Cloud-Ereignis erzeugen kann.
Drittanbieterquellen	Ereignisquellen, die weder Google- noch Endnutzern gehören. Dazu gehören beliebte Veranstaltungsquellen wie GitHub, SAP, Datadog, PagerDuty usw., die sich im Besitz von Drittanbietern, Partnern oder OSS-Communitys befinden und von diesen verwaltet werden.

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

Events for Cloud Run entspricht Knative Eventing und ermöglicht die Portabilität von Containern zu und von anderen Knative-basierten Implementierungen. Dadurch erhalten Sie ein konsistentes, cloudagnostisches Framework für die deklarative Vernetzung von Ereigniserstellern mit Ereignisnutzern.

3. Aktueller Status

Diese Vorschau ist die erste Version, die erste langfristige Funktionen bietet.

Damit Nutzer ereignisgesteuerte serverlose Anwendungen erstellen können, konzentrieren wir uns anfangs auf zwei Dinge:

Stellen Sie ein breites System von Google Cloud-Quellen bereit, mit dem Cloud Run-Dienste im Anthos-Cluster auf Ereignisse aus Google Cloud-Diensten reagieren können.

Ereignisse aus Google Cloud-Quellen werden von Anfang an über Cloud-Audit-Logs (CAL) gesendet, 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. Bei jeder Veröffentlichung eines Ereignisses aus einer Google Cloud-Quelle wird ein entsprechender Cloud-Audit-Logeintrag erstellt.
Neben Cloud-Audit-Logs gibt es erstklassigen Support für die Nutzung von Ereignissen aus Cloud Storage, Cloud Pub/Sub und Cloud Scheduler. Im Zuge der Weiterentwicklung und des Feedbacks unserer Nutzer werden wir dieses Ökosystem weiter um hochwertigere Quellen erweitern.

Durch Veröffentlichen in einer Namespace-bezogenen cluster-lokalen Broker-URL können Endnutzeranwendungen und -dienste benutzerdefinierte Ereignisse ausgeben.

Der zugrunde liegende Übermittlungsmechanismus verwendet Cloud Pub/Sub-Themen und -Abonnements, die in den Projekten. Daher bietet die Funktion dieselben Zustellungsgarantien wie Cloud Pub/Sub.

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

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

Wir werden in iterativer Weise weiterhin einen Mehrwert erzielen – bis hin zu Google Analytics und darüber hinaus.

4. Einrichtung und Anforderungen

Umgebung für das selbstbestimmte 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 Ihr Anzeigename für dieses Projekt. Solange Sie die Namenskonventionen einhalten, können Sie beliebig festlegen und jederzeit aktualisieren.
Die Projekt-ID muss für alle Google Cloud-Projekte eindeutig sein und ist unveränderlich. Sie kann später nicht mehr geändert werden. Die Cloud Console generiert automatisch einen eindeutigen String. ist Ihnen meist egal, was es ist. In den meisten Codelabs musst du auf die Projekt-ID verweisen, die in der Regel als PROJECT_ID identifiziert wird. Wenn es dir nicht gefällt, kannst du eine weitere zufällige Projekt-ID generieren. Du kannst aber auch selbst eine andere testen, um zu sehen, ob sie verfügbar ist. Dann ist es „eingefroren“ sobald das Projekt erstellt ist.

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

Dieses Codelab sollte ohne großen Aufwand betrieben werden. Folgen Sie der Anleitung im Abschnitt „Bereinigen“, . Hier erfahren Sie, wie Sie Ressourcen herunterfahren, damit Ihnen über dieses Tutorial hinaus keine Kosten entstehen. Neue Google Cloud-Nutzer haben Anspruch auf eine kostenlose Testversion von 300$.

Cloud Shell starten

Sie können Google Cloud zwar von Ihrem Laptop aus aus der Ferne bedienen, in diesem Codelab verwenden Sie jedoch Google Cloud Shell, 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 dauert nur einen Moment. Wenn er abgeschlossen ist, sollten Sie in etwa Folgendes sehen:

Diese virtuelle Maschine verfügt über sämtliche Entwicklertools, die Sie benötigen. Es bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft auf Google Cloud, wodurch die Netzwerkleistung und Authentifizierung erheblich verbessert werden. Sie können alle Aufgaben in diesem Lab ganz einfach in einem Browser erledigen.

5. APIs aktivieren, Zone und Plattform festlegen

Projekt-ID einrichten und Alpha-Komponenten installieren

In Cloud Shell sollte für GOOGLE_CLOUD_PROJECT bereits Ihre Projekt-ID festgelegt sein. Ist dies nicht der Fall, prüfen Sie, ob sie konfiguriert und gcloud mit dieser Projekt-ID konfiguriert ist:

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-Ereignissen erstellen, legen Sie den Clusternamen, die Zone und die Plattform fest. Als Beispiel haben wir hier den Namen und die Zone auf events-cluster und europe-west1-b festgelegt. Die Plattform ist gke,.

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

Sie können prüfen, 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-Ereignissen erstellen

Erstellen Sie einen GKE-Cluster, auf dem Kubernetes >= 1.15.9-gke.26 ausgeführt wird, wobei die folgenden Add-ons aktiviert sind: 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-Ereignisse einrichten (Steuerungsebene)

Cloud Run-Ereignisse 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 Ereignising initialisiert. Außerdem werden mehrere erforderliche Dienstkonten erstellt. Achten Sie darauf, „Ja“ auszuwählen. wenn Sie zum Erstellen eines Dienstkontos aufgefordert werden.

Jetzt sollte die Steuerungsebene ordnungsgemäß initialisiert sein. Sie sollten vier Pods mit einem

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. Führen Sie dazu die folgenden Befehle aus:

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-Ereignisse einrichten (Datenebene)

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

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

export NAMESPACE=default

Wenn der angegebene Namespace nicht vorhanden ist (d.h., es ist kein 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 im Namespace einen Standard-Broker:

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. Ereignissuche

Sie erfahren, was die registrierten Quellen sind, welche Ereignistypen 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 ab:

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 CloudEvent-Ereignisses protokolliert.

Sie können das bereits kompilierte event_display von Knative und das zugehörige Container-Image verwenden, das im Rahmen des Knative-Release erstellt wurde. Details zum Container-Image 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 Ihre 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

Eine Möglichkeit, Ereignisse zu empfangen, ist über Cloud Pub/Sub. Benutzerdefinierte Anwendungen können Nachrichten in Cloud Pub/Sub veröffentlichen und diese Nachrichten können über Ereignisse für Cloud Run an Google Cloud Run-Senken gesendet 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

Informieren Sie sich vor dem Erstellen des Triggers über die Parameter, 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 im bereitgestellten Cloud Run-Dienst veröffentlicht wurden:

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 zehn Minuten dauern, bis der Trigger übernommen wird und Ereignisse gefiltert werden.

Wenn Sie eine benutzerdefinierte Anwendung simulieren möchten, die eine Nachricht sendet, können Sie mit gcloud ein Ereignis auslösen:

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

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

„Hallo!“ wird so Base64-codiert, wie sie von Pub/Sub gesendet wurde. Sie müssen es decodieren, wenn Sie sehen möchten, wie die ursprüngliche Nachricht gesendet wurde.

Trigger löschen

Optional können Sie den Trigger löschen, nachdem der Test abgeschlossen ist.

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

12. Ereignistrigger für Audit-Logs erstellen

Sie richten einen Trigger ein, um auf Ereignisse aus Audit-Logs zu warten. Genauer gesagt, suchen Sie in Audit-Logs nach Ereignissen zur Erstellung 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ü oben links IAM & Admin > Audit Logs aus. Klicken Sie in der Liste der Dienste auf das Kästchen für 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 für Tests

Um zu erfahren, wie Sie die Parameter identifizieren, müssen Sie einen tatsächlichen Trigger einrichten.

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 diese Aktualisierung generiert wurde. Wählen Sie in der Cloud Console im Menü oben links Logging > Logs Viewer aus.

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

Wenn Sie die Abfrage ausführen, werden Logs für Pub/Sub-Themen angezeigt. Eines dieser Themen sollte google.pubsub.v1.Publisher.CreateTopic sein:

Beachten Sie serviceName, methodName und resourceName. Wir verwenden diese beim Erstellen des Triggers.

Trigger erstellen

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

Wenn Sie den folgenden Befehl ausführen, erhalten Sie weitere Informationen zu den Parametern, 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

Listen Sie alle Trigger auf, um zu prüfen, ob der Trigger erfolgreich erstellt wurde:

gcloud beta events triggers list

Warten Sie bis zu 10 Minuten, bis der Trigger erstellt wurde und mit dem Filtern von Ereignissen beginnt. Anschließend werden erstellte Ereignisse gefiltert und an den Dienst gesendet. Jetzt können Sie ein Ereignis auslösen.

Erstellen Sie wie zuvor ein weiteres Pub/Sub-Thema:

gcloud pubsub topics create cre-gke-topic2

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

Trigger und Themen löschen

Optional können Sie den Trigger löschen, nachdem der Test abgeschlossen ist:

gcloud beta events triggers delete trigger-auditlog

Löschen Sie außerdem die Themen:

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

13. Ereignistrigger für Cloud Storage erstellen

Sie richten einen Trigger ein, um auf Ereignisse aus Cloud Storage zu warten.

Bucket erstellen

Erstellen Sie zuerst einen Cloud Storage-Bucket in derselben Region, in der sich auch der bereitgestellte Cloud Run-Dienst befindet. 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 mithilfe der Schritte unter Cloud Storage-Dienstkonto abrufen oder mit dem folgenden Befehl abrufen:

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.

Wenn das oben ermittelte Dienstkonto service-XYZ@gs-project-accounts.iam.gserviceaccount.com ist, legen Sie dies auf eine Umgebungsvariable fest:

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

Gewähren Sie diesem Dienstkonto dann die Berechtigung, in Pub/Sub zu veröffentlichen:

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.

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

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

Listen Sie alle Trigger auf, um zu prüfen, ob der Trigger erfolgreich erstellt wurde:

gcloud beta events triggers list

Warten Sie bis zu 10 Minuten, bis der Trigger erstellt wurde und mit dem Filtern von Ereignissen beginnt. Anschließend werden erstellte Ereignisse gefiltert und an den Dienst gesendet.

Jetzt können Sie ein Ereignis auslösen.

Laden Sie eine zufällige 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 prüfen, sollten Sie das empfangene Ereignis sehen:

Trigger löschen

Optional können Sie den Trigger löschen, nachdem der Test abgeschlossen ist:

gcloud beta events triggers delete trigger-storage

14. Ereignistrigger für Cloud Scheduler erstellen

Sie richten einen Trigger ein, um auf Ereignisse von Cloud Scheduler zu warten.

App Engine-Anwendung erstellen

Nutzer müssen für Cloud Scheduler derzeit eine App Engine-Anwendung erstellen. Wählen Sie einen App Engine-Speicherort aus und erstellen Sie die Anwendung:

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

Trigger erstellen

Wenn Sie den folgenden Befehl ausführen, erhalten Sie weitere Informationen zu den Parametern, 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-Speicherort aus, um den Planer zu erstellen:

export SCHEDULER_LOCATION=europe-west1

Erstellen Sie einen Trigger, der einen Job erstellt, der jede Minute in Google Cloud Scheduler ausgeführt werden soll, und rufen Sie den Zieldienst auf:

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

Listen Sie alle Trigger auf, um zu prüfen, ob der Trigger erfolgreich erstellt wurde:

gcloud beta events triggers list

Warten Sie bis zu 10 Minuten, bis der Trigger erstellt wurde und mit dem Filtern von Ereignissen beginnt. Anschließend werden erstellte Ereignisse gefiltert und an den Dienst gesendet.

Wenn Sie die Logs des Cloud Run-Dienstes in der Cloud Console prüfen, sollten Sie das empfangene Ereignis sehen.

Trigger löschen

Optional können Sie den Trigger löschen, nachdem der Test abgeschlossen ist:

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 normalerweise programmatisch erstellt. In diesem Schritt verwenden Sie jedoch curl, um einzelne Ereignisse manuell zu senden und zu sehen, wie sie vom richtigen Nutzer empfangen werden.

Führen Sie den folgenden Befehl aus, um einen Pod zu erstellen, der als Ereignisersteller 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 ordnungsgemäß 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 spezifischen 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 für den Trigger haben, damit es gefiltert werden kann. Umgekehrt werden alle Ereignisse in Ihrem Service empfangen, wenn Sie keinen Filter angeben.

Erstellen Sie den Trigger:

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

Trigger testen

Listen Sie alle 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. Erinnern Sie sich an die Broker-URL, indem Sie Folgendes ausführen:

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. Eine Meldung ähnlich der folgenden wird 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 einen Termin:

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 der Termin eingegangen ist, erhalten Sie eine HTTP 202 Accepted-Antwort. SSH-Sitzung mit Ctrl + D beenden

Prüfen Sie in den 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

Optional können Sie den Trigger löschen, nachdem der Test abgeschlossen ist:

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 Ereignissen für Cloud Run for Anthos
Cloud Run-Senke 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