Pular para o conteúdo principal

Podcast Sysadmin #02: GitOps - Operações por Pull Requests






Se um operador humano precisa estar em contato com seu sistema durante as operações normais, você tem um bug. 

A definição de normal muda a medida que a empresa cresce.


Se estamos aplicando a engenharia em processos e soluções que não sejam automatizáveis, continuaremos precisando contratar pessoas para dar manutenção no sistema. Se precisarmos contratar pessoas para fazer o trabalho, estaremos alimentando as maquinas com sangue, suor e lágrimas de seres humanos.



Problemas que não se resolvem com a IAAC (Infraestrutura como Código):


Segundo artigo do Dmitrii Evstiukhin da Provectus no site Dzone.com todas as abordagens para gerenciamento de configuração de infraestrutura possuem problemas.
E alguns não podem ser resolvidos pela IaaC. como por exemplo:

 

  •     Infra-estrutura implícita, seu estado e configuração. Às vezes, você precisa realizar uma investigação em grande escala para descobrir onde e como o aplicativo está sendo executado.

    

  •     Falta de histórico das mudanças. Pode ser ainda mais difícil descobrir como alguns aplicativos foram desenvolvidos em primeiro lugar e quem os gerencia agora.


  •     Falhas de segurança nos ambientes. Criados para facilitar o acesso do administrador às ferramentas de Entrega Contínua, esses buracos garantem a velocidade e a conveniência do desenvolvimento, mas colocam em risco os aplicativos e seus usuários.


  •     A dependência do sucesso das operações no estado anterior. Uma variável verdadeiramente imprevisível, que, no entanto, implica o sucesso de todo o projeto.


  •     Dificuldades de recuperação de desastres. Com processos manuais / semi-manuais, a recuperação de desastres requer uma estratégia, que nem sempre é o caso.



  •     Consistência eventual da configuração. Mesmo com o uso da configuração centralizada, a configuração real e a declarada podem derivar com operações manuais.




GitOps


"GitOps" é um termo originalmente criado pela Weaveworks em 2017 para definir o novo método de usar a ferramenta para conduzir operações.


GitOps em sua raiz é DevOps com IaaC, gerenciamento de configuração, integração continua e etc... mas com o git sendo o centro destas operações.Num ambiente padrão, tudo é desenvolvido em "manifestos", o push é feito enviando para o Git e a partir disto (com o pull request aprovado) há o deploy no ambiente.




É frequentemente associado à configuração do Kubernetes, porque o Kubernetes é usado em todos os lugares agora, e o GitOps é melhor para gerenciar a configuração do k8s.


Mas com o GitOps não há o kubectl nem scripts! (nem tanto rsrsss)


Usando o Git como nossa fonte de verdade (na verdade, o git é única fonte de verdade), podemos operar quase tudo.
Como por exemplo, controle de versão, histórico, revisão por pares e reversão acontecem no Git sem precisar mexer em ferramentas como o kubectl.


Todas as operações são feitas por requests (além de pipelines de compilação e delivery), ou seja, somente é usado automação baseada em push/pull.
As ferramentas Diff detectam qualquer divergência e nos notificam via alertas do Slack;
Ferramentas de sincronização permitem convergência
Logs de reversão e auditoria também são fornecidos via Git  


No caso do Kubernetes, usamos o controle de versão não apenas para o código, mas também para os arquivos YAML que definem as implantações, os serviços, os daemonets da Kubernetes, etc. Também usamos o Terraform e o Ansible para provisionar o Kubernetes no Amazon, e eles também são controlados por versão no Git.  



A abordagem não se limita a Kubernetes, ou Ansible e Terraform. 


O GitOps determina princípios de alto nível e não ferramentas em sí, se você quiser, poderá usar como gerenciamento de configuração, um sistema baseado todo em shell scripts (bash), como é o https://aviary.sh


Os quatro princípios principais:

  1. O sistema inteiro deve ser definido declarativamente.
  2. Versão de toda a definição de sistema no Git.
  3. Aplicar automaticamente alterações aprovadas à infraestrutura.
  4. Agentes de automação especiais garantem a convergência do sistema




Colocando na linguagem técnica: Antes de 2006, se você precisava de um LAMP (ambiente com Linux, Apache, MySQL e PHP) em funcionamento, era necessário fazer o SSH no servidor, instalar ou compilar pacotes, fazer todas as configurações no PHP, banco, servidor web, corrigir direitos de acesso e iniciar os serviços. 


Quando você precisava do segundo servidor, fazia o SSH novamente e precisava fazer o mesmo do zero, com novas versões de pacotes. 

Se você precisasse de 50 servidores, a quantidade de trabalho aumentaria em 50x.

Foi quando todos entenderam que algo precisava mudar e a abordagem Infraestrutura como Código se tornou popular.


Com o GitOps, passamos dos servidores para o estado desejado, além de contar com a automação para atingir esse estado.
Trabalhamos com a definição de infraestrutura no Git, em vez de scripts.


Depois de mesclada, a automação do GitOps cuidará de todas as configurações necessárias e garantirá que o aplicativo permaneça em funcionamento se algo der errado.


Lembre-se de que não nos importamos com o que exatamente a automação fará. Estamos em um nível totalmente novo de abstração agora.


O GitOps é um novo paradigma, um passo adicional na evolução da administração do sistema. Mudamos o foco das operações diárias da própria infraestrutura para sua representação no repositório Git.


Kubernetes se encaixa perfeitamente nesse novo paradigma. Por ser declarativo e com apenas uma etapa adicional - a instalação do agente GitOps - você pode implementar a abordagem GitOps para o Kubernetes.


O GitOps para Kubernetes é melhor começar a experimentar e se acostumar com a conveniência e a segurança do método. Em seguida, mudaremos todas as suas soluções de IaC para o GitOps.



Adoção


Obviamente, o GitOps não é a panacéia para todos os problemas de infraestrutura. Tem seus desafios.


O primeiro desafio que você enfrenta ao decidir adotar a abordagem GitOps é o número de decisões a serem tomadas. Como o GitOps introduz a mudança de foco e determina princípios de alto nível, você decide como gerenciar manifestos, dividir repositórios e implementar provisionamento e atualizações de ambiente.


Automação, em geral, é algo que você mesmo descobriu. Para o Kubernetes, você pode encontrar vários agentes do GitOps, como o ArgoCD ou o Weave Flux - duas soluções mais maduras.



O maior desafio da abordagem GitOps é a mudança cultural, no entanto.
O GitOps me lembra o DevOps, pois nos leva a mudar nossos hábitos, mentalidade e rotinas diárias de trabalho.


Essa mudança de foco é difícil de executar a princípio, pois todos os desenvolvedores e administradores de sistema estão acostumados a trabalhar diretamente com servidores.


E agora estamos dizendo a eles que tudo o que eles podem fazer é solicitar via Pull Request. Você não pode fazer o SSH no servidor e aplicar um hotfix ao aplicativo ou à sua configuração. Ou, deixe-me colocar desta maneira: você pode fazer isso, mas a automação o reverterá, mesmo assim, forçando você a seguir o processo.


Essa mentalidade começou a mudar quando tudo começou a ficar em contêiner com o Kubernetes. Como o aplicativo no contêiner é imutável, você não pode simplesmente corrigi-lo. Você precisa criar relações públicas e criar uma nova imagem.


Mas isso preocupava apenas desenvolvedores, os administradores de sistema ainda podiam interagir diretamente com o sistema e fazer alterações na configuração.


Agora, com a abordagem GitOps, se você quiser alterar alguma coisa - faça um pull request, mesmo se você for o administrador do sistema.


Essa mudança cultural é fundamental para a implementação do GitOps.


Exige muito esforço da equipe e ainda mais esforço de líderes e gerentes. 







Recompensas pelo esforço
Então, o que vamos conseguir por todo esse esforço?

Transparência.

    Com o GitOps, você obtém uma infraestrutura de auto-documentação e implantações auto-descritas. Você sempre sabe onde implantou algo. Você tem um histórico de alterações com seus autores gratuitamente.
    O estado da infraestrutura não é mais um conhecimento sagrado. Além disso, você pode criar plataformas de autoatendimento muito mais fáceis.




plataformas de autoatendimento

    rollback fáceis e recuperação de desastres. Se você tiver uma representação completa de sua infraestrutura, poderá recriar todo o sistema do zero em questão de minutos. E, se sua atualização mais recente não correu bem, a única coisa que você precisa fazer é "reverter o git".



Segurança aprimorada

    O GitOps melhora a segurança de várias maneiras diferentes. Altere a aplicação de fluxo e aprovações no nível do repositório Git. Você pode dividir e dividir o acesso da maneira que desejar, por diferentes estruturas de repositório.

 

Segurança do ambiente de tempo de execução

você não precisa passar o acesso de administrador do Kubernetes a nada fora do Kubernetes, porque o agente GitOps gerencia o cluster por dentro.



Precisão das operações.

    Sempre obtemos o que é descrito no Git. Não precisamos mais confiar no terceiro com o script.




Processo de integração mais rápido.

    Com toda a infraestrutura e configuração de aplicativos no Git, é muito mais fácil integrar novos membros da equipe. Com mensagens de confirmação adequadas, as novas contratações podem se familiarizar com as operações e processos diários muito mais rápido e fácil.




Quando começar a implementar a abordagem GitOps?
Depende. Talvez você tenha que começar a fazer isso ontem; por exemplo. se você já possui um cluster Kubernetes e não tem uma imagem clara do que e onde está implantado.


Como fazer isso? Fácil - são apenas duas etapas:

  1. Criar uma representação de infraestrutura no Git
  2. Comece a sincronizar automaticamente a infraestrutura com sua representação










Links:

https://www.gitops.tech/


https://github.com/fluxcd/flux


https://www.weave.works/blog/what-is-gitops-really


https://www.weave.works/blog/gitops-operations-by-pull-request


https://dzone.com/articles/the-why-and-when-of-gitops

 Musica de inicio: https://www.bensound.com


Postagens mais visitadas deste blog

TuxMath - Tux, do Comando da Matemática. Ensino e diversão a crianças.

Tux Of Math Command, (Tux, do Comando da Matemática, em sátira ao desenho animado, Buzz Lightyear, do Comando Estelar) ou simplesmente TuxMath é um game open source, no estilo arcade, originalmente desenvolvido para linux, mas atualmente é multiplataforma, disponível em Windows, Mac, BeOS, web, dispositivos móveis...

Melhor desempenho da memória RAM e SWAP no Linux

Melhor desempenho da RAM/SWAP Objetivo: Determinar através do kernel (sysctl) quando o sistema deverá utilizar a memória swap. Com isto, o linux vai usar mais a memória RAM e dar prioridade a ela, ao invés de levar isto para o HD (swap) e deixar alguns processos mais demorados. Por padrão, o valor de swappiness no debian é 60. Ou seja, usará o swap quando a RAM estiver em torno de 40% a 50% em uso. Verificar valor padrão: # cat /proc/sys/vm/swappiness Reduzindo o valor de swappiness para 10 ou 15 (neste exemplo, reduzi para 5), o arquivo de swap será usado apenas quando o uso da RAM chegar em torno de 80 a 90 por cento. Edite: # vim /etc/sysctl.conf Altere (adicione se não existir a linha) no arquivo: # vm.swappiness = 5 (Há quem coloque 0 ou 1, mas prefiro assim) Para evitar a necessidade de reiniciar o sistema, execute: # sysctl vm.swappiness=5 depois, apenas como verificação, execute: # swapoff -a # swapon -a # sysctl -p /etc/sysctl.conf

Tipos de VPNs: PPTP x OpenVPN x L2TP/IPsec x SSTP x IKEv2 x Chameleon x WireGuard

Olá, Baseando-me no formato do artigo sobre Certificados e a sopa de letras: HTTPS, TLS, SSL, HSTS, CA, PGP, GPG e OpenPGP , com o artigo sobre o WireGuard  e a atual crise mundial que forçou muitos em quarentena a trabalhar remotamente, resolvi fazer um semelhante abordando os diferentes tipos de VPN. O principal problema é que ao ler a documentação e artigos atuais, além de longos eles se prolongam muito no detalhe técnico entre elas, então tentei criar um TL;DR (que ficou um pouco grande, mas bem resumido). Uma VPN, ou rede virtual privada, permite criar uma conexão segura entre duas redes ou entre seu dispositivo/host com alguma rede, usando a internet como meio, como túnel para chegar ao destino. As VPNs podem ser usadas para acessar sites restritos por região (países proíbem torrents, outros proíbem redes sociais, sites de noticias...), proteger sua navegação (em redes não confiáveis como hotéis, wifi de lojas, etc...), acessar um sistema corporativo que está instalado e disponív

DHCP - Guia Completo

atualizado em 18/03/2015 Olá a todos, disponibilizo mais um guia ;-) Apesar de um assunto bem fácil, sem segredos ou mistérios, o tema deste guia é DHCP Servers. Nele, abordo o que é o dhcp, como funciona e como configurar. A novidade neste guia é que mostro como realizar a configuração de um servidor DHCP usando roteadores "home / small office", como os famosos d-link, encore, tenda, pacific, tp-link, etc... Como criar um servidor dhcp usando equipamentos Cisco, como habilitar o DHCP Server usando a plataforma Windows (Windows Server 2003), e finalmente usando o GNU/Linux. Claro que meu foco é favorecer o uso do Linux para prover este serviço, para isto, mostro desde a configuração mais simples, até algumas avançadas, tanto em modo texto quanto as mais variadas interfaces gráficas existentes no S.O. para configurar e monitorar este simples serviço de rede. No GNU/Linux, abordo o DHCP Server mais utilizado no mundo (da ISC), as configurações mais utilizadas, o c

SSD no linux

Mitos e verdades do SSD no Linux - Instalando, configurando e otimizando SSD no Linux SSD são suportados no Linux desde o kernel 2.6.29. Schedulers e File Systems também suportam os 'discos sólidos' ou 'não-rotacionais' (SSDs) há um bom tempo. A maioria dos artigos que existem na internet são bem antigos e não refletem os ambientes atuais dos sistemas Linux. Este artigo trás alguns macetes para otimizar o SSD num ambiente onde o sistema operacional estará instalado nele. Tiro alguns mitos de que seria necessário mudanças bruscas no sistema para que o SSD seja bem aproveitado (hoje, basicamente no uso do dia-a-dia, nada é preciso após instala-lo) apenas alguns pontos a serem observados.

Teste de Performance de Rede com Iperf

Troubleshooting,  Throughput,  testes de  conectividade e transmissão de pacotes em rede com Software Livre/Open Source Sumário Base de Conhecimento Rede Local e o tráfego de informações O que é Possíveis situações de uso O Básico - Executando como Server No Windows No GNU/Linux O Básico – o Cliente No Windows No Linux Utilizando UDP Argumentando... Mais Opções Opções gerais -f, --format -i, --interval n -l, --len N -m, --print_mss -o, --output <arquivo> -p, --port n -u, --udp -x, --reportexclude -y, --reportstyle C -w, --window n -B, --bind <host> -M, --mss n -N, --nodelay -V, --IPv6Version Opções para o cliente -P , --parallel -T, --ttl -n, --num -t, --time -d, --dualtest -r, --tradeoff -L, --listenport -b, --bandwidth -F, --fileinput <name> -I, --stdin Opções para o Servidor -s, --server -U, --single_udp -D, --daemon Interface Gráfica em JAVA Conclusão Minha rede está lenta, e agora?? Download e Links Base de Conhecimento O TCP é o protocolo

Colorindo o terminal do Linux

Abaixo, 3 dicas simples para colorir o Linux: Deixar o terminal (bash) colorido; Deixar o vim e o nano colorido; Deixar as manpages coloridas; No bash facilita a identificação de tipos de arquivos, diretórios e permissões (pois cada um terá uma cor diferente). Nos editores de texto, (neste caso o Nano e VIm), as cores facilitam ao criar scripts e programas nas mais variadas linguagens, os esquemas de cores, identificam a sintax da linguagem e colorem de acordo com os comandos, por exemplo, uma cor diferente para scripts entre aspas, comentários, cores diferentes para variáveis, etc... E a melhor de todas as dicas: colorir as manpages! Parece que não, mas facilita muito a vida quando você olha as manpags e enxerga facilmente as flags e opções de cada comando, exemplos e distingui a descrição da opção do comando. Colorindo o Bash Coloque no final do arquivo .bashrc (ele é um arquivo oculto que está dentro do seu /home), é o arquivo de configuração do bash de cada usuário.  

Protocolo RIP - Lab com passo-a-passo em roteadores Cisco

O RIP ou Routing Information Protocol é um protocolo aberto, definido na RFC 1058, e classificado como vetor de distância. As diferenças básicas entre o RIP versão 1 e versão 2 é que o primeiro é classfull, ou seja, suporta apenas classes cheias (A, B ou C) ou subrede com a mesma máscara e troca atualizações de roteamento via broadcast. Já a versão 2 suporta CIDR (classless) e VLSM (divisão de subredes com várias máscaras de subrede), além disso, troca informações através de multicast no endereço 224.0.0.9. Ambas as versões trocam informações utilizando UDP na porta 520. Para IPv6 (versão 6 do protocolo IP) o RIP passa a chamar RIPng (Next Generation) e funciona basicamente da mesma maneira que o RIP versão 2 para IPv4, porém enviando updates no endereço IPv6 de multicast FF02::9. Para configurar o RIP versão 1 basta ativar o protocolo com o comando “router rip”, depois em modo de configuração do roteador definir as redes que serão anunciadas com o comando “network”. No comando

Aula #5 - A estrutura da árvore do Sistema de Arquivos Linux

Existem vários tipos de arquivos presentes em um sistema Linux.  Eles diferem em propósito, tamanho, dono, nível de compartilhamento e volatilidade.  O resultado é uma organização coerente de toda a árvore do sistema de arquivos que é padrão(na medida do possível) entre as distribuições Linux.

Aula #14 - Os sistemas de arquivos ext2/ext3/ext4

  A família de sistemas de arquivos ext tem sido nativa para o Linux desde os seus primeiros dias, e tem sido a mais utilizada. Até recentemente, o ext4 foi a escolha padrão mais comum das distribuições Linux, devido à sua excelente combinação de desempenho, integridade e estabilidade.