1. Introducción
Cloud Run te permite ejecutar contenedores sin estado en un entorno completamente administrado. Está compilado a partir de Knative de código abierto, lo que te permite ejecutar tus contenedores completamente administrados con Cloud Run o en el 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 crear arquitecturas controladas por eventos en las que los microservicios están vinculados y distribuidos de manera flexible. También se encarga de la transferencia de eventos, la entrega, la seguridad, la autorización y el manejo de errores por ti, lo que mejora la agilidad del desarrollador y la resiliencia de las aplicaciones.
En este codelab, aprenderás sobre los eventos para Cloud Run for Anthos. De manera más específica, escucharás eventos de Cloud Pub/Sub, Registros de auditoría, Cloud Storage y Cloud Scheduler, y aprenderás a producir o consumir eventos personalizados.
Qué aprenderás
- Visión a largo plazo de los eventos para Cloud Run for Anthos
- Estado actual de los eventos de Cloud Run for Anthos
- Crea un receptor de Cloud Run
- Crea un activador de eventos para Cloud Pub/Sub
- Crea 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 una arquitectura sin servidores, los eventos se vuelven una parte integral de cómo se comunican los microservicios separados. Events for Cloud Run for Anthos convierte a los eventos en un recurso de primera clase de la oferta de Cloud Run for Anthos, de modo que sea fácil compilar aplicaciones sin servidores controladas por eventos.
Los eventos para Cloud Run for Anthos permiten la entrega de eventos asíncronos, confiables, seguros y escalables desde fuentes de eventos empaquetadas o creadas por apps a consumidores en el clúster 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, Administración de Android 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 que desarrolló el usuario o cualquier otra aplicación que se ejecute en el clúster y que pueda producir un evento de Cloud. |
Fuentes de terceros | Fuentes de eventos que no son propiedad de Google ni del usuario final. Esto incluye fuentes de eventos populares, como GitHub, SAP, Datadog, Pagerduty, etc., que son propiedad de proveedores externos, socios o comunidades de OSS, y los mantienen. |
Los eventos se normalizan en el formato CloudEvents v1.0 para la interoperabilidad entre servicios. CloudEvents es una especificación abierta neutral para proveedores que describe los datos de eventos en formatos comunes, lo que permite la interoperabilidad entre servicios, plataformas y sistemas.
Los eventos de Cloud Run cumplen con las especificaciones de Knative Eventing y permiten la portabilidad de los contenedores desde y hacia otras implementaciones basadas en Knative. Esto proporciona un marco de trabajo coherente e independiente de la nube para conectar de forma declarativa a los productores de eventos con consumidores de eventos.
3. Estado actual
Esta versión preliminar es la primera versión que proporciona un conjunto inicial de la funcionalidad a largo plazo.
Para permitir que los usuarios compilen aplicaciones sin servidores impulsadas por eventos, nuestro enfoque inicial es dos aspectos:
- Proporcionar un amplio ecosistema de fuentes de Google Cloud que permite que los servicios de Cloud Run en el clúster de Anthos reaccionen a los eventos de los servicios de Google Cloud
- Desde el principio, los eventos de fuentes de Google Cloud se entregan a través de 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 de 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 la entrada correspondiente de los registros de auditoría de Cloud.
- Junto con los Registros de auditoría de Cloud, hay asistencia 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 primera clase a medida que aprendamos más de los recorridos de los usuarios y los comentarios.
- Habilita las aplicaciones y los servicios de usuario final para que emitan eventos personalizados mediante la publicación en una URL de agente 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 las proyectos. 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 aquellos que coincidan con el filtro de activadores se entreguen al destino (o receptor) al que apunta el activador.
Todos los eventos se entregan en el formato de Cloud Events v1.0 para la interoperabilidad entre servicios.
Seguiremos entregando más valor de manera iterativa hasta llegar a la DG 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 para este proyecto. Siempre y cuando sigas sus convenciones de nomenclatura, puedes usar lo que desees 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 te importa qué es. En la mayoría de los codelabs, deberás hacer referencia al ID del proyecto (que suele identificarse como
PROJECT_ID). Por lo tanto, si no te gusta, genera otro aleatorio, o bien puedes probar el tuyo y ver si está disponible. Luego, se “congela” una vez creado el proyecto.
- 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 no incurrir en facturación más allá de este instructivo. Los usuarios nuevos de Google Cloud son aptos para participar en el programa Prueba gratuita de$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, configura la zona y la plataforma
Cómo instalar el ID del proyecto y los componentes Alfa
En Cloud Shell, GOOGLE_CLOUD_PROJECT ya debería estar establecido como el ID de tu proyecto. De lo contrario, asegúrate de que esté configurada y que tu gcloud esté configurada 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 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
Configura la zona y la plataforma
Antes de crear un clúster de GKE con eventos de Cloud Run, establece el nombre del clúster, la zona y la plataforma. A modo de ejemplo, aquí establecemos el nombre y la zona en events-cluster y europe-west1-b, y la plataforma es 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 eventos de Cloud Run
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 se deben configurar por separado. Para configurar el plano de control, haz lo siguiente:
En Cloud Shell:
gcloud beta events init
Esto inicializará eventos y también creará un número de 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 inicializarse de forma correcta. Deberías ver cuatro Pods con un
Estado 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 comprobarlo, 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 eventos de Cloud Run (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 desde y hacia Pub/Sub.
En Cloud Shell, configura una variable de entorno NAMESPACE para el espacio de nombres que deseas usar en tus objetos. Puedes configurarlo como 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, el espacio de nombres no es el predeterminado), deberás 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 pueden pasar unos segundos hasta que el corredor esté 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 consumirlas.
Para ver la lista de diferentes tipos de eventos, sigue estos pasos:
gcloud beta events types list
Para obtener más información sobre cada tipo de evento, sigue estos pasos:
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 elemento event_display de Knative que ya está compilado y su imagen de contenedor compilada como parte de la versión de Knative. Puedes ver los detalles de la imagen de 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 tu 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. Crea 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 pueden entregarse a receptores de Google Cloud Run a través de eventos para Cloud Run.
Cómo crear 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 construir un activador para los 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 implementado de Cloud Run:
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 el activador se cree, 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.
Si quieres 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 la instancia de Cloud Run:
Ten en cuenta que “Hola” tendrá la codificación en base64 como la envió Pub/Sub y tendrás que decodificarlo si quieres ver el mensaje original enviado.
Borra el activador
De manera opcional, puedes borrar el activador una vez que finalice la prueba.
gcloud beta events triggers delete trigger-pubsub --namespace ${NAMESPACE}
12. Crea un activador de eventos para los registros de auditoría
Configurarás un activador para escuchar los eventos de los registros de auditoría. Específicamente, deberás buscar 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ú superior izquierdo. En la lista de servicios, marca Google Cloud Pub/Sub:
En el lado derecho, asegúrate de que estén seleccionadas las opciones Administrador (Admin), Lectura y Escritura (Write). Haz clic en Save:
Prueba los registros de auditoría
Si deseas aprender a identificar los parámetros que necesitarás para configurar un activador real, realiza 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ú superior izquierdo.
En Query Builder,, elige Cloud Pub/Sub Topic y haz clic en Add:
Una vez que ejecutes la consulta, verás registros de los temas de Pub/Sub, y uno de ellos debería ser google.pubsub.v1.Publisher.CreateTopic:
Observa el serviceName, methodName y resourceName. Los usaremos para crear el activador.
Crea un activador
Ya puedes crear un activador de eventos para los registros de auditoría.
Si quieres obtener más detalles sobre los parámetros que necesitarás para crear un activador para los 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 adecuados:
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
Enumera todos los activadores para confirmar que se creó de forma correcta:
gcloud beta events triggers list
Espera hasta 10 minutos para que se propague la creación del activador y comience a filtrar eventos. Una vez que esté listo, filtrará los eventos de creación y los enviará al servicio. Ya está todo listo para que inicies un evento.
Crea otro tema de Pub/Sub, como lo hiciste antes:
gcloud pubsub topics create cre-gke-topic2
Si revisas los registros del servicio de Cloud Run en la consola de Cloud, deberías ver el evento recibido:
Borra el activador y los temas
De manera opcional, puedes borrar el activador una vez que finalice la prueba:
gcloud beta events triggers delete trigger-auditlog
Borrar también los 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 implementado de Cloud Run. 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 los permisos de Cloud Storage
Antes de crear un activador, debes otorgar permiso de publicación en Pub/Sub a la cuenta de servicio predeterminada de Cloud Storage.
Primero, debes buscar la cuenta de servicio que usa Cloud Storage para publicar en Pub/Sub. Puedes seguir los pasos descritos 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 debería aparecer en email_address.
Supongamos que la cuenta de servicio que encontraste antes era service-XYZ@gs-project-accounts.iam.gserviceaccount.com. Configura esto en una variable de entorno:
export GCS_SERVICE_ACCOUNT=service-XYZ@gs-project-accounts.iam.gserviceaccount.com
Luego, otorga los 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
Ya está todo listo para crear un activador de 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 adecuados:
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
Enumera todos los activadores para confirmar que se creó de forma correcta:
gcloud beta events triggers list
Espera hasta 10 minutos para que se propague la creación del activador y comience a filtrar eventos. Una vez que esté listo, filtrará los eventos de creación y los enviará al servicio.
Ya está todo listo para que inicies 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 la consola de Cloud, deberías ver el evento recibido:
Borra el activador
De manera opcional, puedes borrar el activador una vez que finalice la prueba:
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 necesita 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
Si quieres obtener más detalles sobre los parámetros que necesitarás para crear un activador para los 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 que se ejecutará cada minuto en Google Cloud Scheduler y llamará 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
Enumera todos los activadores para confirmar que se creó de forma correcta:
gcloud beta events triggers list
Espera hasta 10 minutos para que se propague la creación del activador y comience a filtrar eventos. Una vez que esté listo, filtrará los eventos de creación y los enviará al servicio.
Si revisas los registros del servicio de Cloud Run en la consola de Cloud, deberías ver el evento recibido.
Borra el activador
De manera opcional, puedes borrar el activador una vez que finalice la prueba:
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.
Cómo crear un Pod de Curl para producir eventos
Por lo general, los eventos se crean de manera 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 para el tipo de CloudEvents en particular (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 en 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, todos los eventos se recibirán en tu Service.
Crea el activador:
gcloud beta events triggers create trigger-custom \
--namespace ${NAMESPACE} \
--target-service ${SERVICE_NAME} \
--type=alpha-type \
--custom-type
Prueba el activador
Enumera todos los activadores para confirmar que se creó de forma correcta:
gcloud beta events triggers list
Envía una solicitud HTTP al agente para crear un evento. Ejecuta el siguiente comando para recordar la URL del agente:
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 antes:
kubectl --namespace ${NAMESPACE} attach curl -it
Estableciste una conexión SSH al Pod 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:/ ]$
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"}'
Si se recibió el evento, recibirás una respuesta HTTP 202 Accepted. Sal de la sesión de SSH con Ctrl + D
Para verificar que el evento publicado se envió, consulta los registros del servicio de Cloud Run:
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 finalice la prueba:
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 los eventos de Cloud Run for Anthos
- Crea un receptor de Cloud Run
- Crea un activador de eventos para Cloud Pub/Sub
- Crea 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