Eventarc te permite compilar arquitecturas controladas por eventos sin tener que implementar, personalizar ni mantener la infraestructura subyacente. Eventarc ofrece una solución estandarizada para administrar el flujo de cambios de estado, llamados eventos, entre microservicios separados. Cuando se activa, Eventarc enruta estos eventos a varios destinos (consulta Destinos de eventos) mientras administras la entrega, la seguridad, la autorización, la observabilidad y el manejo de errores por tu cuenta.
Puedes administrar Eventarc desde la consola de Google Cloud, desde la línea de comandos mediante la CLI de gcloud o mediante la API de Eventarc.
Eventarc cumple con estas certificaciones y estándares.
1 Los eventos de los proveedores de Google Cloud se envían directamente desde la fuente (por ejemplo, Cloud Storage) o mediante las entradas de registros de auditoría de Cloud, y usan Pub/Sub como capa de transporte. Los eventos de las fuentes de Pub/Sub pueden usar un tema de Pub/Sub existente, o Eventarc creará automáticamente un tema y lo administrará por ti.
2 Los eventos para destinos de Google Kubernetes Engine (GKE), incluidos los servicios de Knative serving que se ejecutan en un clúster de GKE, usan el servidor de reenvío de eventos de Eventarc para extraer eventos nuevos de Pub/Sub y reenviarlos al destino. Este componente actúa como un mediador entre la capa de transporte de Pub/Sub y el servicio de destino. Funciona en servicios existentes y también admite servicios de señalización (incluidos los que no se exponen fuera del clúster completamente administrado) y simplifica la configuración y el mantenimiento. Ten en cuenta que Eventarc administra el ciclo de vida del componente de reenvío de eventos, y si borras el componente de reenvío de eventos por accidente, Eventarc restablecerá este componente.
3 Los eventos para una ejecución del flujo de trabajo se transforman y se pasan al flujo de trabajo como argumentos del entorno de ejecución. Los flujos de trabajo pueden combinar y organizar los servicios de las API de HTTP y Google Cloud en el orden que establezcas.
4 Todas las funciones controladas por eventos de Cloud Run (2ª gen.) usan activadores de Eventarc para entregar eventos. Puedes configurar activadores de Eventarc cuando implementas una función de Cloud Run con la interfaz de funciones de Cloud Run.
Casos de uso clave
Eventarc admite muchos casos prácticos para las aplicaciones de destino. Por ejemplo:
| Configurar y supervisar |
|
| Harmonizar |
|
| Analizar |
|
Eventos
Un evento es un registro de datos en el que se expresan un caso y su contexto. Un evento es una unidad de comunicación discreta que es independiente de otros eventos. Por ejemplo, un evento puede ser un cambio en los datos de una base de datos, un archivo agregado a un sistema de almacenamiento o un trabajo programado.
Consulta Tipos de eventos compatibles con Eventarc.
Proveedores de eventos
Los eventos se enrutan desde un proveedor de eventos (la fuente) hasta los consumidores de eventos interesados. El enrutamiento se realiza según la información contenida en el evento, pero un evento no identifica un destino de enrutamiento específico. Eventarc admite eventos de las siguientes fuentes:
- Más de 130 proveedores de Google Cloud. Estos proveedores envían eventos (por ejemplo, una actualización a un objeto en un bucket de Cloud Storage o un mensaje publicado en un tema de Pub/Sub) directamente desde la fuente o a través de las entradas de los registros de auditoría de Cloud.
- Proveedores externos. Estos proveedores envían eventos directamente desde la fuente (por ejemplo, proveedores de SaaS de terceros, como Datadog o la plataforma de Check Point CloudGuard).
Destinos de eventos
Los eventos se enrutan a un destino específico (el destino) conocido como el receptor (o consumidor) de eventos a través de suscripciones de envío de Pub/Sub.
Funciones de Cloud Run (2ª gen.)
Todas las funciones controladas por eventos en Cloud Run (2ª gen.) usan activadores de Eventarc para publicar eventos. Un activador de Eventarc permite que una función se active con cualquier tipo de evento compatible con Eventarc. Puedes configurar activadores de Eventarc al implementar una función de Cloud Run en la interfaz de funciones de Cloud Run.
Cloud Run
Obtén más información sobre cómo compilar un servicio de receptor de eventos que se pueda implementar en Cloud Run.
Para determinar la mejor manera de enrutar eventos a un servicio de Cloud Run, consulta Opciones de enrutamiento de eventos.
GKE
Eventarc admite la creación de activadores que se orientan a los servicios de Google Kubernetes Engine (GKE). Esto incluye los extremos públicos de los servicios privados y públicos que se ejecutan en un clúster de GKE.
Para que Eventarc oriente y administre servicios en cualquier clúster, debes otorgar a la cuenta de servicio de Eventarc los permisos necesarios.
Debes habilitar Workload Identity Federation for GKE en el clúster de GKE en el que se ejecuta el servicio de destino. Se requiere Workload Identity Federation for GKE para configurar el servidor de reenvío de eventos de forma correcta y es la forma recomendada de acceder a los servicios de Google Cloud desde aplicaciones que se ejecutan dentro de GKE debido a sus propiedades de seguridad y capacidad de administración mejoradas. Para obtener más información, consulta Habilitar identidad de Workload Identity.
Extremos HTTP internos en una red de VPC
Puedes configurar el enrutamiento de eventos a un extremo HTTP interno en una red de nube privada virtual (VPC). Para configurar el activador, también debes proporcionar un ID de adjunto de red. Para obtener más información, consulta Enrutar eventos a un extremo HTTP interno en una red de VPC.
Workflows
Instancias que activan la ejecución tu flujo de trabajo:
- Cuando se publican mensajes en un tema de Pub/Sub
- Cuando se crea un registro de auditoría que coincide con los criterios del filtro del activador
- También se activa en respuesta a un evento no mediado, como una actualización a un objeto en un bucket de Cloud Storage
Workflows requiere un correo electrónico de la cuenta de servicio de IAM que el activador de Eventarc usará para invocar las ejecuciones del flujo de trabajo. Recomendamos usar una cuenta de servicio con los privilegios mínimos necesarios para acceder a los recursos requeridos. Para obtener más información, consulta Crear y administrar cuentas de servicio.
Formato de eventos y bibliotecas
Eventarc entrega eventos al destino objetivo sin importar el proveedor y en un formato de CloudEventscon una solicitud HTTP en modo de contenido de objeto binario. CloudEvents es una especificación para describir metadatos de eventos de forma común, en la Cloud Native Computing Foundation y organizados por grupo de trabajo sin servidores.
Según qué proveedor de eventos, puedes especificar la codificación de los datos de carga útil del evento, como application/json o application/protobuf. El búfer de protocolo (o Protobuf) es un mecanismo extensible y neutral en cuanto al lenguaje para la serialización de datos estructurados. Ten en cuenta lo siguiente:
- En el caso de las fuentes personalizadas o los proveedores externos, o para eventos directos de Pub/Sub, esta opción de formato no es compatible.
- Una carga útil de evento con formato JSON es más grande que una con formato Protobuf, lo que podría afectar la confiabilidad según el destino del evento y los límites de tamaño de este. Para obtener más información, consulta Problemas conocidos.
Los destinos objetivo como funciones de Cloud Run, Cloud Run y GKE consumen eventos en formato HTTP. Para los destinos de Workflows, el servicio de Workflows convierte el evento en un objeto JSON y lo pasa a la ejecución del flujo de trabajo como un argumento del entorno de ejecución.
Usar una manera estándar para describir los metadatos de eventos garantiza la coherencia, la accesibilidad y la portabilidad. Los consumidores de eventos pueden leer estos eventos directamente, o puedes usar los SDK y las bibliotecas de CloudEvents de Google en varios lenguajes (incluidos C#, Go, Java, Node.js y Python) para leer y analizar los eventos:
La estructura del cuerpo HTTP para todos los eventos está disponible en el repositorio de GitHub de CloudEvents de Google.
Compatibilidad con versiones anteriores
Eventarc considera la adición de los siguientes atributos y campos compatibles con versiones anteriores:
- Atributos de filtrado opcionales o atributos solo de salida
- Campos opcionales a la carga útil del evento
Activadores de Eventarc
Los eventos ocurren sin importar si reacciona un destino objetivo o no. Las respuestas a los eventos se crean mediante un activador. Un activador es una declaración de tu interés en un evento o conjunto de eventos determinado. Cuando creas un activador, especificas filtros para el activador que te permiten capturar y actuar sobre esos eventos específicos, incluido su enrutamiento de una fuente de evento a un destino de destino. Para obtener más información, consulta la representación de REST de un recurso activador y Proveedores y destinos de eventos.
Ten en cuenta que, independientemente de la actividad, las suscripciones de Pub/Sub creadas para Eventarc persisten y no expiran. Para cambiar las propiedades de suscripción, consulta Propiedades de la suscripción.
Eventarc admite activadores para estos tipos de eventos:
| Eventos de registros de auditoría de Cloud (CAL) | |
|---|---|
| Descripción | Los registros de auditoría de Cloud proporcionan registros de auditoría de acceso a los datos y de actividad de los administradores para cada proyecto, carpeta y organización de Cloud. Los servicios de Google Cloud escriben entradas en estos registros. Eventarc admite registros de auditoría a nivel de proyecto. Para obtener más
información, consulta los valores específicos serviceName y methodName que son compatibles con Eventarc como tipos de eventos. |
| Tipo de filtro de eventos | Los activadores de Eventarc con type=google.cloud.audit.log.v1.written envían solicitudes a tu servicio o flujo de trabajo cuando se crea un registro de auditoría que coincide con los criterios de filtro del activador. |
| Eventos directos | |
| Descripción | Eventarc puede activarse mediante varios eventos directos, como una actualización de un bucket de Cloud Storage, una actualización de una plantilla de Firebase Remote Config o cambios de recursos
en los servicios de Google Cloud.
Eventarc también puede activarse mediante mensajes publicados en temas de Pub/Sub. Pub/Sub es un bus de mensajes distribuido a nivel global que se escala de forma automática en la medida que lo necesitas. Como Eventarc puede invocarse mediante mensajes en un tema de Pub/Sub, puedes integrarlo con cualquier otro servicio que admita Pub/Sub como destino. |
| Tipo de filtro de eventos | Los activadores de Eventarc con tipos de filtro de eventos específicos envían solicitudes a tu servicio o flujo de trabajo cuando se produce un evento que coincide con los criterios de filtro del activador, como por ejemplo type=google.cloud.storage.object.v1.finalized (cuando se crea un objeto en un bucket de Cloud Storage) o type=google.cloud.pubsub.topic.v1.messagePublished (cuando se publica un mensaje en el tema de Pub/Sub especificado).
|
Ubicación del activador
Los servicios de Google Cloud, como Cloud Storage, se pueden configurar para que sean regionales o multirregionales. Algunos servicios, como Cloud Build, se pueden configurar de forma global.
Eventarc te permite crear activadores regionales o, para algunos eventos, puedes crear un activador global y recibir eventos de todas las regiones. Para conocer más, consulta Información sobre las ubicaciones de Eventarc.
Debes especificar la ubicación del activador de Eventarc para que coincida con la ubicación del servicio de Google Cloud que genera eventos y evitar cualquier problema de rendimiento y residencia de datos que genere un activador global.
Puedes especificar las ubicaciones de los activadores mediante una marca --location con cada comando.
Para los destinos de Cloud Run, si no se especifica una marca --destination-run-region, se supone que el servicio está en la misma región que el activador. Para obtener más información, consulta la referencia de Google Cloud CLI.
Confiabilidad y entrega
Las expectativas de entrega son las siguientes:
- Los eventos que usan registros de auditoría de Cloud se entregan en menos de un minuto. (Nota: Aunque un activador de registros de auditoría de Cloud se crea de inmediato, puede tardar hasta dos minutos para propagar y filtrar los eventos).
- Los eventos que usan Pub/Sub se entregan en segundos.
No hay garantía de entrega en orden ni de la regla primero en entrar. Ten en cuenta que tener un orden estricto comprometería las funciones de disponibilidad y escalabilidad de Eventarc que coinciden con las de su capa de transporte, Cloud Pub/Sub. Para obtener más información, consulta Ordena mensajes.
La latencia y la capacidad de procesamiento son el mejor esfuerzo. Varían en función de varios factores, incluido el hecho de si el activador de Eventarc es regional, multirregional o global; la configuración de un servicio en particular y la carga de red en los recursos de una región de Google Cloud
Ten en cuenta que hay cuotas y límites de uso que se aplican, por lo general, a Eventarc. También existen límites y cuotas de uso que son específicos de Workflows.
Política de reintentos de eventos
Las características de reintento de Eventarc coinciden con las de Cloud Pub/Sub, su capa de transporte. Para obtener más información, consulta Solicitudes de reintento y Retirada de envío.
La duración predeterminada de la retención de mensajes que establece Eventarc es de 24 horas con un retraso de retirada exponencial.
Puedes actualizar la política de reintento a través de la suscripción de Pub/Sub asociada con el activador de Eventarc:
- Abre la página Detalles del activador.
- Haz clic en el tema.
- Haz clic en la pestaña Suscripciones.
Cualquier suscripción
creada automáticamente por Eventarc tendrá este formato:
projects/PROJECT_ID/subscriptions/eventarc-REGION-TRIGGER_ID-sub-SUBSCRIPTION_ID. Para obtener más información sobre los límites
de suscripción, consulta
Límites de recursos de Pub/Sub.
Si Pub/Sub intenta entregar un mensaje, pero el destino no puede confirmar la recepción, Pub/Sub volverá a enviar el mensaje con una retirada exponencial mínima de 10 segundos. Si el destino continúa sin confirmar la recepción del mensaje, se agrega más tiempo a la demora en cada reintento (hasta un máximo de 600 segundos) y el mensaje se vuelve a enviar al destino.
Ten en cuenta que Workflows confirma los eventos apenas comienza la ejecución del flujo de trabajo.
Temas de mensajes no entregados
Si el destino no recibe el mensaje, puedes reenviar los mensajes no entregados a un tema de mensajes no entregados (también conocido como la cola de mensajes no entregados). Un tema de mensajes no entregados puede almacenar mensajes que el destino no puede confirmar. Debes establecer un tema de mensajes no entregados cuando crees o actualices una suscripción de Pub/Sub, no cuando crees un tema de Pub/Sub o cuando Eventarc cree un tema de Pub/Sub. Para obtener más información, consulta Controla las fallas de los mensajes.
Errores que no garantizan reintentos
Cuando las aplicaciones usan Pub/Sub como la fuente del evento y dicho evento no se entrega, se vuelve a intentar el evento de forma automática, excepto los errores que no garantizan reintentos. Los eventos al destino del flujo de trabajo desde cualquier fuente no se volverán a intentar si el flujo de trabajo no se ejecuta. Si se inicia la ejecución del flujo de trabajo, pero luego falla, no se reintentan las ejecuciones. Para resolver estos problemas de servicio, debes manejar los errores y los reintentos dentro del flujo de trabajo.
Eventos duplicados
Los eventos duplicados pueden entregarse a los controladores de eventos. Según la especificación de CloudEvents, se considera que la combinación de los atributos source y id es única y, por lo tanto, cualquier evento con la misma combinación se considera duplicado. .
Debes implementar controladores de eventos idempotentes ya que es una práctica recomendada y general.
Observabilidad
Los registros detallados de Eventarc, Cloud Run, GKE, Pub/Sub y Workflows están disponibles en los registros de auditoría de Cloud.
Recuperación ante desastres
Puedes aprovechar las zonas y las regiones para lograr la confiabilidad en caso de interrupciones. Con el fin de obtener más información sobre cómo garantizar que los objetivos de RTO (objetivo de tiempo de recuperación) y RPO (objetivo de punto de recuperación) se cumplan para los tiempos de copia de seguridad y recuperación cuando se usa Eventarc, consulta Arquitectura de recuperación ante desastres para infraestructura de nube. interrupciones.
¿Qué sigue?
- Prueba el Codelab.
- Crea un activador para un proveedor, un tipo de evento y un destino específicos
- Soluciona problemas