Architettura dell'ambiente Cloud Composer

Cloud Composer 1 | Cloud Composer 2

Questa pagina descrive l'architettura degli ambienti Cloud Composer 1.

Configurazioni dell'architettura dell'ambiente

Gli ambienti Cloud Composer 1 possono avere le seguenti configurazioni dell'architettura:

• Architettura IP pubblico

• Architettura di IP privati con peering VPC

• IP privato con architettura di condivisione limitata per i domini (DRS)

Ogni configurazione modifica leggermente l'architettura delle risorse dell'ambiente.

Progetti di clienti e tenant

Quando crei un ambiente, Cloud Composer distribuisce le risorse dell'ambiente tra un tenant e un progetto del cliente.

Il progetto del cliente è un progetto Google Cloud in cui puoi creare i tuoi ambienti. Puoi creare più di un ambiente in un singolo progetto cliente.

Il progetto tenant è un progetto tenant gestito da Google. Il progetto tenant offre controllo unificato degli accessi e un ulteriore livello di sicurezza dei dati per il tuo ambiente. Ogni ambiente Cloud Composer ha un proprio progetto tenant.

Componenti dell'ambiente

Un ambiente Cloud Composer è costituito da componenti di ambiente.

Un componente dell'ambiente è un elemento di un'infrastruttura Airflow gestita in esecuzione su Google Cloud, nell'ambito del tuo ambiente.

I componenti dell'ambiente vengono eseguiti nel tenant o nel progetto cliente del tuo ambiente.

Alcuni dei componenti del tuo ambiente si basano su prodotti Google Cloud autonomi. Le quote e i limiti per questi prodotti si applicano anche ai tuoi ambienti. Ad esempio, gli ambienti Cloud Composer utilizzano i peering VPC. Le quote sul numero massimo di peering VPC si applicano al progetto cliente, quindi una volta che il progetto raggiunge questo numero massimo di peering, non è possibile creare ambienti aggiuntivi.

Cluster dell'ambiente

Il cluster dell'ambiente è un cluster Google Kubernetes Engine in modalità Standard native VPC o basato su route Google Kubernetes Engine del tuo ambiente:

• I nodi di ambiente sono VM nel cluster dell'ambiente.

• I pod nel cluster dell'ambiente eseguono container con altri componenti dell'ambiente, come worker e scheduler Airflow. I pod vengono eseguiti su nodi di ambiente.

• Le risorse del carico di lavoro del cluster dell'ambiente gestiscono gli insiemi di pod nel cluster dell'ambiente. Molti componenti del tuo ambiente vengono implementati come diversi tipi di risorse dei carichi di lavoro. Ad esempio, i worker Airflow vengono eseguiti come Deployment. Oltre ai deployment, il tuo ambiente include anche tipi di carichi di lavoro StatefulSet, DaemonSet e Job.

Attenzione: non introdurre modifiche nel cluster dell'ambiente. I cluster per Cloud Composer e i carichi di lavoro di cui è stato eseguito il deployment al loro interno sono gestiti da Google. È possibile modificare la configurazione del cluster dell'ambiente, ma farlo potrebbe danneggiare l'ambiente. Se elimini il cluster di un ambiente, questo non potrà essere ripristinato; devi eliminare l'ambiente e crearne uno nuovo.

Per impostazione predefinita, Cloud Composer attiva gli upgrade automatici dei nodi e la riparazione automatica dei nodi per proteggere il cluster del tuo ambiente dalle vulnerabilità di sicurezza. Queste operazioni vengono eseguite durante i periodi di manutenzione specificati per il tuo ambiente.

Scheduler, worker e coda Redis di Airflow

Gli pianificatori Airflow controllano la pianificazione delle esecuzioni dei DAG e delle singole attività dei DAG. Gli scheduler distribuiscono le attività ai worker di Airflow utilizzando una coda Redis, che viene eseguita come applicazione nel cluster del tuo ambiente. Gli scheduler Airflow vengono eseguiti come Deployment nel cluster del tuo ambiente.

I lavoratori Airflow eseguono singole attività dai DAG rimuovendole dalla coda Redis. I worker Airflow vengono eseguiti come Deployment nel cluster del tuo ambiente.

Coda Redis contiene una coda di singole attività dei tuoi DAG. Gli scheduler Airflow riempiono la coda; i worker di Airflow prendono le proprie attività da lì. La coda Redis viene eseguita come applicazione StatefulSet nel cluster del tuo ambiente, in modo che i messaggi vengano mantenuti tra i riavvii dei container.

Server web Airflow

Il server web Airflow esegue l'UI di Airflow del tuo ambiente.

In Cloud Composer 1, il server web Airflow è un'istanza App Engine Flex in esecuzione nel progetto tenant del tuo ambiente.

Il server web Airflow è integrato con Identity-Aware Proxy. Cloud Composer nasconde i dettagli dell'integrazione IAP e fornisce l'accesso al server web in base alle identità degli utenti e alle associazioni di criteri IAM definite per gli utenti.

Il server web Airflow viene eseguito su un account di servizio diverso rispetto ai worker Airflow e agli scheduler Airflow. L'account di servizio per il server web viene generato automaticamente durante la creazione dell'ambiente e deriva dal dominio del server web. Ad esempio, se il dominio è example.appspot.com, l'account di servizio è [e-mail].

Database Airflow

Il database Airflow è un'istanza Cloud SQL in esecuzione nel progetto tenant del tuo ambiente. Ospita il database di metadati Airflow.

Per proteggere le informazioni sensibili sulla connessione e sul flusso di lavoro, Cloud Composer consente l'accesso al database solo all'account di servizio del tuo ambiente.

Attenzione: la modifica dello schema del database Airflow o l'emissione dei comandi resetdb, initdb o upgradedb di Airflow può interrompere l'ambiente Cloud Composer.

Bucket dell'ambiente

Il bucket dell'ambiente è un bucket Cloud Storage in cui sono archiviati DAG, plug-in, dipendenze dei dati e log di Airflow. Il bucket dell'ambiente si trova nel progetto del cliente.

Quando carichi i file DAG nella cartella /dags del bucket del tuo ambiente, Cloud Composer sincronizza i DAG con worker, scheduler e server web del tuo ambiente. Puoi archiviare gli artefatti del tuo flusso di lavoro nelle cartelle data/ e logs/ senza preoccuparti dei limiti di dimensioni e mantenere il pieno controllo dell'accesso ai tuoi dati.

Nota: a causa di una limitazione del servizio su App Engine, le cartelle data/ e logs/ non sono disponibili per il server web Airflow.

Altri componenti dell'ambiente

Un ambiente Cloud Composer ha diversi componenti aggiuntivi:

• Archiviazione di Cloud SQL. Archivia i backup dei database Airflow. Cloud Composer esegue giornalmente il backup dei metadati Airflow per ridurre al minimo la potenziale perdita di dati.

  Cloud SQL Storage viene eseguito nel progetto tenant del tuo ambiente. Non puoi accedere ai contenuti di archiviazione di Cloud SQL.

• proxy Cloud SQL. Connette altri componenti del tuo ambiente al database Airflow.

  Il tuo ambiente IP pubblico può avere una o più istanze del proxy Cloud SQL, a seconda del volume di traffico verso il database Airflow.

  Nel caso di un ambiente IP pubblico, un proxy Cloud SQL viene eseguito come deployment nel cluster del tuo ambiente.

  Una volta eseguito il deployment nel cluster del tuo ambiente, il proxy Cloud SQL autorizza anche l'accesso all'istanza Cloud SQL da un'applicazione, un client o un altro servizio Google Cloud.

- HAProxy. Bilancia il carico del traffico verso l'istanza Cloud SQL tra due istanze del proxy Cloud SQL in esecuzione nel progetto tenant. Nel caso di Cloud Composer 1, questo componente viene utilizzato in ambienti IP privati ed viene eseguito come container nel deployment del proxy Cloud SQL.

• Monitoraggio del flusso d'aria. Segnala le metriche di ambiente a Cloud Monitoring e attiva il DAG airflow_monitoring. Il DAG airflow_monitoring segnala i dati sullo stato di integrità dell'ambiente, che vengono utilizzati in seguito, ad esempio, nella dashboard di monitoraggio del tuo ambiente. Il monitoraggio di Airflow viene eseguito come deployment nel cluster del tuo ambiente.

• L'agente Composer esegue operazioni relative all'ambiente come la creazione, l'aggiornamento, l'upgrade e l'eliminazione di ambienti. In generale, questo componente è responsabile dell'introduzione di modifiche nell'ambiente. Viene eseguito come job nel cluster del tuo ambiente.

• Airflow InitDB crea un'istanza Cloud SQL e uno schema di database iniziale. Airflow InitDB viene eseguito come Job nel cluster del tuo ambiente.

• FluentD. Raccoglie i log da tutti i componenti dell'ambiente e li carica in Cloud Logging. Viene eseguito come DaemonSet nel cluster del tuo ambiente.

• Abbonamenti a Pub/Sub. Il tuo ambiente comunica con il suo agente di servizio GKE tramite le abbonamenti Pub/Sub. Si basa sul comportamento predefinito di Pub/Sub per la gestione dei messaggi. Non eliminare .*-composer-.* argomenti Pub/Sub. Pub/Sub supporta un massimo di 10.000 argomenti per progetto.

• Sincronizzazione dei bucket: Questo processo sincronizza i bucket di ambiente nei progetti cliente e tenant. Questo componente viene usato nell'IP privato con l'architettura dell'ambiente DRS. Questo componente viene eseguito come container nei pod di altri componenti che utilizzano i bucket di ambiente.

  Architettura dell'ambiente IP pubblico

  

  Figura 1. Architettura dell'ambiente IP pubblico (fai clic per ingrandire)

  In un'architettura di ambiente IP pubblico per Cloud Composer 1:

  • Il progetto tenant ospita un'istanza Cloud SQL, uno spazio di archiviazione Cloud SQL e un'istanza App Engine Flex che esegue il server web Airflow.
  • Il progetto del cliente ospita tutti gli altri componenti dell'ambiente.
  • Gli scheduler e i worker di Airflow nel progetto del cliente comunicano con il database Airflow attraverso un'istanza proxy Cloud SQL situata nel progetto del cliente.
  • Il server web Airflow nel progetto tenant comunica con il database Airflow attraverso un'istanza proxy Cloud SQL situata nel progetto tenant.

  Architettura dell'ambiente IP privato

  

  Figura 2. Architettura dell'ambiente con IP privato (fai clic per ingrandire)

  In un'architettura di ambiente con IP privato:

  • Il progetto tenant ospita un'istanza Cloud SQL, uno spazio di archiviazione Cloud SQL e due istanze App Engine che eseguono il server web Airflow.
  • Il progetto del cliente ospita tutti gli altri componenti dell'ambiente.
  • Gli scheduler e i worker di Airflow si connettono al database Airflow tramite il processo HAProxy nel cluster dell'ambiente.
  • Il processo HAProxy bilancia il carico del traffico verso l'istanza Cloud SQL tra due istanze del proxy Cloud SQL che si trovano nel progetto tenant. Gli ambienti IP privati utilizzano due istanze proxy Cloud SQL perché il progetto del cliente non accede direttamente al database a causa di limitazioni di rete. Sono necessarie due istanze per garantire che i componenti del tuo ambiente abbiano sempre accesso al database.

  IP privato con DRS

  

  Figura 3. Architettura dell'ambiente con IP privato (fai clic per ingrandire)

  Se il criterio dell'organizzazione Condivisione limitata di dominio (DRS) è attivo nel progetto, Cloud Composer utilizza l'IP privato con l'architettura dell'ambiente DRS.

  Nell'architettura di ambiente IP privato con DRS:

  • Il progetto tenant ospita un'istanza Cloud SQL, uno spazio di archiviazione Cloud SQL e due istanze App Engine che eseguono il server web Airflow.

  • Il progetto tenant ospita un bucket dell'ambiente aggiuntivo. Il server web Airflow accede direttamente a questo bucket.

  • Il progetto del cliente ospita tutti gli altri componenti dell'ambiente.

  • Il progetto del cliente ospita il processo di sincronizzazione dei bucket nel cluster dell'ambiente. Questo processo sincronizza due bucket di ambiente.

  • Gli scheduler e i worker di Airflow si connettono al database Airflow tramite il processo HAProxy nel cluster dell'ambiente.

  • Il processo HAProxy bilancia il carico del traffico verso l'istanza Cloud SQL tra due istanze del proxy Cloud SQL che si trovano nel progetto tenant. Gli ambienti IP privati utilizzano due istanze proxy Cloud SQL perché il progetto del cliente non accede direttamente al database a causa di limitazioni di rete. Sono necessarie due istanze per garantire che i componenti del tuo ambiente abbiano sempre accesso al database.

  Integrazione con Cloud Logging e Cloud Monitoring

  Cloud Composer si integra con Cloud Logging e Cloud Monitoring del tuo progetto Google Cloud , in modo che tu possa disporre di una posizione centrale in cui visualizzare i log del flusso di lavoro e del servizio Airflow.

  Cloud Monitoring raccoglie e importa metriche, eventi e metadati da Cloud Composer per generare insight tramite dashboard e grafici.

  Grazie alla natura in modalità flusso di Cloud Logging, puoi visualizzare i log emessi immediatamente dallo scheduler e dai worker di Airflow invece di attendere che i log di Airflow vengano visualizzati nel bucket Cloud Storage del tuo ambiente. Poiché i log di Cloud Logging per Cloud Composer si basano su google-fluentd, hai accesso a tutti i log prodotti dagli scheduler e dai worker di Airflow.

  Per limitare il numero di log nel progetto Google Cloud, puoi interrompere l'importazione di tutti i log. Non disabilitare Logging.

  Passaggi successivi

  • Creare un ambiente
  • Panoramica del controllo delle versioni