Visão geral do Cloud Composer

Nesta página, você encontra uma visão geral do ambiente do Cloud Composer e dos produtos do Google Cloud Platform usados em uma implantação do Apache Airflow.

O Cloud Composer é um serviço gerenciado de orquestração de fluxo de trabalho baseado no Airflow. Ele implanta vários componentes para executar o Airflow, como em uma implantação no local. Nesta página, você encontrará a descrição dos componentes do GCP, as funções deles e como você executa fluxos de trabalho.

O Cloud Composer depende de determinadas configurações para executar fluxos de trabalho, o que também é similar à implantação no local. Alterar as configurações necessárias para as conexões ou comunicações do Cloud Composer pode causar erros ou interromper a implantação do Airflow. Nesta página, você conhece as configurações de ambiente importantes.

Ambientes

O Airflow é um framework com arquitetura de microsserviços. Para implantá-lo em uma configuração distribuída, o Cloud Composer provisiona vários componentes do GCP, conhecidos como ambientes do Cloud Composer.

Os ambientes são um conceito fundamental do Cloud Composer. É possível criar um ou mais em um projeto. Os ambientes são implantações autônomas do Airflow baseadas no Google Kubernetes Engine. Eles funcionam com os serviços do GCP por meio de conectores integrados ao Airflow.

Os ambientes do Cloud Composer são criados em regiões compatíveis e executados em uma zona do Compute Engine. Nos casos de uso simples, crie um ambiente em uma região. Já nos mais complexos, você cria vários ambientes em uma única região ou em várias. O Airflow se comunica com outros produtos do GCP por meio das APIs públicas deles.

Arquitetura

Quando você cria um ambiente, o Cloud Composer distribui os recursos dele entre um projeto de locatário gerenciado pelo Google e um de cliente. Isso é mostrado no diagrama a seguir:

Recursos do ambiente do Cloud Composer no projeto de locatário e de cliente (clique para ampliar)
Recursos do ambiente do Cloud Composer (clique para ampliar)

Recursos do projeto de locatário

Para garantir o controle de acesso unificado do Cloud Identity and Access Management e uma camada extra de segurança de dados, o Cloud Composer implanta o Cloud SQL e o App Engine no projeto de locatário.

Cloud SQL

O Cloud SQL armazena os metadados do Airflow. O Cloud Composer limita o acesso ao banco de dados à conta de serviço padrão ou à conta personalizada especificada que você usou para criar o ambiente. Isso protege informações confidenciais de conexão e fluxo de trabalho. O Cloud Composer faz o backup dos metadados do Airflow diariamente para reduzir as possíveis perdas de dados.

A conta de serviço usada para criar o ambiente do Cloud Composer é a única que pode acessar os dados no banco de dados do Cloud SQL. Para autorizar remotamente o acesso ao banco de dados do Cloud SQL a partir de um aplicativo, cliente ou outro serviço do GCP, o Cloud Composer fornece o proxy do Cloud SQL no cluster do GKE.

App Engine

O ambiente flexível do App Engine hospeda o servidor da Web do Airflow. Por padrão, o servidor é integrado ao Cloud Identity-Aware Proxy. O Composer oculta os detalhes de integração do Cloud IAP e permite que você use a política do IAM do Composer para gerenciar o acesso ao servidor da Web. Para conceder acesso somente ao servidor da Web do Airflow, atribua o papel composer.user ou outros papéis do Cloud Composer que forneçam acesso a diferentes recursos no ambiente. Para as organizações com requisitos extras de controle de acesso, o Cloud Composer também aceita a implantação de um servidor da Web autogerenciado do Airflow no projeto de cliente.

Recursos do projeto de cliente

O Cloud Composer implanta o Cloud Storage, o Google Kubernetes Engine e o Stackdriver no projeto de cliente.

Cloud Storage

O Cloud Storage fornece o intervalo de armazenamento para organizar DAGs, plug-ins, dependências de dados e registros. Para implantar fluxos de trabalho (DAGs), você copia os arquivos para o intervalo do ambiente. O Cloud Composer processa a sincronização dos DAGs entre workers, programadores e servidores da Web. Com o Cloud Storage, você armazena artefatos de fluxo de trabalho nas pastas data/ e logs/ sem se preocupar com limitações de tamanho e mantém o controle de acesso total sobre os dados.

Google Kubernetes Engine

O Cloud Composer implanta componentes básicos em um cluster do GKE. Eles incluem o programador do Airflow, os nós de worker e o CeleryExecutor. O Redis é o agente de mensagens do CeleryExecutor. Ele é executado como um aplicativo StatefulSet para que as mensagens sejam mantidas nas reinicializações do contêiner.

Ao executar o programador e os workers no GKE, é possível usar o KubernetesPodOperator para executar qualquer carga de trabalho do contêiner. Por padrão, o Cloud Composer possibilita o upgrade e o reparo automáticos para proteger os clusters do GKE contra vulnerabilidades de segurança. Se você precisa fazer o upgrade do cluster do GKE do Cloud Composer antes do ciclo de atualização automática, é possível fazer o upgrade manual.

Além do servidor da Web do Airflow, os nós do programador e worker do Airflow são executados em diferentes contas de serviço.

  • Programador e workers: se você não especificar uma conta de serviço durante a criação do ambiente, ele será executado na conta de serviço padrão do Compute Engine.
  • Servidor da Web: a conta de serviço é gerada automaticamente durante a criação do ambiente e derivada do domínio do servidor da Web. Por exemplo, se o domínio for foo-tp.appspot.com, a conta de serviço será foo-tp@appspot.gserviceaccount.com.

Você encontra as informações de serviceAccount e airflowUri nos detalhes do ambiente.

Stackdriver

O Cloud Composer é integrado ao Stackdriver Logging e ao Stackdriver Monitoring para que você tenha uma visão central de todos os registros de fluxos de trabalho e serviços do Airflow.

Por conta da natureza de streaming do Stackdriver Logging, é possível ver de imediato os registros emitidos pelos workers e programador do Airflow, em vez de aguardar a sincronização do módulo de registros. E como os registros do Stackdriver no Cloud Composer são baseados no google-fluentd, você tem acesso a todos os registros gerados pelos contêineres de workers e programador. Eles ajudam bastante na depuração e contêm informações úteis sobre a dependência do Airflow e o nível do sistema.

O Stackdriver Monitoring coleta e ingere métricas, eventos e metadados do Cloud Composer para gerar insights por meio de painéis e gráficos.

Informações importantes sobre configuração

  • Alguns parâmetros do Airflow são pré-configurados para os ambientes do Cloud Composer, de modo que não é possível alterá-los. Você configura outros parâmetros ao criar o ambiente.
  • Quaisquer cotas ou limites que se apliquem a produtos individuais do GCP usados pelo Cloud Composer na implantação do Airflow também se aplicam ao ambiente.
  • O Cloud Composer depende das configurações a seguir para executar fluxos de trabalho:
    • O back-end de serviço do Cloud Composer se comunica com o agente de serviço do GKE por meio de assinaturas do Cloud Pub/Sub e se baseia no comportamento padrão do Cloud Pub/Sub para gerenciar mensagens. Não exclua os tópicos .*-composer-.*. O Cloud Pub/Sub aceita até 10.000 tópicos por projeto.
    • O serviço do Cloud Composer coordena a geração de registros com o Stackdriver. Para limitar o número de registros no projeto do GCP, interrompa a ingestão de todos os registros. Não desative o Stackdriver.
    • Não modifique a vinculação de política do Cloud Identity and Access Management na conta de serviço do Cloud Composer. Por exemplo, service-your-project-number@cloudcomposer-accounts.iam.gserviceaccount.com.
    • Não altere o esquema do banco de dados do Airflow.
  • Com a ferramenta de linha de comando gcloud, é possível executar a CLI do Airflow. Para evitar que as operações do banco de dados sejam impactadas, não emita os comandos resetdb, initdb ou upgradedb do Airflow.
  • Uma versão do Cloud Composer que execute uma versão estável do Airflow pode incluir atualizações do Airflow aplicadas retroativamente a partir de uma versão futura dele.
  • Os nós do worker e do programador têm capacidades diferentes e são executados em uma conta de serviço distinta do servidor da Web do Airflow. Para evitar falhas do DAG no servidor da Web do Airflow, não execute cálculos pesados nem acesse recursos do GCP que o servidor não pode acessar no momento da análise.
  • A exclusão do ambiente não remove estes dados do projeto de cliente: o intervalo do Cloud Storage do ambiente e os registros do Stackdriver. Para evitar alterações na conta do GCP, exporte e exclua os dados conforme necessário.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…