Implementação de gerência de configurações para
infraestrutura de TI usando ferramenta Open Source
Leandro Batista Silva, Marcos Alberto Lopes da Silva
Instituto de Informática – Centro Universitário do Triângulo (UNITRI) Caixa Postal 309 – 38.411-106 – Uberlândia – MG – Brasil
leandrobs1984@gmail.com, malopes@unitri.edu.br
Resumo. A Tecnologia de Informação (TI) tem um papel fundamental para
que as organizações aumentem sua competitividade no mercado através da automação dos processos manuais, pois permite reduzir custos operacionais e simplifica a complexidade de manter o ambiente em funcionamento. Neste contexto a ferramenta Puppet em conjunto com um método ágil de gerenciamento de configurações, denominado DevOps, propõe a automação das diversas atividades necessárias para gerenciar a infraestrutura com maior facilidade e flexibilidade. Este artigo apresenta a
aplicação da metodologia DevOps, que propõe uma nova cultura de trabalho alinhando as respectivas responsabilidades de diversas áreas da TI através de um estudo de caso aplicado em um ambiente produtivo de uma empresa de Telecom, utilizando a ferramenta Open source denominada Puppet. O resultado obtido demonstrou o aumento na produtividade de administração da infraestrutura e melhora na velocidade de resposta para o cliente.
1. Introdução
As organizações cada vez mais ampliam sua capacidade operacional com a computação, trazendo excelentes inovações tecnológicas, aplicações técnicas diferenciadas, desenvolvendo serviços para atender demandas de clientes internos e também os externos. Com o advento da virtualização de sistemas operacionais em grande escala, em seguida a computação em nuvem (Cloud Computing), o principal desafio dos profissionais que trabalham com infraestrutura é atender estas demandas de forma rápida, contínua e escalável para instalar, configurar, atualizar e administrar o ambiente.
Realizar o gerenciamento eficiente de uma infraestrutura, requer entender detalhadamente o projeto corporativo, estudar metodologias em conjunto com as ferramentas de soluções ágeis e após estes passos decidir o que será usado na implementação da solução. O investimento tecnológico proporciona a automação de vários processos e possibilita que os gestores dediquem mais tempo para assuntos estratégicos de grande importância para o negócio, como o relacionamento com os clientes e fornecedores e planejar tomadas de decisões que afetam diretamente no crescimento da empresa.
Portanto, este artigo tem como objetivo apresentar a metodologia DevOps que propõe uma cultura de trabalho colaborativa para melhorar a atuação da TI em conjunto com a ferramenta de automação e gerenciamento de configurações de recursos para infraestrutura chamada Puppet.
2. Metodologia DevOps e ferramenta Open Source Puppet
Nos tópicos a seguir serão apresentados os conceitos e o desenvolvimento da implementação da metodologia DevOps e da ferramenta open source Puppet.
2.1. Conceito de DevOps na TI das Organizações
DevOps é uma metodologia usada para mudar a cultura de trabalho dentro da TI nas
organizações, em que se propõe melhorar a comunicação entre as equipes de Open
Source Puppet desenvolvedores de software, analistas de qualidade e equipe de
operação, aumentando a colaboração entre as equipes para desenvolver soluções rápidas usando a automação de processos [RANKIN, 2013].
No ano de 2008, na “Agile 2008 Conference” foram abordados assuntos para discutir o gerenciamento ágil da infraestrutura e software. Esta abordagem ganhou força e no ano de 2009 durante a conferência Velocity promovida pela O’Reilly, os analistas John Allspaw (Etsy) e Paul Hammond (TypeKit) falaram sobre técnicas, cultura e ferramentas importantes que auxiliam no gerenciamento de incidentes e análise para resolver problemas no ambiente. O título da apresentação “10+ Deploys Per Day: Dev
and Ops Cooperation at Flickr”, se refere ao trabalho realizado na empresa Flickr pelos
analistas. A partir desta apresentação outras conferências chamadas de “DevOps Days” foram realizadas com o apoio de Patrick Debois e outros profissionais de tecnologia, a primeira em Ghent na Bélgica em 2009 seguidas de outras em outros países [WILLIS, 2011]. A Figura 1 representa a DevOps como uma cultura colaborativa entre as equipes de TI, que compartilham conhecimentos específicos para melhoria do processo.
Figura 1. Sinergia entre Desenvolvimento, Operações e Garantia de Qualidade [WALKER, 2013].
2.2. Apresentação da Metodologia DevOps como Cultura de Trabalho
As metodologias de desenvolvimento de software evoluem ao passar dos anos, mas o processo de abstrair problemas traduzindo-os em código envolve algumas atividades, tais como: o levantamento de requisitos, projeto, definição da arquitetura viável, teste, e por fim a implantação em produção. Após sua homologação, os usuários iniciam o uso do sistema em produção, a partir de então diversas questões surgem e começam a fazer
parte do ciclo de vida do software, sendo elas: suporte, monitoramento, segurança, disponibilidade, desempenho, usabilidade, etc [SATO, 2013].
As organizações segregam o departamento de TI (Tecnologia da Informação) de acordo com o conhecimento específico e responsabilidade, compondo equipes de desenvolvimento e negócio, equipes de operações e suporte e a equipe de garantia de qualidade. A princípio, esta divisão de responsabilidades nos passa a certeza de estar estrategicamente corretos, pois cada equipe tem um papel específico por ter formas de trabalho diferentes. As ferramentas de análise, o conhecimento especializado, se tornam um fator determinante e necessário para compor cada equipe. A equipe de desenvolvimento evolui o sistema adicionando atualizações de software, por outro lado a equipe de operações acompanha o comportamento destas atualizações no ambiente após aplicadas, porque elas trazem um certo risco à estabilidade do sistema e possivelmente à estabilidade do ambiente. Principalmente se este ambiente compartilhar recursos com outras aplicações ocasionando incidentes ou problemas. Desta forma, cria-se um conflito de interescria-se entre as equipes [SATO, 2013].
Na tentativa de solucionar o conflito para ambas as partes, sugere-se definir modelos de processos de trabalho, bem como detalhar as responsabilidades de cada equipe. Acompanhando a evolução do software, a equipe de desenvolvimento entregará novos pacotes para serem implantados, será elaborada a documentação contendo o passo a passo para instalar e configurar parâmetros de Sistema Operacional e repassar a responsabilidade para a equipe de operação e suporte. É comum nomear o processo de implantação do pacote de software no ambiente de deploy, que também significa implantar o software [SATO, 2013].
Com o passar do tempo, o processo de deploy torna-se ainda mais burocrático e o seu número de frequências tende a diminuir. Em consequência, acumula-se a quantidade de mudanças acarretando o risco de instabilidade no ambiente caraterizado como um processo de ciclo vicioso, mostrado na Figura 2 [SATO, 2013].
Figura 2. Ocorrência de ciclo vicioso entre desenvolvimento e operação [SATO, 2013].
O ciclo vicioso não só diminui a capacidade das organizações em atender de forma rápida as mudanças no negócio, como também impacta as etapas anteriores do processo de desenvolvimento por haver demora na execução das etapas. Em alguns casos, as organizações falham em atingir o objetivo principal por usarem abordagens tradicionais que não são suficientes para melhorar a qualidade. O que ocasiona o atraso na entrega do produto ou serviço pelo fato de ser um desenvolvimento personalizado ou por ter vários processos manuais [SATO, 2013].
A organização precisa ter soluções rápidas na resposta do feedback de seus clientes para se manter competitiva. É fato que uma metodologia ágil melhora a maneira como a empresa oferece valor aos clientes, pois diminui o tempo a partir da concepção ou ideia até a implementação do software em produção. Quando o processo de deploy deixa de ser burocrático e começa a ocorrer com uma frequência planejada e encadeada, o ciclo vicioso é invertido e passa a aumentar o controle de alteração no ambiente. O aumento da frequência de deploys faz com que a quantidade de mudança em cada
deploy diminua, ao passo que diminuirá o risco de instabilidade no ambiente referente
ao deploy realizado. É possível identificar com maior precisão o que ocorreu, pois a quantidade de fatores que podem ter causado o problema é menor. O ciclo referente ao processo de automação é apresentado na Figura 3 [SATO, 2013].
Portanto, ao diminuir o risco não necessariamente implicará extinguir os processos criados entre as equipes de desenvolvimento e operações, mas sim permitir a inversão do ciclo a fim de automatizar os processos de deploy. No momento em que se elabora o processo de automação, este passa a ser executado a qualquer momento de forma confiável, garantindo o baixo risco de um erro humano [SATO, 2013].
Figura 3. Prática de DevOps modifica o ciclo vicioso através da automação de processos [SATO, 2013].
Automatizar processos não é uma atividade recente, várias organizações desenvolvem scripts ou até mesmo usam poderosas ferramentas que auxiliam o administrador de sistemas neste trabalho. Práticas como o desenvolvimento de manifestos contendo parâmetros padronizados para gerenciar configurações de software em um ou muitos servidores no ambiente, seja esta instalação já definida inicialmente no projeto ou sob demanda para atender a capacidade de disponibilidade, aumentando assim a estabilidade do ambiente de produção [SATO, 2013].
DevOps direciona o foco para práticas de automação das diversas atividades
necessárias para gerenciar a infraestrutura com maior facilidade e flexibilidade, possibilitando propor novas soluções com menos esforços e menor custo com agilidade. Organizações como o Facebook, Google, Amazon, NetFlix e Flickr aplicaram esta metodologia e conseguiram excelentes resultados [SATO, 2013].
Adotar DevOps não é algo que acontece de um dia para outro. É uma mudança conceitual e de modelo mental por exigir conhecimento de novas práticas e uso intenso de tecnologia para automatizar ao máximo o processo de desenvolvimento de software e infraestrutura [SATO, 2013].
2.3. Definição de Puppet
Puppet é um framework Open Source composto por um conjunto de ferramentas
utilizado para gerenciamento de configuração. O Puppet possibilita realizar várias atividades tais como: automação na instalação de pacotes de software; garantir a integridade por determinar padrões e facilitar a auditoria do ambiente. Foi
desenvolvido por Luke Kanies, fundador da empresa Puppet Labs. Seu código fonte foi construído usando a linguagem Ruby e seu paradigma é declarativo, sua licença é do tipo Apache 2.0. O Puppet pode ser usado para gerenciar configurações de servidores em múltiplas plataformas, tais como: Unix, Linux e Microsoft Windows [SPENCER et
al.,2013].
3. O Framework Puppet
Devido a crescente demanda na administração de sistemas e da infraestrutura (física ou virtual), o Puppet contribui para a automação das atividades complexas e para a metodologia DevOps como sendo um importante componente tecnológico. Permite melhorar a interação entre a equipe de desenvolvimento de sistemas e a equipe de operação que juntas elaboram soluções ágeis e constroem versões de sistemas automatizados. Cada vez mais o Puppet é utilizado na infraestrutura para tratá-la como código, principalmente em Data Centers por ter grandes aplicações em execução consumindo recursos computacionais de forma crescente e expansiva, o gerenciamento da configuração de hardware e software deve ser automatizado e escalável. É possível usar o Puppet para gerenciar configurações de dispositivos de rede, fazer o balanceamento de carga em servidores e gerenciar instâncias de máquinas virtuais.
As configurações criadas no Puppet para representar sistemas são apresentadas como recursos, estes recursos são modelos complexos desenvolvidos usando o paradigma chamado DSL (Domain Specific Language) linguagem de domínio específico. Há uma grande quantidade de recursos nativos para modelar o estado de um sistema, tais como: user, group, packages, services, file, class, etc. O Puppet tem funções que possibilitam criar pacotes e serviços personalizados, configurações específicas para cada cenário e a linguagem usada para codificar estes recursos é o Ruby [BODE LIU, 2013].
O Puppet é usado para gerenciar servidores em todo o seu ciclo de vida, ou seja, desde sua criação, instalação de softwares, atualizações e configurações, manutenções e finalmente o fim do ciclo de vida quando o serviço é movido para outro servidor. O
Puppet é projetado para interagir continuadamente com os servidores da rede e
apresenta um modelo operacional simples, fácil de ser entendido e desenvolvido [BODE LIU, 2013]. O Puppet possibilita construir processos automáticos associando a sua funcionalidade com ferramentas de integração contínua. As camadas de instalação das bibliotecas de arquivos, linguagem e abstração de recursos e transacional são citadas a seguir.
3.1. Camada de Instalação das Bibliotecas de Arquivos
Para apresentar este trabalho, será abordada a configuração no sistema operacional
Linux, porém o Puppet tem portabilidade para outros sistemas operacionais. A Tabela 4
Tabela 4. Sistemas Operacionais suportados [PUPPETLABS, 2015 1].
O modelo de arquitetura é cliente-servidor. A estrutura do servidor é chamada de “Puppet Master” e é composta pelos binários do Puppet, pelo catálogo de dados formado pelos arquivos de manifesto que são armazenados em módulos e por fim o serviço (daemon). O agente Puppet é instalado nos servidores clientes e estabelece conexão usando SSL (Secure Socket Layer) com o Puppet Master para consultar informações de configurações contidas nos arquivos de manifesto e nos módulos definidos para cada servidor cliente configurado no manifesto [SPENCER et al.,2013]. A Figura 5 apresenta a arquitetura cliente-servidor.
Figura 5. Arquitetura de comunicação cliente-servidor Puppet [SPENCER et al.,2013].
As configurações de recursos ficam armazenadas no Puppet Master e podem ser aplicadas em uma grande quantidade de servidores clientes executando comandos de forma manual ou agendada [SPENCER et al.,2013].
3.2. Camada de Linguagem e Abstração de Recurso
A linguagem Puppet é declarativa e define o estado pretendido dos recursos. Esta característica da ferramenta é intuitiva e importante em relação às outras ferramentas de automação, ao contrário de outras linguagens cujo paradigma é procedural ou imperativo exigindo que o código contenha a lógica para ter o estado pretendido do recurso. É possível declarar que o pacote deve estar instalado, o serviço deve estar iniciado após sua instalação e/ou parado para ser reconfigurado. Os recursos possuem propriedades específicas para a sua criação, citadas a seguir:
Type (Tipo): é o tipo de componente de sistema que será gerenciado pelo Puppet,
sempre deverá conter o tipo ao declarar o recurso. Exemplo: user, group, file, service e
package.
Title (Título): o título do recurso identifica uma instância do seu tipo. A combinação do
tipo seguido com seu título refere-se ao único elemento a ser gerenciado pelo Puppet. Exemplo: o tipo de recurso user com o título tomcat.
Attributes (Atributos): cada recurso suporta uma lista de atributos representados por
pares de chaves e valor. Por exemplo, o pacote Apache HTTP Server deverá estar instalado, no servidor e após concluir a instalação o serviço deverá ser iniciado automaticamente [BODE LIU, 2013]. A Figura 6 apresenta a sintaxe usada para declarar um recurso:
<type> { <title> : attribute1 => value1, attribute2 => value2 }
Figura 6. Sintaxe padrão para declarar o recurso no Puppet [BODE LIU, 2013].
É possível declarar um ou mais recursos em um arquivo de manifesto, o arquivo deve ser salvo com o nome (init.pp) no diretório /etc/puppet/manifests para que o Puppet o reconheça. A Figura 7 apresenta um exemplo de código para instalar o pacote do Apache HTTP Server:
# /etc/puppet/manifests/init.pp package { 'httpd': ensure => latest, } service { 'httpd': ensure => running, subscribe => Package['httpd'], }
Figura 7. Código para instalar o pacote Apache HTTP Server [BODE LIU, 2013].
O Puppet usa o modelo de herança para criar subclasses. Uma subclasse pode herdar atributos, funções e valores da superclasse. Os valores podem ser sobrescritos possibilitando criar subclasses com funções específicas para novos recursos. A Figura 8 apresenta o exemplo de herança da superclasse redhat.
class redhat { service {"mdmdp": enable => true, ensure => stopped,} }
class rhel5 inherits redhat { Service["mdmdp"]
{ ensure => running } }
Figura 8. Código que representa a herança de classes [TURNBULL, 2008].
O agrupamento do código é importante para organizar os recursos do Puppet, esta organização é denominada classe. A classe tem por finalidade agrupar coleções de recursos que resulta em um único processo de instalação e configuração. Exemplo: a aplicação Apache HTTP Server que é construída de pacotes, arquivos de configuração, usuário com permissão para executar o serviço, estrutura de diretórios e serviço.
Portanto, a estrutura da classe é codificada seguindo os pré-requisitos de configuração dos recursos, ou seja, para iniciar o serviço httpd os diretórios deverão estar criados e ter as devidas permissões. O arquivo de configuração estará parametrizado com valores pertinentes aquele ambiente e o usuário será criado e terá a permissão para iniciar o serviço. A Figura 9 apresenta um exemplo da classe Apache
class apache { package { 'httpd':
ensure => "installed" }
user {'apache':
ensure => present, managehome => false }
apache::apache_files {"/etc/httpd/conf/httpd.conf": source => "puppet:///apache/httpd.conf" }
define appache::apache_files($mode = 644, $owner = apache, $group = apache,
$recurse =
false, $ensure = file, $source){
file { $name:
mode => $mode, owner => $owner, group => $group, recurse => $recurse, ensure => $ensure, require => Package["httpd"], source => "puppet:///httpd/ $source" } }
define apache::virtual_host($ip, $ensure = "enabled") { $file = "/etc/httpd/conf.d/$name.conf"
$document_root = "/var/www/html/$name"
file { $document_root:
ensure => $ensure ? { enabled => directory, disabled => absent }, require => File["$file"] } file { $file:
ensure => $ensure ? { enabled => present, disabled => absent,
content => template(“apache/virtual_host.erb), notify => Service["httpd"] } }
service { "httpd":
enable => "true", ensure => "running", hasrestart => "true", hasstatus => "true", require => Package["httpd"] }
}
Figura 9. Trecho de código da classe Apache com recursos de instalação e configuração [TURNBULL, 2008].
Gerenciar configurações de recursos é necessário para manter o ambiente íntegro e conexo, à medida que os serviços e as funções são automatizados são criados novos arquivos de configuração, templates, classes e definições. A maneira de organizá-los é agrupar todos os arquivos pertencentes ao serviço, em outras palavras, criar módulos para que sejam estruturados e reutilizados.
O módulo é um diretório e fica armazenado no Puppet Master no caminho
/etc/puppet/modules e é carregado de forma automática pelo Puppet [PUPPETLABS,
2015 2]. A estrutura de um módulo é apresentada a seguir. manifests – São os arquivos de manifesto do módulo;
init.pp – Principal arquivo de configuração do módulo;
templates – Armazena arquivos dinâmicos. Exemplo: variáveis, funções, fatos e constantes;
lib – Armazena arquivos de plugin;
examples – Armazena exemplos que mostram como declarar classes de módulos e definições de classes.
files – Armazena arquivos estáticos. Exemplo: um pacote java
spec – Armazena arquivo que são usados para validar as classes.
Entender a estrutura do módulo é primordial para desenvolver um ambiente totalmente organizado. Há também um padrão para nomenclatura das classes, ou seja, deverá conter uma única classe por arquivo de manifesto e este arquivo deve ser nomeado com o nome da classe. Como por exemplo, um manifesto criado dentro do módulo Apache com o nome de apache_r3.pp, que deverá ter uma única classe com o mesmo nome apache::apache_r3.
O Puppet irá compilar a configuração do módulo transformando-o em catálogo através do arquivo de configuração chamado site.pp. A partir deste arquivo é que o servidor Puppet Master identificará a configuração para ser enviada a um agente no servidor cliente. A Figura 10 apresenta o código usado para apontar quais são os servidores web que receberão a configuração:
# /etc/Puppet/manifests/site.pp
node 'web1.network.com', 'web2.network.com'{ package { 'httpd': ensure => latest, } service { 'httpd': ensure => running, subscribe => Package['httpd'],} }
Figura 10. Código para aplicar a funcionalidade webserver nos servidores.
O Puppet usa o software chamado facter para coletar informações, como parte do facter há uma biblioteca de facts (fatos), as quais auxiliam na coleta de diversas informações sobre software e hardware. A Figura 11 apresenta o código que usa algumas variáveis geradas pelo facter para coletar informações do servidor.
notify {'sumario':
message => “O Sistema Operac. é ${kernel} versão ${kernelversion}, quant. de processador ${ physicalprocessorcount} quant. de memoria ${memorytotal}” } notify {'distribuicao':
message => “A distribuição é ${operatingsystem} versão ${operatingsystemrelease} } notify {'hostname':
message => "nome do servidor: ${hostname}" }
Figura 11. Código para coletar dados de hardware e software dos servidores.
O resultado da execução do código referente à Figura 11 é apresentado a seguir:
Notice: Compiled catalog for puppet-dev01.network.com in environment production in 0.11 seconds
Notice: Nome do servidor: puppet-dev01
Notice: /Stage[main]/Main/Notify[hostname]/message: defined 'message' as 'Nome do servidor: puppet-dev01'
Notice: O Sistema Operac. é Linux, versao 2.6.32 quant. de processadores 2 e quant. de memoria
Notice: A distribuicao e CentOS versão 6.5
Notice: /Stage[main]/Main/Notify[distribuicao]/message: defined 'message' as 'A distribuicao e CentOS versão 6.5'
Figura 12. Resultado da execução do código referente à Figura 11. 3.3. Camada Transacional
A camada transacional é compreendida por processos sequenciais que iniciam com a análise dos recursos solicitados pelo agente Puppet do servidor cliente ao Puppet
Master. O Puppet Master apresenta ao servidor cliente todos os recursos cadastrados em
sua biblioteca local e os associa aos recursos solicitados pelo servidor cliente. Em seguida o Puppet Master relaciona os dados solicitados com os recursos de sua biblioteca, como resultado os recursos compatíveis são compilados criando um catálogo para ser enviado ao servidor cliente. Após receber o catálogo de recursos o agente
Puppet aplica as configurações no servidor cliente e ao término da configuração o
servidor cliente envia como resposta para o Puppet Master um relatório com o resultado do processo de aplicação dos recursos [SPENCER et al.,2013].
É possível repetir este processo várias vezes, através das chamadas dos clientes para o servidor. O Puppet garante a consistência das configurações nos clientes devido ao processo ser idempotente, ou seja, uma função é chamada várias vezes e irá reproduzir o mesmo resultado apenas alterando o que for necessário, se um pacote for instalado ele não será reinstalado [SPENCER et al.,2013].
O Puppet não é totalmente transacional, pelo fato de possuir um modelo não transacional (no operation) em sua estrutura. Esta função é útil para testar a configuração dos recursos antes de aplicá-los definitivamente [SPENCER et al.,2013]. 4. Estudo de caso
O estudo de caso apresenta um projeto implementado e implantado em uma empresa na área de telecomunicações localizada na cidade de Uberlândia/MG com o objetivo de melhorar o sistema de atendendimento dos seus clientes. Devido ao grande número de servidores, a tarefa de configurá-los manualmente não é produtiva por exigir muito tempo para realizá-la culminando com o não cumprimento do acordo de nível de serviço
SLA (Service Level Agreement) pela equipe de infraestrutura.
O módulo Tomcat citado no estudo de caso está disponivel para ser acessado no endereço eletrônico: https://github.com/leandrobs1984/TCC_2015.
4.1. Instalação e Configuração dos Recursos
A sequência de instalação e configuração é fundamental para o correto funcionamento e são definidas no módulo desenvolvido. Esta sequência é apresentada a seguir:
Configurar parâmetros de segurança no Sistema operacional; Criar o usuário da aplicação;
Instalar (JDK – Java Development Kit) Kit de desenvolvimento Java; Instalar o pacote do Apache Tomcat;
Fazer o deploy e configurar os parâmetros nos arquivos de controle da aplicação; Iniciar o serviço do servidor Web.
A Figura 13 apresenta o trecho de código desenvolvido para automatizar a instalação e configuração o pacote Apache Tomcat no servidor.
define tomcat7_r2::install($tomcat_path, $tomcat_package, $tomcat_home, $tomcat_user, $tomcat_initd,$tomcat_project) { file {"${tomcat_path}": path => "${tomcat_path}", ensure => directory, } file {"${tomcat_path}/${tomcat_package}": path => "${tomcat_path}/${tomcat_package}", ensure => present, owner => "${tomcat_user}",
source => "puppet:///modules/tomcat7_r2/${tomcat_package}", mode => '0755', require => File["${tomcat_path}"], } exec {"Install_tomcat_${title}": path => "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", cwd => "${tomcat_path}",
command => "tar -xzvf ${tomcat_package} && rm -f ${tomcat_package} && chmod 755 ${tomcat_path} && chmod 755 $ {tomcat_home} && chown -R ${tomcat_user}
creates => "${tomcat_home}/LICENSE",
require => File["${tomcat_path}/${tomcat_package}"], } file {"/etc/init.d/${tomcat_initd}":
ensure => present,
content => template("tomcat7_r2/tomcat.erb"), owner => 'root', mode => '0755',
replace => true, require => Exec["Install_tomcat_${title}"], } file {"${tomcat_home}/conf/server.xml":
ensure => present,content => template("tomcat7_r2/server.xml.erb"), owner => "${tomcat_user}", group => "${tomcat_user}",
mode => '0755', replace => true,
require => File["${tomcat_home}/bin/catalina.sh"], } tomcat7_r2::service{"aplica_permissao_${title}":
tomcat_path => "${tomcat_path}", tomcat_user => "${tomcat_user}", require => File["${tomcat_home}/conf/server.xml"],
} }
Figura 13. Trecho de código para automação do Apache Tomcat. 4.2. Usar o Puppet na Automação da Configuração
A arquitetura de infraestrutura deste projeto está segregada pelos ambientes teste integrado, homologação e produção. Os servidores serão configurados com o Apache
Tomcat, que é um container web e Open source que permite a execução de aplicações
para web baseadas em Java.
Os dados de configuração são parametrizáveis e sofrem alterações de acordo com o ambiente, como por exemplo: definição do tamanho da memória usada pela aplicação, segurança de acesso, balanceamento de tráfego de rede, o nome do servidor e o seu endereço de rede. Logo, o módulo Tomcat será carregado pela ferramenta Puppet para automatizar a instalação e configuração. A Figura 14 apresenta o modelo de arquitetura Puppet usado para automatizar a configuração nos servidores.
Figura 14. Infraestrutura a qual usou a automação para provisionar os servidores web.
Este processo será detalhado a seguir nos passos de 1 a 3.
Passo 1. O arquiteto de infraestrutura envia a documentação que contém os requisitos não funcionais referente ao projeto e o analista de infraestrutura responsável pela gerência de configurações inicia o trabalho para desenvolver o código do módulo Tomcat. Ao longo do desenvolvimento os manifestos podem passar por manutenções ou são adicionados novos recursos no módulo. Portanto a organização do código Puppet é submetida ao versionamento por seus desenvolvedores.
Passo 2. O analista de infraestrutura atualiza o repositório local do Puppet
Master com a versão atual do módulo que é copiada do servidor de versões. Passo 3. A configuração dos servidores clientes é iniciada pelo mesmo analista
após executar o comando e haver a interpretação pelo agente Puppet que em seguida inicia a comunicação com o servidor Puppet Master. A troca do certificado digital é realizada e estabelece relação de confiança entre os servidores, isto garante que os dados solicitados pelos servidores clientes e respondidos pelo servidor Puppet Master serão transmitidos de forma segura por usar criptografia SSL.
O processo de instalação e configuração dos recursos contidos no módulo é automático e gerenciado entre o agente Puppet no servidor local e o agente no Puppet
Master, abre-se uma transação para iniciá-la e finalizá-la resultando na conclusão da
configuração do servidor cliente ou na falha de processo. O analista de infraestrutura acompanha o resumo apresentado da atividade em tempo de execução na tela do seu terminal.
4.3. Resultado
O uso da ferramenta Puppet para automatizar os processos proporcionou resultados significativos para o ambiente. Desde a sua fácil instalação até iniciar o desenvolvimento das soluções, o Puppet possibilitou tornar a infraestrutura totalmente orientada a mudanças e programável com respostas rápidas na entrega de serviços. Como a configuração do ambiente fica centralizada em documentos, permite a equipe de infraestrutura visualizar as configurações do ambiente para rastrear mudanças, melhorando a capacidade de resposta na tratativa de problemas.
O resultado obtido demonstrou o aumento na produtividade de administração da infraestrutura e melhora na velocidade de resposta para o cliente.
5. Conclusão
As organizações revolucionam suas estratégias de negócio com melhores práticas de gestão, adoção de métodos ágeis de gerenciamento e apoio tecnológico. O compartilhamento de ideias e a colaboração do trabalho entre as equipes de TI é um fator determinante para o progresso da organização.
A metodologia DevOps inovou ao sugerir que a equipe de operação gerencie as configurações dos servidores (físicos ou virtuais) da mesma forma que os desenvolvedores de software conseguem gerenciar o código fonte de suas aplicações.
A ferramenta Open source Puppet reforça o conceito de infraestrutura como código e possibilita aos analistas desenvolver a infraestrutura totalmente modular e automatizável.
Portanto, este artigo apresenta a metodologia DevOps que propôs neste cenário melhorar a interação entre equipes de desenvolvimento e infraestrutura na TI. Como componente tecnológico foi apresentado a ferramenta Puppet que automatizou os processos de instalação e configuração dos servidores, permitindo integrar a funcionalidade de automação configurada no módulo Puppet com a ferramenta de entrega contínua, utilizada pela equipe de desenvolvimento. Proporcionando automatizar os deploys da aplicação. Logo se cumpre a promessa de entrega contínua.
Como trabalhos futuros, sugere-se a implementação de uma solução que possibilite definir métricas de execução para monitorar processos automatizados e que gere relatórios para acompanhar a produtividade no processo de automação no ambiente. Visto que a versão Open source do Puppet não dispõe de tal ferramenta.
Este trabalho contribui para o conhecimento dos profissionais de TI que buscam soluções na melhoria do ambiente, tornando os processos consistentes e automatizados.
6. Referências
BODE, D. LIU N. (2012). Puppet Types and Providers. Editora O’ Reilly. Sebastopol, 92 páginas.
PUPPETLABS 1 (2015). System Requirements and Pre-Installation. Disponível em: < https://docs.puppetlabs.com/pe/latest/install_system_requirements.html#hardware-requirements>. Acesso em: 20 maio de 2015.
PUPPETLABS2 (2015). Module Fundamentals. Disponível em: <https://docs.puppetlabs.com/puppet/latest/reference/modules_fundamentals.html>. Acesso em: 20 maio de 2015.
RANKIN, K. (2013). DevOps Troubleshooting – Linux Server Best Practices. Editora Addison-Wesley Professional. Crawfordsville, 235 páginas.
SATO, DANILO. (2013). DevOps na prática: Entrega de software confiável e
automatizada. Editora Casa do Código. São Paulo, 248 páginas.
SPENCER, K. et aL. (2013). Pro Puppet Second Edition. Editora Apress. Berkley, 301 páginas.
TURNBULL, JAMES. (2008). Pulling Strings with Puppet: Management Made
Easy. Editora Apress. New York, 192 páginas.
WALKER, GRACE (2013). Meeting the continuous challenge. Disponível em: <http://www.ibm.com/developerworks/library/d-testops-continuous-test>. Acesso em: 7 Julho de 2015.
WILLIS, JOHN (2011). The Convergence of DevOps. Disponível em: <http://itrevolution.com/the-convergence-of-devops>. Acesso em: 8 março de 2015.
