INFRASTRUCTURE AS CODE
Impulsionar DevOpsDiana Martins - dsm@eurotux.com
MOVING BUSINESS FORWARDwww.eurotux.com
INFRASTRUCTURE AS CODE
Impulsionar DevOps
Diana Martins - dsm@eurotux.com
AGENDA
Infrastructure as Code
2
3
4
5
1 DEVOPS: A FILOSOFIA
INFRASTRUCTURE AS CODE
OS DESAFIOS
OS PRINCÍPIOS
TRADE-OFFS
FERRAMENTAS
O QUE PRECISAMOS?
6
7
DEVOPS
A filosofia
DEVOPS
A filosofia
Digite para introduzir uma legenda.
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
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.
INFRASTRUCTURE AS CODE
O impulso
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
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.
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.
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
INFRASTRUCTURE AS CODE
As ferramentas
INFRASTRUCTURE AS CODE
O impulso
Deployment de
infraestrutura
Gestão de
configuração
DEPLOYMENT DE INFRAESTRUTURA
Infrastructure as Code
‣ Codificar a infraestrutura em que a aplicação corre:
‣ Servidores;
‣ Redes;
‣ Utilizadores;
‣ Segurança.
‣ Documentar;
‣ Repetir.
DEPLOYMENT DE INFRAESTRUTURA
Ferramentas
Azure Resource Manager
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
PUSH PULL
GESTÃO DE CONFIGURAÇÃO
Ferramentas
O QUE PRECISAMOS?
PERDER O MEDO!
eurotux.com
linkedin.com/company/eurotux-sa
facebook.com/eurotux
twitter.com/eurotux
youtube.com/eurotuxsa
Portugal
Rua Irmãs Missionárias do Espírito Santo, 27
- 4715-340 Braga, Portugal
info@eurotux.com
+351 253 680 300
Moçambique
Avenida 24 de Julho n.º 2041, 1º andar
Maputo - Moçambique
info@eurotux.co.mz
+258 21 420 687
Questões?
Diana Martins
dsm@eurotux.com

DevOps Braga #4: Infrastructure as Code: Impulsionar DevOps

Notas do Editor

  • #8 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
  • #10 Ou seja, criar e gerir infraestrutura (tanto a nível de componentes “físicos” como de configuração), através de código
  • #11 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…)
  • #12 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
  • #15 breve descrição
  • #18 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
  • #19 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
  • #21 - 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