Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1
Esta página descreve a arquitetura dos ambientes do Cloud Composer.
Configurações de arquitetura do ambiente
Os ambientes do Cloud Composer 1 podem ter as seguintes configurações de arquitetura:
- Arquitetura de IP público
- Arquitetura de IP privado com interligações de VPCs
- IP privado com arquitetura de partilha restrita por domínio (DRS)
Projetos de clientes e inquilinos
Quando cria um ambiente, o Cloud Composer distribui os recursos do ambiente entre um inquilino e um projeto do cliente:
O projeto do cliente é um Google Cloud projeto onde cria os seus ambientes. Pode criar mais do que um ambiente num único projeto de cliente.
O projeto de inquilino é um projeto de inquilino gerido pela Google e pertence à organização Google.com. O projeto de inquilino oferece controlo de acesso unificado e uma camada adicional de segurança de dados ao seu ambiente. Cada ambiente do Cloud Composer tem o seu próprio projeto de inquilino.
Componentes do ambiente
Um ambiente do Cloud Composer é composto por componentes do ambiente.
Um componente de ambiente é um elemento de uma infraestrutura do Airflow gerida que é executado no Google Cloud, como parte do seu ambiente. Os componentes do ambiente são executados no inquilino ou no projeto do cliente do seu ambiente.
Cluster do ambiente
O cluster do ambiente é um cluster do Google Kubernetes Engine no modo Standard nativo da VPC ou baseado em rotas do seu ambiente:
Por predefinição, o Cloud Composer ativa as atualizações automáticas de nós e a autorreparação de nós para proteger o cluster do seu ambiente contra vulnerabilidades de segurança. Estas operações ocorrem durante os períodos de manutenção que especificar para o seu ambiente.
Segmento do ambiente
O contentor do ambiente é um contentor do Cloud Storage que armazena DAGs, plug-ins, dependências de dados e registos do Airflow. O contentor do ambiente está localizado no projeto do cliente.
Quando carrega os ficheiros DAG para a pasta /dags no contentor do seu ambiente, o Cloud Composer sincroniza os DAGs com os componentes do Airflow do seu ambiente.
Servidor Web do Airflow
O servidor Web do Airflow executa a IU do Airflow do seu ambiente.
No Cloud Composer 1, o servidor Web do Airflow é executado no projeto de inquilino do seu ambiente.
O servidor Web do Airflow está integrado com o Identity-Aware Proxy. O Cloud Composer oculta os detalhes da integração do IAP e fornece acesso ao servidor Web com base nas identidades dos utilizadores e nas associações de políticas de IAM definidas para os utilizadores.
No Cloud Composer 1, o servidor Web do Airflow é executado numa conta de serviço diferente dos trabalhadores e dos programadores do Airflow. A conta de serviço para o servidor Web é gerada automaticamente durante a criação do ambiente e é derivada do domínio do servidor Web. Por exemplo, se o domínio for example.appspot.com, a conta de serviço é example@appspot.gserviceaccount.com.
Base de dados do Airflow
A base de dados do Airflow é uma instância do Cloud SQL que é executada no projeto de inquilino do seu ambiente. Alojamento da base de dados de metadados do Airflow.
Para proteger informações confidenciais de ligação e fluxo de trabalho, o Cloud Composer permite o acesso à base de dados apenas à conta de serviço do seu ambiente.
Outros componentes do fluxo de ar
Outros componentes do Airflow que são executados no seu ambiente:
Os programadores do Airflow analisam ficheiros de definição de DAG, programam execuções de DAG com base no intervalo de programação e colocam tarefas em fila para execução pelos trabalhadores do Airflow. No Cloud Composer 1, os processadores DAG do Airflow são executados como parte dos componentes do programador.
Os trabalhadores do Airflow executam tarefas agendadas pelos programadores do Airflow.
Arquitetura do ambiente de IP público
Numa arquitetura de ambiente de IP público para o Cloud Composer 1:
- O projeto de inquilino aloja uma instância do Cloud SQL, armazenamento do Cloud SQL e uma instância do App Engine Flex que executa o servidor Web do Airflow.
- O projeto do cliente aloja todos os outros componentes do ambiente.
- Os programadores e os trabalhadores do Airflow no projeto do cliente comunicam com a base de dados do Airflow através de instâncias de proxy do Cloud SQL localizadas no projeto do cliente.
- O servidor Web do Airflow no projeto do inquilino comunica com a base de dados do Airflow através de uma instância do proxy do Cloud SQL localizada no projeto do inquilino.
Arquitetura do ambiente de IP privado
Numa arquitetura de ambiente de IP privado:
- O projeto de inquilino aloja uma instância do Cloud SQL, armazenamento do Cloud SQL e duas instâncias do App Engine que executam o servidor Web do Airflow.
- O projeto do cliente aloja todos os outros componentes do ambiente.
- Os programadores e os trabalhadores do Airflow ligam-se à base de dados do Airflow através do processo HAProxy no cluster do ambiente.
- O processo HAProxy equilibra a carga do tráfego para a instância do Cloud SQL entre duas instâncias do proxy Cloud SQL localizadas no projeto do inquilino. Os ambientes de IP privado usam duas instâncias do proxy do Cloud SQL porque o projeto do cliente não acede diretamente à base de dados devido a limitações de rede. São necessárias duas instâncias para garantir que os componentes do seu ambiente têm acesso à base de dados em todos os momentos.
IP privado com DRS
Se a política organizacional de partilha restrita ao domínio (DRS) estiver ativada no seu projeto, o Cloud Composer usa o IP privado com a arquitetura de ambiente de DRS.
Na arquitetura do ambiente de IP privado com DRS:
O projeto de inquilino aloja uma instância do Cloud SQL, armazenamento do Cloud SQL e duas instâncias do App Engine que executam o servidor Web do Airflow.
O projeto de inquilino aloja um contentor de ambiente adicional. O servidor Web do Airflow acede diretamente a este contentor.
O projeto do cliente aloja todos os outros componentes do ambiente.
O projeto do cliente aloja o processo de sincronização de contentores no cluster do ambiente. Este processo sincroniza dois contentores de ambientes.
Os programadores e os trabalhadores do Airflow ligam-se à base de dados do Airflow através do processo HAProxy no cluster do ambiente.
O processo HAProxy equilibra a carga do tráfego para a instância do Cloud SQL entre duas instâncias do proxy Cloud SQL localizadas no projeto do inquilino. Os ambientes de IP privado usam duas instâncias do proxy do Cloud SQL porque o projeto do cliente não acede diretamente à base de dados devido a limitações de rede. São necessárias duas instâncias para garantir que os componentes do seu ambiente têm acesso à base de dados em todos os momentos.
Integração com o Cloud Logging e o Cloud Monitoring
O Cloud Composer integra-se com o Cloud Logging e o Cloud Monitoring do seu Google Cloud projeto, para que tenha um local central para ver os registos do Airflow e DAG.
O Cloud Monitoring recolhe e carrega métricas, eventos e metadados do Cloud Composer para gerar estatísticas através de painéis de controlo e gráficos.
Devido à natureza de streaming do Cloud Logging, pode ver os registos emitidos pelos componentes do Airflow imediatamente, em vez de esperar que os registos do Airflow apareçam no contentor do Cloud Storage do seu ambiente.
Para limitar o número de registos no seu Google Cloud projeto, pode parar toda a ingestão de registos. Não desative o registo.