Atelier de programmation sur les événements pour Cloud Run for Anthos

1. Introduction

Cloud Run vous permet d'exécuter des conteneurs sans état dans un environnement entièrement géré. La plate-forme étant basée sur Knative, vous pouvez exécuter vos conteneurs soit de façon entièrement gérée avec Cloud Run, soit dans votre cluster Google Kubernetes Engine avec Cloud Run pour Anthos.

Events for Cloud Run for Anthos permet de connecter facilement les services Cloud Run aux événements provenant de diverses sources. Il vous permet de créer des architectures basées sur des événements dans lesquelles les microservices sont faiblement couplés et distribués. Il gère également l'ingestion, la diffusion, la sécurité, l'autorisation et le traitement des erreurs pour vous, ce qui améliore l'agilité des développeurs et la résilience des applications.

Dans cet atelier de programmation, vous allez découvrir les événements pour Cloud Run pour Anthos. Plus précisément, vous allez écouter les événements provenant de Cloud Pub/Sub, des journaux d'audit, de Cloud Storage et de Cloud Scheduler, et apprendre à produire et consommer des événements personnalisés.

Points abordés

Vision à long terme des événements pour Cloud Run for Anthos
État actuel des événements pour Cloud Run pour Anthos
Créer un récepteur Cloud Run
Créer un déclencheur d'événement pour Cloud Pub/Sub
Créer un déclencheur d'événement pour les journaux d'audit
Créer un déclencheur d'événement pour Cloud Storage
Créer un déclencheur d'événement pour Cloud Scheduler
Produire et consommer des événements personnalisés

2. Vision à long terme

Lorsque nous adoptons une architecture sans serveur, les événements font partie intégrante de la façon dont les microservices découplés communiquent. Events for Cloud Run for Anthos fait des événements un élément essentiel de l'offre Cloud Run for Anthos, ce qui facilite la création d'applications sans serveur axées sur les événements.

Events for Cloud Run for Anthos permet une diffusion d'événements asynchrone fiable, sécurisée et évolutive à partir de sources d'événements packagées ou créées par des applications vers des consommateurs sur cluster et hors cluster.

Sources Google Cloud	Sources d'événements qui sont des produits appartenant à Google Cloud
Sources Google	Sources d'événements appartenant à Google, telles que Gmail, Hangouts, la gestion Android, etc.
Sources personnalisées	Sources d'événements qui ne sont pas des produits Google et qui sont créées par les utilisateurs finaux eux-mêmes. Il peut s'agir de sources Knative développées par l'utilisateur ou de toute autre application exécutée sur le cluster et capable de générer un événement Cloud.
Sources tierces	Sources d'événements qui n'appartiennent ni à Google ni à l'utilisateur final. Cela inclut les sources d'événements populaires telles que GitHub, SAP, Datadog, Pagerduty, etc., qui appartiennent à des fournisseurs tiers, des partenaires ou des communautés OSS et sont gérées par eux.

Les événements sont normalisés au format CloudEvents v1.0 pour l'interopérabilité entre les services. CloudEvents est une spécification ouverte et indépendante des fournisseurs qui décrit les données d'événement dans des formats courants, ce qui permet l'interopérabilité entre les services, les plates-formes et les systèmes.

Events for Cloud Run est conforme à Knative Eventing et permet la portabilité des conteneurs vers et depuis d'autres implémentations basées sur Knative. Cela fournit un framework cohérent et indépendant du cloud pour connecter de manière déclarative les producteurs d'événements aux consommateurs d'événements.

3. État actuel

Cet aperçu est la première version qui fournit un ensemble initial de fonctionnalités à long terme.

Pour permettre aux utilisateurs de créer des applications sans serveur basées sur des événements, nous nous concentrons initialement sur deux aspects :

Fournir un vaste écosystème de sources Google Cloud qui permet aux services Cloud Run du cluster Anthos de réagir aux événements des services Google Cloud.

Au départ, les événements provenant de sources Google Cloud sont fournis par le biais de journaux d'audit Cloud (CAL), ce qui permet d'utiliser un large éventail de sources d'événements. La latence et la disponibilité de la diffusion des événements provenant de ces sources sont liées à celles de Cloud Audit Logs. Chaque fois qu'un événement provenant d'une source Google Cloud est publié, une entrée Cloud Audit Logs correspondante est créée.
En plus des journaux d'audit Cloud, vous bénéficiez d'une assistance de premier ordre pour consommer des événements provenant de Cloud Storage, Cloud Pub/Sub et Cloud Scheduler. Nous continuerons à étendre cet écosystème de sources en ajoutant d'autres sources de premier ordre à mesure que nous en apprendrons davantage sur les parcours utilisateur et les commentaires.

Permettez aux applications et services destinés aux utilisateurs finaux d'émettre des événements personnalisés en les publiant sur une URL de broker locale au cluster et limitée à un espace de noms.

Le mécanisme de distribution sous-jacent utilise des sujets et des abonnements Cloud Pub/Sub visibles dans les projets des clients. Par conséquent, cette fonctionnalité offre les mêmes garanties de distribution que Cloud Pub/Sub.

Le déclencheur d'événements permet de s'abonner à des événements afin que ceux correspondant au filtre du déclencheur soient envoyés à la destination (ou au récepteur) vers laquelle pointe le déclencheur.

Tous les événements sont diffusés au format CloudEvents v1.0 pour l'interopérabilité entre les services.

Nous continuerons à vous proposer plus de valeur de manière itérative jusqu'à la disponibilité générale et au-delà.

4. Préparation

Configuration de l'environnement d'auto-formation

Connectez-vous à la console Cloud, puis créez un projet ou réutilisez un projet existant. (Si vous ne possédez pas encore de compte Gmail ou Google Workspace, vous devez en créer un.)

Le nom du projet est celui que verront les participants au projet. Tant que vous respectez ses conventions de dénomination, vous pouvez utiliser ce que vous voulez et le mettre à jour à tout moment.
L'ID du projet doit être unique sur l'ensemble des projets Google Cloud et doit être immuable (vous ne pouvez pas le modifier une fois que vous l'avez défini). La console Cloud génère automatiquement une chaîne unique (en général, vous n'y accordez d'importance particulière). Dans la plupart des ateliers de programmation, vous devrez indiquer l'ID de votre projet (généralement identifié par PROJECT_ID). Si l'ID généré ne vous convient pas, vous pouvez en générer un autre de manière aléatoire ou essayer le vôtre pour voir s'il est disponible. Il est ensuite "gelé" une fois le projet créé.

Vous devez ensuite activer la facturation dans Cloud Console pour pouvoir utiliser les ressources Google Cloud.

L'exécution de cet atelier de programmation est très peu coûteuse, voire sans frais. Veillez à suivre les instructions de la section "Nettoyer" qui indique comment désactiver les ressources afin d'éviter les frais une fois ce tutoriel terminé. Les nouveaux utilisateurs de Google Cloud peuvent participer au programme d'essai sans frais pour bénéficier d'un crédit de 300$.

Démarrer Cloud Shell

Bien que Google Cloud puisse être utilisé à distance depuis votre ordinateur portable, nous allons nous servir de Google Cloud Shell pour cet atelier de programmation, un environnement de ligne de commande exécuté dans le cloud.

Depuis la console GCP, cliquez sur l'icône Cloud Shell de la barre d'outils située dans l'angle supérieur droit :

Le provisionnement et la connexion à l'environnement prennent quelques instants seulement. Une fois l'opération terminée, le résultat devrait ressembler à ceci :

Cette machine virtuelle contient tous les outils de développement nécessaires. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud, ce qui améliore nettement les performances du réseau et l'authentification. Vous pouvez réaliser toutes les activités de cet atelier dans un simple navigateur.

5. Activer les API, définir la zone et la plate-forme

Configurer l'ID du projet et installer les composants alpha

Dans Cloud Shell, GOOGLE_CLOUD_PROJECT devrait déjà être défini sur l'ID de votre projet. Si ce n'est pas le cas, assurez-vous qu'il est défini et que votre gcloud est configuré avec cet ID de projet :

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

Assurez-vous que le composant gcloud pour la version alpha est installé :

gcloud components install alpha

Activer les API

Activez tous les services nécessaires :

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

Définir la zone et la plate-forme

Avant de créer un cluster GKE avec Cloud Run Events, définissez le nom du cluster, la zone et la plate-forme. Par exemple, nous définissons ici le nom et la zone sur events-cluster et europe-west1-b, et la plate-forme sur gke,.

Dans 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

Vous pouvez vérifier que la configuration est définie :

gcloud config list

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

6. Créer un cluster GKE avec Cloud Run Events

Créez un cluster GKE exécutant Kubernetes >= 1.15.9-gke.26, avec les modules complémentaires suivants activés : 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. Configurer les événements Cloud Run (plan de contrôle)

Les événements Cloud Run comportent un plan de contrôle et un plan de données qui doivent être configurés séparément. Pour configurer le plan de contrôle :

Dans Cloud Shell :

gcloud beta events init

Cela initialisera l'événement et créera également le nombre de comptes de service nécessaires. Assurez-vous de sélectionner "Oui" lorsque vous êtes invité à créer un compte de service.

À ce stade, le plan de contrôle doit être correctement initialisé. Vous devriez voir quatre pods avec un

Running, 2 (controller-xxx-xxx et webhook-xxx-xxx) dans l'espace de noms cloud-run-events et 2 (eventing-controller-xxx-xxx et eventing-webhook-xxx-xxx) dans l'espace de noms knative-eventing. Vous pouvez le vérifier en exécutant les commandes suivantes :

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. Configurer les événements Cloud Run (plan de données)

Ensuite, configurez le plan de données dans les espaces de noms utilisateur. Cela crée un broker avec les autorisations appropriées pour lire et écrire dans Pub/Sub.

Dans Cloud Shell, définissez une variable d'environnement NAMESPACE pour l'espace de noms que vous souhaitez utiliser pour vos objets. Vous pouvez le définir sur default si vous souhaitez utiliser l'espace de noms par défaut, comme indiqué ci-dessous :

export NAMESPACE=default

Notez que si l'espace de noms spécifié n'existe pas (c'est-à-dire qu'il n'est pas défini par défaut), vous devez le créer :

kubectl create namespace ${NAMESPACE}

Initialisez l'espace de noms avec le secret par défaut :

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

Créez un courtier par défaut dans l'espace de noms :

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

Vérifiez que le courtier a été créé. Notez que l'agent peut mettre quelques secondes à être prêt :

kubectl get broker -n ${NAMESPACE}

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

9. Découverte d'événements

Vous pouvez découvrir les sources enregistrées, les types d'événements qu'elles peuvent émettre et comment configurer des déclencheurs pour les utiliser.

Pour afficher la liste des différents types d'événements :

gcloud beta events types list

Pour en savoir plus sur chaque type d'événement :

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

10. Créer un récepteur Cloud Run

En tant que récepteur d'événements, déployez un service Cloud Run qui consigne le contenu du CloudEvent qu'il reçoit.

Vous pouvez utiliser event_display de Knative, qui est déjà compilé et dont l'image de conteneur est créée dans le cadre de la version Knative. Vous pouvez consulter les détails de l'image de conteneur dans event-display.yaml :

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

Déployer sur Cloud Run

Déployez votre application conteneurisée sur 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

En cas de réussite, la ligne de commande affiche l'URL du service. Vous pouvez maintenant accéder au conteneur déployé en ouvrant l'URL du service dans une fenêtre de navigateur quelconque.

11. Créer un déclencheur d'événement pour Cloud Pub/Sub

Pour recevoir des événements, l'un des moyens possibles consiste à passer par Cloud Pub/Sub. Les applications personnalisées peuvent publier des messages dans Cloud Pub/Sub, et ces messages peuvent être transmis aux récepteurs Google Cloud Run par le biais d'Events pour Cloud Run.

Créer un sujet

Commencez par créer un sujet Cloud Pub/Sub. Vous pouvez remplacer TOPIC_ID par un nom de sujet unique de votre choix :

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

Créer un déclencheur

Avant de créer le déclencheur, obtenez plus de détails sur les paramètres dont vous aurez besoin afin de créer un déclencheur pour les événements provenant de Cloud Pub/Sub :

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

Créez un déclencheur pour filtrer les événements publiés dans le sujet Cloud Pub/Sub et les envoyer à notre service Cloud Run déployé :

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

Tester le déclencheur

Vous pouvez vérifier que le déclencheur a été créé en listant tous les déclencheurs :

gcloud beta events triggers list

Vous devrez peut-être attendre jusqu'à 10 minutes pour que la création du déclencheur se propage et que celui-ci commence à filtrer les événements.

Pour simuler l'envoi d'un message par une application personnalisée, vous pouvez utiliser gcloud pour déclencher un événement :

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

Le récepteur Cloud Run que nous avons créé enregistre le corps du message entrant. Vous pouvez le voir dans la section "Journaux" de votre instance Cloud Run :

Notez que "Hello there" sera encodé en base64, car il a été envoyé par Pub/Sub. Vous devrez le décoder si vous souhaitez voir le message d'origine.

Supprimer le déclencheur

Une fois les tests terminés, vous pouvez éventuellement supprimer le déclencheur.

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

12. Créer un déclencheur d'événement pour les journaux d'audit

Vous allez configurer un déclencheur pour écouter les événements des journaux d'audit. Plus précisément, vous rechercherez les événements de création de sujets Pub/Sub dans les journaux d'audit.

Activer les journaux d'audit

Pour recevoir des événements d'un service, vous devez activer les journaux d'audit. Dans la console Cloud, sélectionnez IAM & Admin > Audit Logs dans le menu en haut à gauche. Dans la liste des services, cochez Google Cloud Pub/Sub :

Sur la droite, assurez-vous que les options "Admin", "Lecture" et "Écriture" sont sélectionnées. Cliquez sur "Enregistrer" :

Tester les journaux d'audit

Pour apprendre à identifier les paramètres, vous allez devoir configurer un déclencheur et effectuer une véritable opération.

Par exemple, créez un sujet Pub/Sub :

gcloud pubsub topics create cre-gke-topic1

Voyons maintenant quel type de journal d'audit cette mise à jour a généré. Dans la console Cloud, sélectionnez Logging > Logs Viewer dans le menu en haut à gauche.

Sous Query Builder,, sélectionnez Cloud Pub/Sub Topic, puis cliquez sur Add :

Une fois la requête exécutée, vous verrez les journaux des sujets Pub/Sub. L'un d'eux devrait être google.pubsub.v1.Publisher.CreateTopic :

Notez les valeurs de serviceName, methodName et resourceName. Nous les utiliserons pour créer le déclencheur.

Créer un déclencheur

Vous êtes maintenant prêt à créer un déclencheur d'événement pour les journaux d'audit.

Pour obtenir plus d'informations sur les paramètres dont vous aurez besoin pour créer un déclencheur pour les événements provenant de sources Google Cloud, exécutez la commande suivante :

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

Créez le déclencheur avec les bons filtres :

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

Tester le déclencheur

Affichez la liste de tous les déclencheurs pour vérifier que le déclencheur a bien été créé :

gcloud beta events triggers list

Attendez que la création du déclencheur se propage et que celui-ci commence à filtrer les événements (ce processus peut prendre 10 minutes). Une fois prêt, il filtrera les événements de création et les enverra au service. Vous êtes maintenant prêt à déclencher un événement.

Créez un autre sujet Pub/Sub, comme vous l'avez fait précédemment :

gcloud pubsub topics create cre-gke-topic2

Si vous consultez les journaux du service Cloud Run dans la console Cloud, l'événement reçu devrait s'afficher :

Supprimer le déclencheur et les thèmes

Une fois les tests terminés, vous pouvez supprimer le déclencheur :

gcloud beta events triggers delete trigger-auditlog

Supprimer également les thèmes suivants :

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

13. Créer un déclencheur d'événement pour Cloud Storage

Vous allez configurer un déclencheur pour écouter les événements de Cloud Storage.

Créer un bucket

Commencez par créer un bucket Cloud Storage dans la même région que le service Cloud Run déployé. Vous pouvez remplacer BUCKET_NAME par un nom unique de votre choix :

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

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

Configurer les autorisations Cloud Storage

Avant de créer un déclencheur, vous devez autoriser le compte de service par défaut pour Cloud Storage à publier sur Pub/Sub.

Tout d'abord, vous devez trouver le compte de service que Cloud Storage utilise pour publier sur Pub/Sub. Vous pouvez suivre les étapes décrites dans Obtenir le compte de service Cloud Storage pour obtenir le compte de service ou utiliser la commande suivante :

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

Le compte de service doit être listé sous email_address.

En supposant que le compte de service que vous avez trouvé ci-dessus soit service-XYZ@gs-project-accounts.iam.gserviceaccount.com, définissez-le sur une variable d'environnement :

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

Ensuite, accordez à ce compte de service les droits de publication sur Pub/Sub :

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

Créer un déclencheur

Vous êtes maintenant prêt à créer un déclencheur d'événement pour les événements Cloud Storage.

Obtenez plus de détails sur les paramètres dont vous aurez besoin pour créer le déclencheur :

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

Créez le déclencheur avec les bons filtres :

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

Tester le déclencheur

Affichez la liste de tous les déclencheurs pour vérifier que le déclencheur a bien été créé :

gcloud beta events triggers list

Vous êtes maintenant prêt à déclencher un événement.

Importez un fichier aléatoire dans le bucket Cloud Storage :

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

Si vous consultez les journaux du service Cloud Run dans la console Cloud, l'événement reçu devrait s'afficher :

Supprimer le déclencheur

Une fois les tests terminés, vous pouvez supprimer le déclencheur :

gcloud beta events triggers delete trigger-storage

14. Créer un déclencheur d'événement pour Cloud Scheduler

Vous allez configurer un déclencheur pour écouter les événements de Cloud Scheduler.

Créer une application App Engine

Cloud Scheduler exige actuellement que les utilisateurs créent une application App Engine. Sélectionnez un emplacement App Engine et créez l'application :

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

Créer un déclencheur

Pour obtenir plus d'informations sur les paramètres dont vous aurez besoin pour créer un déclencheur pour les événements provenant de sources Google Cloud, exécutez la commande suivante :

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

Choisissez un emplacement Cloud Scheduler pour créer le planificateur :

export SCHEDULER_LOCATION=europe-west1

Créez un déclencheur qui créera une tâche à exécuter toutes les minutes dans Google Cloud Scheduler et appellera le service cible :

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"

Tester le déclencheur

Affichez la liste de tous les déclencheurs pour vérifier que le déclencheur a bien été créé :

gcloud beta events triggers list

Si vous consultez les journaux du service Cloud Run dans la console Cloud, vous devriez voir l'événement reçu.

Supprimer le déclencheur

Une fois les tests terminés, vous pouvez supprimer le déclencheur :

gcloud beta events triggers delete trigger-scheduler

15. Événements personnalisés (point de terminaison du courtier)

Dans cette partie de l'atelier de programmation, vous allez produire et consommer des événements personnalisés à l'aide du Broker.

Créer un pod Curl pour générer des événements

Les événements sont généralement créés de manière programmatique. Toutefois, lors de cette étape, vous utiliserez curl pour envoyer manuellement des événements individuels et voir comment ces événements sont reçus par le bon consommateur.

Pour créer un pod qui sert de producteur d'événements, exécutez la commande suivante :

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

Vérifiez que le pod curl fonctionne correctement. Vous devriez voir un pod appelé curl avec Status=Running :

kubectl get pod curl -n ${NAMESPACE}

Créer un déclencheur

Vous allez créer un déclencheur avec un filtre sur le type CloudEvents spécifique (alpha-type dans ce cas) que vous allez émettre. Notez que vous pouvez utiliser un filtrage par mot clé exact sur un nombre illimité d'attributs CloudEvents et d'extensions. Si votre filtre définit plusieurs attributs, un événement doit comporter tous les attributs pour que le déclencheur puisse le filtrer. À l'inverse, si vous ne spécifiez pas de filtre, tous les événements seront reçus dans votre service.

Créez le déclencheur :

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

Tester le déclencheur

Affichez la liste de tous les déclencheurs pour vérifier que le déclencheur a bien été créé :

gcloud beta events triggers list

Créez un événement en envoyant une requête HTTP au Broker. Rappelez-vous l'URL du courtier en exécutant la commande suivante :

kubectl get brokers -n ${NAMESPACE}

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

Connectez-vous en SSH au pod curl que vous avez créé précédemment :

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

Vous vous êtes connecté au pod via SSH et pouvez maintenant effectuer une requête HTTP. Une invite semblable à celle ci-dessous s'affiche :

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

Créez un événement :

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

Si l'événement a été reçu, vous recevrez une réponse HTTP 202 Accepted. Quittez la session SSH avec Ctrl + D.

Vérifiez que l'événement publié a été envoyé en consultant les journaux du service Cloud Run :

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

Supprimer le déclencheur

Une fois les tests terminés, vous pouvez supprimer le déclencheur :

gcloud beta events triggers delete trigger-custom

16. Félicitations !

Bravo ! Vous avez terminé cet atelier de programmation.

Points abordés

Vision à long terme des événements pour Cloud Run for Anthos
État actuel des événements pour Cloud Run pour Anthos
Créer un récepteur Cloud Run
Créer un déclencheur d'événement pour Cloud Pub/Sub
Créer un déclencheur d'événement pour les journaux d'audit
Créer un déclencheur d'événement pour Cloud Storage
Créer un déclencheur d'événement pour Cloud Scheduler
Produire et consommer des événements personnalisés