Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Infraestrutura como código

753 views

Published on

Nesse talk falo sobre gerenciamento de infra, arquitetura de cloud e infra ágil. A ideia é propor uma discussão sobre uso de ferramentas e processos.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Infraestrutura como código

  1. 1. Infraestrutura como código
  2. 2. Whoami ● DevOps na Rivendel Tecnologia ● Formado em ADS pela Fatec Zona Sul (2016) ● ITIL® Foundation Certificate in IT Service Management ● Áreas de interesse: ○ Cultura DevOps ○ Cloud ○ Entrega Contínua ○ Automação
  3. 3. Agenda ● Building on the cloud ● Infraestrutura como código ● Boas práticas ● Gerenciamento de Infraestrutura ● Ferramentas ● Sugestão de Ferramentas por camada ● Off Topic ● Perguntas
  4. 4. Building on the cloud ● Visível ● Volátil ● Persistente https://www.thoughtworks.com/insights/blog/layering-cloud
  5. 5. Camada Visível ● Camada entre a cloud e o resto do mundo. ● DNS, Load Balance, VPN, VPC. ● Estática e Consistente. ● Dificilmente muda. https://www.thoughtworks.com/insights/blog/layering-cloud
  6. 6. Camada Volátil ● Servidores de aplicação ● Mudanças ● Habilidade de reconstrução sem perda de dados https://www.thoughtworks.com/insights/blog/layering-cloud
  7. 7. Camada Persistente ● Backup e Restore ● Redundância ● Estado Imutável https://www.thoughtworks.com/insights/blog/layering-cloud
  8. 8. https://www.thoughtworks.com/insights/blog/moving-to-phoenix-server-pattern-things-to-consider PERSISTENT LAYER
  9. 9. O que é Infraestrutura como código?
  10. 10. Infrastructure as Code “Infrastructure as Code is using development practices and tools to manage infrastructure.”
  11. 11. Boas práticas ● Controle de versão ● Pensar em reúso ● Versionamento semântico ● Testes ● CI/CD
  12. 12. module "instance" { source = "git::ssh://git@git.repo.io/devops/instance.git?v1.0" } module "rds" { source = "git::ssh://git@git.repo.io/devops/rds.git?v1.2" } module "route53" { source = "git::ssh://git@git.repo.io/devops/route53.git?v1.1" }
  13. 13. - src: git::ssh://git@git.repo.io/devops/ansible-role-httpd.git scm: git version: v2.0 - src: git::ssh://git@git.repo.io/devops/ansible-role-zabbix-agent.git scm: git version: v2.3
  14. 14. def test_httpd_package(Package): httpd = Package('httpd') assert httpd.is_installed def test_zabbix_package(Package): zabbix = Package('zabbix-agent') assert zabbix.is_installed
  15. 15. node (docker) { stage ('INFO: Checkout code') { checkout scm } stage ('Creating Containers') { sh 'molecule create' } stage ('Installing the Role') { sh 'molecule converge' } stage ('Idempotence check') { sh 'molecule idempotence' } stage ('Verify the application') { sh 'molecule verify' } stage ('Destroy the containers') { sh 'molecule destroy' } }
  16. 16. Gerenciamento de Infraestrutura ● Manual ● Sincronizado ● Imutável
  17. 17. Gerenciamento Manual “Abordagem tradicional pré-automação (faça login em um servidor, edite arquivos, instale pacotes e crie contas de usuário), esta ainda é uma abordagem bastante comum mesmo para pessoas que usam ferramentas de automação como Ansible, Chef e Puppet. As pessoas escrevem ou modificam uma definição de configuração e, em seguida, as executam manualmente. Eles não executam a ferramenta de configuração, a menos que tenham uma mudança específica que desejam fazer.” http://infrastructure-as-code.com/book/2016/05/24/models-for-server-updates.html
  18. 18. https://www.slideshare.net/linux.rafa/precisamos-falar-sobre-testes-de-infraestrutura
  19. 19. ● “Simples” ● Pouca Visibilidade ● Baixa Confiança ● Caro Pros Contras
  20. 20. Gerenciamento Sincronizado “Aplica-se repetidamente as definições de configuração aos servidores. Isso acontece em todos os servidores, independentemente de terem sido feitas quaisquer alterações nas definições. Fazer isso garante que as alterações feitas fora da automação sejam trazidas de acordo com as definições. Isso desencoraja as mudanças manuais. Também garante que cada servidor esteja atualizado, tendo tido todas as definições de configuração atuais aplicadas.” http://infrastructure-as-code.com/book/2016/05/24/models-for-server-updates.html
  21. 21. https://www.slideshare.net/linux.rafa/precisamos-falar-sobre-testes-de-infraestrutura
  22. 22. ● Sem mudanças manuais ● Infra como código ● Testes ● Automation Fear Spiral ● Snowflake Servers ● Erosion-resistence Pros Contras
  23. 23. Gerenciamento Imutável “As equipes que utilizam infraestrutura imutável fazem alterações de configuração substituindo completamente os servidores. Uma mudança é feita construindo uma nova versão de um modelo de servidor (como um AMI) e, em seguida, reconstruindo qualquer servidor baseados nesse modelo específico. Isso aumenta a previsibilidade, uma vez que há pouca variação entre servidores testados e servidores em produção.” http://infrastructure-as-code.com/book/2016/05/24/models-for-server-updates.html
  24. 24. https://martinfowler.com/bliki/ImmutableServer.html
  25. 25. ● Estado conhecido e testado ● S.O atualizado e seguro ● Confiança ● Processos maduros ● Ferramentas para gerar templates ● 12 factor app Ganhos Desafios
  26. 26. FERRAMENTAS
  27. 27. Persistent Layer
  28. 28. Off Topic ● https://github.com/metacloud/molecule ● https://github.com/aelsabbahy/goss ● https://www.spinnaker.io/ ● https://medium.com/@kief/https-medium-com-kief-using-pipelin es-to-manage-environments-with-infrastructure-as-code-b3728 5a1cbf5
  29. 29. Perguntas
  30. 30. Especialistas em Cloud Computing / DevOps

×