DEV Community: Rodrigo Ferraz

GitOps com Flux v2 - Parte 1 - O que é GitOps e quem é Flux?

Rodrigo Ferraz — Sat, 01 Jan 2022 12:01:39 +0000

O que é GitOps?

GitOps é um termo que foi criado pela WeaveWorks em 2017 (sim, aquela do plugin de rede para Kubernetes o Weave Net) para descrever, nas palavras da própria WeaveWorks:

“Um modelo operacional para infraestrutura como código, que fornece um conjunto de práticas recomendadas que unificam a implantação, o gerenciamento e o monitoramento de aplicativos em contêineres.

Um caminho para uma experiência de desenvolvimento para gerenciar aplicativos; onde pipelines CI/CD ponta a ponta e fluxos de trabalho Git são aplicados a operações e desenvolvimento.”

Básicamente aqui a coisa toda significa que é uma forma de você usar Infraestrutura como código não só para a sua arquitetura mas também para o seu deployment.

Isso trás muitas vantagens, como padronização, facilidade de replicação, compartilhamento, etc. Tudo isso ainda aplicado ao Git nos permite ter uma única fonte de verdade para todos os nossos códigos além da facilidade de acompanhar a evolução do repositório hostóricamente atráves de cada commit.

Dito isso chegamos então ao cara que visa implementar essa idéia para facilitar nosso dia a dia.

Se você entender um pouco de inglês pode conferir o artigo da própria WeaveWorks sobre GitOps na íntegra aqui

E aqui temos as definições de GitOps.

Flux

O Flux é uma ferramenta criada também pela WeaveWorks no intuito de fazer a idéia do GitOps ser implementada na comunidade, ela o descreve como:

“Uma ferramenta para manter clusters Kubernetes sincronizados com a origem de suas configurações(como repositórios Git) e automatizar atualizações de configuração quando há um novo código para implantar.”

Ou seja, o Flux nos permite usar uma única fonte de verdade(o repositório Git) para nosso cluster kubernetes.

De maneira simplória o Flux age como uma espécie de mediador entre nosso cluster Kubernetes e nosso repositório Git, ele olha para nosso repositório Git pega os manifestos do Kubernetes e verifica se estão aplicados em nosso cluster, caso não estejam, ele automaticamente aplica esses manifestos no cluster e caso hajam alterações pendentes ele também as aplica.

Tudo isso agiliza muito o desenvolvimento pois tenho um "Cluster como código" pronto pra ser replicado pra um ambiente de staging, dev ou prod. Posso fazer o rollback do meu commit com um simplesgit revert caso algo dê errado, num piscar de olhos, o código aplicado ao cluster sempre será o disponível no Git(esse é o comportamento padrão) assim não temos aquela história de "ahh eu já apliquei a alteração no cluster mas não subi pro Git ainda", entre outras coisas.

Somado à tudo isso vem a facilidade de implementação que só precisa da instalação de um binário de linha de comando e pronto, você já pode começar a usar o Flux.

Outra coisa super interssante é que o Flux é um projeto incubado pelo CNCF onde temos outros grandes nomes como o próprio Kubernetes, Helm, Prometheus, e por ai vai. Então pode ficar tranquilo que não é qualquer programa de fundo de boteco que você vai utilizar é uma ferramenta em constante desenvovimento, com uma grande empresa por trás, uma comunidade super ativa e um futuro bem promissor.

Documentação do Flux: https://fluxcd.io/docs/
GitHub: https://github.com/fluxcd/flux2#flux-version-2
Apresentação detalhada(inglês): https://www.youtube.com/watch?v=nGLpUCPX8JE

Curtiu o Flux e a idéia de usar GitOps até nos seus projetos particulares?
Então fica atento pras próximas postagens! Valeu!

Branches e Repositórios Remotos- Parte 3

Rodrigo Ferraz — Sun, 20 Jun 2021 11:41:34 +0000

Finalmente chegou a hora de falarmos de Branches e Repositórios. Se você não acompanhou as outras postagens da série, é bom que as leia antes de começar essa aqui, por fim, vamos lá.

Branches

Entenda branches como uma linha de desenvolvimento independente. Algo similar à você ter um modelo de Slide para apresentações, fazer uma cópia dele, e começar a fazer suas alterações nessa cópia.
Ok...mas quais as vantagens disso? Muitas. Se por acaso as alterações que você fizer ficarem ruins, ou não estiverem do gosto que você esperava? Caso tenha feito a cópia pode excluir e começar daquele slide modelo novamente, caso contrário, lamento muito. Dito isso acho que ficou claro que as branches criam "cópias" de uma linha de desenvolvimento, para uma outra linha, onde você possa trabalhar em novas features, corrigir problemas, alterar algum campo, sem causar danos no código principal. Agora chega de lenga lenga e vamos è mão na massa.

Primeiro de tudo, pra ficar mais visual essa história de branch, vou usar o site learn-git pra gente testar os comandos.

Como crio a branch?

git branch branch-1

Lá no learn-git vai aparecer assim:

Repare no * ao lado da branch main(mais comumente chamada de "master"), isso quer dizer que aquela é sua HEAD(guarde essa palavra na mente pois é ela que aparece no terminal) que nada mais é do que a branch na qual você esta fazendo suas alterações no momento. Vamos fazer um commit na branch main:

git commit -m "commit branch main"

Se ainda ficou um pouco complexo entender as branches pense nelas também como "pastas" com cópias dos arquivos de uma pasta principal, na qual você vai adicionando novos arquivos e fazendo alterações, cada alteração salva é o equivalente à um commit. No momento, só criamos a branch, ou seja, uma "cópia" identica à da pasta principal, então do ponto de vista do Git, elas estão "no mesmo ponto", com os mesmos arquivos e conteúdos.

E agora nossa imagem ficou assim:

Visualmente fica claro que os commits estão sendo gerados na branch main, a cada commit uma snapshot é tirada e nossa branch avança. Agora vamos mudar pra branch-1 e fazer um commit nela, o comando pra mudar é:

git checkout branch-1

E o comando que fiz pra gerar o commit foi o:

git commit -m "commit branch-1"

Feito isso nossas duas linhas de desenvolvimento agora ficam bem visuais.

Ai você pode brincar e ir criando commits e branches e ver como funciona visualmente, esse site é ótimo pra entender esses conceitos.

Um último comando que na verdade é um atalho para criar a branch e já utilizá-la é o:

git checkout -b branch-2

Repositórios

Algumas das vantagens de usar o git como um repositório distribuído ao invés de um centralizado são:

Segurança em caso de perda de dados. Já que geralmente os dados ficam em um servidor que não seja sua máquina os dados ficam menos suscetíveis a se perderem, ainda mais se estiverem em algum serviço de nuvem como Github, Gitlab, etc;
É menos burocrático. Você pode criar branches, commits e merges sem acessar o repositório remoto;
Permite à você colaborar com desenvolvedores remotos sem a necessidade de alterar o repositório principal(fazendo um fork, por exemplo).

Bom, um repositório remoto é o que o próprio nome diz (dãaaaar rsrs), é uma cópia do seu código em outra máquina ou serviço. Nos casos mais comuns é no Github, então vamos enviar nosso repositório local para ele.

Primeiro, obviamente faça uma conta no Github. Feito isso vamos já criar nosso primeiro repositório no Github clicando em "New", lá no canto esquerdo em verde.

Agora temos alguns pontos para preencher:

O nome do repositório;
Uma descrição(opcional);
Visibilidade - Pública ou Privada;
Arquivos que você quer adicionar já na criação do seu repositório;

Dê um nome ao seu repositório, deixe-o como Público e vamos adiante. Você já deve estar vendo uma tela igual à abaixo, com os comandos necessários para inserir esse repositório remoto na sua máquina.

Eu vou usar os 3 comandos da parte debaixo da imagem, respectivamente o que eles fazem é:

Adicionar o repositório remoto do Github ao nosso git com o apelido de "origin";
Renomear nossa branch master para main(pra isso serve o -M);
Enviar nossos arquivos do nosso repositório LOCAL e branch ATUAL(no caso a main) para o repositório REMOTO(que apelidamos de origin) na branch também de nome main e "rastrear"(opção -u) as mudanças que ocorrerem na branch remota.

Essa última linha é importante pois cria um relacionamento entre nossa branch main local e a main remota(Github), assim, nosso git conseguirá nos dizer caso exista alguma mudança lá que ainda não foi aplicada aqui. Veremos isso em outro post.

No nosso terminal(Git Bash, no meu caso), dentro da pasta do nosso projeto, vamos copiar e colar nossos comandos.

Aqui pode ser que seja solicitado à você fazer login no Github.

Por fim basta voltar na tela do nosso repositório no github e dar um F5 ou atualizar a página que nosso commit já vai aparcer lá!

Fim de mais uma parte, logo mais vem as outras!

Repositório e Commit - Parte 2

Rodrigo Ferraz — Wed, 16 Jun 2021 13:03:10 +0000

Essa segunda parte vai guiar você à como iniciar um repositório no Git e fazer seu primerio commit, além de te mostrar como verificar o status dos arquivos, adicionar e remover arquivos do Staging, conforme conversamos na parte 1.

Instalando Git

Antes de mais nada acesse a página do Git aqui e instale o Git conforme seu sistema operacional.

Se você estiver usando o Windows recomendo utilizar o Git Bash para fazer os comandos, pois irei usar comandos que funcionam apenas no terminal Linux e o Git Bash nos dá essa facilidade.

Feito isso basta digitar o comando abaixo:

git --help

E o retorno deve ser algo parecido com isso:

Criando nosso primeiro Repositório

Com o Git instalado agora vamos criar nosso repositório. Crie uma pasta como nome que você preferir(no meu caso será primeiro-repo), acesse ela e digite o comando abaixo:

ls -la

O nosso retorno deve ser dois diretórios, . e .. que no Linux arremetem à respectivamente o diretório atual e ao diretório anterior(apenas para fins de curiosidade).

Resumindo, não há nada em nossa pasta recém criada. Agora vamos criar nosso repositório.

git init

No meu caso, como estou usando o Git Bash eu tive o seguinte retorno:

Repare no master que aparece em azul no fim da linha, ele quer dizer básicamente que nosso repositório foi iniciado e que estamos na branch master. Falaremos sobre branches mais adiante, mas é nosso ramo principal de desenvolvimento no momento.

Outro ponto à se observar é que ao executar o comando ls -la novamente agora tenho uma pasta .git(no Linux, pastas que começam com . são pastas ocultas), nessa pasta é onde ficarão as informações do nosso repositório e por sua vez a pasta que criamos (primeiro-repo) é o nosso Working-Directory.

Agora com o comando abaixo consigo visualizar as alterações que ocorreram no meu repositório.

git status

Como não temos nada obtemos um retorno de que não há nenhum commit nem nada à commitar.

Agora vamos criar um arquivo sem nada dentro

e por fim vamos verificar o que o nosso git status tem à dizer

Aqui o git já nos informa que temos um arquivo não rastreado, que nada mais é que um arquivo que não esta na nossa àrea de Staging (caso não se lembre, olhe aqui), e aqui já temos uma dica de qual comando usar para adicioná-lo

git add teste.txt
```



Feito isso, eu já rodei um `git status` novamente para ver a situação atual do nosso repositório e seus arquivos
![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6ljq0x62ghwgkqtv2b0h.png)

Já podemos ver que o arquivo está na *Staging area* e será incluido no próximo commit, e caso queira removê-lo basta usar `git rm --cached teste.txt`

Antes de criarmos nosso commit temos um ultimo passo que é configurar o git com as informações de usuário, caso contrário, num cenário onde várias pessoas estão alterando o mesmo arquivo de código, nós nunca saberiamos *quem* fez determinada alteração. Para isso é bem simples basta usar os dois comandos à seguir:


```
 git config --global user.email "seu@email.com"
 git config --global user.name "Seu Nome"
```


Como o comando esta com o parâmetro `--global` informado, essas configurações definirão usuário e email para **TODOS** os repositórios que você criar daqui pra frente, assim você não precisa ficar inserindo isso a cada novo repositório criado, mas caso você queira fazer isso para cada um, basta omitir o `--global`.

Agora finalmente vamos criar nosso primeiro commit, o parâmetro `-m` abaixo serve para informarmos uma mensagem de commit, isso nos ajuda a entender porque aquele commit foi feito:


```
git commit -m "Primeiro commit"
```


![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6qkj2rbftdr1edwamlxf.png)

Sucesso! Aqui vemos as informações de em qual branch foi feito o commit(master), se foi o primeiro commit do repositório vemos `(root-commit)` e o identificador resumido do commit `ea0434b`. Por fim para ver mais detalhes do seu commit(como autor, hora, etc) use o comando abaixo. Já deixo algumas outras maneiras de visualizar informações de log dos commits como bonus também, e um [site](https://devhints.io/git-log) com diversas outras formas.


```
git log
```



![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0kjqkioe7uy7so7dgv6q.png)

Resumidamente o que fizemos aqui galera, foi inicializar um repositório(Working Directory), criar um novo arquivo e adicioná-lo ao próximo commit(Staging) e de fato salvar nossas alterações, ou como falamos "*commitar*" as alterações no nosso repositório.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/i47r9nhhttt83cb7g0i2.gif)

Por hora é isso, espero que tenham gostado!

Arquitetura e Estados -Parte 1

Rodrigo Ferraz — Mon, 14 Jun 2021 18:50:31 +0000

Antes de mais nada, todo esse guia é baseado no livro "Pro Git"(incluindo a fonte das imagens) que pode ser baixado na versão PDF aqui e na versão EPUB aqui. O livro é GRATUITO, então se você sabe inglês e quer se aprofundar mais esse é o caminho.

Arquitetura e Funcionamento

O Git é um VCS(Version Control System) utilizado amplamente para o processo de desenvolvimento de software. As ferramentas VCS registram as mudanças em um conjunto de arquivos e são responsáveis principalmente pela edição de arquivos por mais de uma pessoa "ao mesmo tempo", além disso também vem com ferramentas para resolver conflitos de versões e outras mais.

De maneira bem simplória o Git é uma espécie de Google Drive com versionamento. Diferente de outros VCS de mercado o Git trabalha com o arquivo completo para cada versão diferente criada ao longo do tempo, já os outros trabalham salvando apenas as alterações(também chamada de delta) dos arquivos alterados.

VCS que usam o delta:

Git:

Sempre que um commit(ou "Salvamento do estado", bem feio rsrs) do projeto é feito o Git cria uma snapshot do estado atual de todos os arquivos e grava uma referência desse estado(uma espécie de ID). Se um arquivo tem uma alteração, a cópia é feita, senão, ele não grava novamente o arquivo, ele simplesmente faz uma referência(link) para o arquivo do commit anterior.

Estado dos arquivos

O ciclo de vida dos arquivos no Git são 3:

Modified - Os arquivos foram alterados mas as mudanças não foram confirmadas;
Staged - Mudanças foram confirmadas para estar no próximo commit;
Commited - Dados estão salvos na base local.

Outro ponto importante são as seções de um projeto:

Working Directory - Representa uma versão das muitas que um projeto pode ter. Os arquivos são descompactados da base de dados do Git e são colocados no disco para você usar;
Staging Area - É simplesmente um arquivo dentro do diretório do Git que contém as informações de modificações que serão incluídas no próximo commit, uma espécie de índice;
Repository/Git Directory - Local onde o Git guarda os metadados e base do projeto. Essa é a parte mais importante e é o que é copiado quando clonamos um repositório.

Basicamente o Workflow fica assim(observando a imagem acima):

Você esta no seu Working tree e faz alterações em alguns arquivos do seu código;
Você escolhe quais dessas mudanças farão parte do commit e adiciona elas a Staging Area;
Você faz o commit, que tira uma snapshot dos arquivos da maneira que eles estão na sua Staging Area e os armazena permanentemente ao seu Git Directory.

Depois disso o fluxo se reinicia, com você fazendo novas alterações, escolhendo quais vai commitar e de fato fazendo o commit.

Por enquanto é isso nos vemos na próxima!

Aplicação para testes diversos

Rodrigo Ferraz — Sat, 29 May 2021 12:01:27 +0000

As Aplicações abaixo foram desenvolvidas apenas para labs que eu faço em arquiteturas de cloud de forma a testar a comunicação entre zonas de disponibilidades, AutoScaling, deploy com Terraform, etc. Ela será utilizada em uma série de postagens onde vou fazer o deploy dessa aplicação tanto na AWS como no Azure de várias maneiras diferentes, com Ec2, Fargate, EKS e na Azure com os equivalentes.

As aplicações de teste

Bom, as aplicações são simples, elas foram escritas em Python e PHP das quais a que eu realmente entendo é a de Python, mas se você não sabe nada sobre nenhuma dessas linguagens, não tem problema, elas foram feitas com base nos exemplos que tem no próprio site.
Basicamente o APP PHP faz um GET na APP Python que por sua vez conecta no container com o banco Redis e incrementa com +1 a variável API_COUNTER. Para ficar mais visual fiz a imagem abaixo:

O Git para download do código está aqui

APP Python

A única coisa que usei de diferente aqui foi a biblioteca do redis para fazer a conexão com ele e o Flask como framework pra rodar a aplicação. Apenas para fins de curiosidade essa aplicação foi feita com base nesse link.

Porta em que a aplicação roda = 9090
Variáveis de ambiente:
- FLASK_APP = app.py
- REDIS_URL = redis://redis:6379/0

APP PHP

Aqui temos uma aplicação bem simples também usando o Guzzlehttp para subir o servidor web e fazer as requisições para o endpoint da APP Python, a aplicação foi baseada no Quickstart do Guzzle.

Porta em que a aplicação roda = 8080
Variáveis de Ambiente:
- PY_APP_URL = http://python:9090

Subindo o Ambiente para testes

Caso você queira experimentar essa aplicação em sua máquina é totalmente possível, desde que você tenha o Docker devidamente instalado no seu ambiente como também o Docker Composer.

Para subir o ambiente basta clonar este repositório do meu Github, acessar a pasta raiz dele e rodar os comandos abaixo.

Para buildar as imagens, instalar dependencias e fazer toda a parafernalha do Docker:

make build

E para subir o ambiente:

make up

Para acessar as aplicações basta testar acessando pelo seu navegador e deve ver algo como nas imagens abaixo:
Aplicação Python:

Aplicação PHP:

Em breve teremos o Deploy na AWS!