Containers para Software! A mais nova revolução, trazida ao mundo pela Dockers, rodando hoje na AWS. Venha conhecer esta inovadora e revolucionária tecnologia que vai mudar a forma como você desenvolve e implementa software.
9. Static website Web frontendUser DB Queue Analytics DB
VM de
desenvolvimen
Servidor de QA Public Cloud
Notebook
do
Docker é um sistema de envio de container para
código
Variedadede
Stacks
Variedadede
ambientes
Cluster de
produção
Data Center
do Cliente
Serviçose
aplicaçõesinteragem
apropriadamente?
Consigomigrar
rápidoesem
problemas?
…que pode ser manipulado
e operado de forma
consistente em virtualmente
qualquer plataforma de
hardware
Uma engine que permite
qualquer conteúdo ser
encapsulado como um
container leve, portável
e auto-suficiente…
10. Static website
Web frontend
Background workers
User DB
Analytics DB
Queue
VM de
desenvolvim
ento
Servidor de
QA
Servidor
único de
Prod
Cluster
interno
Public Cloud
Notebook do
funcionário
Servidores
do cliente
Docker elimina a matriz do inferno
11. Quais os benefícios?
Negócio:
• Redução de custos
• Velocidade (Time to Market)
• Confiança e previsibilidade de entrega
Área de TI:
• Separação de responsabilidades mais clara
• Portabilidade de aplicações
• Liberdade para devs e times de produto sem perder o controle
• Aumento de velocidade (containers são leves)
• Aumento da confiança (containers são padronizados)
• Uso eficiente de recursos em escala (usando um cluster manager)
12. O que é um container?
?!?
• Conjunto de features do kernel do Linux que isolam processos, user
ids, memória, I/O e network
• “chroot com esteróides!”
• Alocação de recursos granular
• Namespaces, Cgroups
• Essas features existem e tem sido usadas há anos (Solaris “Zones”)
14. Sobre Docker
• Docker é uma plataforma completa para se construir e
rodar containers
• Foi disponibilizado como open source em Março de
2013 pela dotCloud (atualmente Docker, Inc.)
• Inclui um CLI, ferramentas para criação de imagens de
containers (Dockerfiles), e um repositório para hospedar
containers
17. Containers na AWS
• AWS é um complemento natural ao uso de containers
por sua vasta gama de serviços escaláveis de
infraestrutura, onde seus containers podem rodar.
• AWS Elastic Beanstalk, AWS OpsWorks, e Amazon EC2
Container Service provém suporte integrado ao Docker.
• Oportunidade para usar containers em Dev, Test, e
Produção.
18. AWS Elastic Beanstalk
• AWS Elastic Beanstalk é uma camada de gerenciamento para serviços
AWS como Amazon EC2, Amazon RDS, e Elastic Load Balancing
• Remove o requisito de lançar manualmente os recursos AWS necessários
para rodar sua aplicação
• Você faz upload da sua aplicação enquanto o Elastic Beanstalk cuida dos
detalhes de provisionar capacidade, balancamento de carga, escalabilidade
e monitoramento da saúde da aplicação
• Suporte a aplicações Docker multi-container (em conjunto com Amazon
EC2 Container Service)
24. AWS Elastic Beanstalk
Zip com contexto da aplicação
App.zip
-------------------------------
|-- Dockerfile
|-- Dockerrun.aws.json
Dockerfile
Dockerrun.aws.json
25. OpsWorks
• Criado para funcionar com o OpsCode Chef, que permite deploy e
gerenciamento de aplicações diversas
• Permite a definição de stacks para configurar a infraestrutura em
AWS usando “receitas” Chef
• Uma “stack” pode conter um conjunto de recursos que servem a um
propósito único, como uma aplicação web
• As “receitas” Chef utilizadas no AWS OpsWorks podem instalar o
Docker nas instâncias e referenciar um Dockerfile para configurar o
container apropriadamente
26. Adicionar layer customizada
• Criado para funcionar com o OpsCode Chef, que permite deploy e
gerenciamento de aplicações diversas
• Permite a definição de stacks para configurar a infraestrutura em
AWS usando “receitas” Chef
• Uma “stack” pode conter um conjunto de recursos que servem a um
propósito único, como uma aplicação web
• As “receitas” Chef utilizadas no AWS OpsWorks podem instalar o
Docker nas instâncias e referenciar um Dockerfile para configurar o
container apropriadamente
31. EC2 Container Service
• Compatível com Docker
• Gerenciamento de Cluster facilitado
• Alta performance
• Eficiência de uso de recursos
• Extensível
• Seguro
32. ECS: Conceitos-chave
• Cluster
• AMIs “Container-Enabled”
• Agente ECS
• Gerenciador do cluster (Cluster Manager)
• Agendador de container (Container Scheduler)
• Definições de Tarefas (Tasks/Task)
34. Aplicações distribuídas
• Containers habilitam arquiteturas de micro-serviços
• Permite mapeamento de função por container
• Aderente aos conceitos de baixo acoplamento (loose
coupling), elasticidade, escalabilidade e outros
princípios de aplicações distribuídas
• Permite deployments, provisionamento e atualizações
rápidas
37. About MercadoLibre
• Operations in 13 countries.
• Leaders in the region.
• 6.5 Billion MktCap (NASDAQ: MELI).
• 2600 Employees (600 engineers).
• 8th e-commerce site by traffic in the world.
38. About Me
• Darío Simonassi
– Architecture Sr. Manager
– MercadoLibre.Com
– @ldsimonassi
42. MercadoLibre’s engineering teams
• Small teams.
• Full control & Ownership:
– Product decisions
– Development.
– QA (Automated).
– Deployment.
– Alerts & Production management.
43. Current technology stack
opportunities
• Great for:
– Empowerment.
– Flexibility.
• Opportunities:
– Complex.
– Lot of tools.
– Lot of knowledge required.
– Policies are difficult to enforce.
46. Operations
• Code
• Code, run, play & execute tests locally.
• Deploy
• CI, Fast & Safe code shipping.
• Monitoring & Alerting
• Know when something is going wrong.
• Understand what is going wrong.
• Notify the correct person.
• Follow up.
• Troubleshooting
• Take action to solve a problem.
47. Code
• Developers machine setup.
• Local setup for DB & Mock servers.
• Versions headache.
• Environment changes propagation.
• CI environment consistency.
• Developers don’t manage CI servers.
• What works in my machine must work in the CI.
• Environments fidelity.
• Use same libraries, same binaries.
49. Code: Fury CLI Commands
• $> fury get homepage
• Will clone the homepage project repository.
• $> fury run
• Will run the webserver with all the dependencies locally.
• $> fury test
• Will run tests locally with all the dependencies.
• $> fury create-version 0.1
• Will push the code.
• Will tag the version.
• Will trigger CI and open browser window.
50. Deploy
• Risk of downtime
– Smooth transitions between versions.
– Real time metrics.
– Fast rollback.
• Reliability & Fidelity
– New Infrastructure vs Update scripts.
• Hardware usage efficiency
– Autoscaling.
51. Production Instance
• No Updates
• New application version -> New hardware
• No States
• No states like: on_duty, deploying.
• Instances are always supposed to be working.
• Single AMI
• Only one AMI that will run a container inside.
• The same container for the entire instance life.
• Minimal
• Only required stuff in this AMI.
63. Monitoring & Alerting
• Alerting:
– To know fast and reliably when something is going wrong:
• No false alarms.
• Instance health no longer suitable.
• Notify the right persons & follow up.
• Diagnostics:
– To be able to understand what is going wrong.
• Metrics
– Multidimensional.
– Real-Time.
• Logs.
64. Alerting: Based on metrics
• HTTP:
– Errors.
– Response time.
• Infrastructure:
– How many machines stopped working unexpectedly during
the last hour?
• Business:
– Is the application doing what it should?
– Compare vs yesterday / last week.
67. Alerting: No false alarms
• Reasonable thresholds.
– Undesirable but expected situations shouldn’t be an alert.
– You won’t improve your application SLA on Saturday 3AM.
• Different thresholds for different periods.
– Alert on > 25% errors in the last minute.
– Alert on > 5% errors in the last hour.
– Alert on > 0.2% errors in the last day.
68. Alerting: Notifications.
• Teams manage the duty schedule.
• Escalation & Backup is necessary.
• Automatic Alerts follow up.
• Flexibility & Mobile.
– “I’m going to watch a movie, can someone get my
duties for the next three hours?”
70. Diagnostics: Metrics
• Real Time.
– You’ll be changing things and you’ll need feedback.
• Multidimensional
– Tagged metrics will really make the difference when trying
to identify the failure.
72. Diagnostics: Logs
• Useful logs
– Events.
– Unusual errors.
– Avoid traces.
• Tagged
– Good tagging will allow you to make sense of the logged
data.
74. Troubleshooting: Actions
• Deploy
– We’ve deployed a bug.
– We need to rollback fast or deploy a new version fast.
• Scale
– There is a performance issue, we need to increase the compute power.
– There is a specific bug, we need to block traffic.
• Restart
– There is a leak (memory, connections etc).
– Application restarting is a suitable yet temporary workaround for
those cases.
75. Fury: Key AWS Services
• Networking & Availability:
– SDN (Network Isolation/Segmentation)
– Multi AZ
– Direct Connect (OnPremise DC Interop).
• Deploy:
– ELB, ASG, CloudWatch.
• Cache:
– ElasticCache, DynamoDB.
• Resources Orchestration:
– CloudFormation (For external resources too).