Architettura dell'ambiente

Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3

Questa pagina descrive l'architettura degli ambienti Cloud Composer.

Configurazioni dell'architettura dell'ambiente

Gli ambienti Cloud Composer 1 possono avere la seguente architettura configurazioni:

Progetti del cliente e tenant

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

  • Il progetto cliente è un progetto Google Cloud in cui puoi creare ambienti cloud-native. Puoi creare più di un ambiente per un singolo cliente progetto.

Il progetto tenant è un progetto tenant gestito da Google. Il progetto tenant fornisce il controllo dell'accesso unificato e un livello aggiuntivo la sicurezza dei dati nel tuo ambiente. Ogni Cloud Composer ha un proprio progetto tenant.

Componenti dell'ambiente

Un ambiente Cloud Composer è composto da componenti di ambiente.

Un componente dell'ambiente è un elemento di un'infrastruttura Airflow gestita eseguito su Google Cloud, come parte del tuo ambiente. Ambiente vengono eseguiti nel tenant o nel progetto del cliente del tuo ambiente.

Cluster dell'ambiente

Il cluster dell'ambiente è una modalità Standard VPC-native o del cluster Google Kubernetes Engine basato su route questo ambiente:

Per impostazione predefinita, Cloud Composer abilita upgrade automatici dei nodi e riparazione automatica dei nodi per proteggere il cluster del tuo ambiente dalle vulnerabilità di sicurezza. Questi che si verificano durante i periodi di manutenzione specificati per completamente gestito di Google Cloud.

Bucket dell'ambiente

Il bucket dell'ambiente è un bucket Cloud Storage che archivia DAG, plug-in, dipendenze dati e log di Airflow. Ambiente del bucket si trova nel progetto del cliente.

Quando carichi i file DAG nella cartella /dags della Cloud Composer sincronizza i DAG con i componenti Airflow del tuo ambiente.

Server web Airflow

Il server web Airflow esegue la UI di Airflow del tuo ambiente.

In Cloud Composer 1, il server web Airflow viene eseguito nel progetto tenant del tuo ambiente.

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

In Cloud Composer 1, il server web Airflow viene eseguito su un account di servizio diverso dei worker e degli scheduler di Airflow. L'account di servizio per il server web viene generato automaticamente durante la creazione dell'ambiente e deriva dal web dominio del server. Ad esempio, se il dominio è example.appspot.com, il è example@appspot.gserviceaccount.com.

Database Airflow

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

Per proteggere informazioni sensibili relative a connessioni e flussi di lavoro, Cloud Composer consente l'accesso al database solo l'account di servizio del tuo ambiente.

Altri componenti del flusso di aria

Altri componenti di Airflow in esecuzione nel tuo ambiente sono:

  • Gli scheduler di Airflow analizzano i file di definizione dei DAG e pianificano le esecuzioni dei DAG in base all'intervallo pianificato e accoda le attività per l'esecuzione Worker Airflow. In Cloud Composer 1 I processori DAG di Airflow vengono eseguiti come parte dei componenti dello scheduler.

  • I lavoratori Airflow eseguono le attività pianificate da Airflow scheduler.

Architettura dell'ambiente IP pubblico

Risorse dell'ambiente Cloud Composer con IP pubblico nel progetto tenant e nel progetto del cliente
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, spazio di archiviazione Cloud SQL e un'istanza App Engine Flex 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 il database Airflow tramite istanze proxy Cloud SQL situate in per il progetto del cliente.
  • Il server web Airflow nel progetto tenant comunica con Airflow tramite un'istanza proxy Cloud SQL che si trova progetto tenant.

Architettura dell'ambiente IP privato

Risorse dell'ambiente Cloud Composer con IP privato nel progetto tenant e nel progetto del cliente
Figura 2. Architettura dell'ambiente IP privato (fai clic per ingrandire)
.

In un'architettura di ambiente IP privato:

  • Il progetto tenant ospita un'istanza Cloud SQL, 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 Cloud SQL tra due istanze proxy Cloud SQL che sono nel progetto tenant. Gli ambienti IP privati utilizzano due istanze proxy Cloud SQL perché il progetto del cliente non accedono direttamente al database a causa di limitazioni di rete. Due istanze sono necessari per garantire che i componenti del tuo ambiente abbiano accesso all'interno del database.

IP privato con DRS

IP privato con risorse di ambiente Cloud Composer DRS nel progetto tenant e nel progetto del cliente (fai clic per ingrandire)
Figura 3. Architettura dell'ambiente IP privato (fai clic per ingrandire)
.

Se il criterio dell'organizzazione relativo alla condivisione limitata del dominio (DRS) sia attivata nel tuo progetto, Cloud Composer utilizza l'IP con l'architettura di ambiente DRS.

Nell'architettura dell'ambiente IP privato con DRS:

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

  • Il progetto tenant ospita un bucket di ambiente aggiuntivo. Web Airflow che il server web 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 in nel cluster dell'ambiente. Questo processo sincronizza due ambienti bucket.

  • 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 Cloud SQL tra due istanze proxy Cloud SQL che sono nel progetto tenant. Gli ambienti IP privati utilizzano due istanze proxy Cloud SQL perché il progetto del cliente non accedono direttamente al database a causa di limitazioni di rete. Due istanze sono necessari per garantire che i componenti del tuo ambiente abbiano accesso all'interno del 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 posizione centrale per visualizzare i log di Airflow e DAG.

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

A causa della natura dei flussi di Cloud Logging, puoi visualizzare immediatamente i log emessi dai componenti Airflow invece di attendere che i log di Airflow vengano visualizzati nel bucket Cloud Storage del tuo ambiente.

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

Passaggi successivi