1. Introducción
Cloud Run te permite ejecutar contenedores sin estado en un entorno completamente administrado. Se basa en Knative de código abierto, lo que te permite ejecutar tus contenedores completamente administrados con Cloud Run o en tu clúster de Google Kubernetes Engine con Cloud Run for Anthos.
Events for Cloud Run for Anthos facilita la conexión de los servicios de Cloud Run con eventos de una variedad de fuentes. Te permite compilar arquitecturas basadas en eventos en las que los microservicios están distribuidos y con acoplamiento bajo. También se encarga de la transferencia, la entrega, la seguridad, la autorización y el manejo de errores de eventos por ti, lo que mejora la agilidad de los desarrolladores y la resiliencia de las aplicaciones.
En este codelab, aprenderás sobre los eventos para Cloud Run for Anthos. Más específicamente, escucharás eventos de Cloud Pub/Sub, registros de auditoría, Cloud Storage y Cloud Scheduler, y aprenderás a producir y consumir eventos personalizados.
Qué aprenderás
- Visión a largo plazo de los eventos para Cloud Run for Anthos
- Estado actual de Eventos para Cloud Run for Anthos
- Crear un receptor de Cloud Run
- Crear un activador de eventos para Cloud Pub/Sub
- Crear un activador de eventos para los registros de auditoría
- Crea un activador de eventos para Cloud Storage
- Crea un activador de eventos para Cloud Scheduler
- Produce y consume eventos personalizados
2. Visión a largo plazo
A medida que adoptamos la arquitectura sin servidores, los eventos se convierten en una parte integral de la forma en que se comunican los microservicios desacoplados. Events for Cloud Run for Anthos hace que los eventos sean un elemento fundamental de la oferta de Cloud Run for Anthos, de modo que sea fácil compilar aplicaciones sin servidores basadas en eventos.
Los eventos para Cloud Run for Anthos permiten la entrega asíncrona confiable, segura y escalable de eventos desde fuentes de eventos empaquetadas o creadas por aplicaciones a consumidores dentro y fuera del clúster.
Fuentes de Google Cloud | Fuentes de eventos que son productos propiedad de Google Cloud |
Fuentes de Google | Fuentes de eventos que son productos de Google, como Gmail, Hangouts, Android Management y muchos más |
Fuentes personalizadas | Fuentes de eventos que no son productos de Google y que crean los usuarios finales. Pueden ser fuentes de Knative desarrolladas por el usuario o cualquier otra app que se ejecute en el clúster y que pueda producir un Cloud Event. |
Fuentes externas | Son fuentes de eventos que no son propiedad de Google ni de los usuarios finales. Esto incluye fuentes de eventos populares, como GitHub, SAP, Datadog, PagerDuty, etc., que son propiedad de proveedores externos, socios o comunidades de OSS, y que estos mantienen. |
Los eventos se normalizan al formato CloudEvents v1.0 para la interoperabilidad entre servicios. CloudEvents es una especificación abierta independiente del proveedor que describe los datos de eventos en formatos comunes, lo que permite la interoperabilidad entre servicios, plataformas y sistemas.
Events for Cloud Run cumple con Knative Eventing y permite la portabilidad de contenedores hacia y desde otras implementaciones basadas en Knative. Esto proporciona un framework coherente y que no depende de la nube para conectar de forma declarativa los productores de eventos con los consumidores de eventos.
3. Estado actual
Esta versión preliminar es la primera que ofrece un conjunto inicial de la funcionalidad a largo plazo.
Para permitir que los usuarios compilen aplicaciones sin servidores controladas por eventos, nuestro enfoque inicial se centra en dos aspectos:
- Proporcionar un amplio ecosistema de fuentes de Google Cloud que permita que los servicios de Cloud Run en el clúster de Anthos reaccionen a los eventos de los servicios de Google Cloud
- Al principio, los eventos de las fuentes de Google Cloud se entregan a través de los Registros de auditoría de Cloud (CAL), lo que permite una gran variedad de fuentes de eventos. La latencia y la disponibilidad de la entrega de eventos desde estas fuentes están vinculadas a las de los Registros de auditoría de Cloud. Cada vez que se publica un evento de una fuente de Google Cloud, se crea una entrada de registro de auditoría de Cloud correspondiente.
- Junto con los registros de auditoría de Cloud, existe compatibilidad de primer nivel para consumir eventos de Cloud Storage, Cloud Pub/Sub y Cloud Scheduler. Seguiremos expandiendo este ecosistema de fuentes con más fuentes de primer nivel a medida que aprendamos más sobre los recorridos de los usuarios y sus comentarios.
- Permite que las aplicaciones y los servicios para usuarios finales emitan eventos personalizados publicándolos en una URL de Broker local del clúster con alcance de espacio de nombres.
El mecanismo de entrega subyacente usa temas y suscripciones de Cloud Pub/Sub que son visibles en los proyectos de los clientes. Por lo tanto, la función proporciona las mismas garantías de entrega que Cloud Pub/Sub.
El activador de eventos proporciona una forma de suscribirse a eventos para que los eventos que coincidan con el filtro del activador se entreguen en el destino (o receptor) al que apunta el activador.
Todos los eventos se entregan en el formato CloudEvents v1.0 para la interoperabilidad entre servicios.
Seguiremos ofreciendo más valor de forma iterativa hasta el lanzamiento de la versión GA y más allá.
4. Configuración y requisitos
Configuración del entorno de autoaprendizaje
- Accede a la consola de Cloud y crea un proyecto nuevo o reutiliza uno existente. Si aún no tienes una cuenta de Gmail o de Google Workspace, debes crear una.
- El Nombre del proyecto es el nombre visible de este proyecto. Siempre que sigas sus convenciones de nomenclatura, puedes usar lo que quieras y actualizarlo en cualquier momento.
- El ID del proyecto debe ser único en todos los proyectos de Google Cloud y es inmutable (no se puede cambiar una vez que se configura). La consola de Cloud genera automáticamente una cadena única. Por lo general, no importa cuál sea. En la mayoría de los codelabs, deberás hacer referencia al ID del proyecto (suele identificarse como
PROJECT_ID), por lo que, si no te gusta, genera otro aleatorio o puedes probar con uno propio y ver si está disponible. Después de crear el proyecto, este ID se “congela” y no se puede cambiar.
- A continuación, deberás habilitar la facturación en la consola de Cloud para usar los recursos de Google Cloud recursos.
Ejecutar este codelab no debería costar mucho, tal vez nada. Asegúrate de seguir las instrucciones de la sección “Realiza una limpieza”, en la que se aconseja cómo cerrar recursos para que no se te facture más allá de este instructivo. Los usuarios nuevos de Google Cloud son aptos para participar en el programa Prueba gratuita de USD 300.
Inicia Cloud Shell
Si bien Google Cloud y Spanner se pueden operar de manera remota desde tu laptop, en este codelab usarás Google Cloud Shell, un entorno de línea de comandos que se ejecuta en la nube.
En GCP Console, haga clic en el ícono de Cloud Shell en la barra de herramientas superior derecha:
El aprovisionamiento y la conexión al entorno deberían tomar solo unos minutos. Cuando termine el proceso, debería ver algo como lo siguiente:
Esta máquina virtual está cargada con todas las herramientas de desarrollo que necesitarás. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud, lo que permite mejorar considerablemente el rendimiento de la red y la autenticación. Puedes realizar todo tu trabajo en este lab usando simplemente un navegador.
5. Habilita las APIs y configura la zona y la plataforma
Configura el ID del proyecto y, luego, instala los componentes alfa
En Cloud Shell, GOOGLE_CLOUD_PROJECT ya debería estar configurado en el ID de tu proyecto. Si no es así, asegúrate de que esté configurado y de que tu gcloud esté configurado con ese ID del proyecto:
export GOOGLE_CLOUD_PROJECT=your-project-id
gcloud config set project ${GOOGLE_CLOUD_PROJECT}
Asegúrate de que el componente de gcloud para la versión alfa esté instalado:
gcloud components install alpha
Habilita las APIs
Habilita todos los servicios necesarios con el siguiente comando:
gcloud services enable cloudapis.googleapis.com gcloud services enable container.googleapis.com gcloud services enable containerregistry.googleapis.com gcloud services enable cloudbuild.googleapis.com
Establece la zona y la plataforma
Antes de crear un clúster de GKE con Cloud Run Events, establece el nombre del clúster, la zona y la plataforma. Por ejemplo, aquí configuramos el nombre y la zona en events-cluster y europe-west1-b, y la plataforma en gke,.
En 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
Puedes verificar que la configuración esté establecida:
gcloud config list ... [run] cluster = events-cluster cluster_location = europe-west1-b platform = gke
6. Crea un clúster de GKE con Cloud Run Events
Crea un clúster de GKE que ejecute Kubernetes >= 1.15.9-gke.26, con los siguientes complementos habilitados: 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 eventos de Cloud Run (plano de control)
Los eventos de Cloud Run tienen un plano de control y un plano de datos que deben configurarse por separado. Para configurar el plano de control, haz lo siguiente:
En Cloud Shell:
gcloud beta events init
Esto inicializará el sistema de eventos y también creará varias cuentas de servicio necesarias. Asegúrate de seleccionar “Sí” cuando se te solicite crear una cuenta de servicio.
En este punto, el plano de control debería estar inicializado correctamente. Deberías ver cuatro Pods con un
Estado de Running, 2 (controller-xxx-xxx y webhook-xxx-xxx) en el espacio de nombres cloud-run-events y 2 (eventing-controller-xxx-xxx y eventing-webhook-xxx-xxx) en el espacio de nombres knative-eventing. Para verificarlo, ejecuta los siguientes comandos:
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 Cloud Run Events (plano de datos)
A continuación, debes configurar el plano de datos en los espacios de nombres del usuario. Esto crea un agente con los permisos adecuados para leer y escribir en Pub/Sub.
En Cloud Shell, configura una variable de entorno NAMESPACE para el espacio de nombres que deseas usar para tus objetos. Puedes establecerlo en default si deseas usar el espacio de nombres predeterminado, como se muestra a continuación:
export NAMESPACE=default
Ten en cuenta que, si el espacio de nombres especificado no existe (es decir, no es el predeterminado), debes crearlo:
kubectl create namespace ${NAMESPACE}
Inicializa el espacio de nombres con el secreto predeterminado:
gcloud beta events namespaces init ${NAMESPACE} --copy-default-secret
Crea un agente predeterminado en el espacio de nombres:
gcloud beta events brokers create default --namespace ${NAMESPACE}
Verifica que se haya creado el agente. Ten en cuenta que el agente puede tardar unos segundos en estar listo:
kubectl get broker -n ${NAMESPACE}
NAME READY REASON URL
default True http://default-brokercell-ingress.cloud-run-events.svc.cluster.local/default/default
9. Descubrimiento de eventos
Puedes descubrir cuáles son las fuentes registradas, los tipos de eventos que pueden emitir y cómo configurar activadores para consumirlos.
Para ver la lista de los diferentes tipos de eventos, haz lo siguiente:
gcloud beta events types list
Para obtener más información sobre cada tipo de evento, haz lo siguiente:
gcloud beta events types describe google.cloud.pubsub.topic.v1.messagePublished
10. Crea un receptor de Cloud Run
Como receptor de eventos, implementa un servicio de Cloud Run que registre el contenido del CloudEvent que recibe.
Puedes usar el event_display de Knative que ya está compilado y cuya imagen de contenedor se compiló como parte de la versión de Knative. Puedes ver los detalles de la imagen del contenedor en event-display.yaml:
... containers: - image: gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display@sha256:8da2440b62a5c077d9882ed50397730e84d07037b1c8a3e40ff6b89c37332b27
Implementa en Cloud Run
Implementa una aplicación alojada en contenedores en 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
Si la operación se completa de forma correcta, la línea de comandos mostrará la URL de servicio. Ahora puedes abrir la URL de servicio en cualquier ventana del navegador para visitar el contenedor implementado.
11. Crear un activador de eventos para Cloud Pub/Sub
Una forma de recibir eventos es a través de Cloud Pub/Sub. Las aplicaciones personalizadas pueden publicar mensajes en Cloud Pub/Sub, y estos mensajes pueden entregarse a receptores de Google Cloud Run a través de Eventos para Cloud Run.
Crea un tema
Primero, crea un tema de Cloud Pub/Sub. Puedes reemplazar TOPIC_ID por el nombre de tema único que prefieras:
export TOPIC_ID=cr-gke-topic
gcloud pubsub topics create ${TOPIC_ID}
Crea un activador
Antes de crear el activador, obtén más detalles sobre los parámetros que necesitarás para crear un activador para eventos de Cloud Pub/Sub:
gcloud beta events types describe google.cloud.pubsub.topic.v1.messagePublished
Crea un activador para filtrar los eventos publicados en el tema de Cloud Pub/Sub en nuestro servicio de Cloud Run implementado:
gcloud beta events triggers create trigger-pubsub \
--namespace ${NAMESPACE} \
--target-service ${SERVICE_NAME} \
--type google.cloud.pubsub.topic.v1.messagePublished \
--parameters topic=${TOPIC_ID}
Prueba el activador
Para verificar que se haya creado el activador, enumera todos los activadores:
gcloud beta events triggers list
Es posible que debas esperar hasta 10 minutos para que se propague la creación del activador y comience a filtrar eventos.
Para simular una aplicación personalizada que envía un mensaje, puedes usar gcloud para activar un evento:
gcloud pubsub topics publish ${TOPIC_ID} --message="Hello there"
El receptor de Cloud Run que creamos registra el cuerpo del mensaje entrante. Puedes ver esto en la sección Registros de tu instancia de Cloud Run:
Ten en cuenta que "Hola" se codificará en base64, ya que Pub/Sub lo envió, y deberás decodificarlo si quieres ver el mensaje original enviado.
Borra el activador
De manera opcional, puedes borrar el activador cuando termines de probarlo.
gcloud beta events triggers delete trigger-pubsub --namespace ${NAMESPACE}
12. Crear un activador de eventos para los registros de auditoría
Configurarás un activador para escuchar eventos de registros de auditoría. Más específicamente, buscarás eventos de creación de temas de Pub/Sub en los registros de auditoría.
Habilita los registros de auditoría
Para recibir eventos de un servicio, debes habilitar los registros de auditoría. En la consola de Cloud, selecciona IAM & Admin > Audit Logs en el menú de la esquina superior izquierda. En la lista de servicios, marca Google Cloud Pub/Sub:
En el lado derecho, asegúrate de que estén seleccionadas las opciones Administrador, Lectura y Escritura. Haz clic en Guardar:
Registros de auditoría de prueba
Para aprender a identificar los parámetros, necesitarás configurar un activador real y realizar una operación real.
Por ejemplo, crea un tema de Pub/Sub:
gcloud pubsub topics create cre-gke-topic1
Ahora, veamos qué tipo de registro de auditoría generó esta actualización. En la consola de Cloud, selecciona Logging > Logs Viewer en el menú de la esquina superior izquierda.
En Query Builder,, elige Cloud Pub/Sub Topic y haz clic en Add:
Una vez que ejecutes la consulta, verás los registros de los temas de Pub/Sub, y uno de ellos debería ser google.pubsub.v1.Publisher.CreateTopic:
Observa los objetos serviceName, methodName y resourceName. Los usaremos para crear el activador.
Crea un activador
Ahora, ya puedes crear un activador de eventos para los registros de auditoría.
Para obtener más detalles sobre los parámetros que necesitarás para crear un activador para eventos de fuentes de Google Cloud, ejecuta el siguiente comando:
gcloud beta events types describe google.cloud.audit.log.v1.written
Crea el activador con los filtros correctos:
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
Prueba el activador
Haz una lista de todos los activadores para confirmar que se creó correctamente:
gcloud beta events triggers list
Espera hasta 10 minutos para que se propague la creación del activador y comience a filtrar eventos. Cuando esté listo, filtrará los eventos de creación y los enviará al servicio. Ya tienes todo listo para activar un evento.
Crea otro tema de Pub/Sub, como hiciste antes:
gcloud pubsub topics create cre-gke-topic2
Si revisas los registros del servicio de Cloud Run en Cloud Console, deberías ver el evento recibido:
Borra el activador y los temas
De manera opcional, puedes borrar el activador una vez que termines de probarlo:
gcloud beta events triggers delete trigger-auditlog
También borra los siguientes temas:
gcloud pubsub topics delete cre-gke-topic1 cre-gke-topic2
13. Crea un activador de eventos para Cloud Storage
Configurarás un activador para escuchar eventos de Cloud Storage.
Cree un depósito
Primero, crea un bucket de Cloud Storage en la misma región que el servicio de Cloud Run implementado. Puedes reemplazar BUCKET_NAME por el nombre único que prefieras:
export BUCKET_NAME=[new bucket name] export REGION=europe-west1 gsutil mb -p $(gcloud config get-value project) \ -l $REGION \ gs://$BUCKET_NAME/
Configura permisos de Cloud Storage
Antes de crear un activador, debes otorgar permiso a la cuenta de servicio predeterminada de Cloud Storage para publicar en Pub/Sub.
Primero, debes encontrar la cuenta de servicio que Cloud Storage usa para publicar en Pub/Sub. Puedes seguir los pasos que se describen en Cómo obtener la cuenta de servicio de Cloud Storage para obtener la cuenta de servicio o usar el siguiente 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"
La cuenta de servicio debe aparecer en email_address.
Supongamos que la cuenta de servicio que encontraste anteriormente era service-XYZ@gs-project-accounts.iam.gserviceaccount.com. Establece esto en una variable de entorno:
export GCS_SERVICE_ACCOUNT=service-XYZ@gs-project-accounts.iam.gserviceaccount.com
Luego, otorga derechos a esa cuenta de servicio para publicar en Pub/Sub:
gcloud projects add-iam-policy-binding ${GOOGLE_CLOUD_PROJECT} \
--member=serviceAccount:${GCS_SERVICE_ACCOUNT} \
--role roles/pubsub.publisher
Crea un activador
Ahora, ya puedes crear un activador de eventos para los eventos de Cloud Storage.
Puedes obtener más detalles sobre los parámetros que necesitarás para construir el activador:
gcloud beta events types describe google.cloud.storage.object.v1.finalized
Crea el activador con los filtros correctos:
gcloud beta events triggers create trigger-storage \
--namespace ${NAMESPACE} \
--target-service ${SERVICE_NAME} \
--type=google.cloud.storage.object.v1.finalized \
--parameters bucket=${BUCKET_NAME}
Prueba el activador
Haz una lista de todos los activadores para confirmar que se creó correctamente:
gcloud beta events triggers list
Espera hasta 10 minutos para que se propague la creación del activador y comience a filtrar eventos. Cuando esté listo, filtrará los eventos de creación y los enviará al servicio.
Ya tienes todo listo para activar un evento.
Sube un archivo aleatorio al bucket de Cloud Storage:
echo "Hello World" > random.txt
gsutil cp random.txt gs://${BUCKET_NAME}/random.txt
Si revisas los registros del servicio de Cloud Run en Cloud Console, deberías ver el evento recibido:
Borra el activador
De manera opcional, puedes borrar el activador una vez que termines de probarlo:
gcloud beta events triggers delete trigger-storage
14. Crea un activador de eventos para Cloud Scheduler
Configurarás un activador para escuchar eventos de Cloud Scheduler.
Crea una aplicación de App Engine.
Actualmente, Cloud Scheduler requiere que los usuarios creen una aplicación de App Engine. Elige una ubicación de App Engine y crea la app:
export APP_ENGINE_LOCATION=europe-west
gcloud app create --region=${APP_ENGINE_LOCATION}
Crear un activador
Para obtener más detalles sobre los parámetros que necesitarás para crear un activador para eventos de fuentes de Google Cloud, ejecuta el siguiente comando:
gcloud beta events types describe google.cloud.scheduler.job.v1.executed
Elige una ubicación de Cloud Scheduler para crear el programador:
export SCHEDULER_LOCATION=europe-west1
Crea un activador que cree un trabajo para que se ejecute cada minuto en Google Cloud Scheduler y llame al servicio de destino:
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"
Prueba el activador
Haz una lista de todos los activadores para confirmar que se creó correctamente:
gcloud beta events triggers list
Espera hasta 10 minutos para que se propague la creación del activador y comience a filtrar eventos. Cuando esté listo, filtrará los eventos de creación y los enviará al servicio.
Si revisas los registros del servicio de Cloud Run en Cloud Console, deberías ver el evento recibido.
Borra el activador
De manera opcional, puedes borrar el activador una vez que termines de probarlo:
gcloud beta events triggers delete trigger-scheduler
15. Eventos personalizados (extremo del agente)
En esta parte del codelab, producirás y consumirás eventos personalizados con el agente.
Crea un Pod de Curl para generar eventos
Por lo general, los eventos se crean de forma programática. Sin embargo, en este paso, usarás curl para enviar manualmente eventos individuales y ver cómo los recibe el consumidor correcto.
Para crear un Pod que actúe como productor de eventos, ejecuta el siguiente 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 que el Pod de curl funcione correctamente. Deberías ver un pod llamado curl con Status=Running:
kubectl get pod curl -n ${NAMESPACE}
Crea un activador
Crearás un activador con un filtro en el tipo de CloudEvents específico (en este caso, alpha-type) que emitirás. Ten en cuenta que se admite el filtrado de concordancia exacta en cualquier cantidad de atributos de CloudEvents, así como de extensiones. Si el filtro establece varios atributos, un evento debe tener todos los atributos para que el activador lo filtre. Por el contrario, si no especificas un filtro, recibirás todos los eventos en tu servicio.
Crea el activador:
gcloud beta events triggers create trigger-custom \
--namespace ${NAMESPACE} \
--target-service ${SERVICE_NAME} \
--type=alpha-type \
--custom-type
Prueba el activador
Haz una lista de todos los activadores para confirmar que se creó correctamente:
gcloud beta events triggers list
Crea un evento enviando una solicitud HTTP al agente. Para recordar la URL del agente, ejecuta el siguiente comando:
kubectl get brokers -n ${NAMESPACE}
NAME READY REASON URL
default True http://default-broker.<NAMESPACE>.svc.cluster.local
Establece una conexión SSH al Pod curl que creaste anteriormente:
kubectl --namespace ${NAMESPACE} attach curl -it
Accediste al pod a través de SSH y ahora puedes realizar una solicitud HTTP. Aparecerá un mensaje similar al siguiente:
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:/ ]$
Sigue estos pasos para crear 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"}'
Si se recibió el evento, recibirás una respuesta HTTP 202 Accepted. Sal de la sesión de SSH con Ctrl + D.
Revisa los registros del servicio de Cloud Run para verificar que se haya enviado el evento publicado:
kubectl logs --selector serving.knative.dev/service=$SERVICE_NAME \ -c user-container -n $NAMESPACE --tail=100
Borra el activador
De manera opcional, puedes borrar el activador una vez que termines de probarlo:
gcloud beta events triggers delete trigger-custom
16. ¡Felicitaciones!
Felicitaciones por completar el codelab.
Temas abordados
- Visión a largo plazo de los eventos para Cloud Run for Anthos
- Estado actual de Eventos para Cloud Run for Anthos
- Crear un receptor de Cloud Run
- Crear un activador de eventos para Cloud Pub/Sub
- Crear un activador de eventos para los registros de auditoría
- Crea un activador de eventos para Cloud Storage
- Crea un activador de eventos para Cloud Scheduler
- Produce y consume eventos personalizados