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