Forem: Bruno Padilha

Próximos passos com Atlantis

Bruno Padilha — Wed, 19 Jul 2023 16:59:40 +0000

Oi! Esse dev.to não será mais atualizado, agora eu tenho um Substack com temas do tipo. Me segue por lá! => https://blog.padz.dev

Depois de dois longos anos, é hora de reviver essa série de como continuar sua jornada com automação de infraestrutura como código. Em dois anos, muita coisa mudou, aprendi muito usando Atlantis praticamente toda dia, então espero fechar esse post e em breve terminar a série com um resumão e minhas experiências com Atlantis e Terraform.

Nesse post, abordarei um pouco sobre instalação e configuração e integração com GitHub.

Iniciando

Existem alguns modos de instalação, isso vai depender muito de onde você roda sua infraestrutura. Tome cuidado com anti-patterns, aqui vale pensar da seguinte forma "O que vem primeiro? O ovo ou a galinha?". Por isso, pense bem onde você vai subir e rodar sua instância de Atlantis.

Atualmente (Julho de 2023) existem as seguintes formas de você fazer deploy do Atlantis. Vou deixar links abaixo para cada uma delas:

Essa parte vai depender de como você ou seu time vão querer suportar o Atlantis. A minha dica é, se é um projeto greenfield, comece com uma EC2, AWS Fargate, Google Cloud Run ou uma VM no GCE (Google Compute Engine) e depois pense melhor onde rodar. Abordarei mais sobre patterns e anti-patterns no próximo post.

Instalação

Independente de onde você for fazer deploy do Atlantis, a configuração é igual para qualquer uma delas. O que muda a partir daqui é, com qual Git provider você quer integrar o Atlantis.

Os providers suportados são:

Como mencionei anteriormente, faremos a configuração passo a passo com GitHub.

O que você vai precisar ter para os próximos passos é basicamente a URL externa do Atlantis. Vou falar sobre segurança em um próximo post, mas isso vai também depender de sua arquitetura.

Se preparando

Como mencionado no último post, você interage com o Atlantis através de eventos de Pull Request (ou Merge Request no GitLab). Para isso, o Atlantis precisa receber webhooks do seu Git provider para que ele funcione.

De uma forma básica, webhook é uma requisição HTTP que é enviada por um evento a partir de um sistema para outro com um payload com alguns dados. Para saber mais sobre Webhooks, leia aqui.

Uma boa estratégia aqui é criar uma secret para o webhook. Essa secret pode ser criada com qualquer gerador de string e deve ser maior que 24 caractéres. Você pode criar com bash utilizando o comando echo | md5sum | head -c 32; echo; Após gerar salve a secret, você precisará dela mais pra frente.

Outro passo importante é criar um usuário no GitHub específico (ou utilizar algum já existente) para o Atlantis. Mesmo que a documentação trate como opcional, eu recomendo. Você também pode utilizar um GitHub App.

Com esse usuário criado, crie um Personal Access Token com permissões apenas para repo. Também é recomendável que esse token expire de tempos em tempos.

A partir daqui você já deve estar com o Atlantis rodando e acessível via UI na porta 4141 ou na porta que você expôs no Load Balancer.
Se você tem dúvidas de como subir, me chama no Telegram em @brunopadz ou comenta no post e a gente bate um papo.

No GitHub, há duas possibilidades de integração do Atlantis. Ou a nível de organização ou a nível repositório. O processo é o mesmo para ambos.

Adicione um Webhook, no campo Payload URL coloque https://URL_DO_ATLANTIS/events.
No Content-type coloque application/json.
No campo Secret cole a secret gerada anteriomente para o Webhook. Se você está criando um Webhook por repositório, a secret deverá ser a mesma.
Selecione Let me select individual events e selecione:
- Pull request reviews
- Pushes
- Issue comments
- Pull Requests
Deixe o checkbox Active marcado.

Autenticação com cloud provider

O Atlantis funciona basicamente executando os comandos terraform plan e terraform apply. Assim como você roda o Terraform da sua máquina, o Atlantis precisa de credenciais para se comunicar com cloud providers.

Fica a seu critério como realizar a autenticação. É possível fazer via ENV VARs, EC2 Roles (no caso da AWS) ou GCE Instance Service Accounts no Google.

Dica: Para se integrar com múltiplas contas da AWS, é recomendável fazer assume roles. Mais infos sobre isso no próximo post da série.

Na AWS recomendo utilizar EC2 Roles. Fica fácil de utilizar tanto no Fargate, quanto no Kubernetes (com IRSA) ou em EC2s.

Configurando o Atlantis

Existem 3 formas de configurar o Atlantis:

Através de flags no comando atlantis server
Utilizando a flag --repo-config para controlar o comportamento do Atlantis em cada repositório e definir o que usuários podem configurar no atlantis.yaml
Utilizando arquivos atlantis.yaml na raíz dos repositórios que possuem código em Terraform

Dica: Existe uma precedência para carregar as configurações. A ordem é:

Flags

ENV VARs

Arquivos de configuração

Como estamos configurando para integração com GitHub, o mínimo de configurações necessárias são as seguintes flags ou ENV VARS:

--gh-user ou ATLANTIS_GH_USER
--gh-token ou ATLANTIS_GH_TOKEN
--gh-webhook-secret ou ATLANTIS_GH_WEBHOOK_SECRET
--repo-allowlist ou ATLANTIS_REPO_ALLOWLIST

Exemplo:



# Usuário do GitHub que irá fazer os comentários nas Pull Requests
--gh-user=atlantis-ci-user \
# Personal Access Token do usuário "atlantis-ci-user"
--gh-token=abcdefg123456xyz1337 \
# Secret criada para o Webhook
--gh-webhook-secret=abcdefg123456xyz1337abcdefg123456xyz1337 \
# List de quais repos que o Atlantis pode rodar dentro de uma organização
--repo-allowlist='github.com/minha-org/*'

Com essas configurações o Atlantis está pronto para receber os webhooks vindos do GitHub. Para testar, abra uma Pull Request em qualquer repositório que contenha código em Terraform e que esteja na Allow list da configuração.

Nessa mensagem, o Atlantis vai mostrar o output do terraform plan e você pode interagir com ele através de um comentário na Pull Request.

Basicamente, todo comentário é feito com atlantis ao invés de terraform. Para todos os possíveis comandos, consulte a documentação oficial ou atlantis help. Alguns exemplos além do plan e apply são:

atlantis import para importar recursos no state
atlantis state rm para remover recursos do state

No próximo post, trarei alguns temas como boas práticas e anti-patterns ao utilizar o Atlantis.

Até lá!

Iniciando com Atlantis

Bruno Padilha — Tue, 15 Jun 2021 20:48:38 +0000

Oi! Esse dev.to não será mais atualizado, agora eu tenho um Substack com temas do tipo. Me segue por lá! => https://blog.padz.dev

Esse é o primeiro post de uma série sobre o Atlantis, onde o intuito é dar um mega salto no fluxo de trabalho de quem já utiliza Terraform no dia dia. Se você já:

Utiliza Terraform para criar infraestrutura
Ainda usa o Terraform local
E sente falta de um ambiente mais colaborativo para desenvolver sua infraestrutura.

Essa série é para você!

Vamos passar por alguns pontos básicos de como a ferramenta funciona e até explorar alguns modos de deployment. Tudo isso com um repo no Github para te ajudar com configuração e exemplos.

Caso você não tenha experiência prévia com Terraform, super recomendo o conteúdo do Igor Souza no Youtube. :)

O que é o Atlantis

O Atlantis é uma aplicação que automatiza através de Pull Requests a forma como rodamos o Terraform.

Gosto muito da definição do Matheus Fidelis, que o Atlantis permite fazer GitOps para Terraform.

Ele funciona ouvindo Webhooks de plataformas de Git como: Github, Gitlab ou do Bitbucket e retorna o output dos comandos terraform plan e terraform apply através de comentários. Ou seja, todo fluxo de trabalho que antes era feito via CLI, terminal, pipeline do Jenkins, agora é feito nos comentários de uma Pull Request.

Exemplo de fluxo no trabalho. 🙂

De uma forma mais simples, o Atlantis atua como uma "ponte" entre o Terraform e a plataforma de Git tornando os plans e applies muito mais colaborativos. Mas por quê? Oras, infraestrutura como código é uma abordagem de automação de infraestrutura baseada em princípios de desenvolvimento de software, com reviews, testes, CI/CD e etc...

Antes de iniciar

Como mencionei acima, o Atlantis é uma espécie de wrapper do Terraform, por isso, a partir do momento que o Atlantis é adotado, é ele quem define qual versão do Terraform está rodando e é ele quem conhece as secrets e keys dos provedores de cloud, serviços e etc...

Por isso, a primeira dica é ficar de olho nas releases do projeto para saber se a última versão do Terraform já é suportada pelo Atlantis. E não necessariamente utilizar a última versão do Atlantis requer que você atualize seus projetos, por exemplo, é possível utilizar a última versão do Atlantis e para cada repo/projeto utilizar uma versão diferente do Terraform. Veremos sobre isso mais pra frente.

Um pouco de mundo real...

Para os projetos do time de e-commerce da Leroy Merlin, nós rodamos o Atlantis como container no Kubernetes, utilizamos Terraform Cloud como backend e uma abordagem com monorepo e multirepo. Alguns projetos como IAM, configuração do Vault e coisas relacionadas a sec, ficam fora do monorepo por uma questão de segurança.

Nos outros repositórios todo o time de engenharia possui acesso e cada módulo e projeto, possui documentação para auxiliar a criar novos recursos.

Dependendo do repositório e do projeto é necessário que haja no mínimo "x" aprovações para rodar um atlantis apply, em outros é necessário aprovação de CODEOWNERS. O ponto é que não importa sua estrutura atual ou o que você está planejando, o Atlantis vai suportar.

De uma forma gráfica, o Atlantis funciona assim no nosso time:

Fluxo do Atlantis no time de e-commerce da Leroy Merlin.

Indo mais a fundo

Nessa série de posts, utilizarei Github, Kubernetes e AWS. E durante ela, você irá encontrar nesse repo mais informações e formas de deploy.

Requerimentos

Git

O Atlantis suporta as principais plataformas de Git como:

Github
Gitlab
Bitbucket
Azure DevOps

Backend

O Atlantis suporta todos os tipos de backend, menos o local, já que o Atlantis não tem um banco de dados e não commita o state no git (o que é um mega anti-pattern).

Estrutura de diretório e repositórios

Qualquer seja a estrutura utilizada, o Atlantis vai rodar sem problemas. É possível utilizar:

Monorepo com vários projetos
Único repo com um único projeto
Monorepo com vários projetos e + módulos
Multirepo (basta ter um webhook para cada um deles)

É possível também utilizar Workspaces.

Arquitetura

O Atlantis é uma aplicação desenvolvida em Go. Com um binário por volta de 40MB e com uma imagem docker por volta de 250MB é super simples de subi-lo no Kubernetes, ECS / Fargate ou instalá-lo em uma instância.

A comunicação entre o Atlantis e o plataforma de Git é intrínseca. Por exemplo, o Atlantis precisa receber os Webhooks e fazer chamadas para as APIs da plataforma de Git utilizada. Em caso de serviços externos, o Atlantis precisa responder por uma URL válida, já em casos de serviços internos como Github Enterprise, Gitlab Enterprise e Bitbucket Server, isso já não é necessário.

Importante
O Atlantis não possui um banco de dados, todos os arquivos de plan, binários dos providers e etc são salvos em disco.

Configuração

Existem alguns métodos de configurar o Atlantis:

Utilizando flags no comando atlantis server, onde também é possível utilizar arquivo de configuração e ENV VARs. Por exemplo: ```sh

Flags

atlantis server --gh-token="token/123456/ABCDE"

ENV VAR

ATLANTIS_GH_TOKEN='token/123456/ABCDE' atlantis server


* Arquivo de configuração para cada repo. Onde o arquivo de configuração `repos.yml` fica junto do server.
* Arquivo de configuração em cada repositório. Onde cada repo possui o seu `atlantis.yml`.

### Utilização

Como deu pra notar, a principal diferença é que a partir de agora, o comando para rodar o Terraform mudou. O comando a ser chamado agora é o `atlantis`. Existem três principais subcomandos:

* `atlantis plan` que roda o `terraform plan` na branch de uma determinada Pull Request. É possível configurar para rodar de forma automática a cada novo commit, evitando intervenções manuais.
* `atlantis apply` que roda o `terraform apply` no plan executado anteriormente. 
* `atlantis help` que mostra a ajuda do Atlantis.

E claro, existem algumas flags em comum no `plan` e no `apply`, que no caso são as:

* `-w` que roda o plan ou apply contra um determinado workspace.
* `-d` que roda o plan ou apply de um projeto dentro de um diretório. Ele é importante quando a uma criação, alteração ou deleção de vários recursos em vários projetos em um único Pull Request. Se não especificado, roda em todos diretórios novos.

```sh


# Roda um plan para no diretório app1
atlantis plan -d app1

# Roda um plan no diretório aws/iam
atlantis plan -d aws/iam

E existe o -p que roda plan e apply para um projeto.

É possível também utilizar flags do Terraform, como -target, -var e -var-file.

Gerência do state

Assim como o Terraform, o Atlantis trabalha com state locking. Esse processo ocorre toda vez que um atlantis plan é executado e o state só será liberado quando a Pull Request for mergeada, fechada ou o plan é deletado de forma manual.

Vale a pena reforçar que esse state locking é do Atlantis e não do Terraform, onde o state do Atlantis é feito para prevenir várias Pull Requests trabalhando no mesmo projeto e o state do Terraform é feito para prevenir mudanças durante um terraform apply. Mais infos aqui.

Concluindo

Nessa primeira parte, abordamos o básico do Atlantis, como ele funciona, qual problema ele resolve e os motivos de utilizá-lo.

Nos próximos posts iremos nos aprofundar nos passos de instalação, configuração e como trabalhar de uma forma inteligente com Terraform.

Até mais!

Meu primeiro mês com um System76

Bruno Padilha — Mon, 15 Feb 2021 23:36:52 +0000

Esse post reúne informações sobre meu primeiro mês com um notebook da System76.

Há quem diga que notebooks feitos para rodar Linux são o futuro. Vejo cada vez mais meus amigos migrando do MacOS para Linux por questões de privacidade, customização do SO e liberdade. Com System76 não é diferente, os caras desenvolveram um sistema de firmware open source, com suporte a desabilitar o Intel ME.

Fui (ainda sou) usuário da Apple desde meados de 2009, quando comprei meu primeiro Macbook. Os anos foram passando, eu troquei de Macbook mais algumas vezes e até então eu estava trabalhando com um MacbookPro 15" late 2017 e a decisão maior de trocar de notebook foi por justamente o que a Apple permitia fazer e agora não mais, a liberdade de colocar mais um SSD, aumentar a memória e utilizar por muito mais tempo o hardware. Ainda utilizo meu macbook para fins de estudo, parear com a TV usando AirPlay, mas não para trabalhar.

Escolha e importação

A ideia era ter um notebook leve, pequeno e claro, com uma boa configuração e a escolha foi o Lemur Pro. Vale a pena mencionar que antes de considerar um System76, analisei outras opções como XPS da Dell (o qual não existe nenhuma doc que diz que suporta Linux 100%) e o Thinkpad da Lenovo (que não tinha em estoque em loja alguma).

A config que escolhi foi:

Core i5 11th Gen @ 4.2Ghz
16GB DDR4
500GB M2 SSD

Como o clock da CPU é bem maior do que o meu Macbook Pro com i7, resolvi ir de i5 mesmo e economizar uma boa grana.

Fiz o pedido no dia 18 de Dezembro e no mesmo dia recebi um e-mail e uma ligação solicitando a confirmação do pedido, pelo que a pessoa me explicou, foi pelo motivo de ter feito a compra com dados brasileiros e com a entrega nos EUA. Pedido feito, era só aguardar.

Utilizei o MyVipBox como serviço de redirecionamento, já que a System76 não envia direto para o Brasil. Como os notebooks são fabricados por pedido, levou uns 10 dias pra ser fabricado e enviado pro meu endereço nos EUA.
O legal do MyVipBox, é que eles tem alguns serviços adicionais, como usar embalagens menores e mais reforçadas e ainda conseguir diminuir o valor do frete. Mesmo assim tive que pagar um valor bem salgado de imposto aqui Brasil, ~ R$3000.

E no dia 19 de Janeiro, o brinquedo chegou.

A minha primeira impressão foi: que notebook leve e compacto!

Configuração

Qualidade

Pesando pouco mais de 1kg e com uma carcaça totalmente preta, o notebook é muito bonito e bem fabricado.
Eu esperava ter o logo da System76 na tampa, e de fato era para ter, porém por algum problema na fabricação foi enviado sem. A galera no subredit da System76 reclama bastante do controle de qualidade dos caras. Eu realmente curti demais o notebook todo preto.

O teclado dele é retroiluminado e muito (mas muito) parecido com os teclados dos primeiros macbooks retina.

Conectividade e tela

O notebook tem 2x USB 3, 1 USB-C com suporte a DisplayPort, 1 HDMI, entrada P2, Kesington Lock e leitor de MicroSD.
E ainda suporta até 40GB de RAM e ainda tem um slot M2 livre pra outro SSD nvme.

Obviamente a tela dele não se compara as retinas dos macbooks, mas é uma tela bem decente com antiglare de 14" com suporte a 1080p a 120hz.

Vale a pena?

Se você está disposto a esperar e encarar a cotação do dólar, super vale. Eu queria muito voltar a usar Linux para o trabalho e consegui encontrar um notebook que preza pela privacidade.

O único ponto negativo até agora foi o conector da tomada da fonte, que obviamente, veio no padrão americano, mas que por R$20 você compra um padrão brasileiro no Mercado Livre.

E eu acho que é isso, um post bem consumista 🤭 com as minhas impressões iniciais e com mais imagens e informações do que a thread que eu fiz quando ele chegou.