Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1
En esta página, se describe la arquitectura de los entornos de Cloud Composer.
Configuración de la arquitectura del entorno
Los entornos de Cloud Composer 1 pueden tener las siguientes opciones de configuración de la arquitectura:
- Arquitectura de IP pública
- Arquitectura de IP privada con intercambio de tráfico entre VPC
- IP privada con arquitectura de uso compartido restringido al dominio (DRS)
Proyectos del cliente y el usuario
Cuando creas un entorno, Cloud Composer distribuye los recursos del entorno entre un proyecto de usuario y uno del cliente:
- El proyecto del cliente es un Google Cloud proyecto en el que creas tus entornos. Puedes crear más de un entorno en un solo proyecto de cliente.
El proyecto de usuario es un proyecto de usuario administrado por Google. El proyecto de usuario proporciona un control de acceso unificado y una capa adicional de seguridad de datos para tu entorno. Cada entorno de Cloud Composer tiene su propio proyecto de usuario.
Componentes del entorno
Un entorno de Cloud Composer consta de componentes de entorno.
Un componente del entorno es un elemento de una infraestructura administrada de Airflow que se ejecuta en Google Cloud, como parte de tu entorno. Los componentes del entorno se ejecutan en el proyecto del usuario o del cliente de tu entorno.
Clúster del entorno
El clúster del entorno es un clúster de Google Kubernetes Engine nativo de la VPC o basado en rutas en modo estándar de tu entorno:
De forma predeterminada, Cloud Composer habilita las actualizaciones automáticas de nodos y la reparación automática de nodos para proteger el clúster de tu entorno de las vulnerabilidades de seguridad. Estas operaciones ocurren durante los períodos de mantenimiento que especificas para tu entorno.
Bucket del entorno
El bucket de entorno es un bucket de Cloud Storage que almacena DAG, complementos, dependencias de datos y registros de Airflow. El bucket del entorno se encuentra en el proyecto del cliente.
Cuando subes tus archivos DAG a la carpeta /dags
en el bucket de tu entorno, Cloud Composer sincroniza los DAG con los componentes de Airflow de tu entorno.
Servidor web de Airflow
El servidor web de Airflow ejecuta la IU de Airflow de tu entorno.
En Cloud Composer 1, el servidor web de Airflow se ejecuta en el proyecto de usuario de tu entorno.
El servidor web de Airflow está integrado en Identity-Aware Proxy. Cloud Composer oculta los detalles de integración de IAP y proporciona acceso al servidor web según las identidades del usuario y las vinculaciones de políticas de IAM definidas para los usuarios.
En Cloud Composer 1, el servidor web de Airflow se ejecuta en una cuenta de servicio diferente a los trabajadores y programadores de Airflow. La cuenta de servicio para el servidor web se genera automáticamente durante la creación del entorno y se deriva del dominio del servidor web. Por ejemplo, si el dominio es example.appspot.com
, la cuenta de servicio es example@appspot.gserviceaccount.com
.
Base de datos de Airflow
La base de datos de Airflow es una instancia de Cloud SQL que se ejecuta en el proyecto de usuario de tu entorno. Aloja la base de datos de metadatos de Airflow.
Para proteger la información sensible del flujo de trabajo y la conexión, Cloud Composer permite el acceso a la base de datos solo a la cuenta de servicio de tu entorno.
Otros componentes de Airflow
Estos son otros componentes de Airflow que se ejecutan en tu entorno:
Los programadores de Airflow analizan los archivos de definición del DAG, programan las ejecuciones de DAG según el intervalo de programación y ponen en cola las tareas para que los trabajadores de Airflow las ejecuten. En Cloud Composer 1, los procesadores de DAG de Airflow se ejecutan como parte de los componentes del programador.
Los trabajadores de Airflow ejecutan tareas programadas por los programadores de Airflow.
Arquitectura del entorno de IP pública
En una arquitectura del entorno de IP pública para Cloud Composer 1, haz lo siguiente:
- El proyecto del usuario aloja una instancia de Cloud SQL, un almacenamiento de Cloud SQL y una instancia flexible de App Engine que ejecuta el servidor web de Airflow.
- El proyecto del cliente aloja todos los demás componentes del entorno.
- Los programadores y los trabajadores de Airflow en el proyecto del cliente se comunican con la base de datos de Airflow a través de instancias del proxy de Cloud SQL ubicadas en el proyecto del cliente.
- El servidor web de Airflow en el proyecto del usuario se comunica con la base de datos de Airflow a través de una instancia de proxy de Cloud SQL ubicada en el proyecto del usuario.
Arquitectura del entorno de IP privada
En una arquitectura del entorno de IP privada, haz lo siguiente:
- El proyecto de usuario aloja una instancia de Cloud SQL, un almacenamiento de Cloud SQL y dos instancias de App Engine que ejecutan el servidor web de Airflow.
- El proyecto del cliente aloja todos los demás componentes del entorno.
- Los programadores y trabajadores de Airflow se conectan a la base de datos de Airflow a través del proceso de HAProxy en el clúster del entorno.
- La carga del proceso HAProxy balancea el tráfico a la instancia de Cloud SQL entre dos instancias del proxy de Cloud SQL que se encuentran en el proyecto de usuario. Los entornos de IP privada usan dos instancias de proxy de Cloud SQL porque el proyecto del cliente no accede a la base de datos directamente debido a limitaciones de red. Se necesitan dos instancias para garantizar que los componentes del entorno tengan acceso a la base de datos en todo momento.
IP privada con DRS
Si la política de la organización de uso compartido restringido al dominio (DRS) está activada en tu proyecto, Cloud Composer usa la IP privada con la arquitectura del entorno de DRS.
En la arquitectura del entorno de IP privada con DRS, haz lo siguiente:
El proyecto de usuario aloja una instancia de Cloud SQL, un almacenamiento de Cloud SQL y dos instancias de App Engine que ejecutan el servidor web de Airflow.
El proyecto de usuario aloja un bucket de entorno adicional. El servidor web de Airflow accede a este bucket directamente.
El proyecto del cliente aloja todos los demás componentes del entorno.
El proyecto del cliente aloja el proceso de sincronización de buckets en el clúster del entorno. Este proceso sincroniza dos depósitos de entorno.
Los programadores y trabajadores de Airflow se conectan a la base de datos de Airflow a través del proceso de HAProxy en el clúster del entorno.
La carga del proceso HAProxy balancea el tráfico a la instancia de Cloud SQL entre dos instancias del proxy de Cloud SQL que se encuentran en el proyecto de usuario. Los entornos de IP privada usan dos instancias de proxy de Cloud SQL porque el proyecto del cliente no accede a la base de datos directamente debido a limitaciones de red. Se necesitan dos instancias para garantizar que los componentes del entorno tengan acceso a la base de datos en todo momento.
Integración en Cloud Logging y Cloud Monitoring
Cloud Composer se integra en Cloud Logging y Cloud Monitoring de tu Google Cloud proyecto, por lo que tienes un lugar central en el que consultar los registros de Airflow y DAG.
Cloud Monitoring recopila y transfiere métricas, eventos y metadatos de Cloud Composer para generar estadísticas a través de paneles y gráficos.
Debido a la naturaleza de transmisión de Cloud Logging, puedes ver los registros que emiten los componentes de Airflow de inmediato, en lugar de esperar a que aparezcan en el bucket de Cloud Storage de tu entorno.
Para limitar la cantidad de registros en tu Google Cloud proyecto, puedes detener la transferencia de todos los registros. No inhabilites Logging.