Photo by Knut Troim on Unsplash

Como fazer o deploy do Airflow com GitOps

Por Murilo Mendonça
Arquiteto de Software | Ambev Tech

Se você chegou até esse post, provavelmente você se interessa ou até mesmo trabalha na área de Analytics, né? Então, boas-vindas!

Acredito que seja bem difícil falar sobre uma stack moderna para trabalhar com dados analíticos e Big Data de modo geral sem mencionar ferramentas de orquestração e, talvez principalmente, o Airflow.

Vale sempre lembrar que o Airflow é uma das principais ferramentas de orquestração, ou seja, ele é muito bom pra planejar e chamar a execução de ferramentas de processamento externas. Um “casamento” muito interessante e que se tornou recorrente na indústria nos últimos anos é o framework de processamento distribuído Apache Spark, orquestrado pelo Apache Airflow.

Vamos ver como a gente sobe uma instância de Airflow pra fazer isso?

Deploy do Airflow no Kubernetes com Helm

Bom, pra fazer o deployment do Airflow, a gente tem algumas opções. Se você trabalha com AWS ou GCP, existem soluções gerenciadas dos próprios provedores que são relativamente baratas, ou pelo menos com uma boa relação custo vs. benefício. Mas se você tem um time que consegue sustentar ou até mesmo quer economizar o custo de uma plataforma gerenciada, tenho boas notícias. O deployment do Airflow é relativamente simples de se fazer no Kubernetes, porque o time do Airflow recentemente lançou seu repositório com o Helm chart oficial da ferramenta.

Com Helm, você apenas precisa rodar poucos comandos pra instalar ferramentas que demandam muita customização por padrão. Você vai precisar instalar o Helm no seu terminal e executar:

$ helm repo add apache-airflow https://airflow.apache.org
$ helm upgrade -i airflow apache-airflow/airflow -n airflow — create-namespace

Dica: sempre que você vai instalar a primeira vez alguma ferramenta, use esse esquema de helm upgrade -i porque aí você usa o mesmo comando tanto para fazer o deploy, quanto para atualizar a sua release.

Eu escrevi um post um pouco mais detalhado sobre como customizar a instalação do Airflow com o Helm e, se você quiser, pode conferir ele aqui.

O que é GitOps?

Bom, tá no título então vamos lá bem rapidinho. GitOps pode ser entendido como um framework de gestão de operação que se apoia no Git como principal ferramenta. Em linhas gerais, você vai utilizar o fluxo de trabalho com o Git para conseguir gerenciar o deployment das suas ferramentas e infraestrutura.

Esse framework foi responsável por facilitar a gestão de infraestrutura com o surgimento de ferramentas de Infraestrutura como Código (IaC) em conjunto com ferramentas de CI/CD. Além de automatizar os deployments, trabalhar com GitOps possibilita também o versionamento de aplicações e infraestrutura, que não era possível com fluxos tradicionais de software.

Um exemplo: ao aprovar uma Pull Request no repositório da sua aplicação, a sua ferramenta de CI/CD vai aplicar as modificações do seu arquivo de configuração na sua infraestrutura/aplicação respectiva a ela. Se você quiser saber como era a sua aplicação há 3 meses, basta navegar até o commit respectivo a esse período. Legal, né?

Push vs. Pull

Estratégias tradicionais de deployments automatizados em geral estão ligadas ao conceito de dar um “Push”, ou seja, literalmente empurrar a versão mais recente do código para subir uma versão do software que você está trabalhando ou da infraestrutura que você está mantendo.

Algumas ferramentas de GitOps também podem adotar a estratégia de deployment com “Pull”. Isso significa que vai existir um agente ou serviço no seu cluster de Kubernetes que irá periodicamente verificar o estado do seu repositório e, a cada novo commit ou modificação no código, ele vai ser o responsável por “puxar” e propagar essa modificação para a sua aplicação.

A ferramenta que a gente vai usar aqui nessa postagem é o ArgoCD, que trabalha com essa abordagem de pulling. Vamos ver agora como a gente faz um deployment simples com ela?

Deployments do Kubernetes no Argo

Um deployment simples no ArgoCD será feito através de uma Custom Resource Definition (CRD). O nome é diferentão, mas o que ele diz basicamente é que você vai aplicar um arquivo de configuração específico da sua aplicação. No nosso caso, do ArgoCD.

Eu tô aqui partindo da ideia que você já tem uma instância de ArgoCD rodando no seu Kubernetes, tá? Se você quiser ver um post sobre o deploy do Argo, por exemplo, fala pra gente aqui nos comentários! 😃

Bom, a CRD do ArgoCD é super simples, e pode ser declarada da seguinte maneira:

Com ela, é possível então fazer com que o trabalho que antes era manual de dar um kubectl apply -f nome-do-arquivo.yaml todo para o Argo. Em algumas aplicações de Kubernetes, você provavelmente vai precisar fazer isso múltiplas vezes, uma pro Deployment, outra pro Service, outra pro HPA, e assim por diante. Que bom que o ArgoCD tá aqui pra automatizar e sincronizar isso, né?

Mas vamos destrinchar o que tem nessa CRD. Primeiro, a apiVersion que a gente vai usar é a v1alpha1 mesmo, do próprio Argo. E aí a gente vai deployar essa CRD como um kind Application, que é como a CRD entende o que precisa pra fazer esse deployment.

Na chave metadata, temos o metadata.name que é o nome da sua aplicação. O namespace de metadata é o namespace onde está deployado seu ArgoCD. Isso é importante, porque no fim da CRD temos uma outra chave namespace que diz respeito ao namespace pra onde você vai lançar sua aplicação!

Seguindo, vamos pra parte de spec. O ArgoCD permite que você crie múltiplos “projects”, e eles servem para que você consiga agrupar aplicações específicas. Nesse exemplo, vamos manter no project default, que já vem por padrão em qualquer instância do ArgoCD.

Aí em spec.source temos as seguintes chaves:

- repoURL: a URL do repositório de Github onde estão os YAMLs de deploy da sua aplicação

- targetRevision: a branch que você deseja sincronizar, nesse exemplo estamos usando a main

- path: o caminho relativo dentro do repositório onde estão os arquivos YAML

Em spec.destination vamos explicitar onde que será feito esse deployment. Pra isso a gente só precisa dizer em qual cluster de kubernetes com a variável server e qual é o namespace da sua aplicação desejada. Se a gente tivesse instalando o Airflow com essa estratégia, provavelmente o spec.destination.namespace seria “airflow”.

E aí uma única vez que você dê um kubectl apply com essa CRD no cluster de Kubernetes que você possui o ArgoCD instalado, ele já vai identificar essa Application e fazer todos os kubectl apply necessários para que a sua aplicação rode. Aí sempre que você mudar, no seu repositório remoto, o que tá dentro da spec.source.path já vai ser sincronizado automaticamente pelo ArgoCD. Legal, né?

E se você quiser uma explicação mais detalhada, não deixe de conferir a documentação oficial da ferramenta, tá?

Como a gente comentou no início dessa postagem, vamos fazer o deployment do Airflow com Helm e, por essa abordagem de deployment “simples”, com a sincronização dos arquivos que a gente precisaria dar um kubectl apply, não funcionaria.

Existem algumas maneiras de se fazer o deployment de Helm charts com o ArgoCD, e a mais simples delas é utilizando a mesma CRD que comentamos anteriormente. Quando se quer fazer um deploy que não vai sofrer muitas alterações ao longo do tempo, pode funcionar super bem.

O problema é que passaremos a utilizar a estratégia de pushing que comentamos mais cedo, porque para cada alteração nas variáveis com o arquivo values.yaml, você precisaria ter uma pipeline de deploy contínuo que persistiria essas modificações com um kubectl apply -f sua-crd.yaml. E como queremos manter a estratégia de pulling para a nossa demonstração de deployment do Airflow, iremos trabalhar com a estratégia de subcharts, que vamos explicar a seguir.

Estratégia de Subchart

Para configurar um subchart de Helm com o ArgoCD, vamos seguir alguns passos bem diretos e simples. É um pouco confuso no começo, mas depois que você pega o jeito fica bem tranquilo.

Adicionar o chart de Helm no ArgoCD

O primeiro passo é adicionar o chart que você vai se referenciar no ArgoCD. É algo similar ao que você faria localmente com o comando helm repo add. Pra isso, vá até o repositório onde o ArgoCD está configurado e abra o arquivo argocd-cm.yaml. Dentro da chave data, abra uma chave chamada repositories, da seguinte maneira:

Aplique essas modificações e aí o ArgoCD vai conseguir encontrar o repositório quando você precisar referenciá-lo.

Criar a estrutura de pastas e arquivos

No repositório onde você vai fazer o deployment do Airflow, abra uma pasta e nomeie-a como airflow-subchart. Dentro dela, coloque dois arquivos, um Chart.yaml e outro values.yaml.

O primeiro arquivo deve ter essa estrutura aqui:

O values.yaml por sua vez, vai ser exatamente o que você já configurou para fazer o deployment do airflow com Helm manualmente. A única diferença é que tudo o que você especificou vai estar dentro de uma chave chamada “airflow”. O que você pode fazer é Ctrl/Cmd + A, selecionar tudo e dar um Tab. Na primeira linha do arquivo, você coloca a chave “airflow” e pronto! 😇

Com esses dois arquivos criados na pasta que a gente mencionou, agora falta a gente criar a nossa CRD, muito similar ao que foi mostrado no exemplo genérico anterior. Para isso, abra uma pasta com o nome .argocd e dentro dela crie um arquivo chamado airflow-application.yaml. Nele, vamos criar o nosso CRD da seguinte maneira:

Veja que, em comparação com o exemplo da seção anterior, a única coisa “nova” que fizemos foi preencher a chave spec.source.helm com o dicionário valueFiles, que vai basicamente mapear o arquivo de valores que criamos no nosso subchart como uma aplicação Helm.

Fazendo o deploy do Airflow com o ArgoCD

Agora para finalmente subir a aplicação, no seu terminal, execute o seguinte comando:

$ kubectl apply -f .argocd/airflow-application.yaml

E aí você vai poder observar no Argo que uma aplicação vai começar a ser sincronizada e também que no namespace que a gente definiu (nesse caso, airflow) os Pods também vão começar a aparecer.

Parabéns! Você tem uma instância de Airflow rodando no Kubernetes com o ArgoCD! 🎉 😄

Para revisar, nossa estrutura de pastas ficou assim:

airflow
├── .argocd
│   └── airflow-application.yaml
└── airflow-subchart
    ├── Chart.yaml
    └── values.yaml

Agora a cada novo commit que você fizer na branch main no repositório https://github.com/my_org/airflow.git, dentro do seu arquivo airflow-subchart/values.yaml as alterações serão “puxadas” e aplicadas pelo Argo automaticamente.

NOTA: Caso você esteja trabalhando dentro de um projeto no ArgoCD com restrição de acesso aos repositórios, você vai precisar incluir seu repositório manualmente lá! Mas é super intuitivo de fazer, pela própria UI do Argo.

Deletando seu deployment

Bom, um tutorialzinho curto, mas cheio de detalhes pra gente se atentar.

Se você não vai usar o Airflow no ambiente produtivo (ainda), uma boa ideia nesse momento é deletar sua aplicação. Para isso, você pode navegar pela UI do ArgoCD até o deployment do seu Airflow e manualmente deletá-lo clicando no botão e na sequência digitando o nome do deployment. Uma outra opção seria usar o próprio comando:

$ kubectl delete Application -n argocd airflow

E aí, com isso, você vai apagar a definição da aplicação e, junto com ela, todos os recursos que estão de pé.

Espero que tenha sido um tutorial útil para você que chegou até aqui. Gostou da postagem? Ficou com alguma dúvida? Conta pra gente nos comentários!

Saúde 🍻