SlideShare uma empresa Scribd logo
Terraform
Uma breve breve introdução
Leandro Silva
https://github.com/leandrosilva
www.pricefy.com.br
Com um oferecimento...
Todos os meses geramos
mais de 15 milhões de
cartazes em PDFs de alta
qualidade.
E isso não é tudo.
Cenário hipotético
Cenário hipotético
Nosso estudo de caso propõe:
● Uma solução de software definida por um cluster com três nós: API, Web e Daemon;
● Cada nó está encapsulado em um serviço Windows rodando em uma EC2 dedicada;
● A qualquer momento, pode haver mais de uma instância de qualquer um dos nó rodando;
● Estes nós fazem uso de diversos serviços AWS, por exemplo: S3, Redis e Elasticsearch;
● Suas versões são publicadas no S3 e instaladas em suas novas instâncias, de forma
automatizada, via script PowerShell, no momento de sua criação;
● Existe, portanto, uma imagem de Windows base para cada um destes serviços, que é
complementada com a versão determinada do software no catálogo de versões;
● A performance dos nós pode ser monitorada individualmente e notificada à operação;
● O auto scaling também acontece por nó, de acordo com tráfego de rede, CPU, fila de
processamento, período do dia e da semana, etc.
EC2
EC2
EC2
API Windows
Service
API Windows
Service
API Windows
Service
API
EC2
EC2
EC2
Web Windows
Service
Web Windows
Service
Web Windows
Service
Web
EC2
EC2
EC2
Daemon Windows
Service
Daemon Windows
Service
Daemon Windows
Service
Daemon
Cluster
EC2
EC2
EC2
API Windows Service
Web Windows Service
Daemon Windows Service
ElastiCache Redis
Elasticsearch Service
S3
S3-based Registry
versões
Internal
ALB
Client
App
Redis
WebWebWeb
API
Daemon
Web
Daemon
Internal
ALB
S3
assets diversosobtém artefatos
assetsdiversos
entregaartefatos
enfileira pedidos, checa status, etc
pega pedidos da fila e
os processa
enfileira pedidos, consulta infos
da fila, dos workers, etc
in-memory
cache
local
cache
Elastic
Search
- Logs de tudo
- Métricas da fila
- Versões instaladas
- Dashboard
Kibana
Cenário hipotético
Outra proposição do nosso estudo de caso é que:
● A qualquer momento, pode haver mais de um cluster com a exata arquitetura vista até
aqui, rodando em paralelo, sem que um tenha notícia do outro;
● Pode haver também o caso de um ou mais deles estarem em uma versão de arquitetura
diferente, por uma questão experimental, por segregação de carga de trabalho, ou por
uma evolução da solução;
● Portanto, eles podem ou não compartilhar as mesmas instâncias dos serviços da AWS;
● Dito isso, é evidente assumir também que a versão de software de cada cluster independe
da versão do outro, o que é determinado pelo catálogo de versões;
● O catálogo de versões, portanto, mantém o registro de versão de cada cluster.
RedisS3
Elastic
Search
EC2
API Windows Service
EC2
Web Windows Service
EC2
Daemon Windows Service
Internal
ALB
Cluster kitchen01
EC2
API Windows Service
EC2
Web Windows Service
EC2
Daemon Windows Service
Internal
ALB
Cluster kitchen02
VPC restaurant01
Cenário hipotético
Prós:
● Cada nó encapsulado em um serviço Windows rodando em uma EC2 dedicada;
● Versões publicadas no S3 e instaladas nas instâncias EC2 via script PowerShell na criação;
● Performance dos nós podendo ser individualmente monitorada e escalada;
● Auto scaling individualizado por nó, de acordo com tráfego de rede, CPU, fila, etc;
● Possibilidade de ter múltiplos clusters da solução em versões diferentes.
Contras:
● É difícil de gerenciar e dar manutenção em arquiteturas diferentes, com clusters
diferentes, com versões de software diferentes;
● É impossível se lembrar de todas as configurações e conseguir reproduzir rapidamente.
Sim, eu disse isso mesmo. Tente
recriar um cluster desses, na mão.
Uma breve introdução ao Terraform
Entra o Terraform.
Uma breve introdução
ao Terraform
Problema
Reproduzir comportamento de software rodando em infraestruturas diferentes parece um
problema trivial, mas é f%d@ sempre:
● Há pouca rastreabilidade de mudanças de infraestrutura;
● Máquinas rodando há muito tempo sofrem mudanças que ninguém se lembra depois;
● A infraestrutura vai se degradando com o tempo, mas ninguém quer refazer;
● Quanto mais componentes, menor a coragem de refazer uma infra completa;
E criar ambiente de teste & troubleshooting?
● Dá um puta trabalho reproduzir a infra de produção;
● Custa caro em todos os sentidos;
● Quando você finalmente cria, não quer destruir ⎼ por quê? #loop
Problema
Você mesmo nunca fez isso, a gente sabe, mas:
● Tem sempre aquele arquivinho que alguém modificou em uma instância e não se lembra
mais nem que mudou, quando mudou, nem o que mudou, só sabe que agora o serviço está
funcionando corretamente e pelo amor de tudo que é mais sagrado, não mexa nele!
OK, vamos exercitar só mais um pouco esse cenário:
● Como reproduzir esse comportamento em uma nova instância?
● Aliás, esta instância em questão, agora modificada, ninguém sabe como, o quão
compatível estará com a futuras versões do software?
● Como testar se estará, se não será possível criar uma instância de testes igual a esta? (Tudo
bem, você sempre pode clonar a EC2, mas isso só vai empurrar o problema para frente, como uma bola de neve.)
Quanto tempo você leva para
recriar totalmente a stack de uma
aplicação, na mão, do zero até a
primeira requisição atendida com
sucesso? E depois, para destruí-la,
quando você não precisar mais?
Solução: Infraestrutura como Código
● A infraestrutura toda é descrita como código;
● Torna as coisas mais previsíveis;
● Favorece a revisão conceitual da infra;
● Facilita bastante testar arquiteturas diferentes ⎼ cria, testa, destrói;
● Oferece versionamento no git;
● Uma vez codificada, você cria, recria, atualiza e destrói tudo (ou parte) com um comando.
No final das contas sai mais barato (tempo e dinheiro) criar, testar,
modificar, manter e destruir a infraestrutura.
Uma breve introdução ao Terraform
Terraform | o que faz?
● Permite descrever sua infraestrutura como código ✔
● Oferece uma linguagem única entre nuvens (AWS, Azure, GCP, Digital Ocean, etc)
● Seus arquivos de código podem ser versionados e compartilhados no git ✔
● É possível ter um plano de mudança antes da mudança acontecer de fato
● As dependências entre os recursos são graficamente visíveis
● Permite manter paridade entre os ambientes (staging, QA, prd, etc) ✔
● Mantém um histórico local ou remoto da sua infraestrutura ✔
● É possível criar, modificar, destruir quantas vezes for necessário e incrementalmente ✔
● Fluxos mais complexos também podem ser criados encadeando comandos em scripts
Terraform | como começar?
#1 Fazer download e instalação
#2 Inicializar o projeto
https://www.terraform.io/downloads.html
https://www.terraform.io/docs/commands/init.html
Seu primeiro recurso na
AWS
Terraform | seu primeiro recurso na AWS
Terraform | seu primeiro recurso na AWS
Terraform | seu primeiro recurso na AWS
Terraform | seu primeiro recurso na AWS
Terraform | seu primeiro recurso na AWS
Terraform | seu primeiro recurso na AWS
Um exemplo mais
completo
Terraform | um exemplo mais completo
Provedor
Variáveis
Recursos
Saídas
placeholder for your secret provider
placeholder for your secret provider
placeholder for your secret provider
Terraform | um exemplo mais completo
Terraform | um exemplo mais completo
Todos os recursos foram
destruídos minutos depois.
PS> terraform destroy
Boas práticas
Terraform | boas práticas
Módulos de cada
componente da stack
Projetos diferentes
para cada versão
Script e setup
das instâncias
EC2 de cada nó
Terraform | boas práticas
Padrão de segregação de
arquivos dos módulos
Uso dos módulos para
compor a stack
Uma breve introdução
ao devops de EC2
Problema
Idealmente, as instâncias EC2 deveriam viver tanto quanto a versão do software que estão
rodando ⎼ quando não, até menos do que isso. Mas...
● Criar AMI de Windows é um saco;
● Fazer isso a cada nova versão do software, deuzulivre!
● Atualizar uma a uma das máquinas do cluster é f%d@.
Solução: fast food all the way
● Ter um repositório de versões em algum lugar ⎼ e.g. S3, git, nuget;
● Ter um catálogo que defina a versão atual de cada cluster ⎼ e.g. arquivo json no S3;
● Criar uma AMI base, com configurações e softwares adicionais ⎼ e.g. wk, ipp-printer;
● Criar um script que, na criação da EC2, faça o setup da versão que baixou do repositório;
● A partir daí, toda nova EC2 nasce com a versão desejada do software;
● Torna-se possível atualizar a versão das EC2 via auto scaling “increase” ⇨ “decrease”
“Dois hambúrgueres, alface, queijo, molho especial,
cebola, picles num pão com gergelim.” ⎼ na medida do possível,
montados por scripts que vão fazer sempre a mesma coisa, sempre do mesmo jeito.
Script de user_data
Devops | script de user_data
https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-windows-user-data.html
Você pode incluir aqui o script PowerShell que for preciso:
● Criar usuário e definir privilégios;
● Criar regras de firewall;
● Definir variáveis de ambiente;
● Fazer download de versão;
● Instalar versão;
● Fazer boot de serviço;
● Etc, etc, etc.
Devops | script de user_data
placeholder for your secret provider
Isto é um
exemplo
didático!
Idealmente, ele vai estar em um arquivo separado, que possa ser testado
<powershell>
Read-S3Object -BucketName "myapp-scripts" -KeyPrefix "devops/" -Folder "C:AppScripts"
Invoke-Expression "C:AppScriptsboot.ps1"
Invoke-Expression "C:ProgramDataAmazonEC2-WindowsLaunchScriptsInitializeInstance.ps1 -Schedule"
</powershell>
<persist>true</persist>
Devops | script de user_data
data "template_file" "user_data_api" {
template = "${file(var.USER_DATA)}"
vars = {...}
}
resource "aws_instance" "api" {
user_data = "${data.template_file.user_data_api.rendered}"
}
user_data.ps1.tpl
ec2_api/main.tf
1
2
3
Conclusão
Conclusão
● Fazer na mão o setup de stacks inteiras de uma aplicação é um trabalho árduo e bastante
suscetível a falhas;
● Repetir o processo de criação manualmente, igualzinho ao anterior, é muito difícil e
aumenta a chance de cometer erros;
● Processos manuais que se repetem custam caro ⎼ se você tem que fazer um processo mais
de uma vez, é melhor automatizar;
● Terraform te ajuda a criar uma infraestrutura mais consistente e estável;
● Você cria, testa e destrói com alguns poucos comandos;
● Sua infraestrutura fica descrita como código que pode ser revisado e versionado;
● Você não precisa mais manter de pé aquele ambiente de troubleshooting que não está
precisando no momento ⎼ quando você precisar novamente, você o recria;
● Tudo isso junto, no final das contas, reduz bugs na aplicação e custo de manutenção.

Mais conteúdo relacionado

Mais procurados

Orquestração com Mcollective
Orquestração com McollectiveOrquestração com Mcollective
Orquestração com Mcollective
Jose Augusto Carvalho
 
Trabalhando de forma profissional com silex
Trabalhando de forma profissional com silexTrabalhando de forma profissional com silex
Trabalhando de forma profissional com silex
Michael Douglas
 
Trabalhando com Módulos no Puppet
Trabalhando com Módulos no PuppetTrabalhando com Módulos no Puppet
Trabalhando com Módulos no Puppet
Jose Augusto Carvalho
 
Programando php com mais segurança
Programando php com mais segurançaProgramando php com mais segurança
Programando php com mais segurança
Michael Douglas
 
Consegi 2011: Ganeti + Puppet
Consegi 2011: Ganeti + PuppetConsegi 2011: Ganeti + Puppet
Consegi 2011: Ganeti + Puppet
Jose Augusto Carvalho
 
Oficina Puppet - Aprenda a Gerenciar Configurações
Oficina Puppet - Aprenda a Gerenciar ConfiguraçõesOficina Puppet - Aprenda a Gerenciar Configurações
Oficina Puppet - Aprenda a Gerenciar Configurações
Jose Augusto Carvalho
 
True Time API Para Data e Horário NTP no Android
True Time API Para Data e Horário NTP no AndroidTrue Time API Para Data e Horário NTP no Android
True Time API Para Data e Horário NTP no Android
Vinícius Thiengo
 
Javascript por debaixo dos panos
Javascript por debaixo dos panosJavascript por debaixo dos panos
Javascript por debaixo dos panos
Laís Lima
 
Vagrant uma ferramenta realmente útil e versátil
Vagrant   uma ferramenta realmente útil e versátilVagrant   uma ferramenta realmente útil e versátil
Vagrant uma ferramenta realmente útil e versátil
Wanderlei Silva do Carmo
 
Infraestrutura ágil com Puppet - CISL
Infraestrutura ágil com Puppet - CISLInfraestrutura ágil com Puppet - CISL
Infraestrutura ágil com Puppet - CISL
Jose Augusto Carvalho
 
Lab python django - parte 2 - python + virtualenv
Lab python django - parte 2 - python + virtualenvLab python django - parte 2 - python + virtualenv
Lab python django - parte 2 - python + virtualenv
Pedro Fernandes Vieira
 
Infraestrutura como código com Puppet e Mcollective
Infraestrutura como código com Puppet e McollectiveInfraestrutura como código com Puppet e Mcollective
Infraestrutura como código com Puppet e Mcollective
Jose Augusto Carvalho
 
A mágica por trás dos aplicativos ( Api com o Laravel )
A mágica por trás dos aplicativos ( Api com o Laravel )A mágica por trás dos aplicativos ( Api com o Laravel )
A mágica por trás dos aplicativos ( Api com o Laravel )
Michael Douglas
 
Docker para maiores
Docker para maioresDocker para maiores
Docker para maiores
Matheus Fidelis
 
Escalando API's com NodeJS, Docker e RabbitMQ
Escalando API's com NodeJS, Docker e RabbitMQEscalando API's com NodeJS, Docker e RabbitMQ
Escalando API's com NodeJS, Docker e RabbitMQ
Matheus Fidelis
 
Gestão automática de configuração usando puppet
Gestão automática de configuração usando puppetGestão automática de configuração usando puppet
Gestão automática de configuração usando puppet
Daniel Sobral
 
JS Experience 2017 - Utilizando a virtualização para simplificar o desenvolvi...
JS Experience 2017 - Utilizando a virtualização para simplificar o desenvolvi...JS Experience 2017 - Utilizando a virtualização para simplificar o desenvolvi...
JS Experience 2017 - Utilizando a virtualização para simplificar o desenvolvi...
iMasters
 
Docker Para Maiores - GDG Cabreúva
Docker Para Maiores - GDG CabreúvaDocker Para Maiores - GDG Cabreúva
Docker Para Maiores - GDG Cabreúva
Matheus Fidelis
 
Javascript por debaixo dos panos
Javascript por debaixo dos panosJavascript por debaixo dos panos
Javascript por debaixo dos panos
Laís Lima
 
C# 6.0 - DotNetBaixada - Novembro/2015
C# 6.0 - DotNetBaixada - Novembro/2015C# 6.0 - DotNetBaixada - Novembro/2015
C# 6.0 - DotNetBaixada - Novembro/2015
Renato Groff
 

Mais procurados (20)

Orquestração com Mcollective
Orquestração com McollectiveOrquestração com Mcollective
Orquestração com Mcollective
 
Trabalhando de forma profissional com silex
Trabalhando de forma profissional com silexTrabalhando de forma profissional com silex
Trabalhando de forma profissional com silex
 
Trabalhando com Módulos no Puppet
Trabalhando com Módulos no PuppetTrabalhando com Módulos no Puppet
Trabalhando com Módulos no Puppet
 
Programando php com mais segurança
Programando php com mais segurançaProgramando php com mais segurança
Programando php com mais segurança
 
Consegi 2011: Ganeti + Puppet
Consegi 2011: Ganeti + PuppetConsegi 2011: Ganeti + Puppet
Consegi 2011: Ganeti + Puppet
 
Oficina Puppet - Aprenda a Gerenciar Configurações
Oficina Puppet - Aprenda a Gerenciar ConfiguraçõesOficina Puppet - Aprenda a Gerenciar Configurações
Oficina Puppet - Aprenda a Gerenciar Configurações
 
True Time API Para Data e Horário NTP no Android
True Time API Para Data e Horário NTP no AndroidTrue Time API Para Data e Horário NTP no Android
True Time API Para Data e Horário NTP no Android
 
Javascript por debaixo dos panos
Javascript por debaixo dos panosJavascript por debaixo dos panos
Javascript por debaixo dos panos
 
Vagrant uma ferramenta realmente útil e versátil
Vagrant   uma ferramenta realmente útil e versátilVagrant   uma ferramenta realmente útil e versátil
Vagrant uma ferramenta realmente útil e versátil
 
Infraestrutura ágil com Puppet - CISL
Infraestrutura ágil com Puppet - CISLInfraestrutura ágil com Puppet - CISL
Infraestrutura ágil com Puppet - CISL
 
Lab python django - parte 2 - python + virtualenv
Lab python django - parte 2 - python + virtualenvLab python django - parte 2 - python + virtualenv
Lab python django - parte 2 - python + virtualenv
 
Infraestrutura como código com Puppet e Mcollective
Infraestrutura como código com Puppet e McollectiveInfraestrutura como código com Puppet e Mcollective
Infraestrutura como código com Puppet e Mcollective
 
A mágica por trás dos aplicativos ( Api com o Laravel )
A mágica por trás dos aplicativos ( Api com o Laravel )A mágica por trás dos aplicativos ( Api com o Laravel )
A mágica por trás dos aplicativos ( Api com o Laravel )
 
Docker para maiores
Docker para maioresDocker para maiores
Docker para maiores
 
Escalando API's com NodeJS, Docker e RabbitMQ
Escalando API's com NodeJS, Docker e RabbitMQEscalando API's com NodeJS, Docker e RabbitMQ
Escalando API's com NodeJS, Docker e RabbitMQ
 
Gestão automática de configuração usando puppet
Gestão automática de configuração usando puppetGestão automática de configuração usando puppet
Gestão automática de configuração usando puppet
 
JS Experience 2017 - Utilizando a virtualização para simplificar o desenvolvi...
JS Experience 2017 - Utilizando a virtualização para simplificar o desenvolvi...JS Experience 2017 - Utilizando a virtualização para simplificar o desenvolvi...
JS Experience 2017 - Utilizando a virtualização para simplificar o desenvolvi...
 
Docker Para Maiores - GDG Cabreúva
Docker Para Maiores - GDG CabreúvaDocker Para Maiores - GDG Cabreúva
Docker Para Maiores - GDG Cabreúva
 
Javascript por debaixo dos panos
Javascript por debaixo dos panosJavascript por debaixo dos panos
Javascript por debaixo dos panos
 
C# 6.0 - DotNetBaixada - Novembro/2015
C# 6.0 - DotNetBaixada - Novembro/2015C# 6.0 - DotNetBaixada - Novembro/2015
C# 6.0 - DotNetBaixada - Novembro/2015
 

Semelhante a Uma breve introdução ao Terraform

Conheça o Docker
Conheça o DockerConheça o Docker
Conheça o Docker
Uira Ribeiro
 
Aula 6 - EC2, ELB, Auto Scaling, Cloud Watch
Aula 6 - EC2, ELB, Auto Scaling, Cloud WatchAula 6 - EC2, ELB, Auto Scaling, Cloud Watch
Aula 6 - EC2, ELB, Auto Scaling, Cloud Watch
Eduardo de Lucena Falcão
 
Node js - Javascript Server Side
Node js - Javascript Server SideNode js - Javascript Server Side
Node js - Javascript Server Side
Gustavo Corrêa Alves
 
Containers em produção!
Containers em produção!Containers em produção!
Containers em produção!
Evandro Couto
 
Desenvolvimento em .NET utilizando Docker - Meetup 8 Itu Developers
Desenvolvimento em .NET utilizando Docker - Meetup 8 Itu DevelopersDesenvolvimento em .NET utilizando Docker - Meetup 8 Itu Developers
Desenvolvimento em .NET utilizando Docker - Meetup 8 Itu Developers
Dextra Sistemas / Etec Itu
 
Continuous Deployment e DevOps na Nuvem
Continuous Deployment e DevOps na NuvemContinuous Deployment e DevOps na Nuvem
Continuous Deployment e DevOps na Nuvem
Amazon Web Services LATAM
 
Construindo pipelines com Azure DevOps
Construindo pipelines com Azure DevOpsConstruindo pipelines com Azure DevOps
Construindo pipelines com Azure DevOps
Camila Carrera
 
Usando Docker no desenvolvimento .NET
Usando Docker no desenvolvimento .NETUsando Docker no desenvolvimento .NET
Usando Docker no desenvolvimento .NET
Dextra Sistemas / Etec Itu
 
Amazon EC2 boas praticas e otimizações de desempenho
Amazon EC2 boas praticas e otimizações de desempenhoAmazon EC2 boas praticas e otimizações de desempenho
Amazon EC2 boas praticas e otimizações de desempenho
Amazon Web Services LATAM
 
Docker de ponta a ponta - do Desenvolvimento à Nuvem - .NET SP - Outubro-2018
Docker de ponta a ponta - do Desenvolvimento à Nuvem - .NET SP - Outubro-2018Docker de ponta a ponta - do Desenvolvimento à Nuvem - .NET SP - Outubro-2018
Docker de ponta a ponta - do Desenvolvimento à Nuvem - .NET SP - Outubro-2018
Renato Groff
 
Docker de ponta a ponta: do Desenvolvimento à Nuvem - Azure Talks - Agosto-2018
Docker de ponta a ponta: do Desenvolvimento à Nuvem - Azure Talks - Agosto-2018Docker de ponta a ponta: do Desenvolvimento à Nuvem - Azure Talks - Agosto-2018
Docker de ponta a ponta: do Desenvolvimento à Nuvem - Azure Talks - Agosto-2018
Renato Groff
 
DevOps na AWS: Construindo Sistemas para Entregas Rápidas - DEV301 - Sao Pau...
DevOps na AWS: Construindo Sistemas para Entregas Rápidas -  DEV301 - Sao Pau...DevOps na AWS: Construindo Sistemas para Entregas Rápidas -  DEV301 - Sao Pau...
DevOps na AWS: Construindo Sistemas para Entregas Rápidas - DEV301 - Sao Pau...
Amazon Web Services
 
Escalando sua aplicação Web com Beanstalk
Escalando sua aplicação Web com BeanstalkEscalando sua aplicação Web com Beanstalk
Escalando sua aplicação Web com Beanstalk
Amazon Web Services LATAM
 
TDC2017 | São Paulo - Trilha Containers How we figured out we had a SRE team ...
TDC2017 | São Paulo - Trilha Containers How we figured out we had a SRE team ...TDC2017 | São Paulo - Trilha Containers How we figured out we had a SRE team ...
TDC2017 | São Paulo - Trilha Containers How we figured out we had a SRE team ...
tdc-globalcode
 
TDC2016SP - Versionando sua infraestrutura: Como e porque fazer, baseado em c...
TDC2016SP - Versionando sua infraestrutura: Como e porque fazer, baseado em c...TDC2016SP - Versionando sua infraestrutura: Como e porque fazer, baseado em c...
TDC2016SP - Versionando sua infraestrutura: Como e porque fazer, baseado em c...
tdc-globalcode
 
Orchestrando na linha
Orchestrando na linhaOrchestrando na linha
Orchestrando na linha
matheuscmpm
 
Construindo aplicações escaláveis com ASP.NET Core, Docker e o Microsoft Azur...
Construindo aplicações escaláveis com ASP.NET Core, Docker e o Microsoft Azur...Construindo aplicações escaláveis com ASP.NET Core, Docker e o Microsoft Azur...
Construindo aplicações escaláveis com ASP.NET Core, Docker e o Microsoft Azur...
Renato Groff
 
Introdução-a-Docker-compactado.pdf
Introdução-a-Docker-compactado.pdfIntrodução-a-Docker-compactado.pdf
Introdução-a-Docker-compactado.pdf
dadalt1
 
Introduction to Cloud Computing
Introduction to Cloud ComputingIntroduction to Cloud Computing
Introduction to Cloud Computing
Eduardo de Lucena Falcão
 
Quebrando barreiras entre desenvolvimento e operação de software com DevOps
Quebrando barreiras entre desenvolvimento e operação de software com DevOpsQuebrando barreiras entre desenvolvimento e operação de software com DevOps
Quebrando barreiras entre desenvolvimento e operação de software com DevOps
José Alexandre Macedo
 

Semelhante a Uma breve introdução ao Terraform (20)

Conheça o Docker
Conheça o DockerConheça o Docker
Conheça o Docker
 
Aula 6 - EC2, ELB, Auto Scaling, Cloud Watch
Aula 6 - EC2, ELB, Auto Scaling, Cloud WatchAula 6 - EC2, ELB, Auto Scaling, Cloud Watch
Aula 6 - EC2, ELB, Auto Scaling, Cloud Watch
 
Node js - Javascript Server Side
Node js - Javascript Server SideNode js - Javascript Server Side
Node js - Javascript Server Side
 
Containers em produção!
Containers em produção!Containers em produção!
Containers em produção!
 
Desenvolvimento em .NET utilizando Docker - Meetup 8 Itu Developers
Desenvolvimento em .NET utilizando Docker - Meetup 8 Itu DevelopersDesenvolvimento em .NET utilizando Docker - Meetup 8 Itu Developers
Desenvolvimento em .NET utilizando Docker - Meetup 8 Itu Developers
 
Continuous Deployment e DevOps na Nuvem
Continuous Deployment e DevOps na NuvemContinuous Deployment e DevOps na Nuvem
Continuous Deployment e DevOps na Nuvem
 
Construindo pipelines com Azure DevOps
Construindo pipelines com Azure DevOpsConstruindo pipelines com Azure DevOps
Construindo pipelines com Azure DevOps
 
Usando Docker no desenvolvimento .NET
Usando Docker no desenvolvimento .NETUsando Docker no desenvolvimento .NET
Usando Docker no desenvolvimento .NET
 
Amazon EC2 boas praticas e otimizações de desempenho
Amazon EC2 boas praticas e otimizações de desempenhoAmazon EC2 boas praticas e otimizações de desempenho
Amazon EC2 boas praticas e otimizações de desempenho
 
Docker de ponta a ponta - do Desenvolvimento à Nuvem - .NET SP - Outubro-2018
Docker de ponta a ponta - do Desenvolvimento à Nuvem - .NET SP - Outubro-2018Docker de ponta a ponta - do Desenvolvimento à Nuvem - .NET SP - Outubro-2018
Docker de ponta a ponta - do Desenvolvimento à Nuvem - .NET SP - Outubro-2018
 
Docker de ponta a ponta: do Desenvolvimento à Nuvem - Azure Talks - Agosto-2018
Docker de ponta a ponta: do Desenvolvimento à Nuvem - Azure Talks - Agosto-2018Docker de ponta a ponta: do Desenvolvimento à Nuvem - Azure Talks - Agosto-2018
Docker de ponta a ponta: do Desenvolvimento à Nuvem - Azure Talks - Agosto-2018
 
DevOps na AWS: Construindo Sistemas para Entregas Rápidas - DEV301 - Sao Pau...
DevOps na AWS: Construindo Sistemas para Entregas Rápidas -  DEV301 - Sao Pau...DevOps na AWS: Construindo Sistemas para Entregas Rápidas -  DEV301 - Sao Pau...
DevOps na AWS: Construindo Sistemas para Entregas Rápidas - DEV301 - Sao Pau...
 
Escalando sua aplicação Web com Beanstalk
Escalando sua aplicação Web com BeanstalkEscalando sua aplicação Web com Beanstalk
Escalando sua aplicação Web com Beanstalk
 
TDC2017 | São Paulo - Trilha Containers How we figured out we had a SRE team ...
TDC2017 | São Paulo - Trilha Containers How we figured out we had a SRE team ...TDC2017 | São Paulo - Trilha Containers How we figured out we had a SRE team ...
TDC2017 | São Paulo - Trilha Containers How we figured out we had a SRE team ...
 
TDC2016SP - Versionando sua infraestrutura: Como e porque fazer, baseado em c...
TDC2016SP - Versionando sua infraestrutura: Como e porque fazer, baseado em c...TDC2016SP - Versionando sua infraestrutura: Como e porque fazer, baseado em c...
TDC2016SP - Versionando sua infraestrutura: Como e porque fazer, baseado em c...
 
Orchestrando na linha
Orchestrando na linhaOrchestrando na linha
Orchestrando na linha
 
Construindo aplicações escaláveis com ASP.NET Core, Docker e o Microsoft Azur...
Construindo aplicações escaláveis com ASP.NET Core, Docker e o Microsoft Azur...Construindo aplicações escaláveis com ASP.NET Core, Docker e o Microsoft Azur...
Construindo aplicações escaláveis com ASP.NET Core, Docker e o Microsoft Azur...
 
Introdução-a-Docker-compactado.pdf
Introdução-a-Docker-compactado.pdfIntrodução-a-Docker-compactado.pdf
Introdução-a-Docker-compactado.pdf
 
Introduction to Cloud Computing
Introduction to Cloud ComputingIntroduction to Cloud Computing
Introduction to Cloud Computing
 
Quebrando barreiras entre desenvolvimento e operação de software com DevOps
Quebrando barreiras entre desenvolvimento e operação de software com DevOpsQuebrando barreiras entre desenvolvimento e operação de software com DevOps
Quebrando barreiras entre desenvolvimento e operação de software com DevOps
 

Mais de Leandro Silva

Arquitetura de Software 101
Arquitetura de Software 101Arquitetura de Software 101
Arquitetura de Software 101
Leandro Silva
 
SRE - Esperança não é uma estratégia
SRE - Esperança não é uma estratégiaSRE - Esperança não é uma estratégia
SRE - Esperança não é uma estratégia
Leandro Silva
 
Composição e Integração de Sistemas em 2013
Composição e Integração de Sistemas em 2013Composição e Integração de Sistemas em 2013
Composição e Integração de Sistemas em 2013
Leandro Silva
 
Sistemas para o Mundo Real - TDC 2012
Sistemas para o Mundo Real - TDC 2012Sistemas para o Mundo Real - TDC 2012
Sistemas para o Mundo Real - TDC 2012
Leandro Silva
 
Sistemas para o Mundo Real
Sistemas para o Mundo RealSistemas para o Mundo Real
Sistemas para o Mundo Real
Leandro Silva
 
Gerenciando times autogerenciáveis
Gerenciando times autogerenciáveisGerenciando times autogerenciáveis
Gerenciando times autogerenciáveis
Leandro Silva
 
Como vi Scrum ser rechaçado em uma grande empresa
Como vi Scrum ser rechaçado em uma grande empresaComo vi Scrum ser rechaçado em uma grande empresa
Como vi Scrum ser rechaçado em uma grande empresa
Leandro Silva
 
Erlang/OTP - Caelum Tech Day 2009
Erlang/OTP - Caelum Tech Day 2009Erlang/OTP - Caelum Tech Day 2009
Erlang/OTP - Caelum Tech Day 2009
Leandro Silva
 

Mais de Leandro Silva (8)

Arquitetura de Software 101
Arquitetura de Software 101Arquitetura de Software 101
Arquitetura de Software 101
 
SRE - Esperança não é uma estratégia
SRE - Esperança não é uma estratégiaSRE - Esperança não é uma estratégia
SRE - Esperança não é uma estratégia
 
Composição e Integração de Sistemas em 2013
Composição e Integração de Sistemas em 2013Composição e Integração de Sistemas em 2013
Composição e Integração de Sistemas em 2013
 
Sistemas para o Mundo Real - TDC 2012
Sistemas para o Mundo Real - TDC 2012Sistemas para o Mundo Real - TDC 2012
Sistemas para o Mundo Real - TDC 2012
 
Sistemas para o Mundo Real
Sistemas para o Mundo RealSistemas para o Mundo Real
Sistemas para o Mundo Real
 
Gerenciando times autogerenciáveis
Gerenciando times autogerenciáveisGerenciando times autogerenciáveis
Gerenciando times autogerenciáveis
 
Como vi Scrum ser rechaçado em uma grande empresa
Como vi Scrum ser rechaçado em uma grande empresaComo vi Scrum ser rechaçado em uma grande empresa
Como vi Scrum ser rechaçado em uma grande empresa
 
Erlang/OTP - Caelum Tech Day 2009
Erlang/OTP - Caelum Tech Day 2009Erlang/OTP - Caelum Tech Day 2009
Erlang/OTP - Caelum Tech Day 2009
 

Uma breve introdução ao Terraform

  • 1. Terraform Uma breve breve introdução Leandro Silva https://github.com/leandrosilva
  • 2. www.pricefy.com.br Com um oferecimento... Todos os meses geramos mais de 15 milhões de cartazes em PDFs de alta qualidade. E isso não é tudo.
  • 4. Cenário hipotético Nosso estudo de caso propõe: ● Uma solução de software definida por um cluster com três nós: API, Web e Daemon; ● Cada nó está encapsulado em um serviço Windows rodando em uma EC2 dedicada; ● A qualquer momento, pode haver mais de uma instância de qualquer um dos nó rodando; ● Estes nós fazem uso de diversos serviços AWS, por exemplo: S3, Redis e Elasticsearch; ● Suas versões são publicadas no S3 e instaladas em suas novas instâncias, de forma automatizada, via script PowerShell, no momento de sua criação; ● Existe, portanto, uma imagem de Windows base para cada um destes serviços, que é complementada com a versão determinada do software no catálogo de versões; ● A performance dos nós pode ser monitorada individualmente e notificada à operação; ● O auto scaling também acontece por nó, de acordo com tráfego de rede, CPU, fila de processamento, período do dia e da semana, etc.
  • 5. EC2 EC2 EC2 API Windows Service API Windows Service API Windows Service API EC2 EC2 EC2 Web Windows Service Web Windows Service Web Windows Service Web EC2 EC2 EC2 Daemon Windows Service Daemon Windows Service Daemon Windows Service Daemon Cluster
  • 6. EC2 EC2 EC2 API Windows Service Web Windows Service Daemon Windows Service ElastiCache Redis Elasticsearch Service S3 S3-based Registry versões Internal ALB
  • 7. Client App Redis WebWebWeb API Daemon Web Daemon Internal ALB S3 assets diversosobtém artefatos assetsdiversos entregaartefatos enfileira pedidos, checa status, etc pega pedidos da fila e os processa enfileira pedidos, consulta infos da fila, dos workers, etc in-memory cache local cache Elastic Search - Logs de tudo - Métricas da fila - Versões instaladas - Dashboard Kibana
  • 8. Cenário hipotético Outra proposição do nosso estudo de caso é que: ● A qualquer momento, pode haver mais de um cluster com a exata arquitetura vista até aqui, rodando em paralelo, sem que um tenha notícia do outro; ● Pode haver também o caso de um ou mais deles estarem em uma versão de arquitetura diferente, por uma questão experimental, por segregação de carga de trabalho, ou por uma evolução da solução; ● Portanto, eles podem ou não compartilhar as mesmas instâncias dos serviços da AWS; ● Dito isso, é evidente assumir também que a versão de software de cada cluster independe da versão do outro, o que é determinado pelo catálogo de versões; ● O catálogo de versões, portanto, mantém o registro de versão de cada cluster.
  • 9. RedisS3 Elastic Search EC2 API Windows Service EC2 Web Windows Service EC2 Daemon Windows Service Internal ALB Cluster kitchen01 EC2 API Windows Service EC2 Web Windows Service EC2 Daemon Windows Service Internal ALB Cluster kitchen02 VPC restaurant01
  • 10. Cenário hipotético Prós: ● Cada nó encapsulado em um serviço Windows rodando em uma EC2 dedicada; ● Versões publicadas no S3 e instaladas nas instâncias EC2 via script PowerShell na criação; ● Performance dos nós podendo ser individualmente monitorada e escalada; ● Auto scaling individualizado por nó, de acordo com tráfego de rede, CPU, fila, etc; ● Possibilidade de ter múltiplos clusters da solução em versões diferentes. Contras: ● É difícil de gerenciar e dar manutenção em arquiteturas diferentes, com clusters diferentes, com versões de software diferentes; ● É impossível se lembrar de todas as configurações e conseguir reproduzir rapidamente.
  • 11. Sim, eu disse isso mesmo. Tente recriar um cluster desses, na mão.
  • 15. Problema Reproduzir comportamento de software rodando em infraestruturas diferentes parece um problema trivial, mas é f%d@ sempre: ● Há pouca rastreabilidade de mudanças de infraestrutura; ● Máquinas rodando há muito tempo sofrem mudanças que ninguém se lembra depois; ● A infraestrutura vai se degradando com o tempo, mas ninguém quer refazer; ● Quanto mais componentes, menor a coragem de refazer uma infra completa; E criar ambiente de teste & troubleshooting? ● Dá um puta trabalho reproduzir a infra de produção; ● Custa caro em todos os sentidos; ● Quando você finalmente cria, não quer destruir ⎼ por quê? #loop
  • 16. Problema Você mesmo nunca fez isso, a gente sabe, mas: ● Tem sempre aquele arquivinho que alguém modificou em uma instância e não se lembra mais nem que mudou, quando mudou, nem o que mudou, só sabe que agora o serviço está funcionando corretamente e pelo amor de tudo que é mais sagrado, não mexa nele! OK, vamos exercitar só mais um pouco esse cenário: ● Como reproduzir esse comportamento em uma nova instância? ● Aliás, esta instância em questão, agora modificada, ninguém sabe como, o quão compatível estará com a futuras versões do software? ● Como testar se estará, se não será possível criar uma instância de testes igual a esta? (Tudo bem, você sempre pode clonar a EC2, mas isso só vai empurrar o problema para frente, como uma bola de neve.)
  • 17. Quanto tempo você leva para recriar totalmente a stack de uma aplicação, na mão, do zero até a primeira requisição atendida com sucesso? E depois, para destruí-la, quando você não precisar mais?
  • 18. Solução: Infraestrutura como Código ● A infraestrutura toda é descrita como código; ● Torna as coisas mais previsíveis; ● Favorece a revisão conceitual da infra; ● Facilita bastante testar arquiteturas diferentes ⎼ cria, testa, destrói; ● Oferece versionamento no git; ● Uma vez codificada, você cria, recria, atualiza e destrói tudo (ou parte) com um comando. No final das contas sai mais barato (tempo e dinheiro) criar, testar, modificar, manter e destruir a infraestrutura.
  • 20. Terraform | o que faz? ● Permite descrever sua infraestrutura como código ✔ ● Oferece uma linguagem única entre nuvens (AWS, Azure, GCP, Digital Ocean, etc) ● Seus arquivos de código podem ser versionados e compartilhados no git ✔ ● É possível ter um plano de mudança antes da mudança acontecer de fato ● As dependências entre os recursos são graficamente visíveis ● Permite manter paridade entre os ambientes (staging, QA, prd, etc) ✔ ● Mantém um histórico local ou remoto da sua infraestrutura ✔ ● É possível criar, modificar, destruir quantas vezes for necessário e incrementalmente ✔ ● Fluxos mais complexos também podem ser criados encadeando comandos em scripts
  • 21. Terraform | como começar? #1 Fazer download e instalação #2 Inicializar o projeto https://www.terraform.io/downloads.html https://www.terraform.io/docs/commands/init.html
  • 23. Terraform | seu primeiro recurso na AWS
  • 24. Terraform | seu primeiro recurso na AWS
  • 25. Terraform | seu primeiro recurso na AWS
  • 26. Terraform | seu primeiro recurso na AWS
  • 27. Terraform | seu primeiro recurso na AWS
  • 28. Terraform | seu primeiro recurso na AWS
  • 30. Terraform | um exemplo mais completo Provedor Variáveis Recursos Saídas placeholder for your secret provider placeholder for your secret provider placeholder for your secret provider
  • 31. Terraform | um exemplo mais completo
  • 32. Terraform | um exemplo mais completo
  • 33. Todos os recursos foram destruídos minutos depois. PS> terraform destroy
  • 35. Terraform | boas práticas Módulos de cada componente da stack Projetos diferentes para cada versão Script e setup das instâncias EC2 de cada nó
  • 36. Terraform | boas práticas Padrão de segregação de arquivos dos módulos Uso dos módulos para compor a stack
  • 37. Uma breve introdução ao devops de EC2
  • 38. Problema Idealmente, as instâncias EC2 deveriam viver tanto quanto a versão do software que estão rodando ⎼ quando não, até menos do que isso. Mas... ● Criar AMI de Windows é um saco; ● Fazer isso a cada nova versão do software, deuzulivre! ● Atualizar uma a uma das máquinas do cluster é f%d@.
  • 39. Solução: fast food all the way ● Ter um repositório de versões em algum lugar ⎼ e.g. S3, git, nuget; ● Ter um catálogo que defina a versão atual de cada cluster ⎼ e.g. arquivo json no S3; ● Criar uma AMI base, com configurações e softwares adicionais ⎼ e.g. wk, ipp-printer; ● Criar um script que, na criação da EC2, faça o setup da versão que baixou do repositório; ● A partir daí, toda nova EC2 nasce com a versão desejada do software; ● Torna-se possível atualizar a versão das EC2 via auto scaling “increase” ⇨ “decrease” “Dois hambúrgueres, alface, queijo, molho especial, cebola, picles num pão com gergelim.” ⎼ na medida do possível, montados por scripts que vão fazer sempre a mesma coisa, sempre do mesmo jeito.
  • 41. Devops | script de user_data https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-windows-user-data.html
  • 42. Você pode incluir aqui o script PowerShell que for preciso: ● Criar usuário e definir privilégios; ● Criar regras de firewall; ● Definir variáveis de ambiente; ● Fazer download de versão; ● Instalar versão; ● Fazer boot de serviço; ● Etc, etc, etc. Devops | script de user_data placeholder for your secret provider Isto é um exemplo didático! Idealmente, ele vai estar em um arquivo separado, que possa ser testado
  • 43. <powershell> Read-S3Object -BucketName "myapp-scripts" -KeyPrefix "devops/" -Folder "C:AppScripts" Invoke-Expression "C:AppScriptsboot.ps1" Invoke-Expression "C:ProgramDataAmazonEC2-WindowsLaunchScriptsInitializeInstance.ps1 -Schedule" </powershell> <persist>true</persist> Devops | script de user_data data "template_file" "user_data_api" { template = "${file(var.USER_DATA)}" vars = {...} } resource "aws_instance" "api" { user_data = "${data.template_file.user_data_api.rendered}" } user_data.ps1.tpl ec2_api/main.tf 1 2 3
  • 45. Conclusão ● Fazer na mão o setup de stacks inteiras de uma aplicação é um trabalho árduo e bastante suscetível a falhas; ● Repetir o processo de criação manualmente, igualzinho ao anterior, é muito difícil e aumenta a chance de cometer erros; ● Processos manuais que se repetem custam caro ⎼ se você tem que fazer um processo mais de uma vez, é melhor automatizar; ● Terraform te ajuda a criar uma infraestrutura mais consistente e estável; ● Você cria, testa e destrói com alguns poucos comandos; ● Sua infraestrutura fica descrita como código que pode ser revisado e versionado; ● Você não precisa mais manter de pé aquele ambiente de troubleshooting que não está precisando no momento ⎼ quando você precisar novamente, você o recria; ● Tudo isso junto, no final das contas, reduz bugs na aplicação e custo de manutenção.