Continuous Deployment e DevOps na Nuvem

Eduardo Horai
AWS Solutions Architect
Continuous Deployment e DevOps na Nuvem

Vários Tutoriais , treinamentos e mentoria em
português
Inscreva-se agora !!
http://awshub.com.br

Foco de hoje:
Sem discussões filosóficas sobre Continuous Integration (CI),
Continuous Deployment (CD) ou DevOps
Como AWS pode te ajudar em CI / CD / DevOps
Exemplos de boas práticas (porém não verdades absolutas)
AWS + Soluções Open Source

• Continuous Integration
• Continuous Deployment
• DevOps

• DevOps
Técnicas e ferramentas para
implementar processos
contínuos de verificação de
qualidade, aplicados
frequentemente, para
melhorar a qualidade do
software e reduzir o tempo de
entrega.

• DevOps
Técnicas e ferramentas para
melhorar o processo de
entrega de software,
resultando em deployments
rápidos, confiáveis e
repetíveis de melhorias ou
correção de bugs com baixo
risco e mínimo de
intervenção manual.

• DevOps
Entregando o código
feito pelas mãos dos
desenvolvedores ao
ambiente de produção de
maneira rápida e
eficiente, com resultados
positivo

• DevOps
Relação direta entre
desenvolvedores e
operadores de infra, para
diminuir riscos e unir
duas áreas essenciais do
ciclo de vida de um
software.

Continuous Integration & Deployment na AWS
• Infraestrutura também é código (programável)
• Automação de teste e deploy do início ao fim
• Ambientes Dev/QA/Prod são os mais parecidos possíveis
• Utilizar diferente modelos de custo quando necessário
• Simplificar e aumentar a frequência e velocidade do processo de
deploy
• Utilizar serviços da AWS para controlar fluxo
• Monitorar e observar tudo (instância, apliçação, logs)

Infraestrutura hoje!
Na Amazon Web Services

Na infraestrutura atual, tudo é código.
Desde o desenvolvimento de aplicações, até os arquivos de
configurações de ferramentas de automação, incluindo
também templates do CloudFormation ou scripts para
chamar as APIs da AWS.

Infraestrutura é código, por isso…
• Controle de versionamento (bom início, mas não é tudo)!
• Utilizar sistemas de bug tracking / ticketing
• Revisões de código antes de ir pra produção!
• Criar “design patterns” para infraestrutura
• Testar as mudanças no código da infraestrutura

A jornada do seu código até a produção…

1. Código é escrito
Alguém escreve o código, faz commit no Svn/Git/etc
Controlador de versão ativa o trabalho do CI

2. Código é testado
Testes unitários, testes de integração, testes de db,
smoke testes, UI testes, …
Luz verde indica OK ou volta para etapa 1.

3. Código é “deployado”
Código é entregue!
Pronto para ser utilizado em produção!

3. Código é consumido
Clientes utilizam o código (aplicação), adoram,
vitória, fim de uma jornada longa, férias na praia.

Código, código, código, …
1.Software ( tools, services, scripts )
2.Ambientes de infraestrutura( dev, test, prod )
3.Processos ( deploy, monitor, alert, track )

Precisamos de ferramentas para trabalhar
com os códigos acima de maneira rápida e
mais eficiente.
Código, código, código, …
1.Software ( tools, services, scripts )
2.Ambientes de infraestrutura( dev, test, prod )
3.Processos ( deploy, monitor, alert, track )

Opções de Continuous Integration
• Suporte para verificação de QA e testes repetidos com resultados pré definidos
• Opções: hospedado, open source, proprietário, SaaS…

Continuous Integration - Jenkins
“An extendable open source continuous
integration server”
• Open Source
• Well established and used by many
• Has plugins for EC2/SQS/SNS/CloudFormation!
• Supports spot pricing!
• Supports the ability to put workers into a
“standby” mode by stopping instead of
terminating
• Scales well
• Easily add more EC2 instances as workers
• Flexible
• Easy to get started
Internal
GitCI Server
Pre-commit
Hook
Testing Environment Subnet
CI Workers

Teste de receitas Chef com FoodCritic depois de cada commit no GIT.

…e agora, para onde o código vai?

Ambientes de infraestrutura
Ruim, muito ruim:
“Desenvolvedores desenvolvem localmente nos seus laptops, utilizando MacOS
ou Ubuntu, e depois o deploy na produção é em RedHat. Cada laptop tem uma
configuração um pouco diferente com versões de software diferentes.”
– Dev e prod não estão em sincronia
– Dev não está em sincronia com outros devs
– Sem ambiente de teste entre dev e prod

“… na minha máquina funcionou…”
(todo) desenvolvedor

Region
Amazon
Route 53
Amazon
CloudFront
Customer
Traffic
Amazon S3
Availability Zone
Availability Zone
Availability Zone
Internet
Gateway
VPC Subnet VPC Subnet VPC Subnet VPC Subnet
Instance Instance
Instance
NAT
Bastion/
Chef
ELBELB
RDS DB
Instance
RDS DB Instance
Standby (Multi-AZ) Instance
AWS
CloudFormation
Amazon CloudWatch
Amazon
SNS
Potential RDS DB
Instance Read
Replica
Instance Instance

Dev Environment VPC Subnet
DEV WEB ELB
Dev Stack
Tier 1
Dev Stack
Tier 2
Dev MySQL DB Instance DEV APP ELB
Ambiente de desenvolvimento

Region
Amazon
Route 53
Amazon
CloudFront
Customer
Traffic
Amazon S3
Availability Zone
Availability Zone
Availability Zone
Internet
Gateway
Instance Instance
Instance
NAT
Bastio
n/Chef
ELBELB
RDS DB
Instance
RDS DB Instance
AWS
CloudFormation
Amazon CloudWatch
Amazon
SNS
Potential
RDS DB
Instance
Read Replica
Instance Instance

Ambiente de desenvolvimento
Developers
&
Operations
DEV
WEB ELBDev Stack
Tier 1
Dev Stack
Tier 2
Dev
MySQL DB
Instance
DEV APP
ELB
VPN
TUNNEL
VPN facing VPC Subnet
Internet
Gateway
VPN
Endpoint
Dev Admin
Instance
NAT
Instance
Amazon S3
Amazon
DynamoDB
Amazon SQS
Amazon
CloudFront
Amazon
Route 53

Ambientes de desenvolvimento & teste
Developers
&
Operations
Internal
GitCI Server
Pre-commit
Hook
CI Workers
DEV
WEB ELBDev Stack
Tier 1
Dev Stack
Tier 2
Dev
MySQL DB
Instance
DEV APP
ELB
VPN
TUNNEL
Internet
Gateway
VPN
Endpoint
Dev Admin
Instance
NAT
Instance
Amazon S3
Amazon
DynamoDB
Amazon SQS
Amazon
CloudFront
Amazon
Route 53

Ambientes de infraestrutura
• Estar preparado para rodar diversos ambientes
– Development
– Testing/QA
– Staging/Pre-prod
– Production
• Eles devem ser o mais semelhante possível (mesmo stack)
• Utilizar ferramentas de gerenciamento de configuração e orquestração de
infraestrutura
• Toda instância deve ser recriável
• Objetivo: criar do zero, todas instâncias rodando sem intervenção humana

Mas isso parece que dá muito trabalho
e talvez custoso.
(pra não dizer impossível)

NÃO PRECISA SER!
(e sim, é possível)

Automação de infraestrutura
Queremos ser capazes de rapidamente criar novos ambiente conforme
necessitamos.
Hmmm… parece que precisamos de automatização!
– AWS CloudFormation
– AWS Elastic Beanstalk
– AWS OpsWorks
– Chef
– Puppet

AWS CloudFormation
"WebServer" : {
"Type" : "AWS::EC2::Instance",
"Properties" : {
"ImageId" : { "Fn::FindInMap" : [ "AWSRegionArch2AMI", { "Ref" : "AWS::Region" }, "64" ]},
"SpotPrice" : { "Ref" : "SpotPrice" },
"InstanceType" : m1.large",
"SecurityGroups" : [{ "Ref" : "InstanceSecurityGroup" }],
"KeyName" : { "Ref" : "KeyName" },
"UserData": {
"Fn::Base64" : { "Fn::Join" : ["", [
"#!/bin/bash -vn",
"yum update -y aws-cfn-bootstrapn”,
"curl -L http://www.opscode.com/chef/install.sh | bashn",
"cd /etc/chefn",
"/usr/bin/wget http://",{ "Ref" : "ChefServerIP" },"/chef/validation.pemn",
"/usr/bin/wget http://",{ "Ref" : "ChefServerIP" },"/chef/client.rbn",
"/bin/chown -R chef:chef /etc/chefn",

AWS Elastic Beanstalk & OpsWorks
Elastic Beanstalk:
• Application container framework similar to a PaaS
• Deploy your application into Elastic Beanstalk and it takes care of building a self
healing, auto-scaling, multi-AZ infrastructure
• Allows you to turn some of the knobs under the hood to tweak
• Considered one of the easiest places to start with hosting an application on AWS
OpsWorks:
• Build multi-layer application stacks
• Ties in with Chef for a large degree of flexibility and customization
• Makes deploying applications easier
• More flexible than Elastic Beanstalk, but requires a bit more knowledge

AWS Application Management Services
Elastic Beanstalk OpsWorks CloudFormation EC2
Convenience Control
Higher-level Services Do it yourself

Developers
&
Operations
Internal
GitCI Server
Pre-commit
Hook
CI Workers
DEV
WEB ELBDev Stack
Tier 1
Dev Stack
Tier 2
Dev
MySQL DB
Instance
DEV APP
ELB
VPN
TUNNEL
Internet
Gateway
VPN
Endpoint
Dev Admin
Instance
NAT
Instance
Amazon S3
Amazon
DynamoDB
Amazon SQS
Amazon
CloudFront
Amazon
Route 53
Elastic Beanstalk ou OpsWorks

Region
Amazon
Route 53
Amazon
CloudFront
Customer
Traffic
Amazon S3
Availability Zone
Availability Zone
Availability Zone
Internet
Gateway
Instance Instance
Instance
NAT
Bastion/
Chef
ELBELB
RDS DB
Instance
RDS DB Instance
AWS
CloudFormation
Amazon CloudWatch
Amazon
SNS
Potential RDS DB
Instance Read
Replica
Instance Instance
Elastic Beanstalk or OpsWorks

Imagine que você tem uma infraestrutura e você poderia
ligar e desligar por demanda, aproveitar a capacidade
não utilizada por um preço menor ou ainda reservar
capacidade baseado no seu uso e assim economizar!

Utilizando o modelo de custo correto – EC2
• On Demand
• Reserved Instance ( RI ) – 40%+ economia
• Spot – 80%+ economia
Cada um tem seu lugar. Para ambiente de desenvolvimento,
por exemplo:
• On Demand – Dev instances start/stop todo dia
• Reserved Instances – Repositório código, CI master, DBs
• Spot – CI workers, camadas de desenvolvimento que podem ser
desligados eventualmente

Developers
&
Operations
Internal
GitCI Server
Pre-commit
Hook
CI Workers
DEV
WEB ELBDev Stack
Tier 1
Dev Stack
Tier 2
Dev
MySQL DB
Instance
DEV APP
ELB
VPN
TUNNEL
Internet
Gateway
VPN
Endpoint
Dev Admin
Instance
NAT
Instance
Amazon S3
Amazon
DynamoDB
Amazon SQS
Amazon
CloudFront
Amazon
Route 53
RESERVED INSTANCES
SPOT/ON-DEMAND
RRS S3, CloudFront
Price Classes,
DynamoDB RC

Crowdtest
Hugo Barros
Diretor de Projetos

• O Crowdtest é a maior força de trabalho de testes de
software do Brasil, com mais de 4000 testadores
trabalhando 24x7 para encontrar defeitos em sistemas
Web, mobile e desktop.
• O segredo: todos trabalham part-time e só recebem por
produtividade. Por isso, somos 10 vezes mais rápidos e
custamos muito menos para nossos clientes.
• O Crowdtest já atende clientes pequenos e grandes,
como Natura, Buscapé, Locaweb, Sul América, além de
dezenas de startups e pequenas empresas.
• Por que a AWS é um ótimo parceiro para testes e
também para o Crowdtest?
Sem a AWS, nossa startup extremamente escalável
precisaria se transformar em um mini data-center.
“A elasticidade
da AWS é um dos
principais pilares da
escalabilidade no
nosso modelo de
negócio”
- Hugo Barros

Cada vez mais Testes são realizados na nuvem

Cada vez mais empresas usam Testing as a Service

Nossos Desafios
• Desafio 1: hospedar nossa plataforma de gestão de testes baseada em Ruby on
Rails e MySQL.
• Picos de acesso durante execução dos projetos.
• Elevado volume de evidências em vídeo e fotos para registro dos bugs.
• Failover (especialmente durante os projetos)
• Solução: EC2 + RDS + EBS + S3 + CloudWatch
• Desafio 2: durante os testes erros encontrados precisam ser corrigidos e uma
nova versão lançada para aproveitar ao máximo o tempo do testador.
• Solução: integração contínua (builds diários)
• Desafio 3: hospedar os mais diferentes tipos de aplicativos em um ambiente de
homologação
• Solução: EC2
• Desafio 4: testes automáticos disparados a partir de integração contínua em
multi-plataformas
• Durante a integração contínua disparamos testes automáticos paralelos
em multi-plataformas para homologar nossa plataforma de gestão de
testes e de nossos clientes.
• Solução: EC2

Benefícios alcançados com a AWS
• Experimentamosoutras soluções de hospedagem,
aparentementemais baratas, mas nenhuma atendeu a
todas as nossas demandas com a flexibilidade que
precisávamos.
• A rapidez de setup na AWS permite oferecermos
nossas principais vantagens:
• Relatórios de falhas em até 12h
• Testes em regime 24x7
• On-demand
• Múltiplas plataformas
• Orçamentopré-fixado
• Garantia de custos menores

Benefícios alcançados com a AWS
PARAGRAFO RESUMO
CASO _ KEY WORDS
de BENEFICIO,
DESAFIO VENCIDO –
RESUMO DO CASO EM
UM PARAGRAFO
• Implantação simples e rápida, sem entraves. Por exemplo, a
Natura nos contactou às 11h, às 14h tínhamos um piloto e
16h fechamos o contrato.
• Possibilidade de crescer o pool de servidores
automaticamente.
• Scripts permitem retirar a infra do ar e replica-la durante a
janela do projeto que necessita de continuous deployment.
• Redução significativa de despesas antecipadas de capital e
do prazo para setup de servidores em cada projeto de
testes.

Agora, sabemos para onde o código vai,
mas como chegar até lá?

“Deployando” o código
• Como?
– Envio de arquivos:
• Arquivos, texto ou binários
– Pacotes:
• RPMs, Tarballs, etc
– AMI:
• Empacotar em uma AMI
• Quão rápido precisamos fazer deploy?
• Em quantas instâncias?
• Como faremos rollback?

Deploy por envio de arquivos ou pacote
• Mais fácil
• Code Push:
– Origem: Git/SVN/staging
• Rolling restarts para web/app servers
• Utiliza mesmos hosts
• Preocupação com tempo de “refresh”
• Preocupação com possibilidade de rollback
• Preocupação com qual versão está em cada host

Deploy por AMI
AMI
Totalmente
funcional
AMI
Apenas OS
AMI Parcialmente
configurada

Deploy por AMI
AMI
Totalmente
funcional
AMI
Apenas OS
AMI Parcialmente
configurada
Menos flexível
para manter

Deploy por AMI
AMI
Totalmente
funcional
AMI
Apenas OS
AMI Parcialmente
configurada
Menos flexível
para manter
Leva mais tempo
para levantar

Deploy por AMI
AMI
Totalmente
funcional
AMI
Apenas OS
AMI Parcialmente
configurada
Menos flexível
para manter
Leva mais tempo
para levantar
Encontrar um meio
termo ideal aqui

Deploy por AMI – como funciona
Blue/Green Deploys
– Cria infraestrutura duplicada e aos
poucos transfere o tráfego
• Roteamento por DNS
• Facilita o teste de novas features
• Facilita o rollback
– Conforme mais tráfego é transferido,
aumenta/diminui as instâncias por
auto-scaling do novo e antigo
ambientes
• Shut down o antigo ambiente quando
não tem mais tráfego
Amazon
Route 53
EC2 Instances
ELB
100%
DynamoDB MySQL RDS
Instance
ElastiCache
Cache Node

Amazon
Route 53
EC2 Instances
ELB
EC2 Instances
ELB
90% 10%
DynamoDB MySQL RDS
Instance
ElastiCache
Cache Node
Blue/Green Deploys
ambientes

Amazon
Route 53
EC2 Instances
ELB
EC2 Instances
ELB
50% 50%
DynamoDB MySQL RDS
Instance
ElastiCache
Cache Node
Blue/Green Deploys
ambientes

Amazon
Route 53
EC2 Instances
ELB
EC2 Instances
ELB
0% 100%
DynamoDB MySQL RDS
Instance
ElastiCache
Cache Node
Blue/Green Deploys
ambientes

Amazon
Route 53
EC2 Instances
ELB
100%
DynamoDB MySQL RDS
Instance
ElastiCache
Cache Node
Blue/Green Deploys
ambientes

VTEX
André Uchôa
Diretor de pesquisa e inovação

• A VTEX é líder em tecnologia para e-commerce
e pioneira na comercialização de software
como serviço (SaaS) no Brasil. Suas soluções
atendem lojas virtuais independente do
volume de clientes e do segmento de negócio.
• Mais de 300 lojas de e-commerce, 200
funcionarios, 140 desenvolvedores, 4 países,
mais de 50 agencias parceiras. Os clientes
através do uso da plataforma VTEX
transacionaram R$ 2 bilhões em 2012
“Conseguimos diminuir o atrito na publicação do nosso
software, tornando virtualmente ilimitado o número de
deployments possíveis em um dia”.
“A visão da
infraestrutura como
software fornecida pela
AWS cobriu a lacuna
que havia entre os
times de
desenvolvimento e os
ambientes
operacionais.”
- André Uchôa

• Aproximar os times de desenvolvimento da operação do
sistema
• Garantir um padrão de “Continuous Deployment” que
suportasse diferentes plataformas de desenvolvimento
• Incluir o provisionamento de recursos no processo de
deployment
• Permitir o versionamento das demandas de infraestrutura de
cada um dos hoje 11 sistemas que compõe a suite
• Encontrar uma solução de publicação com “Zero Downtime” e
rollback rápido
O Desafio

• Criação automática de ambientes Beanstalk conforme a necessidade de deployment:
• Uma tag no git = ambientes criados e sistema publicado
• Organizaçãoda infraestrutura orientada pelo versionamentosemântico das aplicações
• Parâmetros de infraestrutura configuradose versionados no git junto com o código da aplicação
• “Convention over Configuration”: hardware agora também é software
• Descentralização da publicação do software: cada time é capaz de cuidar da publicação do seu
módulo
• Rollback de versão fácil em caso de falha de nova versão em produção
Sobre o Papel da AWS e Benefícios
alcançados

Nosso código chegou à produção!
Mas e agora?

Infraestrutura de Monitoramento & Log
• Precisa saber o que está acontecendo
• Gaste o tempo necessário para fazer isso bem
• Compartilhe acesso a essas ferramentas com o time inteiro
• Monitore cada instância
• Configure alerta nos serviços, disponibilidade delas e tempo de resposta
• Utilize as diferentes opções de modelos de custo
• Tente manter os logs e dados de monitoramento pelo maior tempo possível
– 6 meses? 1 ano? Vários anos?

Infraestrutura de Monitoramento & Log
Ferramentas:
• Logging
– Logstash
• Check out Kibana!
– Graylog2
– Syslog-ng/rsyslog/syslog
• Metrics
– CloudWatch
– Ganglia
– Graphite
• Monitoring
– Nagios
– Munin
– Sensu

METRICAS
DO S.O.
MÉTRICAS
AGREGADAS
ANÁLISE DAS
MÉTRICAS
MÉTRICAS
DE BUILD

AWS Marketplace
AWS Online Software Store
• Customer can find, research, buy software
• Simple pricing, aligns with EC2 usage model
• Launch in minutes
• Marketplace billing integrated into your AWS
account
• 600+ products across 23 categories
Learn more at: http://aws.amazon.com/marketplace
Developer Tool Categories Include
• Bug Tracking
• Monitoring
• Source Control
• Testing

Continuous Integration & Deployment & DevOps na AWS
• Trate Infraestrutura como código (programável)
• Automatize teste / deploy do início ao fim
• Ambientes Dev/QA/Prod os mais parecidos possíveis
• Utilize diferente modelos de custo quando necessário
• Simplifique e aumente a frequência e velocidade do processo de
deploy
• Utilize serviços da AWS para controlar fluxo
• Monitore e observe tudo (instância, apliçação, logs)

Obrigado!
ehorai@amazon.com
aws.amazon.com/cloudformation
aws.amazon.com/opsworks
aws.amazon.com/elasticbeanstalk

Continuous Deployment e DevOps na Nuvem

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Continuous Deployment e DevOps na Nuvem

Mais de Amazon Web Services LATAM

Último

Continuous Deployment e DevOps na Nuvem