devops aproximando a área de desenvolvimento da operacional
TRANSCRIPT
MINISTÉRIO DA DEFESAEXÉRCITO BRASILEIRO
DEPARTAMENTO DE CIÊNCIA E TECNOLOGIAINSTITUTO MILITAR DE ENGENHARIA
CURSO DE GRADUAÇÃO EM ENGENHARIA DE COMPUTAÇÃO
VENICIUS GONÇALVES DA ROCHA JUNIORLUAN FERREIRA CARDOSORICARDO SOLON ZALLA
DEVOPS: APROXIMANDO A ÁREA DE DESENVOLVIMENTO DAOPERACIONAL
Rio de Janeiro2016
INSTITUTO MILITAR DE ENGENHARIA
VENICIUS GONÇALVES DA ROCHA JUNIORLUAN FERREIRA CARDOSORICARDO SOLON ZALLA
DEVOPS: APROXIMANDO A ÁREA DEDESENVOLVIMENTO DA OPERACIONAL
Projeto de Fim de Curso apresentado ao Curso de Graduação emEngenharia de Computação do Instituto Militar de Engenharia,como requisito parcial para a obtenção do título de bacharel emEngenharia de Computação.
Orientador: Prof. Clayton Escouper das Chagas - M.Sc.
Rio de Janeiro2016
c2016
INSTITUTO MILITAR DE ENGENHARIA
Praça General Tibúrcio, 80 – Praia Vermelha
Rio de Janeiro – RJ CEP: 22290-270
Este exemplar é de propriedade do Instituto Militar de Engenharia, que poderá incluí-
lo em base de dados, armazenar em computador, microfilmar ou adotar qualquer
forma de arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão entre
bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que
esteja ou venha a ser fixado, para pesquisa acadêmica, comentários e citações,
desde que sem finalidade comercial e que seja feita a referência bibliográfica
completa.
Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es) e
do(s) orientador(es).
004 Rocha Junior, Venicius Gonçalves da
R672d DEVOPS: aproximando a área de desenvolvimento daoperacional / Venicius Gonçalves da Rocha Junior, Luan FerreiraCardoso, Ricardo Solon Zalla; orientados por Clayton Escouperdas Chagas – Rio de Janeiro: Instituto Militar de Engenharia,2016.
80p. : il.
Projeto de Fim de Curso (PROFIC) – Instituto Militar deEngenharia, Rio de Janeiro, 2016.
1. Curso de Engenharia de Computação – Projeto de Fim deCurso. 2. Provisionamento. 3. Bluemix. I. Cardoso, LuanFerreira. II. Zalla, Ricardo Solon. III. Chagas, Clayton Escouperdas. IV. Título. V. Instituto Militar de Engenharia.
Ao Rio de Janeiro e ao Instituto Militar de Engenharia, alicercesda nossa formação e do nosso aperfeiçoamento.
3
AGRADECIMENTOS
Agradecemos a todos que nos incentivaram, apoiaram e possibilitaram esta oportu-
nidade de ampliar nossos horizontes.
Meus familiares, mentores e professores.
4
“Engineering is the closest thing to magic that exists in the world.”
ELON MUSK
5
SUMÁRIO
LISTA DE ILUSTRAÇÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
LISTA DE TABELAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
LISTA DE SIGLAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2 APRESENTAÇÃO DOS AMBIENTES . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1 Etapas do Processo de Entrega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.1 Virtualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.2 Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.3 Build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.4 Deploy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.5 Provisionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.6 Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.7 Integração Contínua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Ambientes de Código Aberto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Ambiente Proprietário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Parâmetros de Comparação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3 DETALHAMENTO DAS ARQUITETURAS . . . . . . . . . . . . . . . . . . . . . 24
3.1 Ambientes de Código Aberto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.1 Etapas do Processo de Entrega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.1.1Virtualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.1.2Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.1.3 Build e Deploy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.1.4 Provisionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.1.5Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.1.6 Integração Contínua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6
3.1.2 Prova de Conceito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Ambiente Proprietário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.1 Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.2 Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.3 Etapas do Processo de Entrega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.3.1Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.3.2Build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.3.3Deploy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.3.4 Provisionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.3.5Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.3.6 Integração Contínua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.4 Prova de Conceito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4 COMPARAÇÃO ENTRE AMBIENTES . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1 Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Comparação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6 REFERÊNCIAS BIBLIOGRÁFICAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7 APÊNDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.1 APÊNDICE 1: Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.1.1 Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.1.1.1MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.1.2 Gerenciamento de Configurações de Software - SCM . . . . . . . . . . . . . . . . . . . . . 49
7.1.2.1Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.1.2.2GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.1.3 Build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.1.3.1Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.1.4 Integração Contínua - CI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.1.4.1 Jenkins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.1.5 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.1.5.1 SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.1.6 Provisionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.1.6.1Puppet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7
7.1.6.2Ansible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.1.6.3Vagrant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.1.7 Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.1.7.1Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.1.8 Serviços de Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.1.8.1Amazon Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.1.8.2 IBM Bluemix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.2 APÊNDICE 2: Teste das Ferramentas Usadas para Construir o Se-
gundo Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.2.1 Criação de Chave Pública SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.2.2 Configuração do Controle de Versão com Git e GitHub . . . . . . . . . . . . . . . . . . . 52
7.2.3 Instalação e Configuração do Vagrant e do Virtualbox . . . . . . . . . . . . . . . . . . . . 55
7.2.4 Instalação e Configuração do Ansible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.2.5 Instalação do Jenkins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.2.6 Criação e Teste do Servidor de Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.2.7 Criação e Teste do Servidor Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.3 APÊNDICE 3: Construção do Segundo Ambiente . . . . . . . . . . . . . . . . . . . . . . . 71
7.3.1 Instalação do Virtualbox e do Vagrant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.3.2 Instalação do Ansible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.3.3 Construção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.4 APÊNDICE 4: Teste da aplicação To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.4.1 Ambientes de Código Aberto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.4.2 Ambiente Proprietário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8
LISTA DE ILUSTRAÇÕES
FIG.3.1 Ambiente de produção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
FIG.3.2 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
FIG.3.3 Loja virtual DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
FIG.3.4 Tela para adicionar ou ligar serviço no Bluemix . . . . . . . . . . . . . . . . . . . . . 31
FIG.3.5 Pipeline no Bluemix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
FIG.3.6 Aplicações em execução no Bluemix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
FIG.3.7 Serviços ligados às aplicações instanciadas . . . . . . . . . . . . . . . . . . . . . . . . . . 38
FIG.3.8 Talent Manager em produção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
FIG.3.9 Build do Talent Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
FIG.3.10 Banco de Dados doTalent Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
FIG.3.11 Deploy doTalent Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
FIG.3.12 Resultado de uma busca no Talent Manager . . . . . . . . . . . . . . . . . . . . . . . . 40
FIG.3.13 Build e deploy do Talent Manager pelo serviço Delivery Pipeline . . . . . . . 41
FIG.4.1 Aplicação To-do em produção no Bluemix . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9
LISTA DE TABELAS
TAB.4.1 Tabela Comparativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
10
LISTA DE SIGLAS
API Application Programming Interface
AWS Amazon Web Server
BI Business Inteligence
CI Continuous Integration
DevOps Aproximação entre desenvolvimento e operação
DSL Digital Subscriber Line
EC2 Elastic Compute Cloud
EE Enterprise Edition
GLP General Public License
IaaS Infrastructure as a Service
IBM International Business Machines
IDE Integrated Development Environment
IP Internet Protocol
JPA Java Persistence API
JDK Java Development Kit
LTS Long Term Support
MVC Model-View-Controller
ORM Object Relational Mapping
PaaS Plataform as a Service
PHP Personal Home Page
RAM Random Access Memory
SE Special Edition
SSH Secure Shell
SMC System Management Controller
SGBD Sistema Gerenciador de Banco de Dados
SQL Structure Query Language
TCP Transmission Control Protocol
URL Uniform Resource Locator
XML Extensible Markup Language
11
RESUMO
Este trabalho está focado na análise e comparação de três ambientes DevOps segundo
etapas definidas do processo para a entrega de uma aplicação em produção.
Em uma primeira abordagem, foram desenvolvidos dois ambientes Devops com a uti-
lização de ferramentas de código aberto e contemplando a escolha e integração em cada
uma das etapas definidas anteriormente.
Em uma segunda abordagem, o ambiente Bluemix foi introduzido, teve suas prin-
cipais características alinhadas à metodologia DevOps analisada. Posteriormente, suas
possibilidades em cada uma dessas etapas foram explicadas.
Após a implementação de uma mesma aplicação nos três ambientes, foi feita uma
comparação analisando os parâmetros relativos a cada etapa do processo de entrega da
aplicação testada. Por sua alta versatilidade e desempenho na comparação dos parâ-
metros, concluiu-se que o Bluemix é o ambiente mais interessante do ponto de vista da
metodologia DevOps.
12
ABSTRACT
This work is focused on the analysis and comparison of three DevOps environments
under defined steps of the delivery process of applications.
In a first approach, two DevOps environments were built using just open source tools
and contemplating the process to choose and integrate each one under the steps defined
before.
In a second approach, the Bluemix environment was introduced, had its main cha-
racteristics aligned to DevOps methodology analized. Posteriorly, its possibilities under
the steps defined before explained.
After the implementation of the same application in three environments, a compari-
son analyzing the parameters for each step of the delivery process of the tested application
was made. Because of its high versatility and performance parameters compared, it was
found that the Bluemix is the most interesting environment in the point of view of DevOps
methodology.
13
1 INTRODUÇÃO
1.1 MOTIVAÇÃO
Quando uma organização precisa entregar uma nova versão de software aos usuários
ou precisa de servidores e computadores, surge uma demanda por mais colaboração e
comunicação entre as equipes de desenvolvimento e de operações. Nesse contexto, a falta
de práticas que tenham como objetivo efetivamente automatizar a entrega do desenvol-
vimento de software segundo os requisitos de operações - com a qualidade e a rapidez
necessárias - acabam prejudicando justamente um desses atributos. Além disso, o de-
senvolvimento também não entrega as atualizações em tempo, prejudicando todos os
requisitos de qualidade previstos para o ambiente de operações.
Para resolver esse problema, uma das recentes soluções são as metodologias ágeis, que
buscam viabilizar a entrega rápida e com qualidade de software. Elas atuam, contudo, em
questões relacionadas à comunicação e aos métodos de desenvolvimento, abrindo espaço
para uma área que busque entender como as diversas etapas do desenvolvimento até a
produção se integram.
Surge com frequência, por exemplo, a necessidade de instalação e configuração de
requisitos nos sistemas operacionais para que os programas e serviços funcionem corre-
tamente na operação. Essas situações, aparentemente simples, do ponto de vista de um
usuário comum que necessita de tais requisitos, se transformam em uma tarefa de configu-
ração complexa e custosa de ser feita para grandes organizações, que geralmente possuem
um alto número de servidores, computadores e elevados padrões de governança.
Essa demanda por ativos computacionais e por rapidez e qualidade na entrega de soft-
ware varia dependendo do serviço oferecido pela organização, podendo crescer progressi-
vamente ou apresentar picos sob uma demanda específica. Para se otimizar a relação entre
custo e benefício, e para possibilitar uma entrega contínua e confiável (HUMBLE; FAR-
LEY, 2010), faz-se necessária a capacidade de automatizar o processo de desenvolvimento
e de implantação desses ativos.
Nesse contexto, com a ausência de iniciativas proativas que busquem essa automati-
zação, o processo de entrega de software se torna burocrático e repetitivo para as equipes
de desenvolvimento e de operações, possibilitando prejuízos à atividade fim das organiza-
ções. Tais iniciativas proativas, nesse cenário, começaram a se solidificar por meio de uma
14
tendência para criação direta de cadeias de ferramentas. Portanto, passou-se a estudar
estruturas automatizadas que pudessem facilitar a integração desses processos por meio
do encadeamento de uma ou mais etapas do processo de entrega de softwares.
A partir desse momento, os desenvolvedores ficam menos responsáveis por configurar e
instalar ferramentas e passam a investir mais tempo no desenvolvimento da automatização
entre os diversos passos desse processo, dando origem ao DevOps. Essa metodologia
que trata da integração de operação de sistemas com desenvolvimento de sistemas, se
fortaleceu conforme as demandas por ambientes cada vez mais escaláveis, flexíveis e com
menor custo final.
1.2 OBJETIVO
Esse trabalho possui dois objetivos: o desenvolvimento de ambientes DevOps e a com-
paração entre esses ambientes segundo parâmetros que possibilitem identificar vantagens
e desvantagens de cada um. Para isso, em cada ambiente foram feitas provas de conceito
que permitissem testar o detalhamento de sua construção, além da criação de uma mesma
aplicação em todos eles para a comparação de parâmetros relacionados à complexidade
do software.
Para uniformização dessa comparação, cada ambiente foi detalhado segundo a pers-
pectiva das ferramentas usadas nas seguintes etapas do processo de entrega de software:
virtualização, desenvolvimento, build, deploy, provisionamento, monitoramento e integra-
ção contínua.
Portanto, foram construídos ambientes completos e funcionais para comparações pos-
teriores de parâmetros agrupados por etapa do processo de entrega. Dessa forma, viabi-
lizando uma parametrização clara das semelhanças e diferenças do desempenho de cada
arquitetura em cada etapa.
1.3 JUSTIFICATIVA
Para efetivar a entrega de software, as organizações em geral possuem um conjunto de
ferramentas padrão para cada etapa do ciclo de entrega. Os ambientes DevOps buscam
integrar e automatizar a relação que essas ferramentas possuem entre si, formando uma
cadeia de ferramentas.
Como a metodologia DevOps teve seu início apenas em 2009 (DEBOIS, 2009), as
organizações ainda possuem um amplo espaço de aplicação dessas práticas em seus atuais
conjuntos de ferramentas concernentes à entrega de aplicações.
15
Ilustrar possíveis ambientes DevOps para posterior comparação, portanto, permite
aos líderes dessas organizações abstrair como as práticas DevOps poderiam se encaixar
em suas ferramentas de maneira a otimizar o acoplamento entre elas.
Os resultados potenciais ficam mais claros a partir da visualização de parâmetros e
de métricas que permitem comparar as melhores funcionalidades que os ambientes podem
ter, permitindo a redução do tempo médio de liberação das aplicações sem prejudicar a
qualidade no desenvolvimento.
1.4 METODOLOGIA
A metodologia desse trabalho foi feita essencialmente em três etapas: fase de estudos,
fase de desenvolvimento e teste dos ambientes e fase de comparação. Na fase de compa-
ração, foi uniformizada uma aplicação comum para os três ambientes. Desdobrando tais
fases, foram realizadas as seguintes atividades:
Fase de estudo:
• Estudo conceitual: para entendimento da justificativa, motivação, práticas e ten-
dências do tema DevOps de maneira geral visando uma definição adequada dos
ambientes que seriam desenvolvidos;
• Estudo ferramental: uma vez que um ambiente DevOps se define pela integração das
ferramentas nas etapas de entrega de software para operações, formando uma cadeia
de ferramentas (DevOps toolchain), o aprofundamento nas opções e conveniências
das ferramentas para cada ambiente foi essencial para o rascunho e definição de
como eles funcionariam; e
• Definição das etapas DevOps: uma vez que um dos objetivos do projeto é comparar
os ambientes, é necessário uniformizar o conjunto de etapas a ser utilizado em cada
uma para que eles possam ser comparados segundo um processo de entrega de
software comum a todos.
Fase de desenvolvimento:
• Desenvolvimento ferramental: construção e instanciação das ferramentas em cada
ambiente. Para verificar o progresso nessa etapa, utilizou-se aplicações que serviram
como provas de conceito separadas em cada etapa do processo de entrega; e
• Prova de conceito: escolha de uma aplicação que seja capaz de testar todas as etapas
do processo de entrega criadas em cada ambiente e colocá-la em produção. Assim,
16
os ambientes consolidam-se como capazes e funcionais para serem utilizados por
meio de aplicações reais.
Fase de comparação:
• Aplicação para comparação: com os ambientes devidamente dominados e testados,
foi definida e colocada em produção uma aplicação idêntica em todos para que se
possa comparar os parâmetros estabelecidos;
• Parâmetros de comparação: com os ambientes testados e uma aplicação comum,
definiu-se os parâmetros relativos à cada etapa do processo de entrega que forneces-
sem maior quantidade de insumos para uma conclusão sobre a aderência de cada
ambiente à metodologia DevOps; e
• Comparação final: coleta do comportamento de cada parâmetro em cada ambiente
e análise final das semelhanças e diferenças permitindo derivar prós e contras de
cada um.
17
2 APRESENTAÇÃO DOS AMBIENTES
O presente trabalho realizou a construção de três ambientes DevOps. Para isso, a
montagem dos ambientes foi dividida em sete etapas - que estão definidas a seguir - para
que se pudesse obter a entrega da aplicação funcionando de modo adequado em produção
seguindo um processo comum em todos os ambientes.
2.1 ETAPAS DO PROCESSO DE ENTREGA
2.1.1 VIRTUALIZAÇÃO
A virtualização compreende o uso de software para simular a existência de hardware
e criar um sistema de computadores virtual. No trabalho, tal etapa foi realizada no
momento que se fez necessário mais de uma instância de servidor na mesma máquina.
2.1.2 DESENVOLVIMENTO
No desenvolvimento temos a construção de uma aplicação a partir de requisitos neces-
sários previamente determinados. No presente trabalho, utiliza-se a palavra como forma
de simulação de um ambiente de desenvolvimento de aplicações (codificação).
2.1.3 BUILD
Após o término do desenvolvimento é necessário baixar e compilar o código, rodar
os testes, empacotar a aplicação e colocar a aplicação no ar. Todo esse processo de
compilação, teste e empacotamento é conhecido como build. As etapas do processo de build
também podem incluir gerenciamento de dependências e geração de documentação. A
principal função do processo de build é gerar um ou mais artefatos, com versões específicas,
que se tornam potenciais candidatos para o seu deploy em produção.
2.1.4 DEPLOY
Deploy compreende todos os processos envolvidos após a realização do Build até a
obtenção da nova aplicação executando adequadamente no seu ambiente de execução.
18
2.1.5 PROVISIONAMENTO
O termo provisionamento é usado para se referir as etapas iniciais de configuração de
um novo recurso. No caso de uma empresa que possui infraestrutura própria, tais etapas
seriam:
a) Compra de hardware;
b) Instalação física do hardware;
c) Instalação e configuração do sistema operacional; e
d) Instalação e configuração de serviços comuns (DNS, NTP, SSH).
No contexto desse trabalho utiliza-se o termo como sinônimo das etapas c e d.
2.1.6 MONITORAMENTO
Monitoramento corresponde ao ato de realizar verificações necessárias constantes para
o correto funcionamento do sistema. Caso o sistema monitorado não esteja em conformi-
dade com o esperado, a ferramenta de monitoramento deve ser capaz de enviar notificações
assim que o sistema monitorado esteja em um estado anormal.
2.1.7 INTEGRAÇÃO CONTÍNUA
O termo Integração Contínua se refere a mudanças seguras no código-fonte após a
aplicação estar em produção. Leva-se em consideração desde um envio de mudança no
código (commit) até um pacote que pode ser implantado em produção.
2.2 AMBIENTES DE CÓDIGO ABERTO
Foram construídos dois ambientes DevOps com ferramentas de código aberto. Foram
contempladas as escolhas das ferramentas para a realização de todas as etapas para o pro-
cesso de entrega da aplicação. Muito embora hajam muitas ferramentas disponíveis,certas
categorias delas são essenciais para a configuração de uma cadeia de ferramentas DevOps.
São exemplos dessas: 1 VirtualBox e 2 Vagrant (plataformas de gerenciamento e virtua-1https://www.virtualbox.org/2https://www.vagrantup.com/
19
lização), 3Puppet e 4Ansible (infraestrutura como código) e 5Git (sistema de controle de
versionamento).
Concernente à parte de infraestrutura como código tem-se o Puppet e o Ansible que
trabalham como ferramentas de gerenciamento de configuração de duas maneiras distintas:
o primeiro utilizando os conceitos fundamentais de gerência de configurações e o último
utilizando a orquestração. Os conceitos fundamentais de gerência de configuração utilizam
uma arquitetura agente e servidor, o servidor armazena as configurações dos nós. O agente
que roda no nó busca as configurações e aplica localmente. A orquestração, no entanto,
consiste em executar algo de forma paralela em um sistema operacional ou em um grupo
de sistemas operacionais.
Por esse motivo, optou-se pela realização de dois ambientes DevOps com ferramentas
de código aberto: a primeira utilizando o Puppet e a segunda utilizando o Ansible.
2.3 AMBIENTE PROPRIETÁRIO
Como caso de estudo de um ambiente proprietário que automatiza as etapas DevOps,
foi escolhido o 6Bluemix, plataforma premium de DevOps da IBM.
A IBM desenvolveu o Bluemix com a ideia de possibilitar a construção de aplica-
ções sem se preocupar com a infraestrutura, deixando esta a cargo do Bluemix. Assim,
construído com base nos projetos open source mais populares do mundo, o Bluemix é
uma plataforma em nuvem que permite desenvolvedores construir e executar diversas
aplicações e serviços com arquiteturas diferentes.
Assim, permite-se às organizações e aos desenvolvedores uma maneira otimizada de
criar, realizar o deploy e gerenciar aplicações na nuvem. Ele é uma implementação da
IBM Open Cloud Architecture baseada no 7Cloud Foundry, uma plataforma como serviço
(PaaS – Platform as a Service). Um de seus maiores diferenciais é entregar serviços de
nível empresarial que permitem integrar facilmente as aplicações em nuvem sem precisar se
preocupar com questões de instalação e configuração das mesmas, otimizando dimensões
de custo e produtividade.3https://puppet.com/4https://www.ansible.com/5https://git-scm.com/6https://console.ng.bluemix.net/7https://www.cloudfoundry.org/
20
2.4 PARÂMETROS DE COMPARAÇÃO
As aplicações desenvolvidas em cada ambiente serão comparadas em um conjunto de
parâmetros agrupados de acordo com sua fase na etapa do processo de entrega.
Assim, para cada etapa de cada ambiente serão analisadas as seguintes métricas:
• Desenvolvimento
– IDE Online
O desenvolvimento sempre pode ser feito por meio de IDE local. No entanto, se
o ambiente também proporcionar uma IDE online como alternativa, o usuário
terá uma opção vantajosa para não perder possibilidades de manter-se ativo
no desenvolvimento;
– Integração com Git
A integração com Git proporciona o versionamento do código, característica
fundamental no desenvolvimento de aplicações mais robustas e que tenham um
desenvolvimento colaborativo;
– Planejamento ágil
A metodologia DevOps está intimamente ligada aos objetivos das metodologias
ágeis, portanto, a existência de recursos que possibilitem a aplicação de tais
características é fator fundamental na comparação entre os ambientes;
– Múltiplos usuários
Possibilidade de compartilhamento do ambiente de desenvolvimento seguindo
as etapas do processo de entrega com múltiplos usuários.
• Build
– Build automatizado
Uma vez que o código do projeto esteja pronto para a etapa de build, automa-
tizar o build significa realizá-lo assim que qualquer atualização do repositório
da aplicação seja feita. Sendo, portanto, um fator também para a etapa de
integração contínua;
– Tempo de build
Duração necessária para a geração dos artefatos do build, possibilitando com-
parar qual ambiente se mostra mais eficiente no processamento da compilação
do código da aplicação;
21
– Builders embutidos
Cada aplicação pode ter um tipo diferente de builder. Uma vez que um am-
biente já possua diferentes tipos de builders embutidos, anula a necessidade
de configuração do ambiente de build para o desenvolvimento de aplicações
diferentes.
• Deploy
– Deploy automatizado
Realização do deploy a partir dos artefatos gerados pela etapa de build assim
que esses são gerados, abstraindo para o ambiente uma complexidade que tra-
dicionalmente é executada pela equipe de operações. Esse parâmetro também
é interessante do ponto de vista da integração contínua pois sempre que uma
edição for feita, o deploy automatizado será útil para minimizar o tempo da
chegada na produção.
• Provisionamento
– Provisionamento
O termo provisionamento foi definido anteriormente como sendo as etapas ini-
ciais de configuração de um novo recurso. Em parâmetros o termo é utilizado
para analisar como é realizado o provisionamento em cada ambiente: de ma-
neira manual pela equipe de operações ou de maneira embutida como em um
PaaS (Plataform as a Service).
– Complexidade de configuração de integração Servidor Web e Servidor Banco
de Dados
A fim de que a aplicação possa persistir seus dados, é necessário que seja feita
a configuração do xml que integra as chamadas da aplicação vindas do servidor
web direcionadas ao servidor do banco de dados. O presente parâmetro analisa
o grau de complexidade para realizar tal tarefa.
• Monitoramento
– Monitoramento
Monitoramento corresponde ao ato de realizar verificações necessárias cons-
tantes para o correto funcionamento do sistema. Em parâmetros o termo é
utilizado para analisar se o ambiente apresenta uma ferramenta de monitora-
mento embutida ao ambiente DevOps;
22
– Sistema de notificação
Uma vez que os erros gerem notificações no sistema de monitoramento, há
a existência de um sistema que possibilite organizá-las e encaminhá-las para
os respectivos responsáveis. Tal parâmetro analisa se a ferramenta de moni-
toramento permite realizar tal tarefa de maneira customizável: podendo se
customizar os responsáveis por erros em áreas específicas da aplicação bem
como em escalas de prioridade.
• Integração contínua
– Log de eventos
A manutenção de um log de eventos único para as ferramentas de todas as
etapas para se manter a aplicação funcionando corretamente. Desse modo, o
log das ferramentas de desenvolvimento, build, deploy, provisionamento, mo-
nitoramento e integração contínua pode ser visto e filtrado de acordo com a
necessidade específica de visualização.
23
3 DETALHAMENTO DAS ARQUITETURAS
3.1 AMBIENTES DE CÓDIGO ABERTO
FIG. 3.1: Ambiente de produção
3.1.1 ETAPAS DO PROCESSO DE ENTREGA
3.1.1.1 VIRTUALIZAÇÃO
Conforme a proposta desse trabalho, no qual o objetivo é comparar três ambientes
DevOps diferentes, e sabendo-se que as técnicas DevOps visam automatizar todas as
ferramentas envolvidas no processo de desenvolvimento de um programa, esses dois ambi-
entes foram montados visando a automatização. Desse modo, os desenvolvedores poderão
minimizar os erros causados por diferenças entre os ambientes de desenvolvimento e de
produção e poderão participar ativamente do processo da área operacional (etapas para
se colocar a aplicação em produção).
24
Primeiramente, esses dois ambientes utilizam o programa Virtual Box de forma indi-
reta para executar as máquinas virtuais usadas para atender as exigências do projeto que
será executado ou desenvolvido. Foi dito de forma indireta, pois não há contato direto
com o programa, ele apenas é usado para servir de base para outro programa, nesse caso
o Vagrant, que será usado no projeto para gerenciar as máquinas.
O Vagrant é responsável pelo contato direto com os desenvolvedores, ou seja, é por
meio desse software que são feitas todas as ações para que o projeto funcione corretamente.
Existem duas funções distintas e muito importantes no Vagrant: a de provedor (pro-
vider) e a de provisionador (provisioner). A função do provedor é criar uma instância
de um ambiente, geralmente uma máquina virtual, com um sistema operacional básico
instalado.
Para ter o ambiente de desenvolvimento pronto, é necessário executar uma série de
tarefas, como instalação de pacotes e configuração do sistema. Essas tarefas são feitas pelo
provisionador. A função do provisionador é configurar o ambiente de maneira automati-
zada. Desse modo, ao final desse processo, um ambiente de desenvolvimento totalmente
reproduzível e portátil é construído.
Todas as etapas para criação das máquinas virtuais para executar o projeto Loja
Virtual DevOps como prova de conceito inicial estão especificadas nos apêndices 2.
3.1.1.2 DESENVOLVIMENTO
Para simular o ambiente de desenvolvimento foi utilizado a IDE Eclipse em sua versão
Neon. O Eclipse é um ambiente integrado de desenvolvimento amplamente utilizado
para aplicações JAVA. Esse contém uma área de trabalho e um sistema extensível de
plugins os quais permitem o desenvolvimento em outras linguagens, entre as principais:
PHP, C, C++, Python e Rugby on Rails. Tal escolha de IDE se justifica pois colocamos
em produção aplicações Java (a principal especialidade do Eclipse) e por essa ter uma
integração direta com o 8 GitHub permitindo que se faça o controle de versão do código
através das funcionalidades disponibilizadas pelo GitHub:
a) Commit de mudanças permitindo fácil comparação de código entre diferentes com-
mits;
b) Acompanhamento de mudanças permitindo a identificação do porquê, quando e por
quem cada linha de código foi modificada;8 https://github.com/
25
c) Visualização do histórico de commits ao longo do tempo permitindo a identificação
de quais ramos (branches) foram agrupados (merged)
3.1.1.3 BUILD E DEPLOY
Nessa etapa, o Software Ansible executa o 9Maven para realizar a construção, etapa
que é composta pelas seguintes subetapas: validação, compilação, testes, empacotamento,
verificação de integração, instalação e deploy. Assim, de forma automatizada, ao final
desse processo, tem-se o projeto funcionando e pronto para uso. Para realizar todas essas
atividades, a única ação necessária é a interação inicial com o Vagrant por meio dos
comandos encontrados nos apêndices 1, 2 e 3.
Na etapa de validação, o projeto e todas as outras informações necessárias são ve-
rificadas para se ter certeza de que todas as informações estão corretas. Na etapa de
compilação, o código fonte desenvolvido é compilado. Na etapa de testes, o código com-
pilado é testado com 10Junit. Nesses testes, o código não precisa estar empacotado ou em
produção. Na parte de empacotamento, o código compilado é acoplado em uma forma que
será distribuída, no formato Jar. A parte de instalação instala o pacote em um repositório
local para ser usado como dependência em outros projetos locais. A etapa de deploy copia
o arquivo final do projeto para o servidor de aplicação, que será responsável por gerenciar
o acesso ao sistema.
3.1.1.4 PROVISIONAMENTO
Após a etapa de criação das máquinas virtuais responsáveis pelo banco de dados e
pelo servidor de aplicação, é realizado o provisionamento com dois programas diferentes:
Ansible e Puppet. Esses programas são executado por meio do Vagrant. Essa etapa
é composta pela instalação e configuração dos outros softwares necessários para que a
aplicação funcione corretamente.
Como foi mencionado, o Vagrant executa o Ansible ou o Puppet pré-configurados para
realizar o provisionamento e instalar os seguintes softwares para o servidor de banco de
dados: 11mysql-server, mysql-client. Após as instalações, os programas citados configuram
o banco de dados para atender ao servidor de aplicação.
Para configurar o servidor web, o Vagrant executa o Ansible ou o Puppet, também pré-9https://maven.apache.org/docs/2.2.1/release-notes.html
10http://junit.org/junit4/11 http://www.mysql.com/
26
configurado, instalando e configurando os seguintes softwares: 12tomcat7, mysql-client,
Git, Maven e 13openjdk-6-jdk.
Todas as etapas para instalação e configuração do Ansible e do Puppet estão especi-
ficadas nos apêndices 2 e 3.
3.1.1.5 MONITORAMENTO
FIG. 3.2: Nagios
Nessa etapa, o programa 14Nagios é usado para realizar a parte de monitoramento
dos aplicativos que serão implantados nesse ambiente DevOps proposto. O Nagios recebe
informações dos testes pré-configurados e se alguma falha ocorrer, envia uma mensagem
de alerta, por SMS ou e-mail, para os administradores responsáveis pelo monitoramento.
Na figura acima, pode-se ver a exemplificação do funcionamento do Nagios.
Todas as etapas de provisionamento e configuração do Nagios estão descritas no apên-
dice 3.12http://tomcat.apache.org/13http://openjdk.java.net/14https://www.nagios.org/Nagios
27
3.1.1.6 INTEGRAÇÃO CONTÍNUA
No desenvolvimento de uma aplicação cujo código é compartilhado com a equipe é
preciso seguir um processo disciplinado para garantir que as mudanças não introduzirão
problemas e que elas funcionarão corretamente com o restante do código. Ao terminar
sua tarefa, um build local é executado para que sejam realizados todos os testes (SATO,
2015).
Em um projeto com uma equipe muito grande de desenvolvimento, onde múltiplos
builds são executados em diferentes horários, fazer esse processo manualmente torna-se
custoso e ineficiente. Por esse motivo, utiliza-se um servidor de integração contínua o qual
é responsável por monitorar o repositório central de código e iniciar um build do projeto
toda vez que um novo commit for realizado.
Existem diversas ferramentas comerciais e de código aberto que podem ser usadas
para configurar um servidor de integração contínua. Escolhemos o 15Jenkins por esse ter
plugins que se integram praticamente com toda a cadeia de ferramentas DevOps.
3.1.2 PROVA DE CONCEITO
Como prova de conceito inicial e para teste de integração das ferramentas, foi colocado
em produção o projeto de uma loja virtual sobre a a plataforma 16Broadleaf Commerce.
O projeto pode ser acessado no seguinte repositório do Github:
http://github.com/dtsato/loja-virtual/devops/
Foram utilizadas as funcionalidades padrão de um site de compras online:
• Navegação e busca no catálogo de produtos;
• Páginas de produtos com nome, descrição, preço, fotos e produtos relacionados;
• Carrinho de compras;
• Processo de término de compras (checkout) customizável, incluindo código de com-
pras promocionais, dados de cobrança e de entrega;
• Cadastro de usuário;
• Histórico de compras;15https://jenkins.io/16http://www.broadleafcommerce.org/
28
• Ferramentas de administração para: catálogo de produtos, promoções, preços, taxas
de frete e páginas com conteúdo customizado;
A figura 3.3 mostra a loja virtual em produção.
FIG. 3.3: Loja virtual DevOps
As tecnologias utilizadas na aplicação da loja virtual foram:
• Java: a aplicação é escrita em Java compatível com a versão SE6 e superiores;
• Spring: framework de desenvolvimento de aplicações corporativas popular na co-
munidade Java que oferece diversos componentes como: injeção de dependências,
gerenciamento de transações e segurança;
• JPA e Hibernate: O JPA é a API de persistência Java. Hibernate é a implemen-
tação mais famosa da JPA na comunidade Java, oferecendo recursos para realizar o
mapeamento objeto-relacional entre objetos Java e as tabelas no banco de dados;
• Google Web Toolkit: o GWT é um framework desenvolvido pelo Google para
facilitar a criação de interfaces ricas que rodam no navegador;
• Apache Solr: o Solr é um servidor de pesquisa que permite a indexação do catálogo
de produtos da loja virtual e oferece uma API eficiente e flexível para efetuar a
consulta de texto;
29
• Apache Tomcat: é um servidor que implementa as tecnologias web Java Servlet e
JavaServer Pages do Java EE.
3.2 AMBIENTE PROPRIETÁRIO
3.2.1 CARACTERÍSTICAS
Conforme apresentado na seção 2.3, o Bluemix pode ser entendido como um conjunto
de opções que promovem um mecanismo de adoção incremental dos serviços de DevOps,
integrando as fases de planejamento ágil, codificação, build, testes, deploy, provisiona-
mento e integração contínua em uma única plataforma.
Enquanto experiência integrada para os desenvolvedores, a plataforma oferece:
• Solução na nuvem para desenvolver aplicações;
• Integrar gerenciamento de tarefas, planejamento ágil e controle de recursos;
• Possibilidade de uso tanto das ferramentas pessoais do desenvolvedor ou da Web
IDE; e
• Escalável, seguro e pronto para aplicações empresariais: utiliza como infraestrutura
o 17SoftLayer.
A ideia geral é que o Bluemix traga as ferramentas automatizadas de infraestrutura
e o desenvolvedor se preocupe exclusivamente com o código.
3.2.2 SERVIÇOS
O conceito de serviços no Bluemix possui um caráter interessante e peculiar. Ele
fornece serviços que podem ser usados pelas aplicações sem a necessidade de gerenciar a
configuração e operação desse serviços.
Os serviços disponíveis são listados em um catálogo na Web UI e também podem ser
obtidos usando o comando:
1 cf marketplace
Para ligar um serviço a uma aplicação que desejar usá-lo, o comando é:
1 cf bind -service appname service_instance
17http://www.softlayer.com/
30
FIG. 3.4: Tela para adicionar ou ligar serviço no Bluemix
Depois de ligar o serviço à aplicação, o Bluemix adicionará detalhes sobre o serviço a
uma variável do ambiente que se ligará às aplicações.
Um fato interessante no contexto dos serviços no Bluemix é que além de consumir
serviços, também é possível criar novos. Enquanto os serviços privados são disponíveis ex-
clusivamente para a organização do usuário, os públicos podem ser adicionados na 18IBM
Cloud Marketplace e se tornar um recurso adicional de receita, o que pode ser feito através
do estreitamento de relações com a IBM. Para isso, basta que os serviços rodem ou sejam
implantados na SoftLayer (plataforma de nuvem da IBM), ou se integrem com um dos
serviços de plataforma premium da IBM.
Como forma de organizar os serviços disponíveis aos usuários, o Bluemix oferece um
catálogo agrupado por funcionalidades. São alguns exemplos: Data and Analytics, Wat-
son, Mobile, DevOps, Segurança, Internet of Things, dentre diversos outros. Concernente
aos de DevOps, foi feito um estudo da utilidade de cada um deles visando a compreensão
do contexto de como e quando podem ser úteis:
• Active Deploy
Permite realizar o deploy de novas versões da aplicação sem tempo fora do ar.
Reativa a versão antiga caso algum problema ocorra.
• Auto-Scalling
Habilita a possibilidade de automatizar o acréscimo ou decréscimo da capacidade da
aplicação. O número de instâncias da aplicação é ajustado dinamicamente baseado
na política definida pelo serviço de Auto-Scalling;18https://www.ibm.com/marketplace/cloud/
31
• Delivery Pipeline
Automatiza o build, deploy, execução de testes e configuração de scripts para o build.
• Globalization Pipeline
Serviço de gerenciamento de traduções para rapidamente traduzir e executar apli-
cações mobile ou na nuvem para consumidores globais.
• IBM Alert Notification
Recebimento de notificações da aplicação ou de problemas do serviço rapidamente,
antes de afetar os usuários, impedindo que problemas críticos sejam ignorados.
• Track and Plan
Ferramenta para criar tasks, defeitos, descrever e acompanhar o trabalho de um pro-
jeto. Oferece recursos de planejamento ágil como backlogs, versionamento e sprints.
• Monitoring and Analytics
Permite gerenciar métricas de visibilidade e controle sobre as aplicações, como a
determinação do tempo de resposta para o usuário, entendimento da performance e
disponibilidade dos componentes da aplicação. Permite o diagnóstico de problemas
90% mais rapidamente
• Blaze Meter
Plataforma que permite o carregamento de testes web e mobile de forma inovadora.
• jKool
Visualização e análise em tempo real para dados estáticos e dinâmicos.
• New Relic
Visualização da performance do ponto de vista do usuário final, através dos servi-
dores, até o código.
• Load Impact
Ferramenta de teste sob demanda de múltiplas regiões geográficas.
3.2.3 ETAPAS DO PROCESSO DE ENTREGA
Para se iniciar a criação de uma aplicação no ambiente do Bluemix, há duas maneiras
com processos bem distintos:
32
a) Localmente
O desenvolvedor pode executar algumas das etapas do processo de entrega direta-
mente da linha de comando. Nesse modo, que possui como principal vantagem a
agilidade, o aplicativo é instanciado dentro da plataforma, porém sem necessaria-
mente instanciar os serviços de DevOps; e
b) Ambiente do Bluemix
Deve-se criar e configurar todos os serviços dentro da plataforma. Possui como
principal vantagem o encapsulamento das etapas de build e deploy, pois nesse caso
elas são executadas pelos serviços do Bluemix.
Ambas alternativas são interessantes e serão detalhadas nas etapas do processo de
entrega.
3.2.3.1 DESENVOLVIMENTO
Em relação ao local de codificação das aplicações, há diversas alternativas, ficando a
cargo do usuário escolher onde será feito:
• Desenvolvimento local, através de editores de texto ou da integração com o Eclipse
ou Visual Studio;
• Browser, através da IDE embutida no próprio Bluemix;
• Jazz Source Control, que também tem suporte embutido no Bluemix;
• Repositório git; e
• GitHub.
Concernente ao desenvolvimento ágil, é possível compartilhar o projeto com outras
contas, permitindo que essas se integrem ao desenvolvimento segundo níveis de restrição
escolhidos pelo dono da aplicação. Assim, diferentes contas podem acessar o código de
qualquer lugar, construir colaborativamente desde o início, escolher quem acessa o projeto
e como a aplicação se engaja com comunidades externas. Nos projetos públicos, é fácil ter
acesso e compartilhar trabalho com uma audiência mais ampla. Nos privados, somente é
possível compartilhar com a equipe do projeto.
O desenvolvimento ágil na nuvem também é facilitado com os serviços de DevOps do
Bluemix por funcionalidades como:
33
• Itens de trabalho para planejar, delegar e gerenciar o progresso do desenvolvimento;
• Ferramentas ágeis para o backlog do produto, releases e sprints; e
• Dashboard de gráficos para o status do projeto.
3.2.3.2 BUILD
Com o código do projeto finalizado, o build pode ser feito localmente pelo desenvolve-
dor, ou através do serviço Delivery Pipeline, opção que tem a capacidade de executar de
maneira automatizada as etapas de build, teste e deploy. Para isso, é necessário configurar
cada um desses ambientes de acordo com a aplicação.
No ambiente de build, é necessário configurar:
• Repositório da aplicação: link para o repositório onde o projeto está localizado;
• Caminho (path) do arquivo de builder no diretório do projeto;
• Tipo de builder do projeto.
Com esses passos configurados corretamente, é possível realizar o build direto pelo
Bluemix, que irá gerar os artefatos necessários para o deploy.
3.2.3.3 DEPLOY
Para a realização do deploy no Bluemix é fundamental a existência de dois arquivos
no diretório do projeto da aplicação:
• Arquivo war: artefato gerado na etapa de build; e
• Arquivo manifest.yml: permite automatizar o deploy definindo atributos necessários
à sua realização, como por exemplo: nome da aplicação, serviços utilizados, host da
URL, caminho para o arquivo war, quantidade de instâncias, memória utilizada,
entre outros.
Com esses arquivos gerados corretamente, é possível realizar o deploy de duas manei-
ras:
a) Ambiente de deploy do serviço Delivery Pipeline
É possível configurar o nome da aplicação e automatizar a realização do deploy.
Nesse contexto, o Bluemix possui um forte viés para a importância do desenvolvi-
mento dirigido a testes (não há código que seja escrito se não for para passar em
um teste).
34
FIG. 3.5: Pipeline no Bluemix
b) Interface da linha de comando
Após a instalação da API do Bluemix e do Cloud Foundry com a linha de comando,
é necessário se conectar ao Bluemix:
1 api https://api.DomainName
2 bluemix login -u username -o "org_name" -s "space_name"
E, no diretório do projeto, realizar o deploy através do comando:
1 cf push "app_name"
Se for desejado, também é possível sobrescrever atributos do arquivo manifest pelo
comando cf push.
Caso a aplicação se relacione com serviços que utilizam dados externos ao diretório do
projeto, como banco de dados, é necessário criar, configurar e ligar o serviço ao aplicativo,
e depois realizar o deploy novamente, com os serviços utilizados por ele devidamente
funcionais.
Nesse contexto, se o usuário desejar utilizar algum banco de dados que não possua
serviço equivalente no Bluemix, é necessário voltar à etapa de desenvolvimento e refatorar
o código para que exista acoplamento entre o projeto e um serviço existente no catálogo
do Bluemix.
Com o deploy realizado, é possível acessar a aplicação pelo browser através da URL
"host.mybluemix.net", sendo host o atributo configurado no arquivo manifest, que em
combinação com o domínio deve formar uma URL única.
3.2.3.4 PROVISIONAMENTO
Como o provisionamento se refere à configuração iniciais de recursos de hardware e
35
de servidores, Enquanto PaaS, os serviços do Bluemix operam sobre o Soft Layer, IaaS
da plataforma de nuvem da IBM.
Assim, diversas questões relacionadas às configurações iniciais dos recursos de hard-
ware e servidores não precisam ser abstraídas pelo usuário.
Alguns atributos relativos à infraestrutura do servidor como a memória utilizada pela
aplicação, quantidade de instâncias e URL são determinados antecipadamente na fase
de deploy através do arquivo manifest, que tem justamente a função de automatizar o
processo de deploy.
3.2.3.5 MONITORAMENTO
O monitoramento é feito através de serviços do catálogo de DevOps que possuem
como função dispôr indicadores sobre o comportamento da aplicação em execução.
O principal deles é o serviço Monitoring and Analytics, que quando ligado à uma
aplicação em execução passa a monitorá-la e a exibir o comportamento dos seguintes
parâmetros em seu dashboard:
• Disponibilidade: eficiência no tempo em que a aplicação está disponível ao usuário;
• Média do tempo de resposta ao usuário; e
• Tamanho médio retornado pelo servidor para as requisições HTTP.
Dentre os outros serviços que auxiliam no monitoramento das aplicações, destacam-se:
• IBM Alert Notification: permite notificações de problemas antes que o usuário final
seja afetado;
• jKool: fornece análises sobre o comportamento dos dados estáticos e dinâmicos; e
• New Relic: monitora parâmetros de performance do usuário final, como tempo de
carregamento da página para o backend e frontend, erros no JavaScript, erros em
cada sessão, entre outros.
3.2.3.6 INTEGRAÇÃO CONTÍNUA
Uma vez que as etapas anteriores possuem diferentes opções, a edição de aplicações
em execução por meio do Bluemix pode ser feito de diferentes maneiras.
Com o desenvolvimento da edição realizado, o usuário deve realizar novamente as
etapas de build e deploy escolhendo alguma das opções previamente mencionadas para
36
essas etapas. Caso o repositório escolhido tenha sido o Jazz Hub, o usuário pode editar
o código diretamente pela Web IDE e realizar o commit das mudanças diretamente no
repositório do Jazz Hub. Por esse caminho, totalmente dentro do ambiente do Bluemix,
o build e deploy devem necessariamente ser feitos pelo serviço de Delivery Pipeline.
Concernente ao deploy, uma vantagem trazida pelo serviço Active Deploy, caso seja
usado pela aplicação, é permitir o deploy de novas versões sem down time, reativando a
versão antiga caso algum problema ocorra.
3.2.4 PROVA DE CONCEITO
O Bluemix permite diversas possibilidades para o desenvolvimento de aplicações.
Todas as fases do processo de entrega foram testadas até o sucesso na execução com
diversas outras aplicações, que ficam dispostas no dashboard principal do Bluemix, como
mostra a figura 3.6.
FIG. 3.6: Aplicações em execução no Bluemix
Assim como os serviços que estão ligados às aplicações, na figura 3.7.
Como proposta de estudo de uma que utiliza diversas alternativas do catálogo serviços
do Bluemix, incluindo os serviços de DevOps, será demonstrado como foi instanciada a
aplicação Talent Manager, um projeto de aplicação Java web com código aberto que
utiliza banco de dados e uma inteligência artificial para agrupar e ordenar pessoas com
perfil de trabalho semelhante. A tela inicial da aplicação em produção pode ser vista na
figura 3.8.
Isso foi feito através das seguintes etapas:
a) Download do projeto através de repositório público para posteriores edições por IDE
37
FIG. 3.7: Serviços ligados às aplicações instanciadas
FIG. 3.8: Talent Manager em produção
local. O projeto editado pode ser encontrado no repositório https://github.com/
zallaricardo/talent-manager-pfc;
b) Build pela linha de comando com o ant, conforme builder da aplicação. Para isso,
no diretório raiz do projeto, executa-se do comando:
1 ant
Conforme demonstra a figura 3.9:
38
FIG. 3.9: Build do Talent Manager
c) Deploy por meio da linha de comando: Configuração do host (URL do domínio
.mybluemix.net deve ser única) no arquivo manifest.yml, e execução do comando:
1 cf push
d) Criação do serviço de banco de dados
1 cf create -service cloudantNoSQLDB Shared talent -manager -db
e) Replicação do serviço de banco de dados, através do dashboard de gerenciamento
de banco de dados disponibilizado pelo serviço do Cloudant no Bluemix. Assim,
é possível visualizar e gerenciar o banco da dados pelo Cloudant, conforme figura
3.10.
f) Criação do serviço de inteligencia entre perfis
1 cf create -service personality_insights tiered personality -
insights -talent -manager
g) Deploy final da aplicação, agora com serviços. Dessa forma, é possível visualizar os
atributos da aplicação instanciada no ambiente Bluemix, conforme figura 3.11.
Assim, é possível acessar a aplicação através da URL definida pelo deploy: talent-
manager-pfc.mybluemix.net e buscar pelos gerentes e desenvolvedores com maior
aderência a um determinado perfil, conforme figura 3.12.
39
FIG. 3.10: Banco de Dados doTalent Manager
FIG. 3.11: Deploy doTalent Manager
FIG. 3.12: Resultado de uma busca no Talent Manager
40
Conforme apresentado nas etapas do processo de entrega da arquitetura proprietária,
também é possível realizar o build e deploy pelo serviço de Delivery Pipeline. Para fins de
persistência e de completude, esse método também foi testado para colocar a aplicação
em execução, conforme figura 3.13.
FIG. 3.13: Build e deploy do Talent Manager pelo serviço Delivery Pipeline
41
4 COMPARAÇÃO ENTRE AMBIENTES
4.1 APLICAÇÃO
Para realizar a comparação entre os três ambientes DevOps com base nos parâmetros
estabelecidos no Capítulo 2 foi posto em produção a aplicação To do.
Trata-se de uma aplicação Java que persiste tarefas que ainda necessitam ser feitas.
Tão logo tais tarefas sejam realizadas essas podem ser sinalizadas como prontas e, even-
tualmente, retiradas da lista. Foram colocadas em produção três versões da aplicação:
a) Com as tarefas armazenadas em uma estrutura de dados interna, como por exemplo
em um Array;
b) Com as tarefas armazenadas no Banco de Dados Mongo;
c) Com as tarefas armazenadas no 19Couch DB via 20Cloudant
A implementação da aplicação é feita utilizando o modelo MVC onde os arquivos do
diretório frontend são guiados pelo controller.
Essa é uma aplicação sem autenticação, pois a lista de tarefas é mantida numa lista
global que diferentes usuários podem acessar, compartilhar e editar uma vez que tenham
acesso à URL. O intuito é demonstrar uma aplicação com um frontend que utiliza um
banco de dados como backend. Uma aplicação com maior completude ainda precisaria de
um sistema de autenticação de usuários.
O projeto dessa aplicação e suas referências de código aberto podem ser encontradas
em:
https://github.com/zallaricardo/to-do-pfc
O passo a passo para colocar a aplicação em produção em cada um dos três ambientes
pode ser encontrada no Apêndice 4.
A aplicação pode ser vista em produção conforme a figura 4.119http://docs.couchdb.org/en/2.0.0/20https://cloudant.com/
42
FIG. 4.1: Aplicação To-do em produção no Bluemix
4.2 COMPARAÇÃO
Concernente aos parâmetros estabelecidos no capítulo 2, pode-se analisar as seme-
lhanças e diferenças entre os ambientes na tabela comparativa 4.1.
O parâmetro complexidade de configuração de integração servidor Web e Servidor Banco
de Dados conforme apresentado no Capítulo 2, também foi analizado nos dois ambientes.
No ambiente customizado de ferramentas de código aberto tal configuração é feita manu-
almente, necessitando conhecimento técnico e tempo por parte do operador. No ambiente
proprietário Bluemix a plataforma é pré-configurada de forma que não há necesidade de
nenhuma configuração manual.
Como pode ser observado, o ambiente proprietário Bluemix tem desempenho equi-
valente ou melhor em todos os parâmetros estabelecidos. Como mostrado no presente
trabalho, podem ser montados excelentes ambientes DevOps somente com ferramentas de
código aberto. A utilização de plataformas PaaS, contudo, parece ser a tendência no que
se refere à utilização de ambientes DevOps, pois esse traz a integração entre ferramentas
de infraestrutura, deixando que as equipes de desenvolvimento se preocupem somente com
a codificação.
43
Parâmetros 1o Ambiente 2o Ambiente BluemixIDE Online Não Não SimIntegração com Git Sim Sim SimPlanejamento ágil Não Não SimGerenciamento de equipes Sim Sim SimBuild automatizado Sim Sim SimTempo de build 8.0s 8.0s 2.0sBuilders embutidos Não Não SimDeploy Automatizado Não Não SimProvisionamento Manualmente Manualmente EmbutidoMonitoramento Sim Sim SimSistema de notificação Sim Sim SimLog de Eventos Não Não Sim
TAB. 4.1: Tabela Comparativa
As eventuais vantagens do Bluemix possuem, contudo, o preço das aplicações em
produção como contra partida. Através da precificação padrão embutida na plataforma,
estimou-se:
• Bluemix: To-do Cloudant DB para um cenário com banco de dados de 20GB, preço
de U$35,00.
Todos os cenários contemplaram serviços gratuitos e pagos relativos a banco de dados,
monitoramento e provisionamento.
44
5 CONCLUSÃO
DevOps é um movimento que busca aumentar a colaboração e a comunicação entre
a equipe de desenvolvimento e a de operações enquanto busca automatizar o processo de
entrega de software e as mudanças de infraestrutura. Juntamente com o movimento de
desenvolvimento ágil de software, o movimento DevOps está ajudando a estabelecer uma
cultura onde a construção, o teste e a entrega de software pode ser feita de maneira rápida
e segura.
Nesse contexto, o presente trabalho realizou a montagem de três ambientes DevOps:
dois ambientes construídos com ferramentas de código aberto e o ambiente proprietário
Bluemix, fornecido pela IBM. A partir desses ambientes foi colocada em produção a apli-
cação comum To do para que fosse realizada a análise comparativa entre os ambientes
seguindo os parâmetros definidos no capítulo 2. No capítulo 4, tal comparação é sin-
tetizada com a tabela comparativa dos três ambientes, bem como o custo mensal de se
utilizar o ambiente proprietário.
Como principal contribuição, obteve-se o estabelecimento de parâmetros para a com-
paração dos três ambientes DevOps e a respectiva análise com base em tais parâmetros.
Além disso, deve-se analisar a contra partida dos possíveis preços das aplicações em
ambientes proprietários pois é essencial verificar se os requisitos de operação da aplicação
possuem um custo viável ao orçamento dos projetos.
Para futuros trabalhos, poder-se-ia testar os ambientes DevOps montados simulando
o desenvolvimento colaborativo de uma aplicação, bem como a entrega dessa aplicação em
produção, concluindo qual se mostra mais funcional para questões de qualidade e rapidez
em cada etapa.
45
6 REFERÊNCIAS BIBLIOGRÁFICAS
BARTH, W. Nagios: System and network monitoring. [S.l.]: No Starch Press,
2008.
BEZERRA, L. L.; SANTANA, S. A. INTEGRAÇÃO CONTÍNUA UTILIZANDO
JENKINS. [S.l.: s.n.], 2013.
CLOUD, A. E. C. Amazon web services. [S.l.: s.n.], 2011. 2011 p.
DEBOIS, P. Devopdays ghent. https://legacy.devopsdays.org, v. , 2009. Disponível
em: <https://legacy.devopsdays.org/events/2009-ghent/>. Acesso em: 2016-10-07.
GINNIVAN, J. Introduction to semantic versioning. [S.l.]: GitVersion, 2014.
HASHIMOTO, M. Vagrant: Up and Running. [S.l.]: "O’Reilly Media, Inc.", 2013.
HUMBLE, J.; FARLEY, D. Continuous Delivery: Reliable Software Releases
through Build, Test, and Deployment Automation (Adobe Reader). [S.l.]:
Pearson Education, 2010.
LEHTINEN, S.; LONVICK, C. The Secure Shell (SSH) Protocol Assigned Num-
bers. [S.l.: s.n.], 2006.
LOELIGER, J.; MCCULLOUGH, M. Version Control with Git: Powerful tools and
techniques for collaborative software development. [S.l.]: "O’Reilly Media,
Inc.", 2012.
LONGO, J.; KELLEY, T. M. Use of GitHub as a platform for open collaboration
on text documents. [S.l.: s.n.], 2015. 22 p.
MILLER, F. P.; VANDOME, A. F. ; MCBREWSTER, J. Apache Maven. [S.l.]: Alpha
Press, 2010.
MOHAAN, M.; RAITHATHA, R. Learning Ansible. [S.l.]: Packt Publishing Ltd, 2014.
PORTER, B.; CHING, M. O. Apache Maven 2 Effective Implementation. [S.l.]:
Packt Publishing, 2009.
46
REINITZ, R. IBM Bluemix Garage: Aproximando empresas e startups. [S.l.:
s.n.], 2014.
SATO, D. DevOps na prática: entreda de software confiável e automatizada.
[S.l.]: Casa do Código, 2015.
SOMASUNDARAM, R. Git: Version control for everyone. [S.l.]: Packt Publishing
Ltd, 2013.
TURNBULL, J. Pulling strings with puppet: configuration management made
easy. [S.l.]: Apress, 2008.
47
7 APÊNDICES
48
APÊNDICE 1: FERRAMENTAS
7.1.1 BANCO DE DADOS
7.1.1.1 MYSQL
É um sistema de gerenciamento de banco de dados (SGBD), que utiliza a linguagem
SQL (Linguagem de Consulta Estruturada) como interface. Atualmente um dos bancos
mais populares com mais de 10 milhões de instalações pelo mundo.
7.1.2 GERENCIAMENTO DE CONFIGURAÇÕES DE SOFTWARE - SCM
7.1.2.1 GIT
É um sistema de controle de versão distribuído e um sistema de gerenciamento de
código fonte com ênfase em velocidade Loeliger e McCullough (2012). Cada diretório
de trabalho do Git é um repositório com um histórico completo e habilidade total de
acompanhamento de revisões, não dependente de acesso a uma rede ou a um servidor
central Somasundaram (2013).
7.1.2.2 GITHUB
É um serviço de Web Hosting compartilhado para projetos que usam o controle de
versionamento Git Ginnivan (2014). Esse oferece todas as funcionalidades do sistema de
controle de revisão e gerenciamento de código (SCM) Git com algumas funcionalidades
adicionais Longo e Kelley (2015).
7.1.3 BUILD
7.1.3.1 MAVEN
Apache Maven, ou simplesmente Maven, é uma ferramenta de automação de com-
pilação utilizada primariamente em projetos Java Miller et al. (2010). O Maven utiliza
um arquivo XML para descrever o projeto de software sendo construído, suas dependên-
cias sobre módulos e componentes externos, a ordem de compilação, diretórios e plug-ins
necessários Porter e Ching (2009).
49
7.1.4 INTEGRAÇÃO CONTÍNUA - CI
7.1.4.1 JENKINS
Jenkins é uma ferramenta open source de integração contínua escrita em Java Bezerra
e SANTANA (2013). Jenkins conta com serviços de integração contínua para desenvol-
vimento de software. É um sistema de arquitetura servidor rodando em um container
servlet tal qual Apache Tomcat. Esse suporta ferramentas SCM incluindo Git e pode ser
executado em projetos utilizando Apache Ant a Apache Maven.
7.1.5 DEPLOYMENT
7.1.5.1 SSH
Parte da suíte de protocolos TCP/IP que torna segura a administração remota de ser-
vidores do tipo Unix Lehtinen e Lonvick (2006). O SSH possui as mesmas funcionalidades
do TELNET com vantagem da criptografia na conexão entre cliente e o servidor.
7.1.6 PROVISIONAMENTO
7.1.6.1 PUPPET
Utilitário para gerenciamento de configuração de código livre que roda em muitos
sistemas Unix compatíveis bem como em Microsoft Windows Turnbull (2008). Inclui sua
própria linguagem declarativa para descrever a configuração do sistema.
7.1.6.2 ANSIBLE
Plataforma de programa livre para configuração e gerenciamento de computadores,
combina deployment de software multi-nós, execução de tarefas ad hoc e gerenciamento
de configurações Mohaan e Raithatha (2014).
7.1.6.3 VAGRANT
Vagrant é um software de computador que cria e configura ambientes de desenvolvi-
mento virtuais Hashimoto (2013). Pode ser visto como um software que está em um nível
acima dos softwares de virtualização tradicionais, tais como VirtualBox, VMware, KVM
e Linux Conteineres.
50
7.1.7 MONITORAMENTO
7.1.7.1 NAGIOS
Aplicação de monitoramento de rede de código aberto distribuída sob a licença GPL
Barth (2008). Pode monitorar tanto hosts quanto serviços, alertando quando ocorrerem
problemas e também quando os problemas são resolvidos.
7.1.8 SERVIÇOS DE NUVEM
7.1.8.1 AMAZON WEB SERVICES
Plataforma de serviços em nuvem segura oferecendo poder computacional, armazena-
mento de banco de dados, distribuição de conteúdo e outras funcionalidades para ajudar
as empresas em seu dimensionamento e crescimento Cloud (2011).
7.1.8.2 IBM BLUEMIX
IBM Bluemix é uma plataforma de numve como serviço desenvolvida pela IBM Reinitz
(2014). Ele suporta diversas lingaugens de programação e serviços, bem como serviços
de DevOps para construir, executar, implantar (build, run, deploy) e gerenciar aplica-
ções na nuvem. Ele é baseado na tecnologia aberta do Cloud Foundry e roda em uma
infraestrutura do SoftLayer, com serviços que suportam em tempo de execução diversas
linguagenes de programação, incluindo Java, Node.js, Go, PHP, Python, Ruby Sinatra,
Ruby on Rails, e pode ser extendido para suportar outras linguagens como Scala, através
do uso de buildpacks.
51
APÊNDICE 2: TESTE DAS FERRAMENTAS USADAS PARA CONSTRUIR O
SEGUNDO AMBIENTE
7.2.1 CRIAÇÃO DE CHAVE PÚBLICA SSH
Primeiramente, essa arquitetura se inicia com a configuração de chaves públicas. Na
maioria dos provedores, será encontrada uma opção para adicionar uma chave SSH pú-
blica. Para criar uma chave RSA local seguiu-se os seguintes passos:
a) Digite o comando a seguir:
1 ssh -keygen -t rsa
b) Quando for perguntado sobre uma frase digite enter duas vezes.
c) Serão criados dois arquivos:
1 id_rsa_devops e id_rsa_devops.pub
d) Os arquivos com extenção .pub são os únicos que devem ser copiados para outras
máquinas e representam as chaves públicas.
7.2.2 CONFIGURAÇÃO DO CONTROLE DE VERSÃO COM GIT E GITHUB
Para gerenciar o versionamento, foi escolhida a ferramenta Git e seguiu-se os seguintes
paços para realizar sua instalação:
a) Para linux baseado em debian:
1 sudo apt -get install git -core
b) Para linux CentOS/RH
1 sudo yum install git
c) Para MacOSX com homebrew
1 brew install git
52
Após a instalação do Git, foram executados os seguintes comandos para configurar
um nome de usuário e um email, que serão usados toda vez em que for necessário se
conectar ao repositório remoto.
1 git config --global user.name "Seu nome"
2 git config --global user.email "[email protected]"
Nesse momento o ambiente está com o Git instalado e com nome e e-mail configurados.
Será adotado agora um sistema para controlar remotamente os repositórios usados para
construir o modelo de DevOps proposto.
O “Github” é um site que fornece um serviço de controle de repositórios remotos de
“Git” sem custo, caso o projeto seja aberto, e com custo caso o projeto seja privados.
Para utiliza-lo de forma gratuita, foi acessado o site “github.com”, e foi criada uma conta.
Neste ponto, será necessária a chave “ssh” que foi criada anteriormente, que está em:
1 ~/.ssh/id_rsa.pub.
A partir desse ponto, foi criado um novo repositório que posteriormente será sincro-
nizado com o repositório local que estará em cada máquina que estiver trabalhando no
projeto. Para criar esse repositório, foram seguidos os paços do site clicando no botão de
novo repositório. Para esse projeto, será dado o nome de projeto-simples. Assim, será
criado um diretório local e, posteriormente, será feita a associação desse diretório local
com o repositório remoto criado anteriormente no GitHub. Para isso, seguiu-se os passos
listados abaixo:
a) Para criar o diretório local foi digitado na linha de comando:
1 mkdir projeto -simples
b) Entrou-se nesse diretório com o comando:
1 cd projeto -simples
c) Com um editor de textos, foi criado um arquivo de exemplo, com nome de RE-
ADME.md, para poder ser sincronizado com o repositório remoto criado, explicando
a função do projeto. Foi colocado o seguinte texto no arquivo:
1 # README do meu projeto -simples
d) Esse projeto será apenas um shell script que conta itens únicos no diretório etc.
Assim, será criaco o seguinte script com o nome de itens_unicos.sh:
53
1 #!/bin/sh
2 Echo "Itens unicos"
3 Ls /etc | cut -d" -f 1 | sort | uniq | wc -l
Nesse momento, já foi criado o projeto simples que será sincronizado com o repositório
remoto no github. Foram seguidos os passos a seguir para realizar essa sincronização:
a) Para iniciar o repositório Git no diretório local:
1 git init
b) Para adicionar todos os arquivos modificados ao conjunto de modificações que serão
enviadas para serem sincronizadas com o repositório remoto:
1 git add .
c) Para criar uma mensagem, descrevendo as modificações:
1 git commit -m "mensagem descrevendo a altera\c{c}\~ao"
d) Para vincular o repositório local ao repositório remoto:
1 git remote add origin [email protected]:veniciusgrjr/projeto -
simples.git
e) Para enviar as alterações:
1 git push -u origin master
Após isso, a página do repositório remoto foi atualizada e os arquivos locais puderam
ser visializados remotamente. Foi feito agora um pequeno resumo dos comandos do Git:
• Esse comando Inicia um repositório Git no diretório atual.
1 Git init
• Adiciona um ou mais arquivos para serem enviados (commit) ao repositório.
1 Git add.
• Confirma as mudanças e cria um commit com uma mensaApós isso, faça reload da
página do repositório, e os arquivos locais estarão lá.
1 Git commit -m "mensagem"
54
• Esse comando adiciona um remote ao repositório atual, chamado origin. Você po-
deria trabalhar sem ter um remote, não é mandatório.
1 Git remote ...
• Envia push as modificações para o repositório remoto. O parametro -u só é necessário
na primeira execução.
1 Git push -u origin master
• Cria uma cópia o repositório dado pela URL para a máquina local em que foi
digitado.
1 Git clone
• Mostra o estado atual do repositório e das mudanças.
1 Git status
Agora, para testar a ferramenta de sincronização, o diretório local será modificado e
sincronizado com o repositório no Github. Para isso, foi criado um arquivo com o nome
de portas.sh, com o seguinte código:
1 #!/bin/sh
2 echo "Lista de porta 80 no netstat"
3 netstat -an | grep 80
Para adicionar essa modificação ao repositório no Github, foram executados os se-
guintes comandos:
1 Git add portas.sh
2 Git commit -m "add portas.sh"
3 Git push origin master
7.2.3 INSTALAÇÃO E CONFIGURAÇÃO DO VAGRANT E DO VIRTUALBOX
Uma máquina virtual parada é uma imagem de um disco de metadados que descrevem
sua configuração: processador, memória, discos e conexões externas. A mesma máquina
em execução é um processo que depende de um scheduler( agendador de processos) para
coordenar o uso dos recursos locais.
Para gerenciar máquinas virtuais, pode-se usar as interfaces das aplicações Virtu-
alBox, Parallels ou VMW, ou pode-se utilizar bibliotecas e sistemas que abstraem as
55
diferenças entre essas plataformas, com interface consistente para criar, executar, parar e
modificar uma máquina virtual.
Para criar e gerenciar os ambientes de máquinas virtuais locais, foi escolhido o soft-
ware Vagrant (www.vagrantup.com). Para executar as máquinas virtuais, foi escolhido o
software VirtualBox(www.virtualbox.org).
O Vagrant gerencia e abstrai provedores de máquinas virtuais locais e públicos(
VMWare, VirtualBox, Amazon AWS, DigitalOcean, entre outros). Ele tem uma lingua-
gem especifica (DSL) que descreve o ambiente e suas máquinas. Além disso, ele fornece
interface para os sistemas de gerenciamento de configuração mais comuns como Chef,
Puppet, CFEngine e Ansible. Ele é um software que cria e configura ambientes virtuais
de desenvolvimento. Possui interface de linha de comando simples para subir e interagir
com esses ambientes virtuais.
Essa ferramenta ajuda na criação da infraestrutura para o projeto, usando para isso
uma máquina virtual. Nesse momento surge um questionamento: será preciso uma má-
quina virtual para cada projeto, isso não complicaria ainda mais o projeto? A resposta
é não. O Vagrant deixa muita coisa invísivel, possibilitando se preocupar apenas com o
código. Funciona como uma máquina virtual reduzida e portável. Para cada projeto é
possível deixar um ambiente rodando PHP 4, outro PHP 5, outro Debian e outro CentOS.
Para instalação do Virtualbox, foram seguidos os paços do site www.virtualbox.org.
Após isso, para testar se tudo está funcionando, foi feito o download de uma ISO do ubuntu
em www.ubuntu.com/download/server e testou-se a criação de máquinas virtuais.
Para instalar o Vagrant, foi acessado www.vagrantup.com e, foram seguidos os passos
da instalação. Para criar uma máquina virtual usando o Vagrant seguiu-se os paços
abaixo:
a) Foi criado um diretório chamado testvm.
b) Foi criado um arquivo chamado vagrantfile e digitado nele:
1 # -*- mode: ruby -*-
2 # vi: set ft=ruby :
3
4 VAGRANTFILE_API_VERSION = ’’2’’
5
6 Vagrant.configure( VAGRANTFILE_API_VERSION ) do |config|
7
8 config.vm.define ’’testvm ’’ do |testvm|
56
9 testvm.vm.box = ’’ubuntu/trusty64 ’’
10 testvm.vm.network : private_network , ip : ’’
192.168.33.21 ’’
11 end
12 config.vm.provider ’’virtualbox ’’ do |v|
13 v.customize [’’modifyvm ’’, :id, ’’--memory ’’,
’’1024’’]
14 end
15 end
c) No diretório desse arquivo criado,para subir o servidor digitou-se:
1 vagrant up
d) Para testar, foi feita uma conexão com a máquina virtual criada digitando-se:
1 vagrant ssh
e) É importante notar que dentro da máquina o seu diretório local foi mapeado como
um mount point dentro da máquina virtual, acessando o diretório vagrant digitando
cd /vagrant é possível observar isso. É possível criar este ponto com outro nome ou
deixar de criá-lo de acordo com a configuração do Vagrantfile.
f) Para destruir a máquina virtual criada, basta digitar no terminal:
1 vagrant destroy
2 \/\/ seguido de y, quando for perguntado se pode realmente
destruir a m\’aquina virtual
Assim, resumindo os comandos, temos:
a) Para subir a máquina virtual:
1 vagrant up
b) Para se conectar à máquina virtual:
1 vagrant ssh
c) Para destruir a máquina virtual:
1 vagrant destroy
57
d) Para desativar a máquina virtual:
1 vagrant halt
e) Para executar somente o provisionamento:
1 vagrant provision
Usar os processos fornecidos pelo VirtualBox, por exemplo, para criar máquinas vir-
tuais se torna um processo demorado e difícil de ser replicado. Usando esse Vagrantfile,
é possível subir( up) a mesma máquina várias vezes, em ocasiões distintas sem usar a
interface do VirtualBox. É possível versionar este arquivo que descreve a máquina virtual
junto com seu código e quando mudar a configuração de memória, por exemplo, esta
mudança estará no histórico junto às mudanças de código.
O Vagrant e sua configuração utilizam Ruby. Existem versões distintas de APIs e
nesse trabalho será utilizada a versão 2. Assim, dentro de uma instância da configuração
definiu-se máquinas e suas características, em um bloco de código Ruby.
O Vagrant implementa o conceito de provisionador com drivers para quase todos os
sistemas de gerenciamento de configuração existentes. Estes sistemas vão desde receitas
simples para instalar pacotes até agentes que verificam a integridade de arquivos de con-
figuração e variáveis do sistema. Vamos utilizar um driver de provisionamento do vagrant
que permite que um arquivo com comandos do shell seja executado logo após a criação
da máquina virtual. Assim será criado o arquivo webserver.sh no mesmo diretório e com
o seguinte código:
1 #!/bin/bash
2
3 echo ’’Atualizando repositorio ’’
4 sudo apt -get update
5 echo ’’Instalando o nginx’’
6 sudo apt -get -y install nginx
Agora o vagrantfile será editado para que o provisionamento seja ativado. ele deve
ficar com o exposto abaixo:
1 # -*- mode: ruby -*-
2 # vi: set ft=ruby :
3
4 VAGRANTFILE_API_VERSION = ’’2’’
5
58
6 Vagrant.configure( VAGRANTFILE_API_VERSION ) do |config|
7
8 config.vm.define ’’testvm ’’ do |testvm|
9 testvm.vm.box = ’’ubuntu/trusty64 ’’
10 testvm.vm.network : private_network , ip : ’’
192.168.33.21 ’’
11 testvm.vm.provision ’’shell’’, path: ’’webserver.sh
’’
12 end
13 config.vm.provider ’’virtualbox ’’ do |v|
14 v.customize [’’modifyvm ’’, :id, ’’--memory ’’, ’’
1024’’]
15 end
16 end
Agora, a máquina que está rodando será destruída com vagrant destroy e criada
novamente com vagrant up. Observando a saída do terminal, e fazendo o teste no browser,
percebe-se que o nginx foi instalado com sucesso sem a necessidade de se conectar por ssh
para executar o comando que instala o nginx na máquina virtual.
Vamos instalar, agora, o PHP5 na máquina virtual. Para isso, será modificado o
arquivo webserver.sh de acordo com o código a seguir:
1 #!/bin/bash
2
3 echo ’’Atualizando repositorio ’’
4 sudo apt -get update
5 echo ’’Instalando o nginx’’
6 sudo apt -get -y install nginx
7 echo ’’instalando PHP’’
8 sudo apt -get install -y php5 -fpm
Nesse ponto, não foi preciso destruir e recriar a máquina para executar novamente o
provisionamento. Foi aproveitado o fato de que o gerenciador de pacotes não instalará
um pacote duas vezes. Assim, é possível executar o mesmo script, que só o PHP seria
instalado. O Vagrant oferece um comando que ativa somente a fase do provisionamento,
vagrant provision. Assim, executando vagrant provision no terminal, observa-se a exe-
cução do script. Note que os comandos do Vagrant só funcionaram dentro do diretório
em que o vagrantfile está. Com o comando ls -larth é possível ver que foi criado um
59
diretório chamado .vagrant que contém todos os dados do ciclo de vida e provisionamento
da máquina virtual.
7.2.4 INSTALAÇÃO E CONFIGURAÇÃO DO ANSIBLE
É um sistema de automação de configuração feito em python, que permite descrever
procedimentos em arquivos no formato YAML que são reproduzidos utilizando SSH em
máquinas remotas. Existem outras ferramentas desta categoria que executam localmente
e que fornecem sevidores para o gerenciamento de dados remotamente, como CHEF,
Puppet e CFEngine. Para essa arquitetura será utilizado o Ansible localmente sem seu
servidor de dados, o Ansible Tower.
O Ansible vem com bibliotecas completas para quase todas as tarefas, além de uma
linguagem de template. Além das tarefas dentro de um servidor, o Ansible fornece mó-
dulos para o provisionamento de máquinas e aplicações remotas. Provisionar é o jargão
para instalar e configurar itens de infraestrutura e plataforma como máquinas, bancos de
dados e balanceadores de carga.
Sistemas como o Ansible implementam tarefas com uma característica importante:
idempotência. A idempotência é uma propriedade que, aplicada ao gerenciamento de
configuração, garante que as operações terão o mesmo resultado independentemente do
momento em que serão aplicadas. A criação de uma máquina utilizando este conjunto de
configurações sempre terá o resultado previsível. Para instalar no ubuntu, utilizou-se os
seguintes comandos:
1 sudo apt -get install software -properties -common
2 sudo apt -add -repository ppa:ansible/ansible
3 sudo apt -get update
4 sudo apt -get install ansible
Para testar se foi instalado corretamente, foi digitado no terminal ansible-playbook
-h, para verificar se aparece a ajuda do Ansible. Para configurar o Ansible, foi criado no
diretório testvm o arquivo com o código a seguir, com o nome de webserver.yml:
1 - hosts: all
2 sudo: True
3 user: vagrant
4 tasks:
5 - name: "Atualiza pacotes"
6 shell: sudo apt -get update
60
7 - name: "Instala o nginx"
8 shell: sudo apt -get -y install nginx
Esse formato de arquivo funciona como um dicionário no formato: chave: valor.
Agora, temos que reconfigurar o Vagrant, para isso o arquivo vagrantfile deve ficar do
modo a seguir:
1 # -*- mode: ruby -*-
2 # vi: set ft=ruby :
3
4 VAGRANTFILE_API_VERSION = ’’2’’
5
6 Vagrant.configure( VAGRANTFILE_API_VERSION ) do |config|
7
8 config.vm.define ’’testvm ’’ do |testvm|
9 testvm.vm.box = ’’ubuntu/trusty64 ’’
10 testvm.vm.network : private_network , ip : ’’
192.168.33.21 ’’
11 testvm.vm.provision ’’ansible ’’ do |ansible|
12 ansible.playbook = ’’webserver.yml’’
13 ansible.verbose = ’’vvv’’
14 end
15 end
16 config.vm.provider ’’virtualbox ’’ do |v|
17 v.customize [’’modifyvm ’’, :id, ’’--memory ’’, ’’
1024’’]
18 end
19 end
A definição de máquina virtual de testvm tem um atributo que define um provisio-
nador. Na configuração anterior, foi utilizado um shell script para instalar o nginx. Com
essa mudança, o Vagrant utilizará o Ansible como provisionador com o playbook webser-
ver.yml. Usou-se o atributo verbose do Ansible com o valor vvv para indicar que todas
as mensagens devem ser enviadas para o console, e assim pode-se observar os comandos
sendo executados.
Toda task é uma função de um módulo de Ansible. Os módulos que vêm na insta-
lação padrão são chamados de Core Modules. É possível construir módulos utilizando a
linguagem Python e estender o Ansible. Agora o playbook precisa ser refatorado, para
61
utilizar um módulo core chamado 21apt_module em vez do módulo shell. O módulo shell
é útil para automatizar muitas tarefas, mas o Ansible possui módulos especializados que
cuidam da consistência da tarefa e criam estados para manter a idempotência. Assim, o
arquivo webserver.yml deve ficar desse modo:
1 - hosts: all
2 sudo: True
3 user: vagrant
4 tasks:
5 - name: "Atualiza pacotes e instala nginx"
6 apt: name=nginx state=latest update_cache=yes
7 install_recommends=yes
Note que duas tarefas foram reduzidas a uma que utiliza o módulo apt e diz para
o Ansible instalar o nginx na última versão presente no repositório. Um dos atributos
desta tarefa está indicando que um update no cache do gerenciador de pacotes deve ser
executado. Outro atributo indica que as dependências recomendadas devem ser instaladas
automaticamente. Note que, utilizando o módulo shell, foi preciso pedir explicitamente
pela atualização do repositório e também adicionar o parâmetro -y ao comando apt-get
install para evitar que a task ficasse esperando uma entrada do usuário.
O Ansible também fornece um módulo para o gerenciador de pacotes 22yum e diretivas
condicionais que podem ser usadas para detectar o sistema operacional e distribuições
de Linux. Veja como declarar a mesma task para instalar nginx para duas famílias de
distribuições de Linux utilizando o condicional when e variáveis internas do Ansible:
1 - name: Install the nginx packages
2 yum: name ={{ item }} state=present
3 with_items: redhat_pkg
4 when: ansible_os_family == "RedHat"
5 - name: Install the nginx packages
6 apt: name ={{ item }} state=present update_cache=yes
7 with_items: ubuntu_pkg
8 environment: env
9 when: ansible_os_family == "Debian"
Para testar o novo webserver.yml, basta digitar vagrant up ou apenas vagrant provi-
sion caso sua máquina virtual ainda esteja sendo executada. Execute o provisionamento21http://docs.ansible.com/apt_module.html22http://docs.ansible.com/yum_module.html
62
em seguida para notar a diferença entre a primeira e a segunda execução. Esta é uma
maneira simples de verificar a idempotência do playbook: na segunda rodada, o atributo
changed deve ser 0.
7.2.5 INSTALAÇÃO DO JENKINS
Primeiramente, é necessário atualizar o instalador de pacotes do ubuntu com o se-
guinte comando:
1 sudo apt -get update
Agora, deve-se instalar o servidor nginx, pois o Jenkins depende do mesmo. Assim:
1 sudo apt -get install nginx
Para testar se o nginx está funcionando, basta digitar o seguinte comando:
1 sudo service nginx status
Agora, prosseguindo com a instalação dos requisitos do Jenkins, será instalado o Java 7,
com o seguinte comando:
1 sudo apt -get install openjdk -7-jdk
Nesse momento o ambiente está pronto para receber a instalação do Jenkins. Assim,
será adicionada a chave para instalação e uma lista de fontes ao apt, com os seguintes
comandos:
1 wget -q -O - https://jenkins -ci.org/debian/jenkins -ci.org.key |
sudo apt -key add -
1 sh -c ’echo deb http ://pkg.jenkins -ci.org/debian binary/ > /etc/apt
/sources.list.d/jenkins.list’
Agora, é necessário atualizar o apt para que as alterações tenham efeito.
1 sudo apt -get update
Assim, nesse momento será feita a instalação do Jenkins:
1 sudo apt -get install -y jenkins
Para verificar se o Jenkins está ativo:
1 sudo service jenkins status
Para alterar as configurações do Jenkins, basta acessar o arquivo:
1 vim /etc/default/Jenkins
63
7.2.6 CRIAÇÃO E TESTE DO SERVIDOR DE BANCO DE DADOS
Primeiramente, foi criado um diretório para abrigar os arquivos necessários para a
construção da arquitetura, com o comando:
1 mkdir exemplo_db
Após isso, acessou-se o diretório criado para iniciar a criação das configurações, com
o comando:
1 cd exemplo_db
Para baixar um box do sistema operacional pré-configurado utilizou-se:
1 vagrant box add hashicorp/precise32
Para criar o servidor de banco de dados, foi criado um arquivo de texto chamado de
vagrantfile que, ao ser executado pelo programa vagrant, cria o servidor:
1 VAGRANTFILE_API_VERSION = ’’2’’
2 Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
3 config.vm.box = ’’hashicorp/precise32 ’’
4 config.vm.define :db do |db_config|
5 db_config.vm.hostname = ’’db’’
6 db_config.vm.network :private_network , :ip => ’’192.168.33.10 ’’
7 end
8 end
Nesse arquivo, o comando "VAGRANTFILE_API_VERSION"especifica a versão da
API do Vagrant usada. O comando "Vagrant.configure(VAGRANTFILE_API_VERSION)
do |config|"cria um objeto com o nome config responsável pelas configurações gerais do
sistema que será executado pelo Virtual Box. O comando "config.vm.box"especifica
qual a versão do sistema operacional que será instalado no servidor, que nesse caso
é o ubuntu precise32, fornecido pela hashicorp. O comando "config.vm.define :db do
|db_config|"define o banco de dados e cria o objeto "db_config"responsável pelas confi-
gurações da instância do servidor. O comando "db_config.vm.hostname"define o nome
do host que será criado. O comando "db_config.vm.network"define os parâmetros de
configurações de rede para a máquina criada. Para criar e ativar o servidor, utilizou-se o
vagrant, com o seguinte comando:
1 vagrant up
Tendo realizado esses passos, tem-se um servidor online e para acessa-lo basta usar o
comando que realiza a conexão por ssh:
64
1 vagrant ssh db
Nesse momento, será iniciada a configuração do servidor para que funcione como um
servidor de banco de dados, usando Mysql. Para instalar o mysql seguimos os passos:
1 sudo apt -get update -y
2 sudo apt -get install -y mysql -server
Quando a senha foi solicitada, colocou-se "secret". A partir desse ponto, as configu-
rações necessárias foram feitas para que o Mysql consiga atender às requisições do sistema
que será executado como exemplo. Primeiramente, foi criado um arquivo de configura-
ção para permitir acesso por máquinas externas. Com o editor de texto nano, criou-se o
arquivo "allow_external.cnf"no diretório "/etc/mysql/conf.d/".
1 sudo nano /etc/mysql/conf.d/allow_external.cnf
Com o texto:
1 [mysqld]
2 bind -address = 0.0.0.0
Após esses passos, reiniciou-se o servidor Mysql para que as configurações tenham
efeito:
1 sudo service mysql restart
Asseguir, foi criado o banco bara atender ao sistema que será executado como exemplo.
1 mysqladmin -u root -p create loja_schema
Para verificar se o banco foi criado corretamente:
1 mysql -u root -p -e "SHOW DATABASES"
Agora, como medida de segurança removeu-se o usuário padrão para que fontes des-
conhecidas não tenham acesso ao banco de dados em questão.
1 mysql -uroot -p -e "DELETE FROM mysql.user WHERE user=’\>’; FLUSH
PRIVILEGES"
Agora, criaremos um usuário chamado "loja"com senha "lojasecret"especifico para o
sistema que servirá de exemplo:
1 mysql -uroot -p -e "GRANT ALL PRIVILEGES ON loja_schema .* TO ’loja’
@’%’ IDENTIFIED BY ’lojasecret ’;"
Para testar se o usuário foi criado corretamente:
65
1 mysql -u loja -p loja_schema -e "select database (), user()"
Para se desconectar da máquina virtual:
1 logout
7.2.7 CRIAÇÃO E TESTE DO SERVIDOR WEB
Primeiramente, foi criado um diretório para abrigar os arquivos necessários para a
construção da arquitetura, com o comando:
1 mkdir exemplo_web
Após isso, acessou-se o diretório criado para iniciar a criação das configurações, com
o comando:
1 cd exemplo_web
Para criar o servidor web, foi criado um arquivo de texto chamado de vagrantfile que,
ao ser executado pelo programa vagrant cria o servidor. Asseguir tem-se o código que foi
utilizado:
1 VAGRANTFILE_API_VERSION = ’’2’’
2 Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
3 config.vm.box = ’’hashicorp/precise32 ’’
4 config.vm.define :web do |web_config|
5 web_config.vm.hostname = "web"
6 web_config.vm.network :private_network ,:ip => "192.168.33.12"
7 end
8 end
Após esse passo, executou-se os seguintes comando para a criação do servidor:
1 vagrant up web
Assim, teve-se o servidor web criado e pronto para ser configurado para atender as
especificações do sistema que será executado como exemplo. Para acessar o servidor:
1 vagrant ssh web
Para instalar o servidor web Tomcat7 e o mysql-client usou-se os seguintes comandos:
1 sudo apt -get update
2 sudo apt -get install -y tomcat7 mysql -client
Para testar se o servidor foi instalado corretamente basta acessar o endereço:
66
1 http:// 192.168.33.12:8080/
Para configurar a ferramenta Keytool para conexões SSL, acessou-se o seguinte dire-
tório com o comando:
1 cd /var/lib/tomcat7/conf
Para configurar a ferramenta seguiu-se os passos abaixo:
1 sudo keytool -genkey -alias tomcat -keyalg RSA -keystore .keystore
2
3 Enter keystore password:secret
4 Re-enter new password:secret
5 What is your first and last name?
6 [Unknown ]: Loja Virtual
7 What is the name of your organizational unit?
8 [Unknown ]: Devops na Pr\’atica
9 What is the name of your organization?
10 [Unknown ]: Casa do C\’odigo
11 What is the name of your City or Locality?
12 [Unknown ]: S\~ao Paulo
13 What is the name of your State or Province?
14 [Unknown ]: SP
15 What is the two -letter country code for this unit?
16 [Unknown ]: BR
17 Is CN=Loja Virtual , OU=Devops na Pr\’atica , ..., C=BR correct?
18 [no]: yes
19 Enter key password for <tomcat > secret
20 (RETURN if same as keystore password):
Para configurar servidor tomcat para habilitar conexões ssl, criou-se o arquivo "ser-
ver.xml"no diretório "/var/lib/tomcat7/conf", com o seguinte código:
1 <?xml version=’1.0’ encoding=’utf -8’?>
2 <Server port="8005" shutdown="SHUTDOWN">
3 <Listener className="org.apache.catalina.core.JasperListener" />
4 <Listener className="org.apache.catalina.core.
JreMemoryLeakPreventionListener" />
5 <Listener className="org.apache.catalina.mbeans.
GlobalResourcesLifecycleListener" />
67
6 <Listener className="org.apache.catalina.core.
ThreadLocalLeakPreventionListener" />
7 <GlobalNamingResources >
8 <Resource name="UserDatabase" auth="Container"
9 type="org.apache.catalina.UserDatabase"
10 description="User database that can be updated and
saved"
11 factory="org.apache.catalina.users.
MemoryUserDatabaseFactory"
12 pathname="conf/tomcat -users.xml" />
13 </GlobalNamingResources >
14 <Service name="Catalina">
15 <Connector port="8080" protocol="HTTP /1.1"
16 connectionTimeout="20000"
17 URIEncoding="UTF -8"
18 redirectPort="8443" />
19 <Connector port="8443" protocol="HTTP /1.1" SSLEnabled="true"
20 maxThreads="150" scheme="https" secure="true"
21 keystoreFile="conf/. keystore"
22 keystorePass="secret"
23 clientAuth="false" sslProtocol="SSLv3" />
24 <Engine name="Catalina" defaultHost="localhost">
25 <Realm className="org.apache.catalina.realm.LockOutRealm">
26 <Realm className="org.apache.catalina.realm.
UserDatabaseRealm"
27 resourceName="UserDatabase"/>
28 </Realm >
29 <Host name="localhost" appBase="webapps"
30 unpackWARs="true" autoDeploy="true">
31 <Valve className="org.apache.catalina.valves.AccessLogValve
" directory="logs"
32 prefix="localhost_access_log." suffix=".txt"
33 pattern="%h %l %u %t "%r" %s %b" />
34 </Host >
35 </Engine >
36 </Service >
37 </Server >
68
Em seguida, para que o servidor suporte o site que será executado, foi necessário
alterar a quantidade de memória usada pelo tomcat7. Para isso, alterou-se o arquivo
"tomcat7"no diretório "/etc/default/"para:
1 TOMCAT7_USER=tomcat7
2
3 TOMCAT7_GROUP=tomcat7
4
5 JAVA_OPTS="-Djava.awt.headless=true -Xmx512m -XX:+
UseConcMarkSweepGC"
6
7 #AUTHBIND=no
Para reiniciar o servidor para que as configurações tenham efeito:
1 sudo service tomcat7 restart
Para testar, basta acessar o endereço:
1 https:// 192.168.33.12:8443/
Nesse ponto tem-se o servidor configurado. Asseguir, será instalado o software que
fará o build( Maven2 ) do projeto e clonará( git) o repositório do site exemplo:
1 sudo apt -get install -y git maven2 openjdk -6-jdk
Para clonar o projeto exemplo:
1 git clone https:// github.com/dtsato/loja -virtual -devops.git
Após essa etapa, o build do projeto será feito com os seguintes comandos:
1 cd loja -virtual -devops
2 export MAVEN_OPTS=-Xmx256m
3 mvn install
Agora vamos configurar o acesso ao banco de dados que foi criado anteriormente.
Para isso, deve-se deixar o arquivo "context.xml"no diretório "/var/lib/tomcat7/conf/"da
seguinte forma:
1 <?xml version=’1.0’ encoding=’utf -8’?>
2 <Context >
3
4 <WatchedResource >WEB -INF/web.xml </ WatchedResource >
5 <Resource name="jdbc/web" auth="Container"
69
6 type="javax.sql.DataSource" maxActive="100" maxIdle="30"
7 maxWait="10000" username="loja" password="lojasecret"
8 driverClassName="com.mysql.jdbc.Driver"
9 url="jdbc:mysql ://192.168.33.10:3306/ loja_schema"/>
10 <Resource name="jdbc/secure" auth="Container"
11 type="javax.sql.DataSource" maxActive="100" maxIdle="30"
12 maxWait="10000" username="loja" password="lojasecret"
13 driverClassName="com.mysql.jdbc.Driver"
14 url="jdbc:mysql ://192.168.33.10:3306/ loja_schema"/>
15 <Resource name="jdbc/storage" auth="Container"
16 type="javax.sql.DataSource" maxActive="100" maxIdle="30"
17 maxWait="10000" username="loja" password="lojasecret"
18 driverClassName="com.mysql.jdbc.Driver"
19 url="jdbc:mysql ://192.168.33.10:3306/ loja_schema"/>
20 </Context >
Agora, será feito o deploy da aplicação com os comandos abaixo:
1 cd ~/loja -virtual -devops
2 sudo cp site/target/devopsnapratica.war /var/lib/tomcat7/webapps
Pode-se monitorar o log do servidor com o seguinte comando:
1 tail -f /var/lib/tomcat7/logs/catalina.out
Agora, para testar, basta acessar o endereço:
1 http:// 192.168.33.12:8080/ devopsnapratica/
70
APÊNDICE 3: CONSTRUÇÃO DO SEGUNDO AMBIENTE
7.3.1 INSTALAÇÃO DO VIRTUALBOX E DO VAGRANT
1 sudo apt -get install virtualbox
2 sudo apt -get install vagrant
3 sudo apt -get install virtualbox -dkms
7.3.2 INSTALAÇÃO DO ANSIBLE
1 sudo apt -get install software -properties -common
2 sudo apt -add -repository ppa:ansible/ansible
3 sudo apt -get update
4 sudo apt -get install ansible
7.3.3 CONSTRUÇÃO
Foi criado um diretório chamado exemplo para comportar os arquivos do projeto:
1 mkdir exemplo
2 cd exemplo
Após acessar o diretório criado, foi criado um arquivo de configuração do Vagrant,
chamado vagrantfile com o código abaixo:
1 VAGRANTFILE_API_VERSION = "2"
2 Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
3 config.vm.box = "hashicorp/precise32"
4
5 config.vm.define :db do |db_config|
6 db_config.vm.hostname = "db"
7 db_config.vm.network :private_network , :ip => "192.168.33.10"
8 db_config.vm.provision "ansible" do |ansible|
9 ansible.playbook = "db.yml"
10 end
11 end
12
71
13 config.vm.define :web do |web_config|
14 web_config.vm.hostname = "web"
15 web_config.vm.network :private_network ,:ip => "192.168.33.12"
16 web_config.vm.provision "ansible" do |ansible|
17 ansible.playbook = "web.yml"
18 end
19 end
20 end
Após essa etapa, foram criados dois arquivos de configuração do Ansible, um para o
servidor web e outro para o servidor db, chamados web.yml e db.yml, respectivamente.
1 - hosts: all
2 sudo: True
3 user: vagrant
4 tasks:
5 - name: "Atualizando pacotes"
6 shell: sudo apt -get -y update
7
8 - name: "Instalando tomcat7 mysql -client "
9 shell: sudo apt -get install -y tomcat7 mysql -client
10
11 - name: "Configurando o Keytool para conex\~oes ssl"
12 shell: sudo keytool -genkey -alias tomcat -keyalg RSA -
keystore /var/lib/tomcat7/conf/. keystore < /vagrant/tmp
13
14 - name: "Removendo /var/lib/tomcat7/conf/server.xml" ## ok
15 shell: sudo rm /var/lib/tomcat7/conf/server.xml
16
17 - name: "Copiando /var/lib/tomcat7/conf/server.xml correto"
18 shell: sudo cp /vagrant/server.xml /var/lib/tomcat7/conf/
server.xml ## ok
19
20 - name: "Removendo /etc/default/tomcat7" ## ok
21 shell: sudo rm /etc/default/tomcat7
22
23 - name: "Copiando /etc/default/tomcat7 atualizado"
24 shell: sudo cp /vagrant/tomcat7 /etc/default/tomcat7 ## ok
72
25
26 - name: "Reiniciando tomcat" ## ok
27 shell: sudo service tomcat7 restart
28
29 - name: "Instalando git , maven2 e openjdk -6-jdk" ## ok
30 shell: sudo apt -get install -y git maven2 openjdk -6-jdk
31
32 - name: "Clonando o projeto loja -virtual -devops.git" ## ok
33 shell: git clone https:// github.com/dtsato/loja -virtual -
devops.git
34
35 - name: "Export MAVEN_OPTS"
36 shell: export MAVEN_OPTS=-Xmx256m ##########
37
38 - name: "Copiando o arquivo de configurac \~ao do Maven"
39 shell: sudo cp /vagrant/pom.xml /home/vagrant/pom.xml
40
41 - name: "Buinging"
42 shell: sudo mvn install
43
44 - name: "Removendo /var/lib/tomcat7/conf/context.xml"
45 shell: sudo rm /var/lib/tomcat7/conf/context.xml
46
47 - name: "Copiando /var/lib/tomcat7/conf/context.xml correto"
48 shell: sudo cp /vagrant/context.xml /var/lib/tomcat7/conf/
context.xml
49
50 - name: "Deploy"
51 shell: sudo cp /home/vagrant/loja -virtual -devops/site/target/
devopsnapratica.war /var/lib/tomcat7/webapps
52
53 - name: "Reiniciando o tomcat7"
54 shell: sudo service tomcat7 restart
1 - hosts: all
2 sudo: True
3 user: vagrant
73
4 vars:
5 MySQL_root_pass: secret
6 MySQL_loja_pass: lojasecret
7 tasks:
8
9 - name: "Atualizando pacotes"
10 shell: sudo apt -get -y update
11
12 - name: "Set MySQL root password before installing"
13 debconf: name=’mysql -server ’ question=’mysql -server/
root_password ’ value=’{{ MySQL_root_pass | quote}}’ vtype=’
password ’
14
15 - name: "Confirm MySQL root password before installing"
16 debconf: name=’mysql -server ’ question=’mysql -server/
root_password_again ’ value=’{{ MySQL_root_pass | quote}}’
vtype=’password ’
17
18 - name: "Install MySQL"
19 apt: package ={{ item }} state=installed force=yes
update_cache=yes cache_valid_time =3600
20 when: ansible_os_family == ’Debian ’
21 with_items:
22 - mysql -server
23 - mysql -client
24 - python -mysqldb
25
26 - name: "Deletes anonymous MySQL server user for localhost"
27 mysql_user: user="" state="absent" login_password="{{
MySQL_root_pass }}" login_user=root
28
29 - name: "Secures the MySQL root user"
30 mysql_user: user="root" password="{{ MySQL_root_pass }}" host
="{{ item }}" login_password="{{ MySQL_root_pass }}"
login_user=root
31 with_items:
32 - 127.0.0.1
74
33 - localhost
34 - ::1
35 - "{{ ansible_fqdn }}"
36
37 - name: "Removes the MySQL test database"
38 mysql_db: db=test state=absent login_password="{{
MySQL_root_pass }}" login_user=root
39
40 - name: "Criando o arquivo de configurac \~ao allow_external.cnf
"
41 shell: sudo cp /vagrant/allow_external.cnf /etc/mysql/conf.d/
allow_external.cnf
42
43 - name: "Reiniciando o Mysql"
44 shell: sudo service mysql restart
45
46 - name: "Criando o banco loja_schema"
47 mysql_db: name=loja_schema state=present login_password="{{
MySQL_root_pass }}" login_user=root
48
49 - name: "Criando usuario mysql"
50 mysql_user: name=loja password="{{ MySQL_loja_pass }}" priv=
loja_schema .*:ALL ,GRANT state=present login_password="{{
MySQL_root_pass }}" login_user=root
Após a criação desses arquivos de configuração, criou-se o seguinte script para instalar
dos pacotes necessários e para executar a ferramenta principal, Vagrant, que criará todo
o ambiente:
1 #!/bin/bash
2
3 echo "Atualizando reposit\’orios"
4 sudo apt -get update
5
6 echo "Instalando Virtual Box"
7 sudo apt -get -y install virtualbox
8
9 echo "Instalando Vagrant"
75
10 sudo apt -get -y install vagrant
11
12 echo "Instalando dkms"
13 sudo apt -get -y install virtualbox -dkms
14
15
16 echo "Instalando Ansible"
17 sudo apt -get -y install software -properties -common
18 sudo apt -add -repository -y ppa:ansible/ansible
19 sudo apt -get update
20 sudo apt -get -y install ansible
21
22 echo "Baixando um box pre -configurado hashicorp/precise32"
23 sudo vagrant box add hashicorp/precise32
24
25 echo "Executando o Vagrant e criando os servidores"
26 sudo vagrant up
Após a criação desse script, basta executá-lo para criar o ambiente:
1 sudo sh ./ arquitetura.sh
Após esse processo terminar, teremos o site funcionando no endereço:
1 http:// 192.168.33.12:8080/ devopsnapratica/
76
APÊNDICE 4: TESTE DA APLICAÇÃO TO DO
7.4.1 AMBIENTES DE CÓDIGO ABERTO
Inicialmente, foi criado o arquivo de configuração para o programa Vagrant, como
pode-se ver abaixo:
1 VAGRANTFILE_API_VERSION = "2"
2 Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
3 config.vm.box = "hashicorp/precise32"
4 config.vm.provider :virtualbox do |vb|
5 vb.customize ["modifyvm", :id , "--memory", "512"]
6 end
7
8 config.vm.define :todo do |todo_config|
9 todo_config.vm.hostname = "todo"
10 todo_config.vm.network :private_network , :ip => "192.168.33.18"
11
12 todo_config.vm.provision "ansible" do |ansible|
13 ansible.playbook = "todo.yml"
14 end
15
16 end
17
18 end
Em seguida, foi criado o arquivo de configuração para o programa Ansible realizar o
provisionamento e as configurações necessárias.
1 - hosts: all
2 sudo: True
3 user: vagrant
4 tasks:
5 - name: "Atualizando pacotes"
6 shell: sudo apt -get -y update
7
8 - name: "Instalando git"
77
9 shell: sudo apt -get install -y git
10
11 - name: "Instalando Maven2"
12 shell: sudo apt -get install -y maven2
13
14 - name: "Instalando openjdk -6-jdk"
15 shell: sudo apt -get install -y openjdk -6-jdk
16
17 - name: "Clonando o projeto loja -virtual -devops.git"
18 shell: git clone https:// github.com/IBM -Bluemix/todo -apps.git
19
20 - name: "Export MAVEN_OPTS"
21 shell: export MAVEN_OPTS=-Xmx256m
22
23 - name: "Execuc \~ao do Maven"
24 shell: sudo mvn -f /home/vagrant/todo -apps/java/bluemix -todo -
app/pom.xml
25
26 - name: "Execuc \~ao do Maven"
27 shell: mvn -P run -f /home/vagrant/tudo -apps/java/bluemix -
todo -app/pom.xml
Após essa etapa, tendo o VirtualBox e o Ansible instalados no computador em ques-
tão, basta executar o Vagrant com o comando a seguir, para que todo o ambiente DevOps
seja criado.
1 sudo vagrant up
Com a intenção de automatizar ainda mais todo esse processo, foi criado um shell
script básico para instalar o VirtualBox e o Ansible no computador de quem for utilizar
o projeto. Em seguida, esse mesmo shell script executa o comando inicial para que o
Vagrant e o Ansible criem todo o ambiente Devops.
1 #!/bin/bash
2
3 echo "Atualizando repositorios"
4 sudo apt -get update
5
6 echo "Instalando Virtual Box"
78
7 sudo apt -get -y install virtualbox
8
9 echo "Instalando Vagrant"
10 sudo apt -get -y install vagrant
11
12 echo "Instalando dkms"
13 sudo apt -get -y install virtualbox -dkms
14
15
16 echo "Instalando Ansible"
17 sudo apt -get -y install software -properties -common
18 sudo apt -add -repository -y ppa:ansible/ansible
19 sudo apt -get update
20 sudo apt -get -y install ansible
21
22 echo "Baixando um box pre -configurado hashicorp/precise32"
23 sudo vagrant box add hashicorp/precise32
24
25 echo "Executando o Vagrant e criando os servidores"
26 sudo vagrant up
Assim, todo o processo de criar o ambiente DevOps com o site funcionando, se resume
a executar o único comando abaixo:
1 sudo sh ./todo.sh
7.4.2 AMBIENTE PROPRIETÁRIO
É necessário usar o plugin do Maven com o Cloud Foundry para fazer o deploy da
aplicação no ambiente do Bluemix. Antes de usar o Maven, é necessário configurar um
arquivo para que o Maven saiba as credenciais do Bluemix. Para isso, é necessário seguir
os seguintes passos:
a) Abrir o arquivo settings.xml no diretório /.m2. Dentro do elemento servers, adici-
onar o código abaixo, com as respectivas credenciais de usuário do Bluemix:
1 <server >
2 <id>BlueMix </id>
3 <username >[email protected] </username >
79
4 <password >bluemixpassword </password >
5 </server >
b) Caso não exista um arquivo settings.xml na pasta /.m2, será necessário criar um.
Para isso, basta copiar o arquivo settings.xml do diretório /conf para o diretório
/.m2, e realizar o passo anterior;
c) Garantindo que o Maven conhece as credenciais, é possível fazer o deploy da aplica-
ção, que pode utilizar o Mongo DB ou o Couch DB via Cloudant como backend;
d) Foi utilizado o Cloudant como backend uma vez que ele possui um dashboard inte-
grado e embutido no Bluemix;
e) Para o deploy com backend Cloudant, basta executar o comando Maven que especi-
fica a URL, organização, credenciais Cloudant, e URL Cloudant. O comando usará
os atributos conforme especificados:
1 mvn -P cloudant -deploy -Dapp -url=myhost.mybluemix.net -Dorg=
myorganization -Dspace=myspace
f) Assim, a aplicação já pode ser acessada pela URL no Browser bem como o banco
de dados Cloudant ligado à ela pode ser acessado pelo seu serviço no Bluemix.
80