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.

1. Infraestrutura como código

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. 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. Building on the cloud
● Visível
● Volátil
● Persistente
https://www.thoughtworks.com/insights/blog/layering-cloud

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. 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. Camada Persistente
● Backup e Restore
● Redundância
● Estado Imutável
https://www.thoughtworks.com/insights/blog/layering-cloud

8. https://www.thoughtworks.com/insights/blog/moving-to-phoenix-server-pattern-things-to-consider
PERSISTENT LAYER

9. O que é Infraestrutura como código?

10. Infrastructure as Code
“Infrastructure as Code is using development practices and
tools to manage infrastructure.”

11. Boas práticas
● Controle de versão
● Pensar em reúso
● Versionamento semântico
● Testes
● CI/CD

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. - 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. 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. 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. Gerenciamento de Infraestrutura
● Manual
● Sincronizado
● Imutável

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. https://www.slideshare.net/linux.rafa/precisamos-falar-sobre-testes-de-infraestrutura

19. ● “Simples”
● Pouca Visibilidade
● Baixa Confiança
● Caro
Pros Contras

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. https://www.slideshare.net/linux.rafa/precisamos-falar-sobre-testes-de-infraestrutura

22. ● Sem mudanças manuais
● Infra como código
● Testes
● Automation Fear Spiral
● Snowflake Servers
● Erosion-resistence
Pros Contras

24. 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

25. https://martinfowler.com/bliki/ImmutableServer.html

26. ● Estado conhecido e testado
● S.O atualizado e seguro
● Confiança
● Processos maduros
● Ferramentas para gerar
templates
● 12 factor app
Ganhos Desafios

27. FERRAMENTAS

29. Persistent Layer

31. 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

32. Perguntas

33. Especialistas em Cloud Computing / DevOps