Puppet: Instalação e fundamentos – DevOps Parte 4

Em DevOps, Sistemas operacionais por Jonathan Maia

Já conhecendo o que são e para que servem as ferramentas de gerenciamento de configuração e automação de servidores, neste artigo passaremos para exemplos práticos de instalação e provisionamento com o Puppet, uma das ferramentas de gerenciamento de configuração mais difundidas do mercado.

Como você pode ver na documentação oficial do Puppet (muito completa, por sinal), ele está disponível em duas versões:

  • Puppet Enterprise (com opções de suporte pago)
  • Open Source Puppet (código aberto – nós na fita)

Se você ainda não conhece o Vagrant (será utilizado aqui para gerenciar as máquinas virtuais), dê uma lida nos artigos  Vagrant: Turbine suas VMs e ambientes de desenvolvimento e Vagrant: Crie sua própria box e disponibilize-a na Vagrant Cloud.

Arquitetura do Puppet

Fonte: Digital Ocean

A partir do quadro acima (elaborado pela Digital Ocean) e conforme documentado na página de Arquitetura do Puppet, aprendemos que podemos trabalhar com ele em duas arquiteturas diferentes:

  • Arquitetura Agent/Master: Existe um Puppet Server (Puppet Master), que mantém e compila os Catálogos (documentos que descrevem os estados e configurações dos servidores, chamados de Puppet Nodes). Cada Puppet Node, periodicamente, solicita ao Puppet Master seu Catálogo (que é compilado pelo Puppet Master) e faz o Apply, ou seja, aplica as mudanças na configuração.
  • Arquitetura Stand-Alone: Não existe a figura do Puppet Server e cada Puppet Node mantém, compila e aplica seu próprio Catálogo.

Neste primeiro artigo sobre Puppet, vamos utilizar a arquitetura Stand-alone, por fins didáticos. Para tanto, basta instalar na máquina que terá sua configuração gerenciada pelo Puppet (Puppet Node) um software chamado Puppet Agent.

Udemy - Learn to Code by Making Games - Complete C# Unity Developer

Na prática, para gerenciar a configuração do seu parque de servidores, o ideal é utilizar a arquitetura Agent/Master, pois ela permite gerenciar a configuração de todos Puppet Nodes de maneira centralizada (você pode utilizar alta disponibilidade para evitar um ponto único de falhas no Puppet Master).

Dê adeus à necessidade de ficar acessando máquina a máquina para fazer as mudanças necessárias.

Instalação do Puppet

Já brincamos com o Ubuntu nos artigos anteriores, agora vamos passar para o Debian.

Tudo que temos que fazer é configurar um Vagrantfile para utilizar a box debian/contrib-jessie64 (na versão 8.8.0) e depois fazer um provisionamento em Shell para a instação do Puppet. Depois, vamos gerar nossa própria box e fazer o upload para reutilização na Vagrant Cloud.

Um dos motivos para a mudança para o Debian é que a box do Ubuntu que usamos nas postagens passadas (ubuntu/trusty64) já vem com uma versão do Puppet instalada (3.4.3), mas ela é antiga (na época em que escrevo este artigo, já estamos no Puppet 5.3).

Se você desejar, pode acessar diretamente a Vagrant Cloud e já procurar por uma box com o Puppet instalado. Por fins didáticos, vou mostrar como montar sua própria box.

Vamos montar nossa própria box com Puppet instalado na versão mais atual

Vamos montar nossa própria box com Puppet instalado na versão mais atual

O código completo utilizado neste artigo está disponível no Github.

O primeiro passo é criar o arquivo Vagrantfile utilizando a box definida:

Utilizamos a box debian/contrib-jessie64 ao invés da debian/jessie64 pois a primeira possui o módulo do kernel vboxfs, que é utilizado pelo VirtualBox (nosso provider no Vagrant) para a montagem das pastas compartilhadas na máquina virtual.

Vamos evoluir nosso Vagrantfile para instalar o puppet-agent utilizando provisionamento em Shell script. Você pode ver na documentação oficial do Puppet os procedimentos de instalação, em especial os procedimentos para Linux.

No caso do Debian, primeiro fazermos o download e instalamos o pacote puppet5-release-jessie.deb para a utilização dos repositórios oficiais do Puppet. Depois recuperamos a lista atualizada de pacotes no apt-get e já instalamos o puppet-agent. Por fim, criamos um link simbólico para o executável no Puppet ficar no PATH e já instalamos alguns módulos do puppet que utilizaremos nas próximas postagens.

Dá uma olhada no novo Vagrantfile:

Ao fazer um vagrant up, você verá todo o processo de instalação do puppet-agent e dos módulos do puppet:

Com tudo instalado, vamos fazer um vagrant ssh para acessar a máquina e chamar o help do puppet:

Observe, no final do puppet help, que estamos usando a versão 5.3.2 do Puppet.

Puppet Apply e nosso primeiro Manifest

Um dos subcomandos mais importantes do Puppet é o apply, em especial para a arquitetura Stand-Alone. É o apply que utiliza um ou vários manifestos (arquivos de configuração do Puppet, similares aos Vagrantfiles ou Dockerfiles) para compilá-los em um catálogo e depois aplicá-los na máquina.

Na mesma pasta do Vagranfile, vamos criar uma pasta chamada manifests e dentro dela o arquivo default.pp. Conforme a documentação do Vagrant, por padrão, quando mandarmos o Vagrant utilizar o Puppet Apply para provisionamento, ele irá procurar por esse arquivo como ponto de entrada.

Vamos colocar apenas o seguinte conteúdo no arquivo manifests/default.pp:

Esse é um manifesto extremamente básico e possui uma única resource declaration . No Puppet, um resource é uma unidade fundamental para configuração de um sistema e descreve algum aspecto específico, como um pacote, um serviço, um arquivo, etc. Dá uma olhada na definição de resource declaration:

A resource declaration is an expression that describes the desired state for a resource and tells Puppet to add it to the catalog. When Puppet applies that catalog to a target system, it manages every resource it contains, ensuring that the actual state matches the desired state.

Ou seja, uma resource declaration é uma expressão que descreve o estado desejado de um resource. Todas resource declarations têm um tipo (que indica o RESOURCE) e atributos com respectivos valores, no seguinte formato:

TYPE { 'TITLE':
  <ATTRIBUTE> => <VALUE>,
  <ATTRIBUTE> => <VALUE>,
}

Segue um exemplo de uma resource declaration que garante que o arquivo /etc/passwd seja um arquivo normal (ensure => ‘file’), que o proprietário seja o root (owner => ‘root’), que o grupo seja o root (group => ‘root’) e que o modo seja 0600 (mode => ‘0600’):

No conteúdo do arquivo manifests/default.pp, desejamos que o pacote links esteja instalado:

O resource é package, o title é ‘links’ (nome do pacote) e o atributo ensure possui o valor installed (queremos o pacote instalado). Fácil, né ? Se você não conhece, o links é um navegador para linha de comando bem prático.

Agora, na máquina virtual, podemos chamar o puppet apply (mais adiante, o processo será integrado ao vagrant):

Após chamar o links para o Blog Eu na TI, você deve ver o menu principal do Blog:

Acessando Blog Eu na TI pelo links

Acessando Blog Eu na TI pelo links

Integração do Puppet com Vagrant

O próximo passo é integrar o provisionamento do Puppet ao nosso Vagrantfile. É muito simples, basta adicionar a seguinte diretiva logo após o provisionamento do shell:

config.vm.provision "puppet"

Como falei anteriormente, por padrão, o Vagrant buscará o manifesto default.pp dentro do diretório manifests.

Neste ponto, faço uma observação: Como estamos utilizando uma versão recente do Puppet, atualize sua versão do Vagrant para a 2.0.0 ou posterior (a versão 1.X apresenta problemas ao provisionar com o Puppet 5.3).

Se você está no Linux, atualize o vagrant com yum ou apt-get. Se você está no Windows e utiliza o gerenciador de pacotes Chocolatey, basta fazer um choco upgrade vagrant.

Assim, a versão final do nosso Vagrantfile já utilizando o provisionamento do Puppet é:

Para testar a integração completa, vamos desinstalar o links na máquina provisionada e mandar o vagrant executar novamente apenas o provisionamento do puppet (–provision-with puppet). Daí, o links já deverá estar disponível novamente.

Se você desejar, pode rodar novamente o provisionamento completo dessa máquina Vagrant para testar a idempotência. Lembra da idempotência ? Em suma, ela nos garante que mesmo que mandemos provisionar novamente uma máquina já provisionada, o estado final dela deve ser consistente. Para executar o provisionamento completo, basta:

vagrant up --provision

Observe que, após o provisionamento, o puppet e o links continuam funcionando normalmente e nas versões desejadas. Maravilhas! Se desejar ver o código completo utilizado neste artigo, acesse no Github.

Disponibilização da box na Vagrant Cloud

Já temos uma instalação funcional do Puppet, mas fica a dúvida: vamos ter que ficar adicionando aqueles passos de instalação do Puppet com o provisionamento em shell em todos nossos Vagrantfiles ? A resposta é não.

Como vimos na postagem Vagrant: Crie sua própria box e disponibilize-a na Vagrant Clod – DevOps Parte 2, podemos criar nossas boxes e disponibilizá-las para usos posteriores ou por terceiros. Utilizei o vagrant package e disponibilizei a box eunati/debian-jessie64-puppet5 na Vagrant Cloud com as seguintes versões:

Debian 8.8.0, Puppet Agent 5.3.2.1, puppetlabs-apt (v4.3.0), puppetlabs-concat (v4.1.0), puppetlabs-docker (v1.0.1), puppetlabs-ntp (v7.0.0), puppetlabs-stdlib (v4.20.0), puppetlabs-vcsrepo

Box eunati/debian-jessie64-puppet5 na Vagrant Cloud

Box eunati/debian-jessie64-puppet5 na Vagrant Cloud

Nos próximos Vagrantfiles, não precisaremos nos preocupar com a instalação do Puppet e podemos apenas chamar o provisionamento do Puppet, da seguinte maneira:

Como a box está na Vagrant Cloud, se desejar, você também pode utilizá-la aí na sua máquina.

Conclusão

Nos próximos artigos, já com o Puppet Agent instalado e com a box pronta na Vagrant Cloud, vamos explorar as Resource Declarations do Puppet e fazer uma instalação completa do Apache e do Ntp.

Espero que você tenha gostado! Agradeço se você puder curtir e compartilhar esse artigo em suas redes sociais.

Assine nosso Blog por e-mail e curta nossas páginas nas redes sociais para acompanhar novas postagens.

Sabia que você também pode escrever para o Blog Eu na TI?

Em breve, mais conteúdos de qualidade para você aqui no Blog Eu na TI, o seu Blog sobre Tecnologia da Informação.

Um forte abraço e até mais.

Olá, sou Jonathan Maia, marido, pai, apaixonado por tecnologia, gestão e produtividade. Atuo na gestão e desenvolvimento de sistemas de informação como analista de TI do TRT Ceará (servidor público federal).

Possuo as certificações em gerenciamento de projetos Project Management Professional (PMP) e Professional Scrum Master I (PSM I), além de especialização em gerenciamento de projetos de TI (2011) e bacharelado em ciências da computação pela UFC (2008). Também sou desenvolvedor Full Stack e possuo experiência em diversas arquiteturas / plataformas.

Fui aprovado e nomeado nos concursos públicos do TJ-CE, Dataprev, Serpro e TRT Ceará, assumindo nos três últimos. Já tive experiências profissionais em redes metropolitanas de alta velocidade (GigaFOR/RNP), business intelligence, desenvolvimento de sistemas e gestão de projetos (tradicionais e ágeis).

Como adepto da gestão ágil, desenvolvi o Organizador Ágil, um método ágil, simples e leve que auxilia no aumento da produtividade e organização pessoal, familiar ou profissional. Também mantenho o Blog Eu na TI.

Deixe uma resposta