Trigger für Cloud Run erstellen

Sie können einen Eventarc-Trigger erstellen, damit Ihr Cloud Run-Dienst Benachrichtigungen über ein bestimmtes Ereignis oder einen Satz von Ereignissen erhält. Durch Angabe von Filtern für den Trigger können Sie das Routing des Ereignisses konfigurieren, einschließlich der Ereignisquelle und des Cloud Run-Zieldienstes.

Anfragen an Ihren Dienst werden durch die folgenden Ereignistypen ausgelöst:

Ein Audit-Log wird erstellt, das den Filterkriterien des Triggers entspricht
Direkte Ereignisse, z. B. eine Aktualisierung eines Cloud Storage-Buckets
In einem Pub/Sub-Thema veröffentlichte Nachrichten

Sie können Trigger mithilfe der Google Cloud CLI oder über die Google Cloud Console erstellen.

Einige der Schritte in diesem Dokument funktionieren möglicherweise nicht richtig, wenn Ihre Organisation Einschränkungen auf Ihre Google Cloud-Umgebung anwendet. In diesem Fall können Sie möglicherweise keine Aufgaben wie das Erstellen öffentlicher IP-Adressen oder Dienstkontoschlüssel ausführen. Wenn Sie eine Anfrage stellen, die einen Fehler zu Einschränkungen zurückgibt, lesen Sie, wie Anwendungen in einer eingeschränkten Google Cloud-Umgebung entwickeln werden.

Erstellung eines Triggers vorbereiten

Bevor Sie einen Trigger erstellen, müssen Sie folgende Voraussetzungen erfüllen:

APIs aktivieren:

gcloud services enable cloudbuild.googleapis.com \
    eventarc.googleapis.com \
    logging.googleapis.com \
    pubsub.googleapis.com \
    run.googleapis.com \
    workflows.googleapis.com

Erstellen Sie ein nutzerverwaltetes Dienstkonto, falls Sie noch keines haben, oder verwenden Sie das Standarddienstkonto.
```
SERVICE_ACCOUNT=SA_NAME
gcloud iam service-accounts create ${SERVICE_ACCOUNT}
```
SA_NAME durch den Namen des Dienstkontos. Der Name des Dienstkontos muss zwischen 6 und 30 Zeichen lang sein und darf alphanumerische Zeichen in Kleinschreibung sowie Bindestriche enthalten. Nachdem Sie ein Dienstkonto erstellt haben, können Sie den Namen nicht mehr ändern.
Beachten Sie, dass in den Beispielen auf dieser Seite das Compute Engine-Standarddienstkonto verwendet wird.
Erteilen Sie die erforderlichen IAM-Rollen, -Berechtigungen und -Flags (Identity and Access Management) für authentifizierte und nicht authentifizierte Aufrufe. Weitere Informationen finden Sie unter Eventarc-Rollen und -Berechtigungen.

Wichtig: Um authentifizierte Aufrufe an Ihren Cloud Run-Dienst zu akzeptieren, müssen Sie Ihren Trigger mit einem Dienstkonto verknüpfen, das die Rolle roles/run.invoker hat. Verwenden Sie beim Erstellen des Triggers das Flag --service-account oder aktualisieren Sie den Trigger, um ein Dienstkonto zu haben.
Wenn Sie einen Trigger für ein direktes Ereignis aus Cloud Storage erstellen, weisen Sie dem Cloud Storage-Dienstkonto die Rolle pubsub.publisher zu:
```
SERVICE_ACCOUNT="$(gsutil kms serviceaccount -p PROJECT_ID)"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:${SERVICE_ACCOUNT}" \
    --role='roles/pubsub.publisher'
```
Ersetzen Sie PROJECT_ID durch die Google Cloud-Projekt-ID. Sie finden Ihre Projekt-ID auf der Seite Dashboard der Google Cloud Console.

Trigger mit gcloud erstellen

Wenn Sie einen gcloud-Befehl zusammen mit den erforderlichen und optionalen Flags ausführen, können Sie einen Trigger erstellen.

Cloud-Audit-Logereignisse

gcloud eventarc triggers create TRIGGER \
    --location=LOCATION \
    --destination-run-service=DESTINATION_RUN_SERVICE \
    --destination-run-region=DESTINATION_RUN_REGION \
    --event-filters="type=google.cloud.audit.log.v1.written" \
    --event-filters="serviceName=SERVICE_NAME" \
    --event-filters="methodName=METHOD_NAME" \
    --service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com

Dabei gilt:

TRIGGER: ID des Triggers oder eine vollständig qualifizierte Kennzeichnung.
LOCATION: der Standort des Eventarc-Triggers. Alternativ können Sie das Attribut eventarc/location festlegen. Beispiel: gcloud config set eventarc/location us-central1.

Cloud-Audit-Log-Trigger für Eventarc sind in bestimmten Regionen und in der globalen Region verfügbar, jedoch nicht an Standorten mit zwei oder mehreren Regionen. Zur Vermeidung von Leistungs- und Datenstandortproblemen, die durch einen globalen Trigger verursacht werden, sollten der Standort mit dem des Google Cloud-Diensts übereinstimmen, der Ereignisse generiert.

Wenn Sie den globalen Standort angeben, erhalten Sie Ereignisse von allen Standorten, die Übereinstimmungen für die Ereignisfilter liefern. Durch das Erstellen eines globalen Eventarc-Triggers können Sie beispielsweise Ereignisse von Ressourcen wie Cloud Storage-Buckets in den Mehrfachregionen der EU und USA empfangen.
DESTINATION_RUN_SERVICE: der Name des Cloud Run-Dienstes, der die Ereignisse für den Trigger empfängt. Der Dienst kann sich an einem der von Cloud Run unterstützten Standorte befinden und muss sich nicht am selben Standort wie der Trigger vorhanden sein. Er muss sich aber im selben Projekt wie der Trigger befinden. Der Dienst empfängt Ereignisse als HTTP-POST-Anfragen, die an seinen Root-URL-Pfad (/) gesendet werden, wenn das Ereignis generiert wird.
DESTINATION_RUN_REGION: die Region, in der sich der Cloud Run-Zieldienst befindet. Wenn keine Angabe erfolgt, wird davon ausgegangen, dass sich der Dienst in derselben Region wie der Trigger befindet.
SERVICE_NAME: die Kennzeichnung des Google Cloud-Dienstes.
METHOD_NAME: die Kennzeichnung des Vorgangs.
PROJECT_NUMBER: Ihre Google Cloud-Projektnummer.

Hinweise:

Diese Flags sind erforderlich:
- --event-filters="type=google.cloud.audit.log.v1.written"
- --event-filters="serviceName=VALUE"
- --event-filters="methodName=VALUE"
Eine Liste der von Eventarc unterstützten Audit-Logereignisse, einschließlich der Werte serviceName und methodName, finden Sie unter Von Eventarc unterstützte Ereignisse.
Jeder Trigger kann mehrere Ereignisfilter haben, die durch Kommata in einem --event-filters=[ATTRIBUTE=VALUE,...]-Flag getrennt sind. Sie können das Flag aber auch wiederholen, um weitere Filter hinzuzufügen. Nur Ereignisse, die mit allen Filtern übereinstimmen, werden an das Ziel gesendet. Platzhalter und reguläre Ausdrücke werden nicht unterstützt. Weitere Informationen finden Sie unter Ereignisfilter für Cloud-Audit-Logs bestimmen.
Das Flag --service-account gibt die IAM-Dienstkonto-E-Mail-Adresse (Identity and Access Management) an, die mit dem Trigger verknüpft ist.
Optional können Sie Ereignisse für eine bestimmte Ressource filtern. Verwenden Sie dazu das Flag --event-filters="resourceName=VALUE" und geben Sie den vollständigen Pfad zur Ressource an. Lassen Sie das Flag für dynamisch erstellte Ressourcen weg, deren Kennzeichnungen zur Erstellungszeit generiert werden. Alternativ können Sie Ereignisse für eine Reihe von Ressourcen filtern, wenn Sie das Flag --event-filters-path-pattern="resourceName=VALUE" verwenden und das Muster für den Ressourcenpfad angeben.
Optional können Sie einen relativen Pfad im Cloud Run-Zieldienst angeben, an den die Ereignisse für den Trigger gesendet werden sollen. Verwenden Sie dazu das Flag --destination-run-path.

Beispiel:

  gcloud eventarc triggers create helloworld-trigger \
      --location=us-central1 \
      --destination-run-service=helloworld-events \
      --destination-run-region=us-central1 \
      --event-filters="type=google.cloud.audit.log.v1.written" \
      --event-filters="serviceName=storage.googleapis.com" \
      --event-filters="methodName=storage.buckets.update" \
      --event-filters="resourceName=projects/_/buckets/eventarc-bucket/objects/random.txt" \
      --service-account=${PROJECT_NUMBER}-compute@developer.gserviceaccount.com

Dadurch wird ein Trigger namens helloworld-trigger für Audit-Logs erstellt, die von storage.googleapis.com geschrieben werden, und für den Vorgang, der als storage.buckets.update identifiziert wird.

Direkte Ereignisse

Cloud Storage

gcloud eventarc triggers create TRIGGER \
    --location=LOCATION \
    --destination-run-service=DESTINATION_RUN_SERVICE \
    --destination-run-region=DESTINATION_RUN_REGION \
    --event-filters="type=EVENT_FILTER_TYPE" \
    --event-filters="bucket=BUCKET" \
    --service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com

Dabei gilt:

TRIGGER: ID des Triggers oder eine vollständig qualifizierte Kennzeichnung.
LOCATION: der Standort des Eventarc-Triggers. Alternativ können Sie das Attribut eventarc/location festlegen. Beispiel: gcloud config set eventarc/location us-central1.

Cloud Storage-Trigger für Eventarc sind an Standorten mit einer, zwei oder mehreren Regionen verfügbar. Der Trigger muss sich am selben Standort wie der Cloud Storage-Bucket befinden.
DESTINATION_RUN_SERVICE: der Name des Cloud Run-Dienstes, der die Ereignisse für den Trigger empfängt. Der Dienst kann sich an einem der von Cloud Run unterstützten Standorte befinden und muss sich nicht am selben Standort wie der Trigger vorhanden sein. Er muss sich aber im selben Projekt wie der Trigger befinden. Der Dienst empfängt Ereignisse als HTTP-POST-Anfragen, die an seinen Root-URL-Pfad (/) gesendet werden, wenn das Ereignis generiert wird.
DESTINATION_RUN_REGION: die Region, in der sich der Cloud Run-Zieldienst befindet. Wenn keine Angabe erfolgt, wird davon ausgegangen, dass sich der Dienst in derselben Region wie der Trigger befindet.
EVENT_FILTER_TYPE: die ID des Cloud Storage-Ereignisses und kann eine der folgenden sein:
- google.cloud.storage.object.v1.finalized: Dieses Ereignis wird gesendet, wenn ein neues Objekt im Bucket erstellt wird (oder ein vorhandenes Objekt überschrieben und eine neue Objektgeneration erstellt wird).
- google.cloud.storage.object.v1.archived: Dieses Ereignis wird gesendet, wenn eine Live-Version eines Objekts archiviert oder gelöscht wird. Dieses Ereignis wird nur für Buckets mit Versionsverwaltung gesendet.
- google.cloud.storage.object.v1.deleted: Dieses Ereignis wird gesendet, wenn ein Objekt dauerhaft gelöscht wird. Abhängig von der für den Bucket ausgewählten Objektversionierung bedeutet dies:
  - Bei Buckets mit Versionsverwaltung wird das Ereignis nur gesendet, wenn eine Version dauerhaft gelöscht wird (aber nicht, wenn ein Objekt archiviert wird).
  - Bei Buckets ohne Versionsverwaltung wird das Ereignis gesendet, wenn ein Objekt gelöscht oder überschrieben wird.
- google.cloud.storage.object.v1.metadataUpdated: Dieses Ereignis wird gesendet, wenn die Metadaten eines vorhandenen Objekts geändert werden.
BUCKET: die global eindeutige ID des Cloud Storage-Buckets.
PROJECT_NUMBER: Ihre Google Cloud-Projektnummer.

Hinweise:

Diese Flags sind erforderlich:
- --event-filters="type=EVENT_FILTER_TYPE"
- --event-filters="bucket=BUCKET"
Nachdem ein Trigger erstellt wurde, kann EVENT_FILTER_TYPE nicht mehr geändert werden. Erstellen Sie stattdessen einen neuen Trigger und löschen Sie den alten.
Ereignisse werden mit Pub/Sub-Benachrichtigungen aus Cloud Storage zugestellt. Wenn zu viele Benachrichtigungen für denselben Bucket eingerichtet werden, kann das Benachrichtigungslimit für den Bucket aufgebraucht werden. Dies wird durch den Fehler Cloud Storage bucket ...: Pub/Sub notification limit reached angegeben. Der Bucket kann bis zu 10 Benachrichtigungskonfigurationen haben, die zum Auslösen von Benachrichtigungen für ein bestimmtes Ereignis festgelegt sind. Weitere Kontingente und Limits finden Sie auf der Seite Cloud Storage-Kontingente und -Limits.
Jeder Trigger kann mehrere Ereignisfilter haben, die durch Kommata in einem --event-filters=[ATTRIBUTE=VALUE,...]-Flag getrennt sind. Sie können das Flag aber auch wiederholen, um weitere Filter hinzuzufügen. Nur Ereignisse, die mit allen Filtern übereinstimmen, werden an das Ziel gesendet. Platzhalter und reguläre Ausdrücke werden nicht unterstützt.
Mit dem Flag --service-account wird die E-Mail-Adresse des IAM-Dienstkontos (Identity and Access Management) angegeben, das mit dem Trigger verknüpft ist.
Optional können Sie einen relativen Pfad im Cloud Run-Zieldienst angeben, an den die Ereignisse für den Trigger gesendet werden sollen. Verwenden Sie dazu das Flag --destination-run-path.
Der Cloud Storage-Bucket muss sich im selben Google Cloud-Projekt und in derselben Region oder Multiregion wie der Eventarc-Trigger befinden.

Beispiel:

gcloud eventarc triggers create helloworld-trigger \
    --location=us-central1 \
    --destination-run-service=helloworld-events \
    --destination-run-region=us-central1 \
    --event-filters="type=google.cloud.storage.object.v1.finalized" \
    --event-filters="bucket=my-project-bucket" \
    --service-account=${PROJECT_NUMBER}-compute@developer.gserviceaccount.com

Dieser Befehl erstellt einen Trigger mit dem Namen helloworld-trigger für den Cloud Storage-Bucket my-project-bucket und das als google.cloud.storage.object.v1.finalized identifizierte Ereignis.

Firebase-Benachrichtigungen

gcloud eventarc triggers create TRIGGER \
    --location=global \
    --destination-run-service=DESTINATION_RUN_SERVICE \
    --destination-run-region=DESTINATION_RUN_REGION \
    --event-filters="type=google.firebase.firebasealerts.alerts.v1.published" \
    --event-filters="alerttype=ALERT_TYPE" \
    --service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com

Dabei gilt:

TRIGGER: ID des Triggers oder eine vollständig qualifizierte Kennzeichnung.
DESTINATION_RUN_SERVICE: der Name des Cloud Run-Dienstes, der die Ereignisse für den Trigger empfängt. Der Dienst kann sich an einem der von Cloud Run unterstützten Standorte befinden und muss sich nicht am selben Standort wie der Trigger vorhanden sein. Er muss sich aber im selben Projekt wie der Trigger befinden. Der Dienst empfängt Ereignisse als HTTP-POST-Anfragen, die an seinen Root-URL-Pfad (/) gesendet werden, wenn das Ereignis generiert wird.
DESTINATION_RUN_REGION: die Region, in der sich der Cloud Run-Zieldienst befindet. Wenn keine Angabe erfolgt, wird davon ausgegangen, dass sich der Dienst in derselben Region wie der Trigger befindet.
ALERT_TYPE. ist der Typ der Firebase-Benachrichtigung und kann einer der Folgenden sein:
- appDistribution.newTesterIosDevice: Das Ereignis wird gesendet, wenn ein neues iOS-Gerät über eine bestimmte Anwendung registriert wird.
- billing.planAutomatedUpdate: Das Ereignis wird gesendet, wenn der Abrechnungstarif für ein Firebase-Projekt automatisch aktualisiert wird. Das ist beispielsweise der Fall, wenn ein Tarif aufgrund von Zahlungsproblemen herabgestuft wird.
- billing.planUpdate: Das Ereignis wird gesendet, wenn der Abrechnungstarif für ein Firebase-Projekt von einem Nutzer geändert wird. Beispiel: Ein Rechnungskonto wird mit einem Projekt verknüpft oder von diesem getrennt.
- crashlytics.newAnrIssue: Das Ereignis wird gesendet, wenn bei einer Anwendung ein neuer ANR-Fehler (Application not responding, Anwendung reagiert nicht) auftritt (nicht für nachfolgende, identische Ereignisse).
- crashlytics.newFatalIssue: Das Ereignis wird gesendet, wenn bei einer Anwendung ein neuer schwerwiegender Absturz auftritt (nicht für nachfolgende, identische Ereignisse).
- crashlytics.newNonfatalIssue: Das Ereignis wird gesendet, wenn bei einer Anwendung ein neuer nicht schwerwiegender Fehler auftritt (nicht für nachfolgende, identische Ereignisse).
- crashlytics.regression: Das Ereignis wird gesendet, wenn eine Anwendung bei einem Problem abstürzt, das für eine frühere Anwendungsversion als geschlossen gekennzeichnet wurde.
- crashlytics.stabilityDigest: Das Ereignis wird gesendet, wenn eine Benachrichtigung über die häufigsten Trendprobleme in Crashlytics vorhanden ist.
- crashlytics.velocity: Das Ereignis wird gesendet, wenn ein einzelnes Problem dafür verantwortlich ist, dass eine beträchtliche Anzahl von Anwendungssitzungen abstürzt.
PROJECT_NUMBER: Ihre Google Cloud-Projektnummer.

Hinweise:

Das Flag --location muss global sein. Weitere Informationen finden Sie unter Eventarc-Standorte.
Die Flags --event-filters="type=google.firebase.firebasealerts.alerts.v1.published" und --event-filters="alerttype=ALERT_TYPE" sind erforderlich.
Optional können Sie Ereignisse für eine bestimmte Firebase-App-ID filtern. Verwenden Sie dazu das Flag --event-filters="appid=APP_ID" und geben Sie eine genaue Übereinstimmung an.
Nachdem ein Trigger erstellt wurde, kann der Ereignisfiltertyp nicht mehr geändert werden. Erstellen Sie stattdessen einen neuen Trigger und löschen Sie den alten.
Mit dem Flag --service-account wird die E-Mail-Adresse des IAM-Dienstkontos (Identity and Access Management) angegeben, das mit dem Trigger verknüpft ist.
Optional können Sie einen relativen Pfad im Cloud Run-Zieldienst angeben, an den die Ereignisse für den Trigger gesendet werden sollen. Verwenden Sie dazu das Flag --destination-run-path.

Beispiel:

gcloud eventarc triggers create helloworld-trigger \
    --location=global \
    --destination-run-service=helloworld-events \
    --destination-run-region=us-central1 \
    --event-filters="type=google.firebase.firebasealerts.alerts.v1.published" \
    --event-filters="alerttype=crashlytics.velocity" \
    --service-account=${PROJECT_NUMBER}-compute@developer.gserviceaccount.com

Dieser Befehl erstellt einen Trigger mit dem Namen helloworld-trigger für das als google.firebase.firebasealerts.alerts.v1.published identifizierte Ereignis und für einen Benachrichtigungstyp crashlytics.velocity.

Firebase Realtime Database

gcloud eventarc triggers create TRIGGER \
    --location=LOCATION \
    --destination-run-service=DESTINATION_RUN_SERVICE \
    --destination-run-region=DESTINATION_RUN_REGION \
    --event-filters="type=EVENT_FILTER_TYPE" \
    --event-filters="instance=INSTANCE" \
    --event-filters-path-pattern="ref=REF" \
    --service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com

Dabei gilt:

TRIGGER: ID des Triggers oder eine vollständig qualifizierte Kennzeichnung.
LOCATION: der Standort des Eventarc-Triggers. Alternativ können Sie das Attribut eventarc/location festlegen. Beispiel: gcloud config set eventarc/location us-central1. Firebase Realtime Database-Trigger für Eventarc sind nur an folgenden Standorten verfügbar:
- us-central1
- europe-west1
- asia-southeast1
Beachten Sie, dass sich der Trigger am selben Speicherort wie die Firebase Realtime Database-Instanz befinden muss. Weitere Informationen finden Sie unter Standorte von Realtime Database.
DESTINATION_RUN_SERVICE: der Name des Cloud Run-Dienstes, der die Ereignisse für den Trigger empfängt. Der Dienst kann sich an einem der von Cloud Run unterstützten Standorte befinden und muss sich nicht am selben Standort wie der Trigger vorhanden sein. Er muss sich aber im selben Projekt wie der Trigger befinden. Der Dienst empfängt Ereignisse als HTTP-POST-Anfragen, die an seinen Root-URL-Pfad (/) gesendet werden, wenn das Ereignis generiert wird.
DESTINATION_RUN_REGION: die Region, in der sich der Cloud Run-Zieldienst befindet. Wenn keine Angabe erfolgt, wird davon ausgegangen, dass sich der Dienst in derselben Region wie der Trigger befindet.
EVENT_FILTER_TYPE: die Kennzeichnung des Firebase Realtime Database-Ereignisses. Dafür sind folgende Optionen verfügbar:
- google.firebase.database.ref.v1.created: Ereignis wird gesendet, wenn Daten in der Datenbank erstellt werden.
- google.firebase.database.ref.v1.updated: Ereignis wird gesendet, wenn Daten in der Datenbank aktualisiert werden.
- google.firebase.database.ref.v1.deleted: Ereignis wird gesendet, wenn Daten in der Datenbank gelöscht werden.
- google.firebase.database.ref.v1.written: Ereignis wird gesendet, wenn Daten in der Datenbank erstellt, aktualisiert oder gelöscht werden.
INSTANCE: eine einzelne Datenbankinstanz. Für den Operator sind folgende Optionen verfügbar:
- Gleich. Beispiel: --event-filters="instance=INSTANCE"
- Pfadmuster. Beispiel: --event-filters-path-pattern="instance=INSTANCE". Weitere Informationen finden Sie unter Informationen zu Pfadmustern.
REF: der Pfad in der Datenbankinstanz, für die Sie Ereignisse erhalten möchten, wenn Daten in diesem Pfad oder in einem untergeordneten Element erstellt, aktualisiert oder gelöscht werden.
PROJECT_NUMBER: Ihre Google Cloud-Projektnummer.

Hinweise:

Diese Flags sind erforderlich:
- --event-filters="type=EVENT_FILTER_TYPE"
- --event-filters="instance=INSTANCE" oder --event-filters-path-pattern="instance=INSTANCE"
- --event-filters-path-pattern="ref=REF"
Nachdem ein Trigger erstellt wurde, kann der Ereignisfiltertyp nicht mehr geändert werden. Erstellen Sie stattdessen einen neuen Trigger und löschen Sie den alten.
Mit dem Flag --service-account wird die E-Mail-Adresse des IAM-Dienstkontos (Identity and Access Management) angegeben, das mit dem Trigger verknüpft ist.
Optional können Sie einen relativen Pfad im Cloud Run-Zieldienst angeben, an den die Ereignisse für den Trigger gesendet werden sollen. Verwenden Sie dazu das Flag --destination-run-path.

Beispiel:

gcloud eventarc triggers create helloworld-trigger \
    --location=us-central1 \
    --destination-run-service=helloworld-events \
    --destination-run-region=us-central1 \
    --event-filters="type=google.firebase.database.ref.v1.created" \
    --event-filters="instance=test-instance" \
    --event-filters-path-pattern="ref=users/*" \
    --service-account=${PROJECT_NUMBER}-compute@developer.gserviceaccount.com

Dieser Befehl erstellt einen Trigger mit dem Namen helloworld-trigger für das als google.firebase.database.ref.v1.created identifizierte Ereignis

Firebase Remote Config

gcloud eventarc triggers create TRIGGER \
    --location=global \
    --destination-run-service=DESTINATION_RUN_SERVICE \
    --destination-run-region=DESTINATION_RUN_REGION \
    --event-filters="type=google.firebase.remoteconfig.remoteConfig.v1.updated" \
    --service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com

Dabei gilt:

TRIGGER: ID des Triggers oder eine vollständig qualifizierte Kennzeichnung.
DESTINATION_RUN_SERVICE: der Name des Cloud Run-Dienstes, der die Ereignisse für den Trigger empfängt. Der Dienst kann sich an einem der von Cloud Run unterstützten Standorte befinden und muss sich nicht am selben Standort wie der Trigger vorhanden sein. Er muss sich aber im selben Projekt wie der Trigger befinden. Der Dienst empfängt Ereignisse als HTTP-POST-Anfragen, die an seinen Root-URL-Pfad (/) gesendet werden, wenn das Ereignis generiert wird.
DESTINATION_RUN_REGION: die Region, in der sich der Cloud Run-Zieldienst befindet. Wenn keine Angabe erfolgt, wird davon ausgegangen, dass sich der Dienst in derselben Region wie der Trigger befindet.
PROJECT_NUMBER: Ihre Google Cloud-Projektnummer.

Hinweise:

Das Flag --location muss global sein. Weitere Informationen finden Sie unter Eventarc-Standorte.
Das Flag --event-filters ist erforderlich und der Typ muss google.firebase.remoteconfig.remoteConfig.v1.updated sein. Ein Ereignis wird gesendet, wenn eine Remote Config-Vorlage aktualisiert wird.
Nachdem ein Trigger erstellt wurde, kann der Ereignisfiltertyp nicht mehr geändert werden. Erstellen Sie stattdessen einen neuen Trigger und löschen Sie den alten.
Mit dem Flag --service-account wird die E-Mail-Adresse des IAM-Dienstkontos (Identity and Access Management) angegeben, das mit dem Trigger verknüpft ist.
Optional können Sie einen relativen Pfad im Cloud Run-Zieldienst angeben, an den die Ereignisse für den Trigger gesendet werden sollen. Verwenden Sie dazu das Flag --destination-run-path.

Beispiel:

gcloud eventarc triggers create helloworld-trigger \
    --location=global \
    --destination-run-service=helloworld-events \
    --destination-run-region=us-central1 \
    --event-filters="type=google.firebase.remoteconfig.remoteConfig.v1.updated" \
    --service-account=${PROJECT_NUMBER}-compute@developer.gserviceaccount.com

Dieser Befehl erstellt einen Trigger mit dem Namen helloworld-trigger für das als google.firebase.remoteconfig.remoteConfig.v1.updated identifizierte Ereignis

Firebase Test Lab

gcloud eventarc triggers create TRIGGER \
    --location=global \
    --destination-run-service=DESTINATION_RUN_SERVICE \
    --destination-run-region=DESTINATION_RUN_REGION \
    --event-filters="type=google.firebase.testlab.testMatrix.v1.completed" \
    --service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com

Dabei gilt:

TRIGGER: ID des Triggers oder eine vollständig qualifizierte Kennzeichnung.
DESTINATION_RUN_SERVICE: der Name des Cloud Run-Dienstes, der die Ereignisse für den Trigger empfängt. Der Dienst kann sich an einem der von Cloud Run unterstützten Standorte befinden und muss sich nicht am selben Standort wie der Trigger vorhanden sein. Er muss sich aber im selben Projekt wie der Trigger befinden. Der Dienst empfängt Ereignisse als HTTP-POST-Anfragen, die an seinen Root-URL-Pfad (/) gesendet werden, wenn das Ereignis generiert wird.
DESTINATION_RUN_REGION: die Region, in der sich der Cloud Run-Zieldienst befindet. Wenn keine Angabe erfolgt, wird davon ausgegangen, dass sich der Dienst in derselben Region wie der Trigger befindet.
PROJECT_NUMBER: Ihre Google Cloud-Projektnummer.

Hinweise:

Das Flag --location muss global sein. Weitere Informationen finden Sie unter Eventarc-Standorte.
Das Flag --event-filters ist erforderlich und der Typ muss google.firebase.testlab.testMatrix.v1.completed sein. Ein Ereignis wird gesendet, wenn eine TestMatrix abgeschlossen ist.
Nachdem ein Trigger erstellt wurde, kann der Ereignisfiltertyp nicht mehr geändert werden. Erstellen Sie stattdessen einen neuen Trigger und löschen Sie den alten.
Mit dem Flag --service-account wird die E-Mail-Adresse des IAM-Dienstkontos (Identity and Access Management) angegeben, das mit dem Trigger verknüpft ist.
Optional können Sie einen relativen Pfad im Cloud Run-Zieldienst angeben, an den die Ereignisse für den Trigger gesendet werden sollen. Verwenden Sie dazu das Flag --destination-run-path.

Beispiel:

gcloud eventarc triggers create helloworld-trigger \
    --location=global \
    --destination-run-service=helloworld-events \
    --destination-run-region=us-central1 \
    --event-filters="type=google.firebase.testlab.testMatrix.v1.completed" \
    --service-account=${PROJECT_NUMBER}-compute@developer.gserviceaccount.com

Dieser Befehl erstellt einen Trigger mit dem Namen helloworld-trigger für das als google.firebase.testlab.testMatrix.v1.completed identifizierte Ereignis

Pub/Sub-Nachrichten (vorhandenes Thema)

gcloud eventarc triggers create TRIGGER \
    --location=LOCATION \
    --destination-run-service=DESTINATION_RUN_SERVICE \
    --destination-run-region=DESTINATION_RUN_REGION \
    --event-filters="type=google.cloud.pubsub.topic.v1.messagePublished" \
    --transport-topic=projects/PROJECT_ID/topics/TOPIC_NAME

Dabei gilt:

TRIGGER: ID des Triggers oder eine vollständig qualifizierte Kennzeichnung.
LOCATION: Speicherort des Eventarc-Triggers. Alternativ können Sie das Attribut eventarc/location festlegen. Beispiel: gcloud config set eventarc/location us-central1.

Pub/Sub-Trigger für Eventarc sind nur an Standorten mit einer Region verfügbar und Sie können keinen globalen Eventarc-Trigger erstellen.
DESTINATION_RUN_SERVICE: der Name des Cloud Run-Dienstes, der die Ereignisse für den Trigger empfängt. Der Dienst kann sich an einem der von Cloud Run unterstützten Standorte befinden und muss sich nicht am selben Standort wie der Trigger vorhanden sein. Er muss sich aber im selben Projekt wie der Trigger befinden. Der Dienst empfängt Ereignisse als HTTP-POST-Anfragen, die an seinen Root-URL-Pfad (/) gesendet werden, wenn das Ereignis generiert wird.
DESTINATION_RUN_REGION: die Region, in der sich der Cloud Run-Zieldienst befindet. Wenn keine Angabe erfolgt, wird davon ausgegangen, dass sich der Dienst in derselben Region wie der Trigger befindet.
PROJECT_ID: Ihre Google Cloud-Projekt-ID
TOPIC_NAME ist der Name des vorhandenen Pub/Sub-Themas. Das Thema muss sich im selben Projekt wie der Trigger befinden.

Hinweise:

Das Flag --event-filters="type=google.cloud.pubsub.topic.v1.messagePublished" ist erforderlich.
Jeder Trigger kann mehrere Ereignisfilter haben, die durch Kommata in einem --event-filters=[ATTRIBUTE=VALUE,...]-Flag getrennt sind. Sie können das Flag aber auch wiederholen, um weitere Filter hinzuzufügen. Nur Ereignisse, die mit allen Filtern übereinstimmen, werden an das Ziel gesendet. Platzhalter und reguläre Ausdrücke werden nicht unterstützt.
Das Flag --transport-topic wird verwendet, um die ID des vorhandenen Pub/Sub-Themas oder dessen vollständig qualifizierte Kennzeichnung anzugeben.
Optional können Sie einen relativen Pfad im Cloud Run-Zieldienst angeben, an den die Ereignisse für den Trigger gesendet werden sollen. Verwenden Sie dazu das Flag --destination-run-path.
Standardmäßig bleiben für Eventarc erstellte Pub/Sub-Abos unabhängig von ihrem Alter bestehen und laufen nicht ab. Informationen zum Ändern des Inaktivitätszeitraums finden Sie unter Abos verwalten.

Beispiel:

  gcloud eventarc triggers create pubsub-trigger-existing \
      --location=us-central1 \
      --destination-run-service=helloworld-events-pubsub \
      --destination-run-region=us-central1 \
      --event-filters="type=google.cloud.pubsub.topic.v1.messagePublished" \
      --transport-topic=projects/${PROJECT_ID}/topics/${TOPIC_NAME}

Mit diesem Befehl wird der Trigger pubsub-trigger-existing für das Pub/Sub-Thema mit der Kennzeichnung projects/${PROJECT_ID}/topics/${TOPIC_NAME} erstellt.

Pub/Sub-Nachrichten (neues Thema)

gcloud eventarc triggers create TRIGGER \
    --location=LOCATION \
    --destination-run-service=DESTINATION_RUN_SERVICE \
    --destination-run-region=DESTINATION_RUN_REGION \
    --event-filters="type=google.cloud.pubsub.topic.v1.messagePublished"

Dabei gilt:

TRIGGER: ID des Triggers oder eine vollständig qualifizierte Kennzeichnung.
LOCATION: Speicherort des Eventarc-Triggers. Alternativ können Sie das Attribut eventarc/location festlegen. Beispiel: gcloud config set eventarc/location us-central1.

Pub/Sub-Trigger für Eventarc sind nur an Standorten mit einer Region verfügbar und Sie können keinen globalen Eventarc-Trigger erstellen.
DESTINATION_RUN_SERVICE: der Name des Cloud Run-Dienstes, der die Ereignisse für den Trigger empfängt. Der Dienst kann sich an einem der von Cloud Run unterstützten Standorte befinden und muss sich nicht am selben Standort wie der Trigger vorhanden sein. Er muss sich aber im selben Projekt wie der Trigger befinden. Der Dienst empfängt Ereignisse als HTTP-POST-Anfragen, die an seinen Root-URL-Pfad (/) gesendet werden, wenn das Ereignis generiert wird.
DESTINATION_RUN_REGION: die Region, in der sich der Cloud Run-Zieldienst befindet. Wenn keine Angabe erfolgt, wird davon ausgegangen, dass sich der Dienst in derselben Region wie der Trigger befindet.

Hinweise:

Das Flag --event-filters="type=google.cloud.pubsub.topic.v1.messagePublished" ist erforderlich.
Jeder Trigger kann mehrere Ereignisfilter haben, die durch Kommata in einem --event-filters=[ATTRIBUTE=VALUE,...]-Flag getrennt sind. Sie können das Flag aber auch wiederholen, um weitere Filter hinzuzufügen. Nur Ereignisse, die mit allen Filtern übereinstimmen, werden an das Ziel gesendet. Platzhalter und reguläre Ausdrücke werden nicht unterstützt.
Optional können Sie einen relativen Pfad im Cloud Run-Zieldienst angeben, an den die Ereignisse für den Trigger gesendet werden sollen. Verwenden Sie dazu das Flag --destination-run-path.
Standardmäßig bleiben für Eventarc erstellte Pub/Sub-Abos unabhängig von ihrem Alter bestehen und laufen nicht ab. Informationen zum Ändern des Inaktivitätszeitraums finden Sie unter Abos verwalten.

Beispiel:

  gcloud eventarc triggers create pubsub-trigger-new \
      --location=us-central1 \
      --destination-run-service=helloworld-events-pubsub \
      --destination-run-region=us-central1 \
      --event-filters="type=google.cloud.pubsub.topic.v1.messagePublished"

Dadurch werden ein neues Pub/Sub-Thema und ein Trigger mit dem Namen pubsub-trigger-new für das Thema erstellt.

Als Best Practice empfiehlt Google, das von einem Trigger erstellte Pub/Sub-Thema nicht wiederzuverwenden, da durch das Löschen eines Eventarc-Triggers auch alle durch den Trigger erstellten Pub/Sub-Themen gelöscht werden.

Trigger über die Konsole erstellen

Auf der Cloud Run-Konsolenseite können Sie Trigger für Cloud-Audit-Logs und Pub/Sub-Ereignistypen erstellen. Zum Erstellen von Triggern für direkte Ereignisse (z. B. aus Cloud Storage oder Firebase-Benachrichtigungen) müssen Sie die gcloud CLI oder die Eventarc-Konsolenseite verwenden.

Aktivieren Sie bei Bedarf die Eventarc API.

API aktivieren
Rufen Sie in der Console Cloud Run auf.

Öffnen Sie Cloud Run.
Klicken Sie in der Liste der Dienste auf einen vorhandenen Dienst oder erstellen Sie einen neuen Dienst.
Klicken Sie auf der Seite „Dienstdetails“ auf den Tab Trigger.
Klicken Sie auf Eventarc-Trigger hinzufügen.

Der Bereich Eventarc-Trigger wird geöffnet. Informationen zum Routing von Ereignissen finden Sie unter Optionen für das Ereignisrouting.
Geben Sie einen Triggernamen ein.

Dies ist die ID des Triggers. Sie muss mit einem Buchstaben beginnen. Sie kann bis zu 63 Kleinbuchstaben, Ziffern oder Bindestriche enthalten.
Wählen Sie einen Ereignisanbieter aus.

Dies ist der Google- oder Partnerdienst, der die Ereignisquelle bildet. Wählen Sie beispielsweise BigQuery aus.
Wählen Sie ein Ereignis aus.
- Benutzerdefinierte Ereignisse: Gilt für einen Cloud Pub/Sub-Ereignisanbieter
- Direkte Ereignisse: gilt nur für einige Ereignisanbieter
- über Cloud-Audit-Logs: Gilt für alle Ereignisanbieter
Benutzerdefiniert
Anfragen an Ihren Dienst werden ausgelöst, wenn eine Nachricht in einem Pub/Sub-Thema veröffentlicht wird. Dies gilt für einen Cloud Pub/Sub-Ereignisanbieter.
1. Wählen Sie aus den unter Benutzerdefiniert aufgeführten Ereignissen Cloud Pub/Sub-Thema aus.
2. Wählen Sie ein vorhandenes Thema aus oder übernehmen Sie die Standardeinstellung Kein, damit für den Trigger ein neues Thema erstellt wird.
  
  Das vorhandene Pub/Sub-Thema muss sich im selben Projekt wie der Trigger befinden.
  
  Standardmäßig bleiben für Eventarc erstellte Pub/Sub-Abos unabhängig von ihrer Aktivität bestehen und laufen nicht ab. Informationen zum Ändern des Inaktivitätszeitraums finden Sie unter Abos verwalten.
  
  Als Best Practice empfehlen wir, das von einem Trigger erstellte Pub/Sub-Thema nicht wiederzuverwenden, da durch Löschen eines Eventarc-Triggers auch alle Pub/Sub-Themen gelöscht werden, die vom Trigger erstellt wurden.
3. Wählen Sie eine Region aus.
  
  Pub/Sub-Trigger für Eventarc sind nur an Standorten mit einer Region verfügbar und Sie können keinen globalen Eventarc-Trigger erstellen.
Direkt
Cloud Storage
Anfragen an Ihren Dienst werden als Reaktion auf ein Ereignis in einem Cloud Storage-Bucket ausgelöst: Erstellen, Löschen, Archivieren sowie Aktualisierungen von Metadaten. Dies gilt für einen Cloud Storage-Ereignisanbieter.

Wählen Sie aus den unter Direkt aufgeführten Ereignissen eine der folgenden Optionen aus:

google.cloud.storage.object.v1.archived: Das Ereignis wird gesendet, wenn eine Live-Version eines Objekts archiviert oder gelöscht wird. Dieses Ereignis wird nur für Buckets mit Versionsverwaltung gesendet.

google.cloud.storage.object.v1.delete: Das Ereignis wird gesendet, wenn ein Objekt endgültig gelöscht wird. Abhängig von der für den Bucket ausgewählten Objektversionierung bedeutet dies:

Bei Buckets mit Versionsverwaltung wird das Ereignis nur gesendet, wenn eine Version dauerhaft gelöscht wird (aber nicht, wenn ein Objekt archiviert wird).

Bei Buckets ohne Versionsverwaltung wird das Ereignis gesendet, wenn ein Objekt gelöscht oder überschrieben wird.

google.cloud.storage.object.v1.finalized: Das Ereignis wird gesendet, wenn ein neues Objekt im Bucket erstellt wird (oder ein bestehendes Objekt überschrieben wird und eine neue Generation dieses Objekts erstellt wird).

google.cloud.storage.object.v1.metadataUpdated: Das Ereignis wird gesendet, wenn sich die Metadaten eines vorhandenen Objekts ändern.

Geben Sie die global eindeutige Kennung des Cloud Storage-Buckets an oder suchen Sie danach.

Der Cloud Storage-Bucket muss sich im selben Google Cloud-Projekt und in derselben Region oder Multiregion wie der Eventarc-Trigger befinden.

Wählen Sie eine Region aus.

Cloud Storage-Trigger für Eventarc sind an Standorten mit einer, zwei oder mehreren Regionen verfügbar. Der Cloud Storage-Bucket muss sich im selben Google Cloud-Projekt und in der Region oder Multiregion befinden wie der Eventarc-Trigger.

Ereignisse werden mit Pub/Sub-Benachrichtigungen aus Cloud Storage zugestellt. Wenn zu viele Benachrichtigungen für denselben Bucket eingerichtet werden, kann das Benachrichtigungslimit für den Bucket aufgebraucht werden. Dies wird durch den Fehler Cloud Storage bucket ...: Pub/Sub notification limit reached angegeben. Der Bucket kann bis zu 10 Benachrichtigungskonfigurationen haben, die zum Auslösen von Benachrichtigungen für ein bestimmtes Ereignis festgelegt sind. Weitere Kontingente und Limits finden Sie auf der Seite Cloud Storage-Kontingente und -Limits.
Firebase-Benachrichtigungen
Anfragen an Ihren Dienst werden als Reaktion auf ein Ereignis ausgelöst, wenn eine Firebase-Benachrichtigung von einem Firebase-Dienst veröffentlicht wird.

Wählen Sie aus den unter Direkt aufgeführten Ereignissen google.firebase.firebasealerts.alerts.v1.Published aus.

Wählen Sie in der Liste Region die Option Global aus.

Weitere Informationen finden Sie unter Eventarc-Standorte.

Wählen Sie im Abschnitt Filter in der Liste Benachrichtigungstyp eine der folgenden Optionen aus:

appDistribution.newTesterIosDevice: Das Ereignis wird gesendet, wenn ein neues iOS-Gerät über eine bestimmte Anwendung registriert wird.

billing.planAutomatedUpdate: Das Ereignis wird gesendet, wenn der Abrechnungstarif für ein Firebase-Projekt automatisch aktualisiert wird. Das ist beispielsweise der Fall, wenn ein Tarif aufgrund von Zahlungsproblemen herabgestuft wird.

billing.planUpdate: Das Ereignis wird gesendet, wenn der Abrechnungstarif für ein Firebase-Projekt von einem Nutzer geändert wird. Beispiel: Ein Rechnungskonto wird mit einem Projekt verknüpft oder von diesem getrennt.

crashlytics.newAnrIssue: Das Ereignis wird gesendet, wenn bei einer Anwendung ein neuer ANR-Fehler (Application not responding, Anwendung reagiert nicht) auftritt (nicht für nachfolgende, identische Ereignisse).

crashlytics.newFatalIssue: Das Ereignis wird gesendet, wenn bei einer Anwendung ein neuer schwerwiegender Absturz auftritt (nicht für nachfolgende, identische Ereignisse).

crashlytics.newNonfatalIssue: Das Ereignis wird gesendet, wenn bei einer Anwendung ein neuer nicht schwerwiegender Fehler auftritt (nicht für nachfolgende, identische Ereignisse).

crashlytics.regression: Das Ereignis wird gesendet, wenn eine Anwendung bei einem Problem abstürzt, das für eine frühere Anwendungsversion als geschlossen gekennzeichnet wurde.

crashlytics.stabilityDigest: Das Ereignis wird gesendet, wenn eine Benachrichtigung über die häufigsten Trendprobleme in Crashlytics vorhanden ist.

crashlytics.velocity: Das Ereignis wird gesendet, wenn ein einzelnes Problem dafür verantwortlich ist, dass eine beträchtliche Anzahl von Anwendungssitzungen abstürzt.

Optional können Sie Ereignisse für eine bestimmte Firebase-App-ID filtern. Klicken Sie auf Filter hinzufügen und geben Sie die appid an.

Es muss sich um eine genaue Übereinstimmung handeln.
Firebase Realtime Database
Anfragen an Ihren Dienst werden als Reaktion auf ein Ereignis ausgelöst, wenn Daten in der Firebase Realtime Database erstellt, aktualisiert oder gelöscht werden.

Wählen Sie aus den unter Direkt aufgeführten Ereignissen eine der folgenden Optionen aus:

google.firebase.database.ref.v1.create: Das Ereignis wird gesendet, wenn Daten in der Datenbank erstellt werden.

google.firebase.database.ref.v1.Updated: Das Ereignis wird gesendet, wenn Daten in der Datenbank aktualisiert werden.

google.firebase.database.ref.v1.deleted: Das Ereignis wird gesendet, wenn Daten in der Datenbank gelöscht werden.

google.firebase.database.ref.v1.writing: Das Ereignis wird gesendet, wenn Daten in der Datenbank erstellt, aktualisiert oder gelöscht werden.

Wählen Sie in der Liste Region eine Region aus.

Beachten Sie, dass die ausgewählte Region mit der Region der Firebase Realtime Database-Instanz übereinstimmen muss. Weitere Informationen finden Sie unter Eventarc-Standorte.

Wählen Sie im Bereich Filter Folgendes aus:

Wählen Sie für das Datenbankattribut instance eine der folgenden Optionen als Operator aus:

Gleich

Pfadmuster
Weitere Informationen finden Sie unter Informationen zu Pfadmustern.

Geben Sie im Feld Attributwert 1 den Namen der Datenbankinstanz ein, von der Ereignisse empfangen werden sollen. Je nach Operator, den Sie im vorherigen Schritt ausgewählt haben, muss der Attributwert exakt dem Namen der Datenbankinstanz entsprechen oder in einem Pfadmusterformat eingegeben werden.

Wählen Sie für das Attribut ref den Operator als Pfadmuster aus.

Geben Sie im Feld Attributwert 2 den Pfad der Datenbankinstanz ein, von der Ereignisse empfangen werden sollen, wenn Daten in diesem Pfad oder in einem untergeordneten Element erstellt, aktualisiert oder gelöscht werden.
Firebase Remote Config
Anfragen an Ihren Dienst werden als Reaktion auf ein Ereignis ausgelöst, wenn eine Remote Config-Vorlage aktualisiert wird.

Wählen Sie aus den unter Direkt aufgeführten Ereignissen google.firebase.remoteconfig.remoteConfig.v1.updated aus.

Wählen Sie in der Liste Region die Option Global aus.

Weitere Informationen finden Sie unter Eventarc-Standorte.
Firebase Test Lab
Anfragen an Ihren Dienst werden als Reaktion auf ein Ereignis ausgelöst, wenn eine TestMatrix abgeschlossen ist.

Wählen Sie aus den unter Direkt aufgeführten Ereignissen google.firebase.testlab.testMatrix.v1.completed aus.

Wählen Sie in der Liste Region die Option Global aus.

Weitere Informationen finden Sie unter Eventarc-Standorte.
über Cloud-Audit-Logs
Anfragen an Ihren Dienst werden ausgelöst, wenn ein Audit-Log erstellt wird, das den Filterkriterien des Triggers entspricht. Dieser Ereignistyp gilt für alle Ereignisanbieter.
1. Wählen Sie aus den Ereignissen, die unter via Cloud-Audit-Logs aufgeführt sind, eines aus.
2. Entscheiden Sie sich für eine der folgenden Möglichkeiten:
  - Beliebige Ressource: Dies ist die Standardeinstellung und enthält dynamisch erstellte Ressourcen, deren ID bei der Erstellung generiert wurde.
  - Bestimmte Ressource: Sie müssen den vollständigen Ressourcennamen angeben.
  - Pfadmuster: Sie können mithilfe eines Pfadmusters nach Ressourcen filtern. Geben Sie beispielsweise projects/_/buckets/eventarc-bucket/objects/random.txt oder projects/_/buckets/**/r*.txt ein.
3. Wählen Sie eine Region aus.
  
  Cloud-Audit-Log-Trigger für Eventarc sind in bestimmten Regionen und in der globalen Region verfügbar, jedoch nicht an Standorten mit zwei oder mehreren Regionen. Zur Vermeidung von Leistungs- und Datenstandortproblemen, die durch einen globalen Trigger verursacht werden, sollten der Standort mit dem des Google Cloud-Diensts übereinstimmen, der Ereignisse generiert.
  
  Wenn Sie den globalen Standort angeben, erhalten Sie Ereignisse von allen Standorten, bei denen die Ereignisfilter übereinstimmen. Durch Erstellen eines globalen Eventarc-Triggers können Sie beispielsweise Ereignisse von Ressourcen in den Mehrfachregionen EU und USA empfangen.
Weitere Informationen zum Erfassen von Ereignissen, die ausgelöst werden, wenn ein Audit-Log erstellt wird, das den Filterkriterien des Triggers entspricht, finden Sie unter Ereignisfilter für Cloud-Audit-Logs bestimmen.
Wählen Sie das Dienstkonto aus, das Ihren Cloud Run-Dienst aufruft.

Oder erstellen Sie ein neues Dienstkonto.

Dies gibt die E-Mail-Adresse des IAM-Dienstkontos an, die mit dem Trigger verknüpft ist. Bei Cloud Run-Zielen wird dieses Dienstkonto verwendet, um beim Aufrufen des Dienstes Identitätstokens zu generieren.
Geben Sie optional den Dienst-URL-Pfad an, an den die eingehende Anfrage gesendet werden soll.

Dies ist der relative Pfad im Zieldienst, an den die Ereignisse für den Trigger gesendet werden sollen. Beispiel: /, /route, route, route/subroute
Nachdem Sie den Trigger erstellt haben, können Sie seinen Status prüfen. Dazu muss im Tab Trigger ein Häkchen angezeigt werden.

Trigger für Cloud Run erstellen

Erstellung eines Triggers vorbereiten

Trigger mit gcloud erstellen

Cloud-Audit-Logereignisse

Direkte Ereignisse

Cloud Storage

Firebase-Benachrichtigungen

Firebase Realtime Database

Firebase Remote Config

Firebase Test Lab

Pub/Sub-Nachrichten (vorhandenes Thema)

Pub/Sub-Nachrichten (neues Thema)

Trigger über die Konsole erstellen

Benutzerdefiniert

Direkt

Cloud Storage

Firebase-Benachrichtigungen

Firebase Realtime Database

Firebase Remote Config

Firebase Test Lab

über Cloud-Audit-Logs

Nächste Schritte