Cloud Run, Cloud Run functions y Eventarc

# Desde una imagen
gcloud run deploy my-service --image us-docker.pkg.dev/PROJECT/repo/app:1.0 --region us-central1

# Desde el código fuente
gcloud run deploy my-service --source . --region us-central1

• Cada despliegue crea una revisión nueva e inmutable.
• El contenedor debe escuchar en un puerto TCP y atender peticiones HTTP.
• Un servicio puede tener varios contenedores (sidecars) con --container; solo uno recibe el tráfico de entrada.
• Roles habituales para desplegar: Cloud Run Admin y Service Account User sobre la cuenta de servicio con la que se ejecuta.

Quién puede invocar el servicio

Invocar un servicio requiere el rol Cloud Run Invoker (roles/run.invoker). Por defecto, solo pueden llamarlo los principales autorizados.

La política de organización «Restrict identities by domain» puede impedir añadir allUsers.

Ingress: desde dónde llega el tráfico

El acceso IAM decide quién; el ingress decide desde qué red se aceptan las peticiones.

Una función se despliega en Cloud Run desde el código fuente indicando el punto de entrada y la imagen base del runtime.

gcloud run deploy my-function --source . \
  --function FUNCTION_ENTRYPOINT --base-image python314 --region europe-west1

• --function: nombre de la función o clase completa que se ejecuta.
• --base-image: entorno del runtime, como nodejs24, python314, go127, java25, dotnet10, ruby40 o php85.
• Funciones HTTP: responden en el endpoint HTTPS del servicio, ideales para webhooks.
• Funciones dirigidas por eventos: todas usan triggers de Eventarc para recibir los eventos.
• Por compatibilidad siguen existiendo gcloud functions deploy, la API Cloud Functions v2 y el recurso de Terraform google_cloudfunctions2_function.

• Un evento es un registro de que algo ocurrió: un cambio en una base de datos, un archivo nuevo, un trabajo programado.
• Proveedores: más de 130 de Google, que envían eventos directamente (por ejemplo, Cloud Storage o Pub/Sub) o a través de entradas de Cloud Audit Logs.
• Los eventos de Google usan Pub/Sub como transporte y llegan al destino en formato CloudEvents.
• Destinos: Cloud Run (servicios y funciones), Workflows, GKE y endpoints HTTP internos de una VPC (estos dos, en vista previa).
• Entrega al menos una vez, sin orden garantizado, con reintentos durante 24 horas por defecto.

Eventarc Standard y Advanced

Ambas usan el mismo modelo de datos, así que se puede pasar de Standard a Advanced cuando el caso de uso se complica.

Crear un trigger de Eventarc

Un trigger filtra los eventos por origen, tipo y atributos, y los envía al destino. En la consola: Cloud Run → servicio → pestaña Triggers → Add trigger.

gcloud eventarc triggers create storage-trigger --location=us-central1 \
  --destination-run-service=my-service --destination-run-region=us-central1 \
  --event-filters="type=google.cloud.storage.object.v1.finalized" \
  --event-filters="bucket=my-bucket" \
  --service-account=trigger-sa@PROJECT_ID.iam.gserviceaccount.com

• Ubicación: la del recurso que vigilas; normalmente el servicio de Cloud Run va en la misma región.
• Identidad: el trigger usa una cuenta de servicio. Si no indicas ninguna, usa la cuenta predeterminada de Compute Engine, que puede tener permisos excesivos. Google recomienda una cuenta gestionada por el usuario con permisos mínimos.
• Los eventos llegan al servicio como peticiones HTTP.

Además de Eventarc, un servicio de Cloud Run puede recibir mensajes de un tema mediante una suscripción push que hace una petición HTTP al servicio por cada mensaje.

gcloud iam service-accounts create cloud-run-pubsub-invoker
gcloud run services add-iam-policy-binding pubsub-tutorial \
  --member=serviceAccount:cloud-run-pubsub-invoker@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/run.invoker
gcloud pubsub subscriptions create myRunSubscription --topic myRunTopic \
  --ack-deadline=600 --push-endpoint=SERVICE-URL/ \
  --push-auth-service-account=cloud-run-pubsub-invoker@PROJECT_ID.iam.gserviceaccount.com

El servicio puede seguir siendo privado: la suscripción se autentica con una cuenta de servicio que tiene roles/run.invoker.

Las notificaciones de Pub/Sub para Cloud Storage publican en un tema un mensaje con el evento y el objeto afectado. La alternativa más directa, si no quieres gestionar un tema, es una Cloud Run function con trigger de Cloud Storage (el bucket debe estar en el mismo proyecto).

• Hasta 100 configuraciones de notificación por bucket y 10 para un mismo evento.
• Entrega al menos una vez: puede llegar el mismo evento varias veces con distinto ID.
• Para otros eventos, como lecturas de objetos u operaciones sobre el bucket, se activan los registros de auditoría y se enrutan a Pub/Sub.

Escenarios de examen

Trampas frecuentes del examen