Activa (casi) cualquier evento en Cloud Run con Eventarc

El quickstart de Google sobre este tema recibe eventos de Cloud Storage, un servicio muy útil para notificar cuando se modifican datos y que Cloud Functions usa con frecuencia para ejecutar acciones cuando se crea, actualiza o elimina un objeto, etc. Además, es un excelente punto de partida para empezar a usar Eventarc.

Para ampliar el quickstart de Google, agrego la funcionalidad de cargar automáticamente en BigQuery los archivos creados en un bucket de GCS, una solicitud muy común que recibimos en DoiT International.

El servicio que utilizo en este artículo se activa cuando se crea un nuevo archivo CSV dentro de un bucket de GCS y ejecuta una carga de ese archivo en una tabla de BigQuery.

Nota: Eventarc todavía es un producto nuevo, recién salido de beta, por lo que aún le faltan ciertas funciones. La más importante es la posibilidad de apuntar a recursos específicos. Esto obliga a que el código activado verifique si se trata o no del recurso correcto, algo que ya está implementado en el código que comparto en este artículo.

El primer paso será clonar un repositorio con el código que escribí para este artículo y luego enviarlo a Cloud Build para crear una imagen de contenedor que pueda usar Cloud Run.

Primero, abre Cloud Shell dentro de tu Consola de GCP. Asegúrate de que esté apuntando al proyecto que quieres usar ejecutando el siguiente comando y reemplazando por el ID de tu proyecto:

gcloud config set project <project id>

Ya con el proyecto correcto configurado, ejecuta el siguiente comando para clonar el repositorio de git:

git clone https://github.com/sayle-doit/eventarc-blog.git
cd eventarc-blog

Una vez clonado, te recomiendo darle un vistazo al código —en especial al Dockerfile y al archivo main.py— para entender qué hace.

Lo siguiente es construir una imagen de contenedor a partir de ese Dockerfile. Ejecuta el siguiente comando en Cloud Shell y reemplaza por el ID de tu proyecto, así como por una etiqueta adecuada para la imagen del contenedor. Puede ser cualquier valor que quieras, siempre y cuando no se repita con otras etiquetas del proyecto:

gcloud builds submit --tag gcr.io/<project id>/<tag>

La construcción debería tardar entre 30 y 60 segundos y devolverá un mensaje de éxito con un ID de build.

Anota la etiqueta que usaste, porque la vas a necesitar para crear el servicio de Cloud Run en la siguiente sección.

En las próximas dos secciones voy a usar algunas opciones que NO son una buena práctica para un entorno de producción. Asegurar el entorno excede el alcance de este artículo. Acá solo muestro una configuración para que la repliques y aprendas a probar los servicios en un entorno controlado, así que ejecútala primero en un proyecto de GCP aislado y que no sea de producción.

Primero, voy a usar la cuenta de servicio predeterminada, Compute Engine default service account, al crear los recursos. Recomiendo encarecidamente no hacer esto en un entorno de producción. Como buena práctica, deberías crear una cuenta de servicio específica aplicando el principio del mínimo privilegio al momento de crear estos servicios.

En segundo lugar, uso variables de entorno para almacenar datos en tiempo de ejecución, por simplicidad. En un entorno de producción es muy probable que el servicio de Cloud Run maneje datos sensibles. Para un workload de producción recomiendo un método de almacenamiento más seguro, como Secret Manager de GCP o el producto Vault de HashiCorp.

Acá uso la línea de comandos para crear el servicio de Cloud Run, ya que Eventarc es un servicio nuevo y su interfaz cambia muy rápido, por lo que es muy probable que cualquier captura de pantalla deje de reflejar la realidad uno o dos meses después de la fecha de publicación.

Dicho esto, al ser un servicio nuevo, la línea de comandos también puede cambiar sin previo aviso a medida que se agregan funciones nuevas, pero históricamente cambia mucho menos que la UI.

Todos estos comandos se ejecutan dentro de tu Cloud Shell en la consola de Google Cloud, salvo que prefieras hacerlo desde tu propia terminal. En cualquier caso, asegúrate de tener instalada la última versión del CLI del Google Cloud SDK, ya que la mayoría de los comandos a continuación solo existen en las versiones más recientes a la fecha de redacción. Para ello, ejecuta este comando y selecciona "sí" cuando se te pida actualizar:

gcloud components update

Creando las variables de entorno

El primer paso será crear algunas variables de entorno que vamos a usar en los comandos de creación más adelante. Como Eventarc y Cloud Run usan definiciones y formatos distintos para los nombres de región, las separé en dos variables diferentes.

Acá va un resumen rápido de cada variable:

TAG_NAME: etiqueta de la imagen de contenedor que especificaste antes en tu comando de Cloud Build submit.

CLOUD_RUN_SERVICE: nombre del servicio de Cloud Run que se va a crear.

CLOUD_RUN_REGION: región donde se ejecutará el servicio de Cloud Run.

BUCKET_NAME: nombre del bucket de GCS que se va a monitorear.

BQ_TABLE: nombre completo de la tabla de BigQuery, incluyendo proyecto y dataset (es decir, project.dataset.table). Este valor DEBE tener este formato o arrojará error.

TRIGGER_NAME: nombre del trigger de Eventarc.

TRIGGER_LOCATION: región de Google Cloud donde el trigger monitoreará el bucket. Si usas un bucket multirregional y quieres monitorearlo por completo, usa la cadena global aquí.

Sustituye tus valores y ejecuta los siguientes comandos:

TAG_NAME=<tag>
CLOUD_RUN_SERVICE=<service name>
CLOUD_RUN_REGION=<region>
BUCKET_NAME=<bucket name>
BQ_TABLE=<BigQuery full table name>
TRIGGER_NAME=<trigger name>
TRIGGER_LOCATON=<global or region># These next two variables rely on the above to be set
PROJECT=$(gcloud config get-value project)
IMAGE=gcr.io/"$PROJECT"/"$TAG_NAME":latest

Creando el servicio de Cloud Run

Ahora, para crear el servicio de Cloud Run propiamente dicho, ejecuta el siguiente comando:

gcloud run deploy $CLOUD_RUN_SERVICE \
  --region="$CLOUD_RUN_REGION"
  --tag "$IMAGE" \
  --platform managed \
  --set-env-vars=BUCKET="$BUCKET",BIGQUERY_TABLE="$BQ_TABLE"

Esto puede tardar hasta 5 minutos usando la imagen mínima provista en GitHub.

Una vez creado el servicio de Cloud Run, crea el trigger de Eventarc que se conecta a él:

gcloud eventarc triggers create "$TRIGGER_NAME" \
  --location="$TRIGGER_LOCATON" \
  --destination-run-service "$CLOUD_RUN_SERVICE"  \
  --matching-criteria type=google.cloud.audit.log.v1.written \
  --matching-criteria methodName=storage.objects.create \
  --matching-criteria serviceName=storage.googleapis.com

Nota: en el futuro, cuando se implemente la funcionalidad para apuntar a recursos específicos, deberá usarse el siguiente comando:

gcloud eventarc triggers create "$TRIGGER_NAME" \
  --location="$TRIGGER_LOCATON" \
  --destination-run-service "$CLOUD_RUN_SERVICE"  \
  --matching-criteria type=google.cloud.audit.log.v1.written \
  --matching-criteria methodName=storage.objects.create \
  --matching-criteria serviceName=storage.googleapis.com \
  --matching-criteria resourceName=projects/_/buckets/"$BUCKET_NAME"

Nota de seguridad: como mencioné antes, acá uso la Compute Engine default service account tanto para el servicio de Cloud Run como para la creación del trigger de Eventarc, por simplicidad, ya que es la opción por defecto. Para cambiar esto en un entorno de producción, usa la bandera service-account tanto en el comando gcloud run como en gcloud eventarc. Para conocer más sobre esto y otros argumentos que podrías necesitar, ejecuta los siguientes comandos:

gcloud run deploy --help
gcloud eventarc triggers create --help

Esta parte es muy sencilla. Incluso incluí un archivo CSV de prueba muy simple para que lo uses.

Nota: si vas a usar mi archivo de muestra, asegúrate de que la tabla que indicaste en tu variable de entorno todavía no exista en BigQuery. De lo contrario, podría provocar un error en la carga, ya que lo más probable es que los esquemas no coincidan.

En tu Cloud Shell (o terminal), ingresa al directorio eventarc donde clonaste el código de GitHub. Luego ejecuta el siguiente comando:

gsutil cp sample-bq-load.csv gs://"$BUCKET"/

Esto copiará el archivo a tu bucket y debería disparar el trigger y todo el proceso.

Verificando el resultado

En la página del servicio de Cloud Run, si haces clic en la pestaña Triggers y buscas el trigger que creaste, unos 20 segundos después de ejecutar el comando deberías ver un gráfico con algunas invocaciones, similar al de abajo.

Invocaciones del trigger de Eventarc

Si vas a la sección de BigQuery en tu Consola de GCP y navegas hasta el proyecto y dataset, en la pestaña Preview deberías ver que se insertaron datos como los del ejemplo a continuación, usando los datos de muestra. También puedes mirar la pestaña Details y revisar la fecha de última modificación de tu tabla, que debería coincidir con la última ejecución del trigger en tu gráfico.

Datos cargados desde el archivo CSV de muestra

¡Acuérdate de eliminar esta tabla después de probar con estos datos y antes de usar datos reales!

En caso de error

Si los datos no aparecen, ve a tu servicio de Cloud Run y haz clic en la pestaña Logs.

Si ves un registro con error POST 500 en tus logs, revisa lo que hay alrededor para ver si aparecen filas con errores. La mayoría dirá algo como ERROR in app: Exception on / [POST], seguido de un Traceback del código de python en el siguiente registro. Ahí suele estar el error que ocurrió.

Si muestra un registro POST 200 pero los datos no se están cargando en BigQuery, busca en los logs el motivo. El código imprimirá un mensaje si el archivo no es un CSV o si alguna variable de entorno está mal configurada.