1. Introduzione
Cloud Run consente di eseguire container stateless in un ambiente completamente gestito. È basato su Knative open source, che ti consente di scegliere se eseguire i container in maniera completamente gestita con Cloud Run o nel tuo cluster Google Kubernetes Engine con Cloud Run for Anthos.
Events for Cloud Run for Anthos semplifica la connessione dei servizi Cloud Run con eventi provenienti da una serie di origini. Consente di creare architetture basate su eventi in cui i microservizi sono a basso accoppiamento e distribuiti. Si occupa anche dell'importazione, della distribuzione, della sicurezza, dell'autorizzazione e della gestione degli errori degli eventi, il che migliora l'agilità degli sviluppatori e la resilienza delle applicazioni.
In questo codelab, imparerai a utilizzare Events for Cloud Run for Anthos. Più nello specifico, ascolterai gli eventi provenienti da Cloud Pub/Sub, audit log, Cloud Storage, Cloud Scheduler e come produrre/utilizzare eventi personalizzati.
Obiettivi didattici
- Visione a lungo termine di Events for Cloud Run for Anthos
- Stato attuale di Events for Cloud Run for Anthos
- Crea un sink Cloud Run
- Creare un trigger evento per Cloud Pub/Sub
- Crea un trigger di eventi per gli audit log
- Crea un trigger evento per Cloud Storage
- Crea un trigger di eventi per Cloud Scheduler
- Produrre e utilizzare eventi personalizzati
2. Long Term Vision
Man mano che adottiamo l'architettura serverless, gli eventi diventano parte integrante del modo in cui comunicano i microservizi disaccoppiati. Events for Cloud Run for Anthos rende gli eventi un elemento di primo piano dell'offerta Cloud Run for Anthos, in modo che sia facile creare applicazioni serverless basate sugli eventi.
Events for Cloud Run for Anthos consente la distribuzione di eventi asincroni affidabile, sicura e scalabile da origini eventi create da pacchetti o app a consumer on-cluster e off-cluster.
Origini Google Cloud | Origini eventi che sono prodotti di proprietà di Google Cloud |
Fonti Google | Origini eventi che sono prodotti di proprietà di Google, come Gmail, Hangouts, Android Management e altri |
Fonti personalizzate | Origini eventi che non sono prodotti di proprietà di Google e che vengono create dagli utenti finali. Questi possono essere origini Knative sviluppate dall'utente o qualsiasi altra app in esecuzione sul cluster in grado di produrre un evento Cloud. |
Origini di terze parti | Origini eventi che non sono di proprietà di Google né dell'utente finale. Sono incluse origini eventi popolari come GitHub, SAP, Datadog, Pagerduty e così via, di proprietà e gestite da fornitori, partner o community OSS di terze parti. |
Gli eventi vengono normalizzati nel formato CloudEvents v1.0 per l'interoperabilità tra i servizi. CloudEvents è una specifica aperta indipendente dal fornitore che descrive i dati sugli eventi in formati comuni, consentendo l'interoperabilità tra servizi, piattaforme e sistemi.
Events for Cloud Run è conforme a Knative Eventing e consente la portabilità dei container da e verso altre implementazioni basate su Knative. In questo modo, viene fornito un framework coerente e indipendente dal cloud per collegare in modo dichiarativo i produttori di eventi con i consumatori di eventi.
3. Stato attuale
Questa anteprima è la prima versione che offre un insieme iniziale di funzionalità a lungo termine.
Per consentire agli utenti di creare applicazioni serverless basate su eventi, il nostro obiettivo iniziale è duplice:
- Fornisce un ampio ecosistema di origini Google Cloud che consente ai servizi Cloud Run sul cluster Anthos di reagire agli eventi dei servizi Google Cloud.
- All'inizio, gli eventi provenienti dalle origini Google Cloud vengono forniti tramite Cloud Audit Logs (CAL), consentendo un'ampia gamma di origini eventi. La latenza e la disponibilità della distribuzione degli eventi da queste origini sono legate a quelle di Cloud Audit Logs. Ogni volta che viene pubblicato un evento da un'origine Google Cloud, viene creata una voce di audit log di Cloud corrispondente.
- Oltre agli audit log di Cloud, è disponibile un supporto di prima classe per utilizzare gli eventi di Cloud Storage, Cloud Pub/Sub e Cloud Scheduler. Continueremo a espandere questo ecosistema di fonti con altre fonti di prima classe man mano che acquisiremo maggiori informazioni dai percorsi e dai feedback degli utenti.
- Consente alle applicazioni e ai servizi per gli utenti finali di emettere eventi personalizzati pubblicando un URL del broker locale del cluster con ambito spazio dei nomi.
Il meccanismo di distribuzione sottostante utilizza argomenti e sottoscrizioni Cloud Pub/Sub visibili nei progetti dei clienti. Pertanto, la funzionalità offre le stesse garanzie di consegna di Cloud Pub/Sub.
Event Trigger consente di abbonarsi agli eventi in modo che quelli corrispondenti al filtro del trigger vengano inviati alla destinazione (o sink) a cui punta il trigger.
Tutti gli eventi vengono pubblicati nel formato CloudEvents v1.0 per l'interoperabilità tra i servizi.
Continueremo a offrire più valore in modo iterativo fino alla disponibilità generale e oltre.
4. Configurazione e requisiti
Configurazione dell'ambiente autonomo
- Accedi alla console Cloud e crea un nuovo progetto o riutilizzane uno esistente. Se non hai ancora un account Gmail o Google Workspace, devi crearne uno.
- Il nome del progetto è il nome visualizzato per questo progetto. Se rispetti le convenzioni di denominazione, puoi utilizzare qualsiasi nome e aggiornarlo in qualsiasi momento.
- L'ID progetto deve essere univoco in tutti i progetti Google Cloud ed è immutabile (non può essere modificato una volta impostato). La console Cloud genera automaticamente una stringa univoca, di solito non ti interessa di cosa si tratta. Nella maggior parte dei codelab, devi fare riferimento all'ID progetto (che in genere è identificato come
PROJECT_ID), quindi, se non ti piace, generane un altro casuale oppure puoi provare il tuo e vedere se è disponibile. Viene "congelato" una volta creato il progetto.
- Successivamente, dovrai abilitare la fatturazione in Cloud Console per utilizzare le risorse Google Cloud.
L'esecuzione di questo codelab non dovrebbe costare molto, se non nulla. Assicurati di seguire le istruzioni riportate nella sezione "Pulizia", che ti consiglia come arrestare le risorse in modo da non incorrere in addebiti oltre questo tutorial. I nuovi utenti di Google Cloud possono beneficiare del programma prova senza costi di 300$.
Avvia Cloud Shell
Sebbene Google Cloud possa essere gestito da remoto dal tuo laptop, in questo codelab utilizzerai Google Cloud Shell, un ambiente a riga di comando in esecuzione nel cloud.
Nella console GCP, fai clic sull'icona di Cloud Shell nella barra degli strumenti in alto a destra:
Bastano pochi istanti per eseguire il provisioning e connettersi all'ambiente. Al termine, dovresti vedere un risultato simile a questo:
Questa macchina virtuale è caricata con tutti gli strumenti per sviluppatori di cui avrai bisogno. Offre una home directory permanente da 5 GB e viene eseguita su Google Cloud, migliorando notevolmente le prestazioni e l'autenticazione della rete. Tutto il lavoro di questo lab può essere svolto semplicemente con un browser.
5. Abilita le API, imposta la zona e la piattaforma
Configura l'ID progetto e installa i componenti alpha
In Cloud Shell, GOOGLE_CLOUD_PROJECT dovrebbe essere già impostato sull'ID progetto. In caso contrario, assicurati che sia impostato e che gcloud sia configurato con l'ID progetto:
export GOOGLE_CLOUD_PROJECT=your-project-id
gcloud config set project ${GOOGLE_CLOUD_PROJECT}
Assicurati che il componente gcloud per alpha sia installato:
gcloud components install alpha
Abilita API
Attiva tutti i servizi necessari:
gcloud services enable cloudapis.googleapis.com gcloud services enable container.googleapis.com gcloud services enable containerregistry.googleapis.com gcloud services enable cloudbuild.googleapis.com
Impostare la zona e la piattaforma
Prima di creare un cluster GKE con Cloud Run Events, imposta il nome del cluster, la zona e la piattaforma. Ad esempio, qui impostiamo il nome e la zona su events-cluster e europe-west1-b e la piattaforma è 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
Puoi verificare che la configurazione sia impostata:
gcloud config list ... [run] cluster = events-cluster cluster_location = europe-west1-b platform = gke
6. Crea un cluster GKE con Cloud Run Events
Crea un cluster GKE che esegue Kubernetes >= 1.15.9-gke.26, con i seguenti componenti aggiuntivi abilitati: 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. Configura Cloud Run Events (control plane)
Cloud Run Events ha un control plane e un data plane che devono essere configurati separatamente. Per configurare il piano di controllo:
In Cloud Shell:
gcloud beta events init
In questo modo verranno inizializzati gli eventi e verranno creati anche diversi service account necessari. Assicurati di selezionare "Sì" quando ti viene chiesto di creare il service account.
A questo punto, il control plane dovrebbe essere inizializzato correttamente. Dovresti vedere quattro pod con un
Running, 2 (controller-xxx-xxx e webhook-xxx-xxx) nello spazio dei nomi cloud-run-events e 2 (eventing-controller-xxx-xxx e eventing-webhook-xxx-xxx) nello spazio dei nomi knative-eventing. Puoi verificarlo eseguendo i seguenti comandi:
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. Configurare Cloud Run Events (piano dati)
Il passaggio successivo consiste nel configurare il piano dati negli spazi dei nomi utente. In questo modo viene creato un broker con le autorizzazioni appropriate per leggere/scrivere da/in Pub/Sub.
In Cloud Shell, imposta una variabile di ambiente NAMESPACE per lo spazio dei nomi che vuoi utilizzare per i tuoi oggetti. Puoi impostarlo su default se vuoi utilizzare lo spazio dei nomi predefinito come mostrato di seguito:
export NAMESPACE=default
Tieni presente che se lo spazio dei nomi specificato non esiste (ovvero non è quello predefinito), devi crearlo:
kubectl create namespace ${NAMESPACE}
Inizializza lo spazio dei nomi con il secret predefinito:
gcloud beta events namespaces init ${NAMESPACE} --copy-default-secret
Crea un broker predefinito nello spazio dei nomi:
gcloud beta events brokers create default --namespace ${NAMESPACE}
Verifica che il broker sia stato creato. Tieni presente che potrebbero essere necessari alcuni secondi prima che il broker sia pronto:
kubectl get broker -n ${NAMESPACE}
NAME READY REASON URL
default True http://default-brokercell-ingress.cloud-run-events.svc.cluster.local/default/default
9. Event Discovery
Puoi scoprire quali sono le origini registrate, i tipi di eventi che possono emettere e come configurare i trigger per utilizzarli.
Per visualizzare l'elenco dei diversi tipi di eventi:
gcloud beta events types list
Per saperne di più su ciascun tipo di evento:
gcloud beta events types describe google.cloud.pubsub.topic.v1.messagePublished
10. Crea un sink Cloud Run
Come sink di eventi, esegui il deployment di un servizio Cloud Run che registra i contenuti del CloudEvent che riceve.
Puoi utilizzare event_display di Knative, già compilato e con la relativa immagine container creata nell'ambito della release di Knative. Puoi visualizzare i dettagli dell'immagine container in event-display.yaml:
... containers: - image: gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display@sha256:8da2440b62a5c077d9882ed50397730e84d07037b1c8a3e40ff6b89c37332b27
Esegui il deployment in Cloud Run
Esegui il deployment dell'applicazione containerizzata su Cloud Run:
export SERVICE_NAME=event-display
gcloud run deploy ${SERVICE_NAME} \
--namespace=${NAMESPACE} \
--image gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display@sha256:8da2440b62a5c077d9882ed50397730e84d07037b1c8a3e40ff6b89c37332b27
Se l'operazione riesce, la riga di comando visualizza l'URL del servizio. Ora puoi visitare il container di cui hai eseguito il deployment aprendo l'URL del servizio in qualsiasi finestra del browser.
11. Creare un trigger evento per Cloud Pub/Sub
Un modo per ricevere eventi è tramite Cloud Pub/Sub. Le applicazioni personalizzate possono pubblicare messaggi su Cloud Pub/Sub e questi messaggi possono essere inviati ai sink Google Cloud Run tramite Events for Cloud Run.
Crea un argomento
Innanzitutto, crea un argomento Cloud Pub/Sub. Puoi sostituire TOPIC_ID con un nome di argomento univoco che preferisci:
export TOPIC_ID=cr-gke-topic
gcloud pubsub topics create ${TOPIC_ID}
Crea un trigger
Prima di creare il trigger, scopri di più sui parametri necessari per creare un trigger per gli eventi di Cloud Pub/Sub:
gcloud beta events types describe google.cloud.pubsub.topic.v1.messagePublished
Crea un trigger per filtrare gli eventi pubblicati nell'argomento Cloud Pub/Sub nel nostro servizio Cloud Run di cui è stato eseguito il deployment:
gcloud beta events triggers create trigger-pubsub \
--namespace ${NAMESPACE} \
--target-service ${SERVICE_NAME} \
--type google.cloud.pubsub.topic.v1.messagePublished \
--parameters topic=${TOPIC_ID}
Testare il trigger
Puoi verificare che il trigger sia stato creato elencando tutti i trigger:
gcloud beta events triggers list
Potresti dover attendere fino a 10 minuti prima che la creazione del trigger venga propagata e inizi a filtrare gli eventi.
Per simulare l'invio di un messaggio da parte di un'applicazione personalizzata, puoi utilizzare gcloud per attivare un evento:
gcloud pubsub topics publish ${TOPIC_ID} --message="Hello there"
Il sink Cloud Run che abbiamo creato registra il corpo del messaggio in arrivo. Puoi visualizzarlo nella sezione Log dell'istanza Cloud Run:
Tieni presente che "Hello there" verrà codificato in base64 perché è stato inviato da Pub/Sub e dovrai decodificarlo se vuoi visualizzare il messaggio originale inviato.
Elimina il trigger
Se vuoi, puoi eliminare il trigger al termine del test.
gcloud beta events triggers delete trigger-pubsub --namespace ${NAMESPACE}
12. Crea un trigger di eventi per gli audit log
Configurerai un trigger per rilevare gli eventi dagli audit log. Più nello specifico, cercherai gli eventi di creazione di argomenti Pub/Sub nei log di controllo.
Abilita audit log
Per ricevere eventi da un servizio, devi abilitare gli audit log. Nella console Cloud, seleziona IAM & Admin > Audit Logs dal menu in alto a sinistra. Nell'elenco dei servizi, seleziona Google Cloud Pub/Sub:
Sul lato destro, assicurati che siano selezionate le opzioni Amministratore, Lettura e Scrittura. Fai clic su Salva:
Testa i log di controllo
Per scoprire come identificare i parametri che dovrai impostare per configurare un trigger effettivo, esegui un'operazione effettiva.
Ad esempio, crea un argomento Pub/Sub:
gcloud pubsub topics create cre-gke-topic1
Ora vediamo che tipo di audit log ha generato questo aggiornamento. Nella console Cloud, seleziona Logging > Logs Viewer dal menu in alto a sinistra.
Nella sezione Query Builder,, scegli Cloud Pub/Sub Topic e fai clic su Add:
Una volta eseguita la query, vedrai i log per gli argomenti Pub/Sub e uno di questi dovrebbe essere google.pubsub.v1.Publisher.CreateTopic:
Nota serviceName, methodName e resourceName. Li utilizzeremo per creare il trigger.
Crea un trigger
Ora puoi creare un trigger di eventi per gli audit log.
Per maggiori dettagli sui parametri necessari per creare un attivatore per gli eventi provenienti da origini Google Cloud, esegui questo comando:
gcloud beta events types describe google.cloud.audit.log.v1.written
Crea l'attivatore con i filtri giusti:
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
Testare il trigger
Elenca tutti i trigger per confermare che il trigger è stato creato correttamente:
gcloud beta events triggers list
Attendi fino a 10 minuti affinché la creazione del trigger venga propagata e inizi a filtrare gli eventi. Una volta pronto, filtrerà gli eventi di creazione e li invierà al servizio. Ora è tutto pronto per attivare un evento.
Crea un altro argomento Pub/Sub, come hai fatto in precedenza:
gcloud pubsub topics create cre-gke-topic2
Se controlli i log del servizio Cloud Run in Cloud Console, dovresti visualizzare l'evento ricevuto:
Eliminare il trigger e gli argomenti
Se vuoi, puoi eliminare il trigger al termine del test:
gcloud beta events triggers delete trigger-auditlog
Elimina anche gli argomenti:
gcloud pubsub topics delete cre-gke-topic1 cre-gke-topic2
13. Crea un trigger evento per Cloud Storage
Configurerai un trigger per ascoltare gli eventi di Cloud Storage.
Crea un bucket
Innanzitutto, crea un bucket Cloud Storage nella stessa regione del servizio Cloud Run di cui è stato eseguito il deployment. Puoi sostituire BUCKET_NAME con un nome univoco che preferisci:
export BUCKET_NAME=[new bucket name] export REGION=europe-west1 gsutil mb -p $(gcloud config get-value project) \ -l $REGION \ gs://$BUCKET_NAME/
Configura le autorizzazioni Cloud Storage
Prima di creare un trigger, devi concedere al service account predefinito per Cloud Storage l'autorizzazione a pubblicare su Pub/Sub.
Innanzitutto, devi trovare il service account utilizzato da Cloud Storage per la pubblicazione su Pub/Sub. Per ottenere il service account, puoi utilizzare i passaggi descritti in Ottenere il service account Cloud Storage o utilizzare il seguente comando:
curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \ "https://storage.googleapis.com/storage/v1/projects/$(gcloud config get-value project)/serviceAccount"
Il service account dovrebbe essere elencato in email_address.
Supponendo che il service account trovato sopra sia service-XYZ@gs-project-accounts.iam.gserviceaccount.com, impostalo su una variabile di ambiente:
export GCS_SERVICE_ACCOUNT=service-XYZ@gs-project-accounts.iam.gserviceaccount.com
Poi, concedi i diritti a questo service account per pubblicare su Pub/Sub:
gcloud projects add-iam-policy-binding ${GOOGLE_CLOUD_PROJECT} \
--member=serviceAccount:${GCS_SERVICE_ACCOUNT} \
--role roles/pubsub.publisher
Crea un trigger
Ora puoi creare un trigger di eventi per gli eventi Cloud Storage.
Puoi trovare maggiori dettagli sui parametri che dovrai utilizzare per creare il trigger:
gcloud beta events types describe google.cloud.storage.object.v1.finalized
Crea l'attivatore con i filtri giusti:
gcloud beta events triggers create trigger-storage \
--namespace ${NAMESPACE} \
--target-service ${SERVICE_NAME} \
--type=google.cloud.storage.object.v1.finalized \
--parameters bucket=${BUCKET_NAME}
Testare il trigger
Elenca tutti i trigger per confermare che il trigger è stato creato correttamente:
gcloud beta events triggers list
Attendi fino a 10 minuti affinché la creazione del trigger venga propagata e inizi a filtrare gli eventi. Una volta pronto, filtrerà gli eventi di creazione e li invierà al servizio.
Ora è tutto pronto per attivare un evento.
Carica un file casuale nel bucket Cloud Storage:
echo "Hello World" > random.txt
gsutil cp random.txt gs://${BUCKET_NAME}/random.txt
Se controlli i log del servizio Cloud Run in Cloud Console, dovresti visualizzare l'evento ricevuto:
Elimina il trigger
Se vuoi, puoi eliminare il trigger al termine del test:
gcloud beta events triggers delete trigger-storage
14. Crea un trigger di eventi per Cloud Scheduler
Configurerai un trigger per ascoltare gli eventi di Cloud Scheduler.
Crea un'applicazione App Engine
Al momento, Cloud Scheduler richiede agli utenti di creare un'applicazione App Engine. Scegli una posizione di App Engine e crea l'app:
export APP_ENGINE_LOCATION=europe-west
gcloud app create --region=${APP_ENGINE_LOCATION}
Crea un trigger
Per maggiori dettagli sui parametri necessari per creare un attivatore per gli eventi provenienti da origini Google Cloud, esegui questo comando:
gcloud beta events types describe google.cloud.scheduler.job.v1.executed
Scegli una località Cloud Scheduler per creare lo scheduler:
export SCHEDULER_LOCATION=europe-west1
Crea un trigger che crei un job da eseguire ogni minuto in Google Cloud Scheduler e chiama il servizio di destinazione:
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"
Testare il trigger
Elenca tutti i trigger per confermare che il trigger è stato creato correttamente:
gcloud beta events triggers list
Attendi fino a 10 minuti affinché la creazione del trigger venga propagata e inizi a filtrare gli eventi. Una volta pronto, filtrerà gli eventi di creazione e li invierà al servizio.
Se controlli i log del servizio Cloud Run in Cloud Console, dovresti vedere l'evento ricevuto.
Elimina il trigger
Se vuoi, puoi eliminare il trigger al termine del test:
gcloud beta events triggers delete trigger-scheduler
15. Eventi personalizzati (endpoint broker)
In questa parte del codelab, produrrai e utilizzerai eventi personalizzati utilizzando il broker.
Crea un pod Curl per generare eventi
Gli eventi vengono in genere creati in modo programmatico. Tuttavia, in questo passaggio utilizzerai curl per inviare manualmente i singoli eventi e vedere come vengono ricevuti dal consumatore corretto.
Per creare un pod che funge da produttore di eventi, esegui questo comando:
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
Verifica che il pod curl funzioni correttamente. Dovresti visualizzare un pod denominato curl con Status=Running:
kubectl get pod curl -n ${NAMESPACE}
Crea un trigger
Creerai un trigger con un filtro sul particolare tipo di CloudEvents (in questo caso alpha-type) che emetterai. Tieni presente che è supportato il filtro di corrispondenza esatta su un numero qualsiasi di attributi CloudEvents e di estensioni. Se il filtro imposta più attributi, un evento deve avere tutti gli attributi affinché il trigger lo filtri. Al contrario, se non specifichi un filtro, tutti gli eventi verranno ricevuti nel tuo servizio.
Crea il trigger:
gcloud beta events triggers create trigger-custom \
--namespace ${NAMESPACE} \
--target-service ${SERVICE_NAME} \
--type=alpha-type \
--custom-type
Testare il trigger
Elenca tutti i trigger per confermare che il trigger è stato creato correttamente:
gcloud beta events triggers list
Crea un evento inviando una richiesta HTTP al broker. Ricordati l'URL del broker eseguendo il seguente comando:
kubectl get brokers -n ${NAMESPACE}
NAME READY REASON URL
default True http://default-broker.<NAMESPACE>.svc.cluster.local
Esegui SSH nel pod curl che hai creato in precedenza:
kubectl --namespace ${NAMESPACE} attach curl -it
Hai eseguito l'accesso SSH al pod e ora puoi effettuare una richiesta HTTP. Verrà visualizzato un prompt simile a quello riportato di seguito:
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:/ ]$
Creare un evento:
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"}'
Se l'evento è stato ricevuto, riceverai una risposta HTTP 202 Accepted. Esci dalla sessione SSH con Ctrl + D
Verifica che l'evento pubblicato sia stato inviato esaminando i log del servizio Cloud Run:
kubectl logs --selector serving.knative.dev/service=$SERVICE_NAME \ -c user-container -n $NAMESPACE --tail=100
Elimina il trigger
Se vuoi, puoi eliminare il trigger al termine del test:
gcloud beta events triggers delete trigger-custom
16. Complimenti!
Congratulazioni per aver completato il codelab.
Argomenti trattati
- Visione a lungo termine di Events for Cloud Run for Anthos
- Stato attuale di Events for Cloud Run for Anthos
- Crea un sink Cloud Run
- Creare un trigger evento per Cloud Pub/Sub
- Crea un trigger di eventi per gli audit log
- Crea un trigger evento per Cloud Storage
- Crea un trigger di eventi per Cloud Scheduler
- Produrre e utilizzare eventi personalizzati