1.
Versionando sua infraestrutura: Benefícios práticos

2.
Sobre a Rivendel
• Fundada em Maio/2013
• Especialistas em Cloud/DevOps
• Empresa mais qualificada em Microsoft Azure e Amazon Web
Services do Brasil
• 110+ clientes atendidos em 3 anos

3.
Bruno Almeida
• Fundador e COO da Rivendel Tecnologia
• Cloud desde 2010
• Cultura DevOps implantada em 110+ clientes

4.
SysAdmin Tools 1999 ~ 2009
Write-only

5.
Deploy 1999 ~ 2009
Documento de GMUD ou documento de deploy
Manualmente
em horário agendado

6.
Redefinindo SysAdmin
• Menos tempo com equipamentos, mais
com aplicações
• Habilidades de Desenvolvimento
• Intenso foco em monitoramento, segurança,
tolerância a falhas, tuning, orquestração e
processos eficientes de deploy

7.
Algumas tecnologias…

8.
SysAdmin / DevOps
Write and update

9.
• Modelo client-server/pull
• DSL própria
• Escrito em Python, usa configs YAML: Ansible Playbooks
• Sem dependências nos endpoints
• Modelo push com ssh, sem agentes, sem master
• Possibilidade de receitas chef-solo
• Receitas escritas em Ruby
• Modelo client-server/pull

10.
• Automação de ambientes locais multi-plataforma
• Ambientes locais montados de forma semelhante aos outros ambientes
• Configuração versionável

11.
Por que orquestrar?
• Vou lembrar de tudo o que tem que ser instalado nesse novo servidor?
• Incluindo aquela biblioteca específica?
• Incluindo o tuning de SO e servidor de aplicação?
• Incluindo melhorias de segurança (hardening linux)?
Ok, você pode até lembrar. Mas você ficará
eternamente na empresa?
O que tem demais? É só um inofensivo apache…

12.
Pois é…
• O desafio é replicar a obra de arte feita
Existe a documentação no confluence, na wiki, no word, mas tenta executá-la…
Veja se funciona?
Não funciona…

13.
Alguns dos problemas mais comuns
Deu problema em produção, o sysadmin que configurou isso não está mais
na empresa…
Versão de sistemas operacionais antigos como Debian 5, Ubuntu 10…
Algumas sistemas legados como Oracle Forms Reports (versão de 2002)
PHP 5.2 em aplicação magento sendo atualizada constantemente…
São sistemas legados (ou não), indo pra Cloud (privada ou pública), ou seja, você
não vai fazer a gambiarra de só gerar uma compactação e levar como esta, vai?

14.
O que propomos?
• Faça uma receita simples
• Faça suas próprias receitas, até que com a experiência você
consiga usar bem as receitas prontas da comunidade
• Teste suas receitas em Homologação antes de aplicá-las em
Produção. A infraestrutura agora é código.
• Defina um padrão de nomenclatura e organização

15.
Você quer que seu ambiente de Dev, Hmg e
Prod sejam identicos, certo?
• A orquestração DEVE ler variáveis de ambiente
• De acordo com o environment, os arquivos de configuração aplicam os
parâmetros corretamente (de banco de dados por exemplo)
• Não adianta nada você ter orquestração, e suas receitas de Dev , Hmg e Prod
serem diferentes.
Por favor, um único repositório…

16.
+ Problemas…
Não adianta nada você fazer tudo por receita e as versões dos pacotes serem
diferentes
Por favor, um único repositório e com sequência correta…
Deu um problema no servidor de aplicação, ai você alterou alguma
configuração ou biblioteca. Você precisa atualizar a receita…

17.
É mais seguro?
É mais seguro, pois o auditor pode ler diretamente sua receita
Você pode demonstrar o processo de destruir servidores e criar novos a partir
das receitas
Se o seu servidor for invadido, você pode remover este e subir outros novos
rapidamente, concorda?
SIM

18.
O ideal é usar um orquestrados pra subir
minha stack inteira?
NÃO
O melhor papel para o orquestrador é configurar os recursos dentro do sistema
operacional…
Para provisionar seu recursos automaticamente na AWS, use CloudFormation…
Para provisionar seu recursos automaticamente no Azure, use Azure Resource
Manager templates…

19.
Alguns cases de sucesso
• Chef: Migração de grande cliente do meio de comunicação, com um site de
esportes, usando Chef. Configuração e migração de Stack Ruby + PHP com 8
aplicações.
• Ansible: Migração do site de viagens HotelUrbano usando tecnologia Ansible.
• Puppet: Ambiente de Desaster Recovery do maior site de venda de vinhos
on-line da América Latina usando puppet.

20.
Ter orquestração significa que eu organizei
meu processo de deploy?
NÃO
O objetivo com o orquestrador, é que você consiga reconfigurar o seu ambiente
de aplicação. Não significa que ele vai resolver seu processo de deploy...
Desenhe seu processo de deploy…

21.
Automatizar deploy?
O processo de deploy bem feito, é uma boa prática de DevOps,
então para isso, optamos por usar
- Entrega contínua (necessita de ação manual)
- Deploy contínuo (não necessita de ação manual)

22.
Ciclo de testes
Como Deve ser feito o ciclo de testes?
O ideal é que o ciclo de testes, contenha testes unitários e
funcionais.
Caso seja alterada uma funcionalidade crítica, o ideal é ser
obrigatório a execução de teste de carga

23.
O que o teste de carga traz de benefícios?
Com o teste de carga, é possível sabermos nos cenários de
infraestrutura, quantas requisições simultâneas conseguimos
atender com os determinados tamanhos de infraestrutura, e
também fazer o tuning do ambiente para ter melhor
performance.

24.
Rollback ?
Um erro que muitos cometem, é não ter processo de rollback no
ciclo de deploy…
Uma das opções pra isso, é ter o blue / green deployment

25.
Blue / Green - Visão de release

26.
Blue / Green - Visão de chaveamento

27.
Como sei o que mudou no ambiente?
Monitoramento…

28.
Resultados
• Menos operando e mais tempo operacionalizando;
• Menos risco de falhas por inconsistência;
• Menos dependências de pessoas;
• Troubleshooting mais rápido e eficiente;
• Mais clareza (e confiança) para a área de negócios;

29.
Casos de sucesso
BioRitmo - APP franquias
Para cada unidade da BioRitmo, havia 1 servidor
de aplicação e um de banco de dados, migramos
para uma estrutura com Chef + Opsworks,
centralizando toda a estrutura no mesmo ambiente.
Reduzimos o custo para 40% do total, e
aumentamos o tempo de disponibilidade da
aplicação que antes era de 98% na métrica geral
para 100% no último mês

30.
Casos de sucesso
HotelUrbano
A aplicação do hotelurbano estava em ambiente
OnPrimeses, com versões distintas de servidor de
aplicação, sem tuning e sem documentação de
ambiente. Este foi migrado para ambiente Cloud, onde
assim o tempo de indisponibilidade foi reduzido,
conseguindo 100% de UPTime na BlackFriday de 2014.

31.
bruno.almeida@rivendel.com.br
Obrigado!