Airflow gestito (terza generazione) | Airflow gestito (seconda generazione) | Airflow gestito (prima generazione legacy)
Questa pagina descrive l'architettura degli ambienti Managed Airflow.
Configurazioni dell'architettura dell'ambiente
Gli ambienti Managed Airflow (prima generazione legacy) possono avere le seguenti configurazioni dell'architettura:
- Architettura IP pubblico
- Architettura IP privato con peering VPC
- Architettura IP privato con condivisione limitata al dominio (DRS)
Progetti cliente e tenant
Quando crei un ambiente, Airflow gestito distribuisce le risorse dell'ambiente tra un progetto tenant e un progetto cliente:
Il progetto cliente è un Google Cloud progetto in cui crei i tuoi ambienti. Puoi creare più ambienti in un singolo progetto cliente.
Il progetto tenant è un progetto tenant gestito da Google e appartiene all'organizzazione Google.com. Il progetto tenant fornisce un controllo dell'accesso unificato e un ulteriore livello di sicurezza dei dati per il tuo ambiente. Ogni ambiente Airflow gestito ha il proprio progetto tenant.
Componenti dell'ambiente
Un ambiente Airflow gestito è costituito da componenti dell'ambiente.
Un componente dell'ambiente è un elemento di un'infrastruttura Airflow gestita che viene eseguita Google Cloud, come parte del tuo ambiente. I componenti dell'ambiente vengono eseguiti nel progetto tenant o nel progetto cliente del tuo ambiente.
Cluster dell'ambiente
Il cluster dell'ambiente è un cluster Google Kubernetes Engine in modalità Standard basato su VPC nativo o basato su route del tuo ambiente:
Per impostazione predefinita, Managed Airflow abilita gli upgrade automatici dei nodi e la riparazione automatica dei nodi per proteggere il cluster dell'ambiente dalle vulnerabilità di sicurezza. Queste operazioni vengono eseguite durante i periodi di manutenzione specificati per l'ambiente.
Bucket dell'ambiente
Il bucket dell'ambiente è un bucket Cloud Storage che archivia DAG, plug-in, dipendenze dei dati e log di Airflow. Il bucket dell'ambiente si trova nel progetto cliente.
Quando carichi i file DAG nella cartella /dags del bucket dell'
ambiente, Airflow gestito sincronizza i DAG con i componenti Airflow del tuo ambiente.
Server web Airflow
Il server web di Airflow esegue la UI di Airflow del tuo ambiente.
In Managed Airflow (prima generazione legacy), il server web di Airflow viene eseguito nel progetto tenant del tuo ambiente.
Il server web di Airflow è integrato con Identity-Aware Proxy. Managed Airflow nasconde i dettagli dell'integrazione di IAP e fornisce l'accesso al server web in base alle identità utente e alle associazioni dei criteri IAM definite per gli utenti.
In Airflow gestito (prima generazione legacy), il server web di Airflow viene eseguito su un account di servizio diverso da quello dei worker e degli scheduler di Airflow. Il 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, il account di servizio è example@appspot.gserviceaccount.com.
Database Airflow
Il database Airflow è un'istanza Cloud SQL che viene eseguita nel progetto tenant del tuo ambiente. Ospita il database dei metadati Airflow.
Per proteggere le informazioni sensibili relative a connessioni e workflow, Managed Airflow consente l'accesso al database solo a il service account del tuo ambiente.
Altri componenti Airflow
Altri componenti Airflow eseguiti nel tuo ambiente sono:
Gli scheduler di Airflow analizzano i file di definizione DAG, pianificano le esecuzioni dei DAG in base all'intervallo pianificato e accodano le attività per l'esecuzione da parte dei worker di Airflow. In Managed Airflow (Legacy Gen 1), i processori DAG di Airflow vengono eseguiti come parte dei componenti dello scheduler.
I worker di Airflow eseguono le attività pianificate dagli scheduler di Airflow.
Architettura dell'ambiente IP pubblico
In un'architettura dell'ambiente IP pubblico per Managed Airflow (prima generazione legacy):
- Il progetto tenant ospita un'istanza Cloud SQL, lo spazio di archiviazione Cloud SQL e un'istanza App Engine Flex che esegue il server web di Airflow.
- Il progetto cliente ospita tutti gli altri componenti dell'ambiente.
- Gli scheduler e i worker di Airflow nel progetto cliente comunicano con il database Airflow tramite le istanze proxy Cloud SQL situate nel progetto cliente.
- Il server web di Airflow nel progetto tenant comunica con il database Airflow tramite un'istanza proxy Cloud SQL situata nel progetto tenant.
Architettura dell'ambiente IP privato
In un'architettura dell'ambiente IP privato:
- Il progetto tenant ospita un'istanza Cloud SQL, lo spazio di archiviazione Cloud SQL e due istanze App Engine che eseguono il server web di Airflow.
- Il progetto 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 proxy Cloud SQL situate nel progetto tenant. Gli ambienti IP privati utilizzano due istanze proxy Cloud SQL perché il progetto cliente non accede direttamente al database a causa delle limitazioni di rete. Sono necessarie due istanze per garantire che i componenti dell'ambiente abbiano sempre accesso al database.
IP privato con DRS
Se nel tuo progetto è attivato il criterio dell'organizzazione Condivisione limitata al dominio (DRS), Managed Airflow utilizza l'architettura dell'ambiente IP privato con DRS.
Nell'architettura dell'ambiente IP privato con DRS:
Il progetto tenant ospita un'istanza Cloud SQL, lo spazio di archiviazione Cloud SQL e due istanze App Engine che eseguono il server web di Airflow.
Il progetto tenant ospita un bucket dell'ambiente aggiuntivo. Il server web di Airflow accede direttamente a questo bucket.
Il progetto cliente ospita tutti gli altri componenti dell'ambiente.
Il progetto cliente ospita il processo di sincronizzazione dei bucket nel cluster dell'ambiente. Questo processo sincronizza due bucket 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 proxy Cloud SQL situate nel progetto tenant. Gli ambienti IP privati utilizzano due istanze proxy Cloud SQL perché il progetto cliente non accede direttamente al database a causa delle limitazioni di rete. Sono necessarie due istanze per garantire che i componenti dell'ambiente abbiano sempre accesso al database.
Integrazione con Cloud Logging e Cloud Monitoring
Airflow gestito si integra con Cloud Logging e Cloud Monitoring del tuo Google Cloud progetto, in modo da avere un luogo centralizzato per visualizzare i log di Airflow e dei DAG.
Cloud Monitoring raccoglie e importa metriche, eventi e metadati da Managed Airflow per generare insight tramite dashboard e grafici.
Grazie alla natura di streaming di Cloud Logging, puoi visualizzare immediatamente i log emessi dai componenti Airflow anziché attendere che i log di Airflow vengano visualizzati nel bucket Cloud Storage del tuo ambiente.
Per limitare il numero di log nel tuo Google Cloud progetto, puoi interrompere l'importazione di tutti i log. Non disabilitare Logging.