DevOps na prática – entrega de software confiável e automatizada

Aproximadamente 55.225 palavras.

Página 1

Página 2

Nenhuma parte deste livro poderá ser reproduzida, nem transmitida, sem autorização prévia por escrito da editora, sejam quais forem os meios:

fotográficos, eletrônicos, mecânicos, gravação ou quaisquer outros.

Casa do Código Livros para o programador Rua Vergueiro, 3185 – 8º andar 04101-300 – Vila Mariana – São Paulo – SP – Brasil

Página 3

Casa do Código "Para meu pai, que me introduziu ao mundo da computação e é meu exemplo de vida.”

Página 4

Página 5

Casa do Código Prefácio Jez Humble Pouco depois que me formei na universidade em 1999, eu fui contratado por umastart-upem Londres. Meu chefe, Jonny LeRoy, ensinou-me a prática de implantaç ão contínua: quando terminávamos uma nova funcionalidade, fazíamos alguns testes manuais rápidos na nossa estaç ão de trabalho e, em seguida, copiávamos osscriptsASP relevantes por FTP para o servidor de produç ão – uma prática que eu não recomendaria hoje, mas que teve a van- tagem de nos permitir mostrar novas ideias para nossos usuários muito rapi- damente.

Em 2004, quando entrei naThoughtWorks, meu trabalho era ajudar em- presas a entregar software e eu fiquei chocado ao descobrir que prazos de me- ses ou mesmo anos eram comuns. Felizmente, tive a sorte de trabalhar com várias pessoas inteligentes em nossa indústria que estavam explorando for- mas de melhorar estes resultados, ao mesmo tempo aumentando a qualidade e melhorando a nossa capacidade de servir nossos usuários. As práticas que desenvolvemos também tornaram a vida melhor para as pessoas com quem estávamos trabalhando (por exemplo, não precisávamos mais fazerdeploys fora do horário comercial) – uma indicaç ão importante de que você está fa- zendo algo certo. Em 2010, Dave Farley e eu publicamosEntrega Contínua, onde descrevemos os princípios e práticas que tornam possível entregar pe- quenas alterações incrementais, de forma rápida, barata e com baixo risco.

No entanto, o nosso livro omite os detalhes práticos do que você re- almente precisa para começar a criar uma pipeline de entrega, como pôr em prática sistemas de monitoramento e infraestrutura como código, além dos outros passos práticos importantes necessários para implementar entrega contínua. Por isso estou muito contente que o Danilo escreveu o livro que está iii

Página 6

Casa do Código em suas mãos, que eu acho ser uma contribuiç ão importante e valiosa para a nossa área. O Danilo está profundamente envolvido em ajudar organizações a implementar as práticas de entrega contínua há vários anos e tem ampla experiência, e eu tenho certeza de que você vai achar o seu livro prático e informativo. Desejo-lhe tudo de melhor na sua jornada.

Página 7

Casa do Código Sobreolivro Entregar software em produç ão é um processo que tem se tornado cada vez mais difícil no departamento de TI de diversas empresas. Ciclos longos de teste e divisões entre as equipes de desenvolvimento e de operações são alguns dos fatores que contribuem para este problema. Mesmo equipes ágeis que produzem software entregável ao final de cada iteraç ão sofrem para chegar em produç ão quando encontram estas barreiras.

DevOps é um movimento cultural e profissional que está tentando que- brar essas barreiras. Com o foco em automaç ão, colaboraç ão, compartilha- mento de ferramentas e de conhecimento, DevOps está mostrando que de- senvolvedores e engenheiros de sistema têm muito o que aprender uns com os outros.

Neste livro, mostramos como implementar práticas de DevOps e Entrega Contínua para aumentar a frequência de deploys na sua empresa, ao mesmo tempo aumentando a estabilidade e robustez do sistema em produç ão. Você vai aprender como automatizar o build e deploy de uma aplicaç ão web, como automatizar o gerenciamento da infraestrutura, como monitorar o sistema em produç ão, como evoluir a arquitetura e migrá-la para a nuvem, além de conhecer diversas ferramentas que você pode aplicar no seu trabalho.

Página 8

Página 9

Casa do Código Agradecimentos Ao meu pai, Marcos, por ser sempre um exemplo a seguir e por ir além tentando acompanhar os exemplos de código mesmo sem nenhum conhe- cimento no assunto. À minha mãe, Solange, e minha irmã, Carolina, pelo incentivo e por corrigirem diversos erros de digitaç ão e português nas ver- sões preliminares do livro.

À minha parceira e melhor amiga, Jenny, pelo carinho e apoio durante as diversas horas que passei trabalhando no livro.

Ao meu editor, Paulo Silveira, pela oportunidade, pela confiança e por saber como dar um puxão de orelha ou um incentivo na hora certa para que o livro se tornasse uma realidade. À minha revisora e amiga, Vivian Matsui, por corrigir todos os meus erros de português.

Aos meus revisores técnicos: Hugo Corbucci, Daniel Cordeiro e Carlos Vilella. Obrigado por me ajudarem a encontrar formas melhores de explicar conceitos difíceis, pela opinião sobre os termos difíceis de traduzir, por ques- tionarem minhas decisões técnicas e por me ajudarem a melhorar o conteúdo do livro.

Aos colegas Prasanna Pendse, Emily Rosengren, Eldon Almeida e outros membros do grupo “Blogger’s Bloc” naThoughtWorks, por me incentivarem a escrever mais e pelofeedbacknos capítulos iniciais, mesmo não entendendo a língua portuguesa.

Aos meus inúmeros outros colegas de trabalho daThoughtWorks, em es- pecial Rolf Russell, Brandon Byars e Jez Humble, que ouviram minhas ideias sobre o livro e me ajudaram a escolher a melhor forma de abordar cada as- sunto, capítulo por capítulo.

vii

Página 10

Casa do Código Por fim, a todos que contribuíram de forma direta ou indireta na escrita deste livro.

Muito obrigado!

viii

Página 11

Casa do Código Sobreoautor Danilo Sato começou a programar ainda criança, quando muitas pessoas ainda não tinham computador em casa. Em 2000 entrou no curso de bacha- relado em Ciência da Computaç ão da Universidade de São Paulo, começando sua carreira como administrador da Rede Linux do IME-USP durante 2 anos.

Ainda na graduaç ão começou a estagiar como desenvolvedor Java/J2EE e teve seu primeiro contato com Métodos Ágeis na disciplina de Programaç ão Ex- trema (XP).

Iniciou o mestrado na USP logo após a graduaç ão e, orientado pelo Pro- fessor Alfredo Goldman, defendeu em Agosto de 2007 a dissertaç ão “Uso Efi- caz de Métricas em Métodos Ágeis de Desenvolvimento de Software” [16].

Durante sua carreira, Danilo atuou como consultor, desenvolvedor, admi- nistrador de sistemas, analista, engenheiro de sistemas, professor, arquiteto e coach, tornando-se consultor líder daThoughtWorks em 2008, onde traba- lhou em projetos Ruby, Python e Java no Brasil, EUA e no Reino Unido. Atu- almente tem ajudado clientes a adotar práticas de DevOps e Entrega Contínua para reduzir o tempo entre a concepção de uma ideia e sua implementaç ão com código rodando em produç ão.

Além da carreira profissional, Danilo também tem experiência como pa- lestrante em conferências nacionais e internacionais, apresentando palestras eworkshopsna: XP 2007/2009/2010, Agile 2008/2009, Ágiles 2008, Cone- xão Java 2007, Falando em Agile 2008, Rio On Rails 2007, PyCon Brasil 2007, RejectConf SP 2007, Rails Summit Latin America 2008, Agile Brazil 2011/2012/2013, QCon SP 2011/2013, RubyConf Brasil 2012/2013, além de ser o fundador do Coding Dojo @ São Paulo e organizador da Agile Brazil 2010, 2011 e 2012.

Página 12

Página 13

Casa do Código

Sumário

Sumário 1 Introdução 1.1 Abordagem tradicional página 2
1.2 Uma abordagem alternativa: DevOps e entrega contínua. . 4 1.3 Sobre o livro página 6
2 Tudo começa em produção 11 2.1 Nossa aplicaç ão de exemplo: a loja virtual página 12
2.2 Instalando o ambiente de produç ão página 15
2.3 Configurando dependências nos servidores de produç ão. . 20 2.4 Build e deploy da aplicaç ão página 28
3 Monitoramento 35 3.1 Instalando o servidor de monitoramento página 36
3.2 Monitorando outros servidores página 42
3.3 Explorando os comandos de verificaç ão do Nagios página 44
3.4 Adicionando verificações mais específicas página 48
3.5 Recebendo alertas página 55
3.6 Um problema atinge produç ão, e agora? página 59
4 Infraestrutura como código 61 4.1 Provisionamento, configuraç ão ou deploy? página 62
4.2 Ferramentas de gerenciamento de configuraç ão página 65
4.3 Introduç ão ao Puppet: recursos, provedores, manifestos e de- pendências página 67

Página 14

Sumário

Casa do Código 4.4 Reinstalando o servidor de banco de dados página 74
4.5 Reinstalando o servidor web página 82
4.6 Fazendo deploy da aplicaç ão página 87
5 Puppet além do básico 97 5.1 Classes e tipos definidos página 97
5.2 Empacotamento e distribuiç ão usando módulos página 101
5.3 Refatorando o código Puppet do servidor web página 105
5.4 Separaç ão de responsabilidades: infraestrutura vs. aplicaç ão115 5.5 Puppet forge: reutilizando módulos da comunidade página 119
5.6 Conclusão página 126
6 Integraç ão contínua 127 6.1 Práticas de engenharia ágil página 128
6.2 Começando pelo básico: controle de versões página 128
6.3 Automatizando o build do projeto página 131
6.4 Testes automatizados: diminuindo risco e aumentando a con- fiança página 133
6.5 O que é integraç ão contínua? página 139
6.6 Provisionando um servidor de integraç ão contínua página 142
6.7 Configurando o build da loja virtual página 147
6.8 Infraestrutura como código para o servidor de integraç ão contínua página 158
7 Pipeline de entrega 165 7.1 Afinidade com a infraestrutura: usando pacotes nativos. . . 166 7.2 Integraç ão contínua do código de infraestrutura página 184
7.3 Pipeline de entrega página 198
7.4 Próximos Passos página 205
8 Tópicos avanç ados 207 8.1 Fazendo deploy na nuvem página 209
8.2 DevOps além das ferramentas página 230

xii

Página 15

Casa do Código

Sumário

8.3 Sistemas avançados de monitoramento página 231
8.4 Pipelines de entrega complexas página 234
8.5 Gerenciando mudanças no banco de dados página 234
8.6 Orquestraç ão de deploy página 235
8.7 Gerenciando configurações por ambiente página 236
8.8 Evoluç ão arquitetural página 238
8.9 Segurança página 241
8.10 Conclusão página 242

Bibliografia 246 xiii

Página 16

Página 17

Capítulo1 Introduç ão Com o avanço da tecnologia, software tem se tornado parte fundamental do dia a dia de muitas empresas. Ao planejar suas férias em família – agendando quarto em hotéis, comprando passagens de avião, realizando transações fi- nanceiras, enviando SMS ou compartilhando as fotos da viagem – você in- terage com diversos sistemas de software. Quando um desses sistemas está fora do ar, o problema não é apenas da empresa que está perdendo negócios, mas também dos usuários que não conseguem realizar suas tarefas. Por esse motivo é importante investir na qualidade e estabilidade do software desde o momento em que a primeira linha de código é escrita até o momento em que ele está rodando em produç ão.

Página 18

1.1. Abordagem tradicional Casa do Código 1.1 Abordagem tradicional Metodologias de desenvolvimento de software evoluíram, porém o processo de transformar ideias em código ainda envolve diversas atividades como: le- vantamento de requisitos,design, arquitetura, implementaç ão e teste. Os Mé- todos Ágeis de desenvolvimento de software surgiram no final da década de 90 propondo uma nova abordagem para organizar tais atividades. Ao invés de realizá-las em fases distintas – modelo conhecido como processo em cas- cata – elas acontecem em paralelo o tempo todo, em iterações curtas. Ao final de cada iteraç ão, o software se torna mais e mais útil, com novas funcionali- dades e menosbugs, e o time decide junto com o cliente qual a próxima fatia a ser desenvolvida.

Assim que o cliente decide que o software está pronto para ir ao ar e o código é colocado em produç ão, os verdadeiros usuários começam a usar o sistema. Nesse momento, diversas outras preocupações se tornam relevantes:

suporte, monitoramento, segurança, disponibilidade, desempenho, usabili- dade, dentre outras. Quando o software está em produç ão, a prioridade é mantê-lo rodando de forma estável. Em casos de falha ou desastres, o time precisa estar preparado para reagir de forma proativa e resolver o problema rapidamente.

Devido à natureza dessas atividades, muitos departamentos de TI pos- suem uma divisão clara de responsabilidades entre otime de desenvolvi- mentoe otime de operaç ões. Enquanto o time de desenvolvimento é res- ponsável por criar novos produtos e aplicações, adicionar funcionalidades ou corrigirbugs, o time de operações é responsável por cuidar desses produtos e aplicações em produç ão. O time de desenvolvimento é incentivado a intro- duzir mudanças, enquanto o time de operações preza pela estabilidade.

À primeira vista, esta divisão de responsabilidades parece fazer sentido.

Cada equipe possui objetivos e formas de trabalho diferentes. Enquanto o time de desenvolvimento trabalha em iterações, o time de operações precisa reagir instantaneamente quando algo dá errado. Além disso, as ferramentas e o conhecimento necessário para trabalhar nessas equipes são diferentes. O time de desenvolvimento evolui o sistema introduzindo mudanças. Por outro lado, o time de operações evita mudan ças, pois elas trazem um certo risco à estabilidade do sistema. Cria-se então um conflito de interesse entre essas

Página 19

Casa do Código Capítulo 1. Introduç ão duas equipes.

Uma vez que o conflito existe, a forma mais comum de gerenciar essa relação é através da criaç ão de processos que definem o modo de trabalho e as responsabilidades de cada equipe. De tempos em tempos, a equipe de desenvolvimento empacota o software que precisa ir para produç ão, escreve documentaç ão explicando como configurar o sistema, como realizar a insta- lação em produç ão e repassa a responsabilidade para o time de operações. É comum o uso de sistemas de controle deticketspara gerenciar a comunica- ção entre as equipes assim como a definiç ão de acordos de nível de serviço (service-level agreementsou SLAs) para garantir que osticketssejam proces- sados e respondidos em um tempo adequado.

Essa passagem de bastão – também conhecida em inglês pelo termohand- off– cria um gargalo no processo de levar código do desenvolvimento e teste para produç ão. É comum chamar esse processo dedeployem ambiente de produç ão. Em português é até possível ouvir o neologismodeploiar, ou então o termo correto em português, que seria “implantar”.

Com o passar do tempo, o processo tende a se tornar mais e mais burocrá- tico, fazendo com que a frequência dedeploysdiminua. Com isso, o número de mudanças introduzidas em cadadeploytende a acumular, aumentando também o risco de cadadeploye criando o ciclo vicioso mostrado na figura 1.1.

Figura 1.1: Ciclo vicioso entre desenvolvimento e operações Esse ciclo vicioso não só diminui a habilidade da empresa de responder rapidamente a mudanças no negócio, como também impacta etapas anterio-

Página 20

1.2. Uma abordagem alternativa: DevOps e entrega contínua Casa do Código res do processo de desenvolvimento. A separaç ão entre os times de desenvol- vimento e de operações, o hand-offde código existente entre eles e a cerimô- nia envolvida no processo dedeployacabam criando o problema conhecido como “a Última Milha” [17].

A última milha se refere à fase final do processo de desenvolvimento que acontece após o software atender todos os requisitos funcionais mas antes de ser implantado em produç ão. Ela envolve várias atividades para verificar se o que vai ser entregue é estável ou não, como: testes de integraç ão, testes de sis- tema, testes de desempenho, testes de segurança, homologaç ão com usuários (também conhecido comoUser Acceptance TestsouUAT), testes de usabili- dade, ensaios dedeploy, migraç ão de dados etc.

É fácil ignorar a última milha quando a equipe está produzindo e demons- trando funcionalidades novas a cada uma ou duas semanas. Porém, são pou- cas as equipes que de fato fazemdeployem produç ão ao final de cada itera- ção. Do ponto de vista do negócio, a empresa só terá retorno no investimento quando o software estiver realmente rodando em produç ão. O problema da última milha só é visível quando se toma uma visão holística do processo.

Para resolvê–lo é preciso olhar além das barreiras impostas entre as diferentes equipes envolvidas: seja a equipe de negócios, a equipe de desenvolvimento ou a equipe de operações.

1.2 Uma abordagem alternativa: D evOps e en- trega contínua Muitas empresas de sucesso na internet – como Google, Amazon, Netflix, Flickr, GitHub e Facebook – perceberam que a tecnologia pode ser usada a seu favor e que o atraso nodeploypara produç ão significa atrasar sua habilidade de competir e se adaptar a mudanças no mercado. É comum que elas realizem dezenas ou até centenas dedeployspor dia!

Essa linha de pensamento que tenta diminuir o tempo entre a criaç ão de uma ideia e sua implementaç ão em produç ão é também conhecida como “Entrega Contínua” [6] e está revolucionando o processo de desenvolvi- mento e entrega de software. Alguns autores preferem utilizar o termo em inglês,continuous delivery.

Página 21

Casa do Código Capítulo 1. Introduç ão Quando o processo dedeploydeixa de ser uma cerimônia e passa a se tornar algo corriqueiro, o ciclo vicioso da figura1.1se inverte completamente.

O aumento da frequência dedeploysfaz com que a quantidade de mudanças em cadadeploydiminua, reduzindo também o risco associado com aquele deploy. Esse benefício não é algo intuitivo, porém quando algo dá errado é muito mais fácil descobrir o que aconteceu, pois a quantidade de fatores que podem ter causado o problema é menor.

No entanto, a diminuiç ão do risco não implica na remoção completa dos processos criados entre as equipes de desenvolvimento e de operações. O segredo que permite a inversão do ciclo é a automatizaç ão desse processo, conforme mostra a figura1.2. Automatizar o processo dedeploypermite que ele seja executado a qualquer momento de forma confiável, removendo o risco de um erro humano causar problemas.

Figura 1.2: Práticas de DevOps ajudam a quebrar o ciclo vicioso através da automaç ão de processos Investir em automatizaç ão não é uma ideia nova, muitas equipes já es- crevem testes automatizados como parte do processo de desenvolvimento de software. Práticas como o desenvolvimento dirigido a testes (Test-Driven De- velopmentou TDD) [3] ou a integraç ão contínua [12] – que será discutida em mais detalhes no capítulo6– são comuns e amplamente aceitas na comuni- dade de desenvolvimento. Esse foco em automaç ão de testes, juntamente com a criaç ão de equipes multidisciplinares, ajudou a quebrar a barreira existente entre desenvolvedores, testadores e analistas de negócio, criando uma cultura de colaboraç ão entre pessoas com habilidades complementares trabalhando

Página 22

1.3. Sobre o livro Casa do Código como parte da mesma equipe.

Inspirado no sucesso dos métodos ágeis, um novo movimento surgiu para levar a mesma linha de raciocínio para o próximo nível: o movimentoDe- vOps. Seu objetivo é criar uma cultura de colaboraç ão entre as equipes de desenvolvimento e de operações que permite aumentar o fluxo de trabalho completado – maior frequência dedeploys– ao mesmo tempo aumentando a estabilidade e robustez do ambiente de produç ão.

Além de uma mudança cultural, o movimento DevOps enfoca bastante nas práticas de automaç ão das diversas atividades necessárias para atacar a úl- tima milha e entregar código de qualidade em produç ão, como: compilaç ão do código, testes automatizados, empacotamento, criaç ão de ambientes para teste ou produç ão, configuraç ão da infraestrutura, migraç ão de dados, mo- nitoramento, agregamento delogse métricas, auditoria, segurança, desempe- nho,deploy, entre outros.

Empresas que aplicaram essas práticas de DevOps com sucesso não enxer- gam mais o departamento de TI como um gargalo mas sim como um agente de capacitaç ão do negócio. Elas conseguem se adaptar a mudanças no mer- cado rapidamente e realizar diversosdeployspor dia de forma segura. Algu- mas delas inclusive fazem com que um novo desenvolvedor realize umdeploy para produç ão no seu primeiro dia de trabalho!

Este livro irá apresentar, através de exemplos reais, as principais práti- cas de DevOps e Entrega Contínua para permitir que você replique o mesmo sucesso na sua empresa. O objetivo principal do livro é aproximar as comuni- dades de desenvolvimento e de operações. Desenvolvedores conhecerão um pouco mais sobre as preocupações e práticas envolvidas para operar e manter sistemas estáveis em produç ão, enquanto engenheiros e administradores de sistema irão aprender como introduzir mudanças de forma segura e incre- mental através de automaç ão.

1.3 Sobre o livro O principal objetivo do livro é mostrar na prática como aplicar os concei- tos e técnicas de DevOps e Entrega Contínua. Por esse motivo, tivemos que escolher quais tecnologias e ferramentas utilizar. Nossa preferência foi usar

Página 23

Casa do Código Capítulo 1. Introduç ão linguagens e ferramentas de código livre e priorizamos aquelas que são bas- tante usadas na indústria.

Você vai precisar usar as ferramentas escolhidas para acompanhar os exemplos de código. Porém, sempre que apresentarmos uma nova ferra- menta, vamos discutir um pouco sobre as outras alternativas, para que você possa pesquisar qual opção faz mais sentido no seu contexto.

Você não precisa de nenhum conhecimento prévio específico para acom- panhar os exemplos. Se você tiver experiência no ecossistema Java ou Ruby, será um bônus. Nosso ambiente de produç ão vai rodar em UNIX (Linux, para ser mais específico), portanto um pouco de conhecimento no uso da linha de comando pode ajudar mas não é obrigatório [13]. De toda forma, você vai ser capaz de rodar todos os exemplos na sua própria máquina, independente se está rodando Linux, Mac ou Windows.

Público alvo Este livro é voltado para desenvolvedores, engenheiros de sistema, admi- nistradores de sistema, arquitetos, gerentes e qualquer pessoa com conheci- mentos técnicos que tenha interesse em aprender mais sobre as práticas de DevOps e Entrega Contínua.

Estrutura dos capítulos O livro foi escrito para ser lido do início ao fim de forma sequencial. De- pendendo da sua experiência com o assunto abordado em cada capítulo, você pode preferir avançar ou seguir em uma ordem diferente.

Nocapítulo2apresentamos a aplicaç ão de exemplo que será usada no restante do livro e as tecnologias usadas para construí-la. Como o foco do li- vro não é no desenvolvimento da aplicaç ão em si, usamos uma aplicaç ão não trivial escrita em Java e usando diversas bibliotecas bem comuns no ecossis- tema Java. Ao final do capítulo, a aplicaç ão vai estar rodando em produç ão.

Com um ambiente de produç ão no ar, nocapítulo3vamos vestir o cha- péu do time de operações e configurar um servidor de monitoramento para detectar falhas e enviar notificações sempre que algum problema for encon- trado. Ao final do capítulo, seremos notificados de que um dos servidores caiu.

Página 24

1.3. Sobre o livro Casa do Código Nocapítulo4vamos reconstruir o servidor problemático, dessa vez de forma automatizada, tratando a infraestrutura como código. Ocapítulo5 é uma continuaç ão do assunto, abordando tópicos mais avançados e refato- rando o código para torná-lo mais modular, legível e extensível.

Após vestir o chapéu do time de operações, iremos voltar nossa aten ção para o desenvolvimento de software. Ocapítulo6discute práticas de enge- nharia ágil que ajudam a escrever código de qualidade. Vamos aprender sobre os diversos tipos de testes automatizados e subir um novo servidor dedicado para fazer integraç ão contínua do código da nossa aplicaç ão.

Apresentamos o conceito da pipeline de entrega nocapítulo7. Coloca- mos o código de infraestrutura na integraç ão contínua e implementamos um processo automatizado para instalar a versão mais nova da aplicaç ão em pro- dução com o simples clique de um botão.

Nocapítulo8migramos o ambiente de produç ão para a nuvem. Por fim, discutimos tópicos mais avançados, com ponteiros para recursos onde você pode pesquisar e aprender mais sobre os assuntos que ficaram de fora do es- copo deste livro.

Convenç ões de código Nos exemplos de código, vamos usar reticências…para omitir as par- tes não importantes. Quando o código já existe, vamos repetir as linhas ao redor da área que precisa ser alterada para dar um pouco de contexto sobre a modificaç ão.

Quando a linha é muito comprida e não couber na página, vamos usar uma barra invertidapara indicar que a próxima linha no livro é a continu- ação da linha anterior. Você pode simplesmente ignorar a barra invertida e continuar digitando na mesma linha.

Nos exemplos na linha de comando, além da barra invertida, usaremos um sinal de maior>na próxima linha para indicar que ela ainda é parte do mesmo comando. Isto é para distinguir o comando que precisa ser digitado da saída que o comando produz quando for executado. Ao executar os co- mandos, você pode simplesmente digitar tudo na mesma linha, ignorando a e o>.

Página 25

Casa do Código Capítulo 1. Introduç ão Mais recursos Criamos um fórum de discussão no Google Groups onde você pode en- viar perguntas, sugestões oufeedbackdireto para o autor. Para se inscrever, acesse a URL:

https://groups.google.com/d/forum/livro-devops-na-pratica Todos os exemplos de código do livro também estão disponíveis no GitHub do autor, nas URLs:

https://github.com/dtsato/loja-virtual-devops https://github.com/dtsato/loja-virtual-devops-puppet

Página 26

Página 27

Capítulo2 Tudocomeçaemproduç ão Ao contrário do que muitos processos de desenvolvimento sugerem, o ciclo de vida do software só deveria começar quando usuários começam a usá-lo.

O problema da última milha apresentado no capítulo1deveria ser a primeira milha, pois nenhum software entrega valor antes de entrar em produç ão. Por isso, o objetivo deste capítulo é subir um ambiente de produç ão completo, começando do zero, e instalar uma aplicaç ão Java relativamente complexa que será usada como ponto de partida para os conceitos e práticas de DevOps apresentados no livro.

Ao final deste capítulo, teremos uma loja virtual web completa rodando – suportada por um banco de dados – que permitirá que usuários se cadas- trem, efetuem compras, além de fornecer ferramentas de administraç ão para gerenciamento do catálogo de produtos, das promoções e do conteúdo dis- ponibilizado na loja virtual.

De que adianta adicionar novas funcionalidades, melhorar o desempe-

Página 28

2.1. Nossa aplicaç ão de exemplo: a loja virtual Casa do Código nho, corrigir defeitos, deixar as telas da loja virtual mais bonitas se isso tudo não for para produç ão? Vamos começar fazendo exatamente essa parte difícil, essa tal de última milha: colocar o software em produç ão.

2.1 Nossa aplicação de exemplo: a loja virtual Como o foco do livro não é no processo de desenvolvimento em si, mas sim nas práticas de DevOps que auxiliam obuild,deploye operaç ão de uma apli- cação em produç ão, usaremos uma aplicaç ão fictícia baseada em um projeto de código aberto. A loja virtual é uma aplicaç ão web escrita em Java sobre a plataformaBroadleaf Commerce(http://www.broadleafcommerce.org/) . O código utilizado neste capítulo e no restante do livro foi escrito com base no site de demonstraç ão oferecido pela Broadleaf e pode ser acessado no seguinte repositório do GitHub:

https://github.com/dtsato/loja-virtual-devops/ OBroadleaf Commerceé uma plataforma flexível que expõe pontos de configuraç ão e de extensão que podem ser customizados para implementar funcionalidades específicas. No entanto, boa parte das funcionalidades pa- drão de um site de compras online como o Submarino ou a Amazon já estão disponíveis, incluindo:

• Navegaç ão e busca no catálogo de produtos; • Páginas de produto com nome, descriç ão, preço, fotos e produtos rela- cionados; • Carrinho de compras; • Processo decheckoutcustomizável incluindo códigos promocionais, dados de cobrança e de entrega; • Cadastro de usuário; • Histórico de compras; • Ferramentas de administraç ão para: catálogo de produtos, promoções, preços, taxas de frete e páginas com conteúdo customizado.

Página 29

Casa do Código Capítulo 2. Tudo começa em produç ão Figura 2.1: Uma prévia da página inicial da loja virtual Além disso, oBroadleaf Commerceutiliza diversos frameworks bem es- tabelecidos na comunidade Java, tornando o exemplo mais interessante do ponto de vista de DevOps, pois representa bem a complexidade envolvida no processo debuildedeployde uma aplicaç ão Java no mundo real. Os deta- lhes de implementaç ão vão além do escopo deste livro, porém é importante conhecer um pouco das principais tecnologias e frameworks utilizados nesta aplicaç ão:

•Java: a aplicaç ão é escrita em Java (http://java.oracle.com/) , compatível com a versão Java SE 6 e superiores.

•Spring: o Spring (http://www.springframework.org/) é um framework de desenvolvimento de aplicações corporativas popular na comunidade Java que oferece diversos componentes como: injeção de dependências, gerenciamento de transações, seguran ça, um framework de MVC, den- tre outros.

•JPA e Hibernate: o JPA é a API de persistência do Java e o Hiber- nate (http://www.hibernate.org/) é a implementaç ão mais famosa da JPA na comunidade Java, oferecendo recursos para realizar o mapea- mento objeto-relacional (object-relational mapping ou ORM) entre ob- jetos Java e as tabelas no banco de dados.

Página 30

2.1. Nossa aplicaç ão de exemplo: a loja virtual Casa do Código •Google Web Toolkit: o GWT (http://developers.google.com/ web-toolkit/) é um framework desenvolvido pelo Google para facilitar a criaç ão de interfaces ricas que rodam no browser. O GWT permite que o desenvolvedor escreva código Java que é então compilado para Javascript. A loja virtual utiliza o GWT para implementar a interface gráfica das ferramentas de administraç ão.

•Apache Solr: o Solr (http://lucene.apache.org/solr/) é um servidor de pesquisa que permite a indexaç ão do catálogo de produtos da loja vir- tual e oferece uma API eficiente e flexível para efetuar consultas de texto em todo o catálogo.

•Tomcat: o Tomcat (http://tomcat.apache.org/) é um servidor que im- plementa as tecnologias web – Java Servlet e JavaServer Pages – do Java EE. Apesar doBroadleaf Commercerodar em servidores de aplicaç ão alternativos – como Jetty, GlassFish ou JBoss – utilizaremos o Tomcat por ser uma escolha comum em diversas empresas rodando aplicações web Java.

•MySQL: o MySQL (http://www.mysql.com/) é um servidor de banco de dados relacional. O JPA e o Hibernate permitem que a aplicaç ão rode em diversos outros servidores de banco de dados – como Oracle, PostgreSQL ou SQL Server – porém também utilizaremos o MySQL por ser uma escolha popular e por disponibilizar uma versão de código aberto.

Não é uma aplicaç ão pequena. Melhor ainda: ela utiliza bibliotecas que são frequentemente encontradas na grande maioria das aplicações Java no mercado. Como falamos, vamos utilizá-la como nosso exemplo, mas você também pode seguir o processo com a sua própria aplicaç ão, ou ainda esco- lher outro software, independente de linguagem, para aprender as técnicas de DevOps que serão apresentadas e discutidas durante o livro.

O próximo objetivo é colocar a loja virtual no ar, porém, antes de fazer o primeirodeploy, é preciso ter um ambiente de produç ão pronto, com servi- dores onde o código possa rodar. O ambiente de produç ão em nosso exemplo será inicialmente composto de 2 servidores, conforme mostra a figura2.2.

Página 31

Casa do Código Capítulo 2. Tudo começa em produç ão Figura 2.2: Ambiente de produç ão da loja virtual Usuários acessarão a loja virtual, que rodará em uma instância do Tom- cat no servidor web. O servidor web rodará todas as bibliotecas e frameworks Java utilizados pela loja virtual, inclusive uma instância embutida do Solr. Por fim, a aplicaç ão web utilizará o MySQL, rodando em um servidor de banco de dados separado. Esta é uma arquitetura web de duas camadas comumente utilizada por diversas aplicações no mundo real. No capítulo 8discutiremos com mais detalhes os fatores que influenciam a escolha da arquitetura física para sua aplicaç ão, porém por enquanto vamos usar algo comum para sim- plificar o exemplo e colocar a loja virtual no ar o quanto antes.

2.2 Instalando o ambiente de produção Comprar servidores e hardware para a loja virtual custaria muito dinheiro, então inicialmente iremos usar máquinas virtuais. Isso permitirá criar todo o ambiente de produç ão na nossa máquina. Existem diversas ferramentas para rodar máquinas virtuais – como VMware ou Parallels – porém algumas são pagas e a maioria usa uma interface gráfica para configuraç ão, o que tornaria este capítulo uma coleção descreenshotsdifíceis de acompanhar.

Para resolver esses problemas, usaremos duas ferramentas que facilitam o uso e configuraç ão de máquinas virtuais: oVagrant(http://www.vagrantup.

com) e oVirtualBox(http://www.virtualbox.org) . O VirtualBox é uma ferra- menta da Oracle que permite configurar e rodar máquinas virtuais nas princi- pais plataformas: Windows, Linux, Mac OS X e Solaris. O VirtualBox possui uma ferramenta de linha de comando para executar e configurar as máquinas virtuais, porém para facilitar ainda mais o trabalho, usaremos o Vagrant que fornece uma DSL em Ruby para definir, gerenciar e configurar ambientes vir- tuais. O Vagrant possui também uma interface de linha de comando simples

Página 32

2.2. Instalando o ambiente de produç ão Casa do Código para subir e interagir com esses ambientes virtuais.

Caso você já possua o Vagrant e o VirtualBox instalados e funcionando, você pode pular para a subseção"Declarando e Subindo os Servidores”. Caso contrário, o processo de instalaç ão dessas ferramentas é simples.

Instalando o VirtualBox Para instalar o VirtualBox, acesse a página dedownloadhttp://www.

virtualbox.org/wiki/Downloadse escolha a versão mais atual. No momento da escrita do livro, a versão mais nova é o VirtualBox 4.3.8 e será a versão uti- lizada no decorrer do livro. Escolha o pacote de instalaç ão de acordo com a sua plataforma: no Windows o instalador é um arquivo executável.exe; no Mac OS X o instalador é um pacote.dmg; no Linux o VirtualBox disponibi- liza pacotes.debou.rpm, dependendo da sua distribuiç ão.

Uma vez que você tenha feito odownload, instale o pacote. No Win- dows e no Mac OS X, basta dar um duplo clique no arquivo de ins- talação (.exeno Windows e.dmgno Mac OS X) e seguir as ins- truções do instalador. No Linux, caso tenha escolhido o pacote.deb, instale-o executando o comandodpkg -i {arquivo.deb}, substi- tuindo{arquivo.deb}pelo nome do arquivo baixado, por exemplo virtualbox-4.3_4.3.8-92456~Ubuntu~raring_i386.deb. Caso tenha escolhido o pacote.rpm, instale-o executando o comandorpm -i {arquivo.rpm}, substituindo {arquivo.rpm}pelo nome do arquivo bai- xado, por exemploVirtualBox-4.3-4.3.8_92456_el6-1.i686.rpm.

Observaç ão: no Linux, caso seu usuário não sejaroot, você precisará rodar os comandos anteriores com o comandosudona frente, por exemplo:sudo dpkg -i {arquivo.deb} ousudo rpm -i {arquivo.rpm}.

Para testar que o VirtualBox está instalado corretamente, acesse o termi- nal e execute o comandoVBoxManage -v. Para abrir o terminal no Win- dows, você pode usarWin+Re digitarcmd. Caso tudo esteja correto, o co- mando retornará algo como “4.3.8r92456”, dependendo da versão instalada.

Instalando o Vagrant Uma vez que o VirtualBox estiver instalado, prossiga com o processo de instalaç ão do Vagrant, que é bem parecido. Acesse a página dedownloaddo

Página 33

Casa do Código Capítulo 2. Tudo começa em produç ão Vagranthttp://www.vagrantup.com/downloads.htmle escolha a versão mais atual. No momento da escrita do livro, a versão mais nova é o Vagrant 1.5.1 e será a versão utilizada no decorrer do livro. Faç a odownloaddo pacote de instalaç ão de acordo com a sua plataforma: no Windows o instalador é um arquivo.msi; no Mac OS X o instalador é um pacote.dmg; no Linux o Va- grant disponibiliza pacotes.debou.rpm, dependendo da sua distribuiç ão.

Assim que tenha feito odownloaddo pacote, instale-o: no Windows e no Mac OS X, basta dar um duplo clique no arquivo de instalaç ão (.msi no Windows e.dmgno Mac OS X) e seguir as instruções do instala- dor. No Linux, basta seguir os mesmos passos da instalaç ão do Virtual- Box no Linux usando o pacote escolhido (vagrant_1.5.1_i686.deb ou vagrant_1.5.1_i686.rpm). No Mac OS X e no Windows, o comando vagrantjá é colocado noPATHapós a instalaç ão. No Linux, você vai preci- sar adicionar/opt/vagrant/binno seuPATH.

Para testar que o Vagrant está instalado corretamente, acesse o terminal e execute o comandovagrant -v. Caso tudo esteja correto, o comando retornará algo como “Vagrant 1.5.1”, dependendo da versão instalada.

O último passo necessário é configurar uma imagem inicial que serve de templatepara inicializar cada máquina virtual. Estas imagens, também co- nhecidas comobox, servem como ponto de partida, contendo o sistema ope- racional básico. No nosso caso, utilizaremos umaboxoferecida pelo próprio Vagrant, que contém a imagem de um Linux Ubuntu 12.04 LTS de 32 bits.

Para baixar e configurar estabox, é preciso executar o comando:

$ vagrant box add hashicorp/precise32 ==> box: Loading metadata for box ’hashicorp/precise32’ box: URL: https://vagrantcloud.com/hashicorp/precise32 …

Esse comando irá fazer odownloaddo arquivo de imagem da máquina virtual, que é grande (299MB), portanto ele vai demorar para executar e uma boa conexão com a internet será necessária. Uma lista de outras ima- gens disponibilizadas pela comunidade Vagrant pode ser encontrada em http://www.vagrantbox.es/e o processo de inicializaç ão é parecido com o co- mando anterior. A empresa por trás do Vagrant, a HashiCorp, introduziu

Página 34

2.2. Instalando o ambiente de produç ão Casa do Código recentemente oVagrant Cloud(https://vagrantcloud.com/) , uma forma de encontrar e compartilharboxescom a comunidade.

Declarando e subindo os servidores Uma vez que o Vagrant e o VirtualBox estão funcionando, declarar e ge- renciar um ambiente virtual é simples. A declaraç ão de configuraç ão das má- quinas virtuais é feita em um arquivo chamadoVagrantfile. O comando vagrant initcria um arquivoVagrantfileinicial, com comentários que explicam todas as opções de configuraç ão disponíveis.

No nosso caso, iremos começar de forma simples e configurar apenas o necessário para subir os dois servidores de produç ão. O conteúdo do Vagrantfileque precisamos é:

VAGRANTFILE_API_VERSION="2"

Vagrant.configure( VAGRANTFILE_API_VERSION) do|config| config.vm.box ="hashicorp/precise32"

config.vm.define :dbdo|db_config| db_config.vm.network :private_network, :ip=>"192.168.33.10"

end config.vm.define :webdo|web_config| web_config.vm.network :private_network, :ip=>"192.168.33.12"

end end Esse arquivo configura duas máquinas virtuais, com apelidos de “db”

e “web”. Ambas utilizarão aboxhashicorp/precise32 que instala- mos anteriormente. Cada uma possui um bloco de configuraç ão que de- fine um endereço IP para configurar a conexão com a rede. Os endereços IP 192.168.33.10e192.168.33.12foram escolhidos de forma arbitrária para evitar conflitos com as configurações de rede da sua máquina.

Para subir os servidores, basta executar o comandovagrant upno mesmo diretório onde o arquivoVagrantfilefoi criado e o Vagrant to- mará conta de subir e configurar as máquinas virtuais para você. Se tudo correr bem, a saída do comando será algo parecido com:

Página 35

Casa do Código Capítulo 2. Tudo começa em produç ão $ vagrant up Bringing machine ’db’ up with ’virtualbox’ provider…

Bringing machine ’web’ up with ’virtualbox’ provider…

==> db: Importing base box ’hashicorp/precise32’…

==> db: Matching MAC address for NAT networking…

==> db: Checking if box ’hashicorp/precise32’ is up to date…

==> db: Setting the name of the VM: blank_db_1394680068450_7763 ==> db: Clearing any previously set network interfaces…

==> db: Preparing network interfaces based on configuration…

db: Adapter 1: nat db: Adapter 2: hostonly ==> db: Forwarding ports…

db: 22 => 2222 (adapter 1) ==> db: Booting VM…

==> db: Waiting for machine to boot. This may take a few minutes…

db: SSH address: 127.0.0.1:2222 db: SSH username: vagrant db: SSH auth method: private key ==> db: Machine booted and ready!

==> db: Configuring and enabling network interfaces…

==> db: Mounting shared folders…

db: /vagrant => /private/tmp/blank ==> web: Importing base box ’hashicorp/precise32’…

==> web: Matching MAC address for NAT networking…

==> web: Checking if box ’hashicorp/precise32’ is up to date…

==> web: Setting the name of the VM:

blank_web_1394680087001_3842 ==> web: Fixed port collision for 22 => 2222. Now on port 2200.

==> web: Clearing any previously set network interfaces…

==> web: Preparing network interfaces based on configuration…

web: Adapter 1: nat web: Adapter 2: hostonly ==> web: Forwarding ports…

web: 22 => 2200 (adapter 1) ==> web: Booting VM…

==> web: Waiting for machine to boot. This may take a few minutes…

web: SSH address: 127.0.0.1:2200

Página 36

2.3. Configurando dependências nos servidores de produç ão Casa do Código web: SSH username: vagrant web: SSH auth method: private key ==> web: Machine booted and ready!

==> web: Configuring and enabling network interfaces…

==> web: Mounting shared folders…

web: /vagrant => /private/tmp/blank Isso significa que as máquinas virtuais estão funcionando e prontas para serem usadas. Se você ler a saída com cuidado, verá que os passos foram os mesmos para ambas as máquinasdbeweb. Além disso, o Vagrant tam- bém mapeou portas de SSH e montou uma partiç ão para acessar os arquivos existentes no diretório da máquina hospedeira. Isso pode soar um pouco con- fuso, mas demonstra algumas das funcionalidades poderosas que o Vagrant disponibiliza.

2.3 Configurandodependênciasnosservidores de produção Agora que os servidores estão rodando, é preciso instalar os pacotes e depen- dências para que a loja virtual funcione. Administradores de sistema prova- velmente já estão acostumados a trabalhar em diversas máquinas ao mesmo tempo, porém desenvolvedores geralmente trabalham sempre em uma má- quina só.

Nas próximas seções começaremos a interagir com mais de uma máquina ao mesmo tempo e a maior parte dos comandos precisarão ser executados no servidor correto. Usaremos uma notaç ão especial para guiar as instruções no restante do livro, representando o usuário e o servidor nopromptda li- nha de comando para servir de lembrete para você verificar se está rodando o comando no servidor certo. O padrão será{usuário}@{servidor}$, no qual o usuário geralmente serávagrante o servidor pode variar entre dbouweb. Desta forma, comandos precedidos devagrant@db$devem ser executados no servidordbe comandos precedidos devagrant@web$ devem ser executados no servidorweb.

Ao invés de pular de um servidor para o outro, iremos focar inicialmente em um servidor por vez, começando pelo servidor de banco de dados.

Página 37

Casa do Código Capítulo 2. Tudo começa em produç ão Servidor de banco de dados Primeiramente, precisamos logar no servidor de banco de dados para ins- talar o MySQL. Isso é feito através do comandovagrant ssh db, que abre uma sessão SSH com o servidordb. Uma vez logado, a instalaç ão do servidor MySQL é feita através do pacotemysql-server:

vagrant@db$ sudo apt-get update Ign http://us.archive.ubuntu.com precise InRelease Ign http://us.archive.ubuntu.com precise-updates InRelease …

Reading package lists… Done vagrant@db$ sudo apt-get install mysql-server Reading package lists… Done Building dependency tree …

ldconfig deferred processing now taking place Para entender o que está acontecendo, vamos analisar cada parte desse comando. O comandoapt-geté usado para gerenciar quais pacotes es- tão instalados no sistema. A instruç ãoupdateatualiza o índice de paco- tes para as últimas versões. A instruç ãoinstallserve para instalar um novo pacote no sistema. Nesse caso o pacote que queremos instalar é o pa- cotemysql-serverque contém o servidor MySQL. O comando inteiro é precedido pelo comandosudo. Em sistemas UNIX, existe um usuário espe- cial com “super poderes” conhecido como usuárioroote o comandosudo permite executar algo como se o usuário atual fosseroot.

O processo de instalaç ão do servidor MySQL exige a escolha de uma se- nha de acesso para o usuárioroot. Você precisará fornecer essa senha duas vezes no processo de instalaç ão. A escolha de uma senha segura é importante para garantir a segurança do sistema, porém é também um tópico de discus- são à parte, que abordaremos no capítulo8. Se alguém descobrir a senha mestre, ele poderá executar qualquer comando no banco de dados, inclusive apagar todas as tabelas! Na vida real você não quer que isso aconteça, porém, no exemplo do livro, usaremos uma senha simples para facilitar: “secret”. Se preferir, você pode escolher outra senha, mas daqui para frente tome cuidado

Página 38

2.3. Configurando dependências nos servidores de produç ão Casa do Código para substituir qualquer menção da senha “secret” pela senha que você esco- lheu.

Ao terminar a instalaç ão do pacote, o servidor MySQL já vai estar rodando, porém apenas para acesso local. Como precisamos acessar o banco de dados do servidor web, é preciso configurar o MySQL para per- mitir conexões externas. Para isto, basta criar o arquivo de configuraç ão /etc/mysql/conf.d/allow_external.cnf. Você pode usar o editor de texto que preferir –emacsevimsão duas opções comuns – porém aqui usaremos onanopor ser um editor mais simples de aprender para quem não está acostumado a editar arquivos na linha de comando. O comando seguinte cria o arquivo (comorootnovamente) desejado:

vagrant@db$ sudo nano /etc/mysql/conf.d/allow_external.cnf Basta então digitar o conteúdo do arquivo abaixo e usarCtrl+Opara salvar eCtrl+Xpara salvar e sair do editor:

[mysqld] bind-address =0.0.0.0 Uma vez que o arquivo foi criado, é preciso reiniciar o servidor MySQL para que ele perceba a nova configuraç ão. Isso é feito com o comando:

vagrant@db$ sudo service mysql restart mysql stop/waiting mysql start/running, process 6460 Neste momento, o servidor MySQL já está pronto e rodando, porém ainda não criamos nenhum banco de dados. É comum que cada aplicaç ão crie seu próprio banco de dados, ouschema, para persistir suas tabelas, índices e da- dos. Precisamos então criar um banco de dados para a loja virtual, que cha- maremos deloja_schema, através do comando:

vagrant@db$ mysqladmin -u root -p create loja_schema Enter password:

Ao executar este comando, a opção-u rootinstrui que a conexão com o MySQL deve ser feita como usuário root e a opção-pirá perguntar a se- nha, que nesse caso será “secret”. O resto do comando é autoexplicativo. Para

DevOps na prática – entrega de software confiável e automatizada