6. O NOVO NORMAL
Developers e engenheiros de
operações partilham
conhecimentos e trabalham em
conjunto no ciclo de vida do
produto
OPERAÇÕES
‣ Administradores de
sistemas;
‣ DBAs;
‣ Release managers;
‣ Segurança;
‣ Monitorização;
‣ Manter.
DEVELOPERS
‣ Recolher requisitos;
‣ Escrever código;
‣ Escrever testes
automáticos;
‣ Testes manuais;
‣ Refactor;
‣ Criar.
DEVOPS
A filosofia
7. DEVOPS
A filosofia
Prática que pressupõe a participação conjunta de engenheiros de
operações e de desenvolvimento no ciclo de vida de um produto
desde o design, passando pelo desenvolvimento, até ao processo
de produção e suporte.
9. INFRASTRUCTURE AS CODE
O impulso
Técnicas, práticas, e ferramentas de desenvolvimento de software
aplicadas à criação de infraestrutura reutilizável, fácil de manter,
extender, e testar.
Infraestrutura dinâmica
10. INFRAESTRUTURA DINÂMICA: DESAFIOS
Infrastructure as Code
‣ Expansão descontrolada de servidores;
‣ Desvio de configuração;
‣ Servidores “floco de neve”;
‣ Infraestrutura frágil;
‣ Medo de automação;
‣ Erosão.
11. OS PRINCÍPIOS
Infrastructure as Code
‣ Os sistemas são:
‣ Facilmente reproduzíveis;
‣ Descartáveis;
‣ Consistentes;
‣ Os processos podem ser repetidos;
‣ O design está sempre a mudar.
12. VANTAGENS
‣ Versionamento de infraestrutura;
‣ Automatização de processos;
‣ Infraestrutura e processos auto-
documentados;
‣ Testabilidade de processos e sistemas.
DESVANTAGENS
‣ Pode trazer mudanças disruptivas nos
processos;
‣ Exige standardização e descrição
exaustiva de processos antes da
execução;
‣ Configurações erradas são multiplicadas
por todas as máquinas;
‣ Marginaliza hotfixes.
TRADE-OFFS
Infrastructure as Code
15. DEPLOYMENT DE INFRAESTRUTURA
Infrastructure as Code
‣ Codificar a infraestrutura em que a aplicação corre:
‣ Servidores;
‣ Redes;
‣ Utilizadores;
‣ Segurança.
‣ Documentar;
‣ Repetir.
17. GESTÃO DE CONFIGURAÇÃO
Infrastructure as Code
‣ Transformar rapidamente um servidor:
‣ Instalar requisitos;
‣ Automatizar builds.
‣ Processo de instalação e configuração guardado como código:
‣ Fácil de reconfigurar;
‣ Evita problemas de dependências.
‣ Curar dores de deployment:
‣ Blue/green deployments;
‣ Rolling deployments.
Push Pull
Defende fortemente a automatização e a monitorização das várias fases do processo;
Ciclos de desenvolvimento mais pequenos e releases mais rápidas;
Este conceito surgiu em 2009 por um grupo de amigos/colegas que não sabiam bem como fazer a ponte estas duas equipas
tudo muito bonito, mas…. vamos por eng de operações a aprender programação e programadores a saber de operações?
É aqui que entra infraestrutura como código
Ou seja, criar e gerir infraestrutura (tanto a nível de componentes “físicos” como de configuração), através de código
Server sprawl: crescimento da infraestrutura mais rápido que aquilo que as equipas conseguem gerir;
Configuration drift: cada pessoa que mexe faz um tweekzinho que faz com que servidores que deviam ser semelhantes são diferentes;
Snowflake servers: Aqueles servidores que tratamos com muito cuidado, nem mexemos, porque não sabemos bem o que aquilo faz, o que precisa, e se mexermos, estragamos tudo;
Fraquile infrastructure: infraestrutura que se desfaz num piscar de olhos e não é facilmente consertável. É o problema do snow flake server em larga escala;
Automation fear: todas estas diferenças levam a medo de automação porque não sabem bem como vai correr;
Erosion: o problema que surge quando as coisas estão a correr há muito tempo. Mesmo que não queiramos, elas vão se alternado (kernel patches, os upgrades…)
Deve ser fácil e reliable reconstruir qualquer elemento da infraestrutura (sem fazer decisões significativas: versões, hostnames…)
Uma vez que são facilmente criado, são igualmente facilmente destruídos, alterados, recriados. A evolução do design de uma infraestrutura é assumido;
Sistemas com funções similares são similares;
Com o mesmo pedaço de configuração conseguimos ter exatamente a mesma infraestrutura recriada;
É assumido que o design das infra-estruturas está sempre a mudar. Deixamos de ter um elevado custo de design inicial para termos um design evolutivo que a infraestrutura consegue acompanhar
breve descrição
blue/green: temos ambientes exatamente iguais em ambiente de teste e em produção para termos a certeza que quando as coisas vão para produção estão a correr com deve ser
rolling deployments: fazer deployments em aos poucos e sem criar muita entropia no sistema
ansible:
playbooks (plays)
Usa ssh para se ligar a máquinas que estejam no inventor file -> seguro
o facto de ser agentless, faz com que nao escale tao facilmente, torna-se um pouco mais lento
chef:
cookboobk, recipe, knife
tres componentes: chef workstation, chef server, chef nodes (com chef client)
é pull based mas já tem suporte para push (chef solo)
bom para ter uma visão global e agregada do estado do cluster
puppet:
puppet manifests
configurações num servidor central: puppet master
puppet agents comunicam com o puppet master e enviam um relatório do seu estado
o puppet pode ser corrido periodicamente como uma espécie de cron
saltstack:
salt master e salt minion
na versão pull based, é usado um canal de comunicação de dados persistente e orientado a eventos
na verão push based, é usado ssh, como no ansible (salt agentless)
desapropriado para sistemas multi tenant porque os nos conseguem ver-se uns aos outros através da árvore de estado do sistema
não é muito bom em termos de segurança porque usa os seus próprios protocolos de segurança, em vez de protocolos bem estabelecidos, como TLS
- Deixar o ciclo vicioso do medo
Não boicotar a automação
Evolui para uma abordagem de devops, com infraestrutura automatizada, aos poucos, fazendo as coisas bem desde o início.
- usar iam por si so não implementa automatização nem uma cultura devops. é preciso escolher a ferramenta certa para o use case certo e estar com o mind set correto desde o inicio