Cette page a été traduite par l'API Cloud Translation.

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 Open Source Knative vous permet d'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 for Anthos.

Les événements pour Cloud Run for Anthos facilitent la connexion des services Cloud Run à des événements provenant de diverses sources. Il vous permet de créer des architectures basées sur des événements dans lesquelles des microservices sont faiblement couplés et distribués. Il se charge également de l'ingestion, de la diffusion, de la sécurité, de l'autorisation et de la gestion des erreurs des événements 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 for Anthos. Plus précisément, vous allez écouter des événements provenant de Cloud Pub/Sub, des journaux d'audit, de Cloud Storage et de Cloud Scheduler, et apprendre à générer/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 for 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
Créer 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 communication des microservices découplés. Events for Cloud Run for Anthos fait des événements un élément de premier ordre de l'offre Cloud Run for Anthos, ce qui facilite la création d'applications sans serveur basées sur des événements.

Events for Cloud Run for Anthos permet de diffuser des événements asynchrones de manière fiable, sécurisée et évolutive depuis les sources d'événements empaquetées ou créées par une application vers les clients sur cluster et hors cluster.

Sources Google Cloud	Sources d'événements appartenant à des produits appartenant à Google Cloud
Sources Google	Sources d'événements qui sont des produits appartenant à Google, tels que Gmail, Hangouts, Android Management, 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 pouvant générer un événement cloud.
Sources tierces	Sources d'événements qui ne sont ni Google, ni les utilisateurs finaux. Il peut s'agir de sources d'événements populaires telles que GitHub, SAP, Datadog ou Pagerduty, entre autres. Ces ressources sont détenues et gérées par des fournisseurs tiers, des partenaires ou des communautés OSS.

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

Les événements pour Cloud Run sont conformes à Knative Eventing et permettent 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, notre objectif initial est de viser deux objectifs:

Fournissez un large é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.

Dans un premier temps, les événements provenant de sources Google Cloud sont transmis par le biais de Cloud Audit Logs (CAL), ce qui permet un large éventail de sources d'événements. La latence et la disponibilité de la diffusion d'événements à partir de ces sources sont liées à celles de Cloud Audit Logs. Chaque fois qu'un événement d'une source Google Cloud est publié, une entrée de journal Cloud Audit Log correspondante est créée.
En plus de Cloud Audit Logs, il offre une assistance de premier ordre pour consommer les événements de Cloud Storage, Cloud Pub/Sub et Cloud Scheduler. Nous continuerons à développer cet écosystème de sources en y ajoutant d'autres sources de premier ordre à mesure que nous tirerons des enseignements des parcours et des commentaires des utilisateurs.

Autorisez les applications et services de l'utilisateur final à émettre des événements personnalisés en publiant l'URL dans une URL d'agent de niveau cluster-local à l'échelle d'un espace de noms.

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

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

Tous les événements sont envoyés au format Cloud Events v1.0 pour assurer l'interopérabilité entre les services.

Nous continuerons à proposer davantage de valeur de façon itérative jusqu'à GA 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 le nom à afficher pour ce projet. Tant que vous respectez ses conventions d'attribution de noms, vous pouvez utiliser ce que vous voulez et la mettre à jour à tout moment.
L'ID du projet doit être unique parmi tous les projets Google Cloud et ne peut pas être modifié une fois qu'il est défini. La console Cloud génère automatiquement une chaîne unique. généralement, vous ne vous souciez pas de ce que c’est. Dans la plupart des ateliers de programmation, vous devrez référencer l'ID du projet (il est généralement identifié comme PROJECT_ID). Si cela ne vous convient pas, générez-en un autre au hasard ou essayez le vôtre pour voir s'il est disponible. Ensuite, il est « 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 gratuite. 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 doit 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 des événements Cloud Run, 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 est 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 des événements Cloud Run

Créez un cluster GKE exécutant Kubernetes avec une version supérieure ou égale à 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 des é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

Cette opération initialise les événements et crée un certain nombre de comptes de service nécessaires. Veillez à 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

État de 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. Pour le vérifier, exécutez 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 des événements Cloud Run (plan de données)

L'étape suivante consiste à configurer le plan de données dans les espaces de noms utilisateur. Cela crée un courtier disposant des autorisations appropriées pour lire/écrire depuis/vers 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 (autrement dit, s'il ne s'agit pas de la valeur 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 l'agent a bien été créé. Notez que cela peut prendre quelques secondes avant que l'agent soit 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 ce que sont 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 de l'événement CloudEvent qu'il reçoit.

Vous pouvez utiliser l'élément event_display de Knative, qui est déjà compilé, et son image de conteneur créée dans 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 une application 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

Vous pouvez recevoir des événements via Cloud Pub/Sub. Les applications personnalisées peuvent publier des messages dans Cloud Pub/Sub, qui peuvent être distribués aux récepteurs Google Cloud Run via des événements 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 thème 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 pour créer un déclencheur pour les événements 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 sur 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 bien été créé en listant tous les déclencheurs:

gcloud beta events triggers list

La propagation de la création du déclencheur et le début du filtrage des événements peuvent prendre jusqu'à 10 minutes.

Afin de simuler une application personnalisée envoyant un message, vous pouvez utiliser gcloud afin de déclencher un événement:

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

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

Notez que "Bonjour" sera encodé en base64 tel qu'il a été envoyé par Pub/Sub. Vous devrez le décoder si vous voulez voir le message d'origine envoyé.

Supprimer le déclencheur

Vous pouvez éventuellement supprimer le déclencheur une fois les tests terminés.

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 provenant des journaux d'audit. Plus précisément, vous allez rechercher 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 dont vous aurez besoin pour configurer un déclencheur réel, effectuez une opération réelle.

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

gcloud pubsub topics create cre-gke-topic1

Voyons maintenant le type de journal d'audit généré par cette mise à jour. 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, les journaux des sujets Pub/Sub s'affichent. L'un d'entre eux devrait être google.pubsub.v1.Publisher.CreateTopic:

Notez les éléments 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énements pour les journaux d'audit.

Pour en savoir plus sur les paramètres nécessaires à la création d'un déclencheur pour des é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 filtres appropriés:

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

Répertoriez tous les déclencheurs pour vérifier qu'ils ont bien été créés:

gcloud beta events triggers list

La propagation de la création du déclencheur et le début du filtrage des événements peuvent prendre jusqu'à 10 minutes. Une fois prêt, il filtre les événements créés et les envoie 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 Cloud Console, vous devriez voir l'événement reçu:

Supprimer le déclencheur et les sujets

Vous pouvez éventuellement supprimer le déclencheur une fois le test terminé:

gcloud beta events triggers delete trigger-auditlog

Supprimer également les sujets:

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 à autoriser Cloud Storage à publier dans Pub/Sub.

Tout d'abord, recherchez le compte de service que Cloud Storage utilise pour publier dans Pub/Sub. Pour obtenir le compte de service, suivez la procédure décrite dans Obtenir le compte de service Cloud Storage ou exécutez 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 répertorié sous email_address.

Supposons 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

Accordez ensuite des droits à ce compte de service pour publier 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énements pour les événements Cloud Storage.

Vous pouvez obtenir 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 filtres appropriés:

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

Répertoriez tous les déclencheurs pour vérifier qu'ils ont bien été créés:

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 Cloud Console, vous devriez voir l'événement reçu:

Supprimer le déclencheur

Vous pouvez éventuellement supprimer le déclencheur une fois le test terminé:

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 a actuellement besoin 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 en savoir plus sur les paramètres nécessaires à la création d'un déclencheur pour des é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 appelle 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

Répertoriez tous les déclencheurs pour vérifier qu'ils ont bien été créés:

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

Vous pouvez éventuellement supprimer le déclencheur une fois le test terminé:

gcloud beta events triggers delete trigger-scheduler

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

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

Créer un pod Curl pour produire des événements

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

Pour créer un pod agissant en tant que 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 nommé curl contenant Status=Running:

kubectl get pod curl -n ${NAMESPACE}

Créer un déclencheur

Vous allez créer un déclencheur avec un filtre correspondant au type CloudEvents (dans le cas présent, alpha-type) que vous émettre. Notez que vous pouvez utiliser le filtrage par mots clés exacts sur un nombre illimité d'attributs CloudEvents ainsi que d'extensions. Si votre filtre définit plusieurs attributs, un événement doit en posséder tous 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

Répertoriez tous les déclencheurs pour vérifier qu'ils ont bien été créés:

gcloud beta events triggers list

Créez un événement en envoyant une requête HTTP à l'agent de service. Pour afficher l'URL du courtier, exécutez 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é en SSH au pod et pouvez maintenant envoyer une requête HTTP. Une invite semblable à la suivante 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éer 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 bien é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

Vous pouvez éventuellement supprimer le déclencheur une fois le test terminé:

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 for 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
Créer et consommer des événements personnalisés