1. Introduzione
Cloud Run consente di eseguire container stateless in un ambiente completamente gestito. È basato su Knative open source, per consentirti di scegliere di eseguire i container in modo completamente gestito con Cloud Run o nel tuo cluster Google Kubernetes Engine con Cloud Run for Anthos.
Eventi per Cloud Run for Anthos semplifica la connessione dei servizi Cloud Run a eventi provenienti da una varietà 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 per te, migliorando l'agilità degli sviluppatori e la resilienza delle applicazioni.
In questo codelab scoprirai eventi per Cloud Run for Anthos. In particolare, ascolterai eventi da Cloud Pub/Sub, Audit Logs, Cloud Storage e Cloud Scheduler e ascolterai come produrre/utilizzare eventi personalizzati.
Cosa imparerai a fare
- Visione a lungo termine di eventi per Cloud Run for Anthos
- Stato attuale di Eventi per Cloud Run for Anthos
- Crea un sink Cloud Run
- Crea un trigger di evento per Cloud Pub/Sub
- Crea un trigger di evento per gli audit log
- Crea un trigger di evento per Cloud Storage
- Crea un trigger di evento per Cloud Scheduler
- Produrre e utilizzare eventi personalizzati
2. Visione a lungo termine
Man mano che adottiamo l'architettura serverless, gli eventi diventano parte integrante del modo in cui comunicano i microservizi disaccoppiati. Eventi per Cloud Run for Anthos rende gli eventi una cittadinanza all'avanguardia dell'offerta Cloud Run for Anthos, facilitando la creazione di applicazioni serverless basate su eventi.
Eventi per Cloud Run for Anthos consente la distribuzione asincrona affidabile, sicura e scalabile di eventi asincroni da origini eventi in pacchetto o create da app a consumer su cluster e fuori cluster.
Origini Google Cloud | Origini evento 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 ancora |
Origini personalizzate | Origini evento che non sono prodotti di proprietà di Google e sono create dagli utenti finali stessi. Può trattarsi di origini Knative sviluppate dall'utente o di qualsiasi altra app in esecuzione sul cluster in grado di produrre un evento Cloud. |
Origini di terze parti | Origini evento che non sono di proprietà di Google né degli utenti finali. Sono incluse origini di eventi popolari come GitHub, SAP, Datadog, Pagerduty e così via, di proprietà e gestite da provider di terze parti, partner o community OSS. |
Gli eventi sono normalizzati nel formato CloudEvents v1.0 per l'interoperabilità tra servizi. CloudEvents è una specifica aperta indipendente dal fornitore che descrive i dati degli eventi in formati comuni, consentendo l'interoperabilità tra servizi, piattaforme e sistemi.
Eventi per Cloud Run è conforme a Knative Eventing e consente la portabilità dei container da e verso altre implementazioni basate su Knative. Questo fornisce un framework coerente e indipendente dal cloud per collegare in modo dichiarativo i produttori di eventi con i consumer di eventi.
3. Stato attuale
Questa anteprima è la prima versione che fornisce un insieme iniziale delle funzionalità a lungo termine.
Per consentire agli utenti di creare applicazioni serverless basate su eventi, ci concentriamo su due aspetti iniziali:
- Offri un ampio ecosistema di origini Google Cloud che consente ai servizi Cloud Run sul cluster Anthos di reagire agli eventi dei servizi Google Cloud.
- Inizialmente, gli eventi provenienti da origini Google Cloud vengono forniti tramite Cloud Audit Logs (CAL), consentendo una vasta 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 corrispondente di Cloud Audit Log.
- Oltre a Cloud Audit Logs, è disponibile un supporto di altissimo livello per il consumo di eventi da Cloud Storage, Cloud Pub/Sub e Cloud Scheduler. Continueremo a espandere questo ecosistema di fonti con fonti più all'avanguardia man mano che impareremo di più dai percorsi degli utenti e dai feedback.
- Consenti alle applicazioni e ai servizi degli utenti finali di emettere eventi personalizzati pubblicando in un URL del broker locale e cluster con ambito dello spazio dei nomi.
Il meccanismo di consegna sottostante utilizza argomenti e sottoscrizioni Cloud Pub/Sub visibili nel pannello in modo programmatico a gestire i progetti. Pertanto, la funzionalità offre le stesse garanzie di consegna di Cloud Pub/Sub.
Il trigger di eventi consente di effettuare la sottoscrizione agli eventi in modo che gli eventi corrispondenti al filtro dell'attivatore vengano inviati alla destinazione (o sink) a cui punta il trigger.
Tutti gli eventi vengono distribuiti nel formato Cloud Events v1.0 per l'interoperabilità tra servizi.
Continueremo a fornire più valore in modo iterativo fino a GA e oltre.
4. Configurazione e requisiti
Configurazione dell'ambiente da seguire in modo 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 progetto è il nome visualizzato per il progetto. Se segui le convenzioni di denominazione, puoi utilizzare tutto ciò che desideri 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 importa cosa sia. Nella maggior parte dei codelab, devi fare riferimento all'ID progetto (che solitamente è identificato come
PROJECT_ID), quindi, se non ti piace, generane un altro a caso oppure puoi fare un tentativo personalizzato e controllare se è disponibile. Poi c'è "congelato" una volta creato il progetto.
- Successivamente, dovrai abilitare la fatturazione in Cloud Console per utilizzare le risorse Google Cloud.
Eseguire questo codelab non dovrebbe costare molto. Assicurati di seguire le istruzioni nella sezione "Pulizia" in cui viene spiegato come arrestare le risorse in modo da non incorrere in fatturazione oltre questo tutorial. I nuovi utenti di Google Cloud sono idonei al programma prova senza costi di 300$.
Avvia Cloud Shell
Anche se Google Cloud può essere utilizzato da remoto dal tuo laptop, in questo codelab utilizzerai Google Cloud Shell, un ambiente a riga di comando in esecuzione nel cloud.
Dalla console di Google Cloud, fai clic sull'icona di Cloud Shell nella barra degli strumenti in alto a destra:
Dovrebbe richiedere solo qualche istante per eseguire il provisioning e connettersi all'ambiente. Al termine, dovresti vedere una schermata simile al seguente:
Questa macchina virtuale viene caricata con tutti gli strumenti di sviluppo necessari. Offre una home directory permanente da 5 GB e viene eseguita su Google Cloud, migliorando notevolmente le prestazioni di rete e l'autenticazione. Tutto il lavoro in questo lab può essere svolto semplicemente con un browser.
5. Abilita le API, imposta zona e piattaforma
Configurare l'ID progetto e installare i componenti alpha
All'interno di Cloud Shell, GOOGLE_CLOUD_PROJECT dovrebbe essere già impostato sull'ID progetto. In caso contrario, assicurati che sia impostato e che lo gcloud sia configurato con quell'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
Abilita 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
Imposta zona e piattaforma
Prima di creare un cluster GKE con gli eventi Cloud Run, imposta il nome, la zona e la piattaforma del cluster. Ad esempio, qui abbiamo impostato 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 gli eventi Cloud Run
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 eventi Cloud Run (piano di controllo)
Gli eventi Cloud Run hanno un piano di controllo e un piano dati che devono essere configurati separatamente. Per configurare il piano di controllo:
In Cloud Shell:
gcloud beta events init
Questa operazione inizializza gli eventi e crea anche il numero di account di servizio necessari. Assicurati di selezionare "Sì". quando viene richiesta la creazione dell'account di servizio.
A questo punto il piano di controllo dovrebbe essere inizializzato correttamente. Dovresti vedere quattro pod con un'etichetta
Stato 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 questi 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. Configura eventi Cloud Run (piano dati)
Poi devi configurare il piano dati negli spazi dei nomi degli utenti. Viene così creato un broker con le autorizzazioni appropriate per leggere/scrivere da/verso Pub/Sub.
In Cloud Shell, imposta una variabile di ambiente NAMESPACE per lo spazio dei nomi che vuoi utilizzare per gli 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 (ad esempio, lo spazio dei nomi non è 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. scoperta evento
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 ulteriori informazioni su ogni 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 dell'evento CloudEvent che riceve.
Puoi utilizzare l'elemento event_display di Knative che è già stato compilato e la sua immagine container creata come parte della release di Knative. Puoi vedere i dettagli dell'immagine container in event-display.yaml:
... containers: - image: gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display@sha256:8da2440b62a5c077d9882ed50397730e84d07037b1c8a3e40ff6b89c37332b27
Eseguire il deployment in Cloud Run
Esegui il deployment della tua applicazione containerizzata in 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. Crea un trigger di evento per Cloud Pub/Sub
Un modo per ricevere eventi è tramite Cloud Pub/Sub. Le applicazioni personalizzate possono pubblicare messaggi in Cloud Pub/Sub e questi possono essere consegnati ai sink di Google Cloud Run tramite Eventi per Cloud Run.
Crea un argomento
Innanzitutto, crea un argomento Cloud Pub/Sub. Puoi sostituire TOPIC_ID con un nome argomento univoco che preferisci:
export TOPIC_ID=cr-gke-topic
gcloud pubsub topics create ${TOPIC_ID}
Crea un trigger
Prima di creare il trigger, consulta ulteriori dettagli sui parametri necessari per creare un trigger per gli eventi da 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 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}
Testa il trigger
Puoi verificare che il trigger venga creato elencando tutti gli attivatori:
gcloud beta events triggers list
Potresti dover attendere fino a 10 minuti per la propagazione della creazione del trigger e per l'inizio del filtro degli eventi.
Per simulare l'invio di un messaggio personalizzato da parte di un'applicazione, puoi utilizzare gcloud per attivare un evento:
gcloud pubsub topics publish ${TOPIC_ID} --message="Hello there"
Il sink di Cloud Run creato registra il corpo del messaggio in arrivo. Puoi visualizzarlo nella sezione Log della tua istanza Cloud Run:
Tieni presente che "Ciao" sarà codificato in base64 così come era stato inviato da Pub/Sub e dovrai decodificarlo se vuoi vedere il messaggio originale inviato.
Elimina l'attivatore
Se vuoi, puoi eliminare il trigger al termine del test.
gcloud beta events triggers delete trigger-pubsub --namespace ${NAMESPACE}
12. Crea un trigger di evento per gli audit log
Configurerai un trigger per ascoltare gli eventi degli audit log. In particolare, cercherai gli eventi di creazione di argomenti Pub/Sub negli audit log.
Abilita log di controllo
Per ricevere eventi da un servizio, devi abilitare gli audit log. Dalla console Cloud, seleziona IAM & Admin > Audit Logs dal menu in alto a sinistra. Nell'elenco dei servizi, controlla Google Cloud Pub/Sub:
Sul lato destro, assicurati che le opzioni Amministrazione, Lettura e Scrittura siano selezionate. Fai clic su Salva:
Audit log dei test
Per scoprire come identificare i parametri necessari per impostare 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. Dalla console Cloud, seleziona Logging > Logs Viewer dal menu in alto a sinistra.
In 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:
Prendi nota di serviceName, methodName e resourceName. Le utilizzeremo per creare il trigger.
Crea un trigger
Ora è tutto pronto per creare un trigger di evento per gli audit log.
Puoi ottenere maggiori dettagli sui parametri necessari per creare un trigger per eventi da origini Google Cloud eseguendo questo comando:
gcloud beta events types describe google.cloud.audit.log.v1.written
Crea l'attivatore con i filtri corretti:
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
Testa il trigger
Elenca tutti i trigger per confermare che sia stato creato correttamente:
gcloud beta events triggers list
Attendi fino a 10 minuti per la propagazione della creazione del trigger e l'inizio del filtro degli eventi. Quando è tutto pronto, filtrerà gli eventi di creazione e li invierà al servizio. Ora puoi 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 vedere l'evento ricevuto:
Eliminare l'attivatore 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 di evento per Cloud Storage
Configurerai un trigger per ascoltare gli eventi da 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/
Configurare le autorizzazioni di Cloud Storage
Prima di creare un trigger, devi fornire all'account di servizio predefinito l'autorizzazione di Cloud Storage per pubblicare in Pub/Sub.
Innanzitutto, devi trovare l'account di servizio che Cloud Storage utilizza per pubblicare in Pub/Sub. Puoi seguire i passaggi descritti in Recupero dell'account di servizio Cloud Storage per recuperare l'account di servizio oppure utilizzare il comando seguente:
curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \ "https://storage.googleapis.com/storage/v1/projects/$(gcloud config get-value project)/serviceAccount"
L'account di servizio deve essere elencato sotto email_address.
Supponiamo che l'account di servizio che hai 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
Concedi quindi a quell'account di servizio i diritti per la pubblicazione in Pub/Sub:
gcloud projects add-iam-policy-binding ${GOOGLE_CLOUD_PROJECT} \
--member=serviceAccount:${GCS_SERVICE_ACCOUNT} \
--role roles/pubsub.publisher
Crea un trigger
Ora è tutto pronto per creare un trigger per gli eventi Cloud Storage.
Puoi ottenere maggiori dettagli sui parametri di cui avrai bisogno per creare l'attivatore:
gcloud beta events types describe google.cloud.storage.object.v1.finalized
Crea l'attivatore con i filtri corretti:
gcloud beta events triggers create trigger-storage \
--namespace ${NAMESPACE} \
--target-service ${SERVICE_NAME} \
--type=google.cloud.storage.object.v1.finalized \
--parameters bucket=${BUCKET_NAME}
Testa il trigger
Elenca tutti i trigger per confermare che sia stato creato correttamente:
gcloud beta events triggers list
Attendi fino a 10 minuti per la propagazione della creazione del trigger e l'inizio del filtro degli eventi. Quando è tutto pronto, filtrerà gli eventi di creazione e li invierà al servizio.
Ora puoi 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 vedere l'evento ricevuto:
Elimina l'attivatore
Se vuoi, puoi eliminare il trigger al termine del test:
gcloud beta events triggers delete trigger-storage
14. Crea un trigger di evento per Cloud Scheduler
Configurerai un trigger per rimanere in ascolto degli eventi di Cloud Scheduler.
Crea un'applicazione App Engine
Cloud Scheduler richiede attualmente la creazione di un'applicazione App Engine da parte di utenti. Seleziona una località App Engine e crea l'app:
export APP_ENGINE_LOCATION=europe-west
gcloud app create --region=${APP_ENGINE_LOCATION}
Crea un trigger
Puoi ottenere maggiori dettagli sui parametri necessari per creare un trigger per eventi da origini Google Cloud eseguendo questo comando:
gcloud beta events types describe google.cloud.scheduler.job.v1.executed
Scegli una località di Cloud Scheduler per creare lo scheduler:
export SCHEDULER_LOCATION=europe-west1
Crea un trigger che creerà un job da eseguire ogni minuto in Google Cloud Scheduler e chiamerà 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"
Testa il trigger
Elenca tutti i trigger per confermare che sia stato creato correttamente:
gcloud beta events triggers list
Attendi fino a 10 minuti per la propagazione della creazione del trigger e l'inizio del filtro degli eventi. Quando è tutto 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 l'attivatore
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 produrre eventi
In genere gli eventi vengono creati in modo programmatico. Tuttavia, in questo passaggio utilizzerai curl per inviare manualmente singoli eventi e vedere come vengono ricevuti dal consumer corretto.
Per creare un pod che agisca da producer 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 vedere un pod denominato curl con Status=Running:
kubectl get pod curl -n ${NAMESPACE}
Crea un trigger
Creerai un trigger con un filtro sul tipo di CloudEvents specifico (in questo caso alpha-type) che emetti. Tieni presente che è supportato il filtro della corrispondenza esatta per un numero qualsiasi di attributi CloudEvents ed estensioni. Se il filtro imposta più attributi, un evento deve avere tutti gli attributi affinché l'attivatore lo filtra. Al contrario, se non specifichi un filtro, tutti gli eventi verranno ricevuti nel tuo Servizio.
Crea l'attivatore:
gcloud beta events triggers create trigger-custom \
--namespace ${NAMESPACE} \
--target-service ${SERVICE_NAME} \
--type=alpha-type \
--custom-type
Testa il trigger
Elenca tutti i trigger per confermare che sia stato creato correttamente:
gcloud beta events triggers list
Crea un evento inviando una richiesta HTTP al broker. Ricorda di inserire l'URL dell'intermediario nel seguente modo:
kubectl get brokers -n ${NAMESPACE}
NAME READY REASON URL
default True http://default-broker.<NAMESPACE>.svc.cluster.local
Accedi tramite SSH al pod curl che hai creato in precedenza:
kubectl --namespace ${NAMESPACE} attach curl -it
Hai eseguito l'accesso tramite 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:/ ]$
Crea 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 osservando i log del servizio Cloud Run:
kubectl logs --selector serving.knative.dev/service=$SERVICE_NAME \ -c user-container -n $NAMESPACE --tail=100
Elimina l'attivatore
Se vuoi, puoi eliminare il trigger al termine del test:
gcloud beta events triggers delete trigger-custom
16. Complimenti!
Complimenti per aver completato il codelab.
Argomenti trattati
- Visione a lungo termine di eventi per Cloud Run for Anthos
- Stato attuale di Eventi per Cloud Run for Anthos
- Crea un sink Cloud Run
- Crea un trigger di evento per Cloud Pub/Sub
- Crea un trigger di evento per gli audit log
- Crea un trigger di evento per Cloud Storage
- Crea un trigger di evento per Cloud Scheduler
- Produrre e utilizzare eventi personalizzati