View
1.250
Download
1
Category
Preview:
DESCRIPTION
Continuous Deployment e DevOps na Nuvem da AWS
Citation preview
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
• Continuous Integration
• Continuous Deployment
• 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.
• Continuous Integration
• Continuous Deployment
• 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.
• Continuous Integration
• Continuous Deployment
• 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
• Continuous Integration
• Continuous Deployment
• 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 antiga!
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 Git CI 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
VPC Subnet VPC Subnet VPC Subnet VPC Subnet
VPC Subnet VPC Subnet VPC Subnet VPC Subnet
Instance Instance
Instance
NAT
Bastion/Chef
ELB ELB
RDS DB Instance
RDS DB Instance Standby (Multi-AZ) Instance
AWS CloudFormation
Amazon CloudWatch
Amazon SNS
Potential RDS DB Instance Read
Replica
Instance Instance
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
VPC Subnet VPC Subnet VPC Subnet VPC Subnet
VPC Subnet VPC Subnet VPC Subnet VPC Subnet
Instance Instance
Instance
NAT
Bastion/Chef
ELB ELB
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
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
VPC Subnet VPC Subnet VPC Subnet VPC Subnet
VPC Subnet VPC Subnet VPC Subnet VPC Subnet
VPC Subnet VPC Subnet VPC Subnet VPC Subnet
Instance Instance
Instance
NAT
Bastion/Chef
ELB ELB
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
VPC Subnet VPC Subnet VPC Subnet VPC Subnet
VPC Subnet VPC Subnet VPC Subnet VPC Subnet
VPC Subnet VPC Subnet VPC Subnet VPC Subnet
Instance Instance
Instance
NAT
Bastion/Chef
ELB ELB
RDS DB Instance
RDS DB Instance Standby (Multi-AZ) Instance
AWS CloudFormation
Amazon CloudWatch
Amazon SNS
Potential RDS DB Instance Read
Replica
Instance Instance
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
VPC Subnet VPC Subnet VPC Subnet VPC Subnet
VPC Subnet VPC Subnet VPC Subnet VPC Subnet
Instance Instance
Instance
NAT
Bastion/Chef
ELB ELB
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
Ambiente de desenvolvimento
Developers &
Operations
Dev Environment VPC Subnet
DEV WEB ELB Dev 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
Ambiente de desenvolvimento
Developers &
Operations
Dev Environment VPC Subnet
DEV WEB ELB Dev 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
Git CI Server
Pre-commit Hook
Testing Environment Subnet
CI Workers
Dev Environment VPC Subnet
DEV WEB ELB Dev 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 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 -v\n", "yum update -y aws-cfn-bootstrap\n”, "curl -L http://www.opscode.com/chef/install.sh | bash\n", "cd /etc/chef\n", "/usr/bin/wget http://",{ "Ref" : "ChefServerIP" },"/chef/validation.pem\n", "/usr/bin/wget http://",{ "Ref" : "ChefServerIP" },"/chef/client.rb\n", "/bin/chown -R chef:chef /etc/chef\n",
Ambientes de desenvolvimento & teste
Developers &
Operations Internal
Git CI Server
Pre-commit Hook
Testing Environment Subnet
CI Workers
Dev Environment VPC Subnet
DEV WEB ELB Dev 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
Git CI Server
Pre-commit Hook
Testing Environment Subnet
CI Workers
Dev Environment VPC Subnet
DEV WEB ELB Dev 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
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
Ambientes de desenvolvimento & teste
Developers &
Operations Internal
Git CI Server
Pre-commit Hook
Testing Environment Subnet
CI Workers
Dev Environment VPC Subnet
DEV WEB ELB Dev 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
Elastic Beanstalk ou OpsWorks
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
VPC Subnet VPC Subnet VPC Subnet VPC Subnet
VPC Subnet VPC Subnet VPC Subnet VPC Subnet
Instance Instance
Instance
NAT
Bastion/Chef
ELB ELB
RDS DB Instance
RDS DB Instance Standby (Multi-AZ) 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!
Ahn….na AWS você pode!
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
Ambientes de desenvolvimento & teste
Developers &
Operations Internal
Git CI Server
Pre-commit Hook
Testing Environment Subnet
CI Workers
Dev Environment VPC Subnet
DEV WEB ELB Dev 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
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
• Experimentamos outras soluções de hospedagem, aparentemente mais 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çamento pré-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
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
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
EC2 Instances
ELB
50% 50%
DynamoDB MySQL RDS Instance
ElastiCache Cache Node
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
EC2 Instances
ELB
0% 100%
DynamoDB MySQL RDS Instance
ElastiCache Cache Node
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
EC2 Instances
ELB
0% 100%
DynamoDB MySQL RDS Instance
ElastiCache Cache Node
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
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
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
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ção da infraestrutura orientada pelo versionamento semântico das aplicações
• Parâmetros de infraestrutura configurados e 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
METRICASDO 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
Recommended