Puppet #1: Entendendo o Puppet

Este é o primeiro post do curso online de Puppet, que contará com dezesseis posts sobre o tema.

Neste post, abordaremos o que é o Puppet, como é sua arquitetura, qual a diferença entre o Open Source Puppet e o Puppet Enterprise, como funciona o fluxo de dados entre um Puppet master e um Puppet agent e, por fim, o que são módulos e environments.

Sem mais delongas, vamos direto ao ponto 🙂

Afinal, o que é Puppet?

Criado em 2005, o Puppet é um utilitário de gerenciamento de configuração de software. O desenvolvimento do Puppet é coordenado pela Puppet Labs.

De acordo com a Puppet Labs, com o Puppet você define o estado que deseja sua infraestrutura de TI, e o Puppet forçará esse estado nela automaticamente.

Ele automatiza o processo de entrega de software, permitindo o provisionamento de máquinas físicas ou virtuais, a orquestração, a emissão de relatórios, ou ainda a distribuição de códigos em fase inicial de desenvolvimento, testes, lançamentos ou atualizações.

 

Em uma definição mais simplista, imagine que você quer fazer um bolo de chocolate. Depois de vários testes, você chegou a receita que considera a ideal. Com isso, todos os bolos de chocolate que você fizer a partir de agora você acabará usando aquela receita, certo? O Puppet é basicamente isso. Você coloca receitas nele, e então toda infraestrutura conectada a ele seguirá o que está definido nessas receitas.

No vídeo abaixo, em inglês, a Puppet Labs explica o que é o Puppet e qual sua importância.

Algumas empresas que utilizam o Puppet: NASA, Spotify, GitHub, Motorola, Sony, Red Hat, dentre outras.

Open Source ou Enterprise?

Se você já pesquisou um pouco sobre o assunto, provavelmente você já ouviu falar que existem duas versões do Puppet: Open Source e Enterprise.

Na versão Enterprise você conta com um dashboard onde pode gerenciar o Open Source Puppet, bem como com suporte oficial da Puppet Labs e alguns outros recursos. Apesar de já ter testado essa solução no curso Puppet Fundamentals, nunca cheguei a utilizar ela no dia-a-dia.

Por isso, todos os posts aqui publicados serão focados no Open Source Puppet, que é livre, gratuito e que pode ser baixado facilmente nos repositórios das distribuições Linux atuais ou no site da Puppet Labs.

Na prática, qual o problema que o Puppet resolve?

Imagine que você esteja gerenciando uma infraestrutura de 20 servidores com o Ubuntu 14.04, onde 15 desses servidores rodam sua aplicação web estável (production), 2 servidores são utilizados para testes (testing), e 3 servidores são utilizados pelos times de desenvolvimento e operações (devops).

• Como você faria para gerenciar a configuração de todos esses servidores?
• Como você faria a entrega das novas versões do seu software?
• Caso precisasse adicionar mais 10 servidores para produção, como você os configuraria?
• Caso você precisasse instalar o python3-simplejson em todos esses servidores, como faria?

Já pensou quanto tempo e dinheiro seriam perdidos se você tivesse que resolver cada um desses problemas manualmente?

Com um Puppet bem configurado você poderia resolver todos os problemas citados acima em questão de minutos.

Esse foi apenas um exemplo de aplicação do Puppet. No próximo post abordaremos alguns pontos que você poderá usar para decidir se o Puppet será ou não uma boa opção para seu negócio.

Arquitetura do Puppet

A arquitetura mais comum para utilização do Puppet é a de cliente/servidor, por meio do Puppet agent (cliente) e do Puppet master (servidor). No entanto, também é possível utilizar o Puppet independentemente, por meio do Puppet apply.

Na figura abaixo você pode ter uma noção de como funciona a arquitetura agent e master do Puppet.

O Puppet master pode rodar em um ou mais servidores, e é onde nossas “receitas de bolo” ficam armazenados.

Já nos nodes nós temos os Puppet agents, que basicamente estão configurados para interagir com o Puppet master.

Fluxo de dados entre o agent e o master

Pra entender melhor essa interação entre o Puppet agent e o Puppet master, vamos analisar o fluxo de dados que ocorre entre eles.

A imagem acima ilustra o processo que ocorre quando você executa o Puppet agent em um dos nodes.

1. Facts: O node envia seus facts para o Puppet master. Esses facts são dados coletados pelo próprio agent (cliente) e que são enviados, em formato YAML, ao master (servidor).

Esses dados coletados incluem detalhes em relação a configuração da máquina atual, como por exemplo a versão do sistema operacional e do kernel, o hostname, o horário atual, os endereços de rede, o modelo do processador, o uptime, dentre outros.

Se você já tem o Puppet instalado em alguma máquina, você pode visualizar os facts que são encaminhados ao Puppet master utilizando o comando facter.

2. Catalog: Após receber os facts, o Puppet master vai compilar um catalog com base nos facts recebidos, e então vai enviar esse catalog para o agent. O agent receberá o catalog e então executará o que está descrito nele.

Em outras palavras, o Puppet master vai criar uma “receita” dizendo exatamente o que aquele agent precisa fazer.

De acordo com a Puppet Labs, um catalog é um documento que descreve o estado desejado do sistema para um computador específico. Ele lista todos os recursos que precisam ser gerenciados, bem como quaisquer dependências entre esses recursos.

Essa parte pode parecer um pouco confusa agora, mas não se desespere. Vamos entender melhor quando colocarmos a mão na massa nos próximos posts 🙂

3. Report: Após o agent aplicar as mudanças do catalog compilado no passo anterior, ele envia um relatório com as mudanças realizadas para o Puppet master.

4. Report: Após o Puppet master receber o report do passo anterior, ele também pode ser configurado para gerar relatórios customizados, enviar dados para sistemas de relatórios externos ou ainda, por exemplo, publicar as falhas de execução em APIs externas (Twitter, HipChat, etc).

A explicação acima cobre todo o fluxo de dados entre o agent e o master. Simples, não? 🙂

Módulos

Quando falamos em Puppet, um módulo pode ser definido como um pacote de código e dados. Eles são as “receitas de bolo” que citamos anteriormente.

Você pode baixar módulos de terceiros ou pode escrever seus próprios módulos.

Por exemplo, podemos ter um módulo de MySQL, que faz a instalação e configuração do MySQL de acordo com as nossas necessidades. Também podemos ter um módulo de Nginx, que instala e configura o Nginx da forma que você deseja nas suas máquinas.

Vale ressaltar que dificilmente você conseguirá trabalhar de maneira eficiente utilizando somente módulos de terceiros. Você certamente precisará escrever seus próprios módulos, voltados para a realidade do seu negócio.

Esse foi apenas um esboço sobre o assunto, já que iremos abordar sobre eles em diversos posts futuros.

Environments

Reaproveitando a imagem que utilizamos anteriormente, observe que temos quatro nodes definidos nela.

Até agora vimos que cada um desses nodes pode ser uma máquina física ou virtual, e que cada um deles contará com um Puppet agent que em suas configurações estará vinculado com o Puppet master. Mas por que estamos falando disso afinal? Para entendermos o conceito de environments.

Para não precisarmos configurar um Puppet master para produção, outro para testes e outro para desenvolvimento, geralmente dividimos o Puppet em ambientes (environments), que nos permitem separar os nodes em grupos isolados, conforme demonstra a imagem abaixo.

O mais comum é dividir os nodes em três environments: production, testing e development. Isso permite você usar diferentes versões do mesmo módulo, ou até mesmo diferentes módulos, em grupos isolados de máquinas.

Um erro muito comum na definição de environments é pensar da seguinte forma: temos um setor que desenvolve a ferramenta X e outro que desenvolve a ferramenta Y. Portanto, vamos criar dois environments, um devX e outro devY. Não devemos pensar nos environments como setores da empresa, mas sim como estágios de desenvolvimento. Mas vamos abordar isso com calma no post sobre o roles/profiles pattern.

Assim como no caso dos módulos, esse foi apenas um esboço do que são environments. Iremos falar novamente sobre eles num futuro não muito distante 🙂

—

Como veremos nos próximos posts, o Puppet em si é uma solução simples e de fácil implantação. O processo mais trabalhoso certamente é a implementação dos módulos voltados para o seu negócio.

Por hoje é só pessoal 🙂 O que achou desse primeiro post? Deixem seus comentários!

Se você tiver alguma dúvida, sugestão ou reclamação, por favor sinta-se a vontade para comentar nesse post, me chamar no Twitter ou ainda enviar um e-mail para tiago AT tiagohillebrandt DOT com.

Já no próximo post, seguindo a agenda, vamos falar um pouco sobre a realidade do Puppet no mundo empresarial. Até lá!

Referências

[0] https://puppetlabs.com/puppet/what-is-puppet
[1] https://puppetlabs.com/puppet/enterprise-and-open-source
[2] https://docs.puppetlabs.com/puppet/4.2/reference/architecture.html
[3] https://docs.puppetlabs.com/guides/reporting.html
[4] Puppet Fundamentals Student Guide v3.4.1 (pg. 19)
[5] https://docs.puppetlabs.com/puppet/latest/reference/modules_fundamentals.html