O porquê de escolhermos o Puppet

Standard

Na organização que trabalho foi colocada a demanda de implantar um ferramenta de gerência de configuração, pois nosso ambiente sofre de uma grande carência em documentar suas mudanças, proporcionar uma documentação atualizada, isso sem falar na velocidade de atendimento de novas demandas ser prejudicada pela necessidade de atividade repetitiva/operacional majoritariamente manual.

Depois de uma longa etapa de analise preliminar iniciamos a comparação entre três soluções que poderia atender nossas expectativas: Chef, Puppet e Salt.

Choices 1

Escolher nem sempre é uma tarefa fácil

Dentre vários critérios analisados, levantamos cinco pontos que julgamos ser os mais relevantes para nossa realidade:

  • Complexidade de instalação
  • Curva de aprendizado
  • Orquestrador
  • Dashboard
  • Quem utiliza

Com base nisso, instalamos cada solução, testamos o que ela poderia fazer para nos ajudar e refletirmos com base nos pontos já informados acima. Segue abaixo o resultado da nossa análise.

Complexidade de instalação

Puppet

A instalação dos pacotes puppetmaster(servidor) e puppet(clientes) na sua versão open-source não revelou-se muito complicada. Sua documentação oficial orienta inicialmente instalar o pacote puppetlabs-release com a versão referente ao sistema operacional. A única ressalva com relação à essa etapa é a escolha do pacote para o servidor, pois o puppetmaster é recomendável somente para ambiente menores, com pouca carga, pois seu servidor web embutido (webrick) suporta poucos nós clientes para um ambiente mais escalável deve-se optar pelo puppetmaster-passenger.

Apesar de orquestrador ser um critério analisado mais adiante, a complexidade de sua instalação está dentro do escopo desse critério. Embora a documentação oficial não faça nenhuma recomendação explicita ao uso do MCollective como orquestrador na versão Opensource, na Enterprise ela já vem embutida, somando isso ao fato dele já possuir plugins nativos para o Puppet pesou na escolha dessa ferramenta para a tarefa de orquestração.

Na versão Opensource do Puppet, o orquestrador não é configurado por padrão, houve um esforço maior na sua instalação e configuração. Há dependência da instalação e configuração de um Midleware, sistema de mensageira (Apache ActiveMQ).

Tivemos dificuldade com relação a falta de orientação para cenários mais complexos, por exemplo, com relação a questão de segurança na comunicação do midleware.

Salt

Basta instalar os pacotes salt-master(servidor) e salt-minion(clientes), fazer uma simples configuração para que os nós clientes reconheçam o master, posteriormente o master autenticar chaves publicas dos clientes e o ambiente já estará pronto para ser utilizado.

O orquestrador faz parte da solução Salt, sendo assim, a facilidade na instalação apresentada até então abrange também o orquestrador.

Chef

Sua instalação, com a exceção do cliente (chef-client), foi dificultada por alguns fatores.

  • Na topologia cliente-servidor, o chef se diferencia das demais em virtude dele ser composto por 3 itens: Server; Workstation e Nodes, que apesar da documentação oficial explicar a função de cada um deles, a mesma não dá uma orientação sobre sua instalação.
  • Com relação ao pacote para servidor (chef-server), no site oficial é disponibilizado apenas para Ubuntu e RHEL, e eles não demonstram nenhum interesse manter uma versão para o Debian no lado do servidor.

Conclusão desse critério

Adotando a topologia cliente-servidor, visto que todas os softwares analisados permitem também a opção standalone, ou seja, em modo autônomo, o Salt demonstrou-se a mais simples, o Chef mais complexa, ficando o puppet com complexidade intermediária. A opção pelo modelo cliente-servidor foi feita em virtude da gerência centralizada e a possibilidade do acompanhamento das modificações nos agentes através de um painel (dashboard), item que será melhor detalhado mais adiante.

Curva de aprendizado

Antes de iniciarmos a discussão desse critério, faz-se necessário a contextualização de alguns aspectos sobre gerenciamento ou automação de configurações, referentes aos três softwares examinados.

Em todos eles, as configurações são codificadas estaticamente através de arquivos chamados: Manifest no Puppet, Formulas no Salt e Cookbooks no Chef. Nessa parte não houve muita dificuldade de compreensão, não necessitando de um conhecimento muito avançado à nível de programação ou de linguagem específica, apesar de que, no Chef os Cookbooks podem ser escritos também em Ruby puro.

O interessante é que em todos eles utilizam algum conceito de linguagens de Orientação à Objetos como por exemplo, suporte a funcionalidade de heranças.

Outro detalhe não menos importantes e bem intuitivo, consiste em que todos eles possuem utilitários responsáveis pela obtenção de informação dos agentes: Facter no Puppet, Grains no Salt e Ohai no Chef, com os quais descrevem as propriedades dos sistemas operacionais, permitindo filtros na definição de estados das configurações assim como na orquestração.

Nesse critério, houve um empate técnico, pois todas são semelhantes no que diz respeito às definições de gerenciamento ou automatização de configurações, com perspectiva bastante compreensíveis.

Orquestrador

Segundo o Guto Carvalho (slide 5 da palestra Orquestração com MCollective): “Orquestrar significa invocar ações de forma paralela ou não, em tempo real, em diversos servidores de um datacenter, fazendo isto de forma automatizada, eficiente e controlada”. Orquestração não é gerenciamento de configuração e sim um tipo diferente de automatização em que ambos se complementam. Diferencia-se da seguinte forma, enquanto que na gerência de configurações, os estados desejados de um sistema é modelado, na orquestração, as ações são executadas remotamente sob demanda.

Nesse critério somente o Puppet e o Salt serão discutidos, visto que o Chef não possui orquestrador integrado como no Salt, nem mesmo tem em sua documentação alguma menção à nenhum utilitário externo desse tipo, como o Puppet tem o MCollective como exemplo, no seu caso, o uso da ferramenta como o knife com ssh, a qual está mais para execução remota, seria o que mais se aproximaria de orquestração.

Puppet

O MCollective, orquestrador adotado pelo mesmo, é uma ferramenta bem simples de utilizar, com bastantes plugins disponíveis, inclusive para o próprio Puppet. Ele disponibiliza diversas funcionalidades, como instalação de pacotes, gerência de serviços, shell (interpretador de comandos) e etc, além de ser extensível através de protocolo RPC. A complexidade de sua instalação, pelo fato do mesmo ser um outro software(pacote), com configuração própria e necessidade de instalar um pacote agent e client para cada plugin disponível, somando-se a depência de um midlleware, no caso o ActiveMQ, que também demanda uma instalação separada.

Salt

No Salt, da mesma forma que o MCollective, seu orquestrador, disponibiliza uma infinidade de módulos, oferecendo funcionalidades como: instalação de pacotes, gerência de serviços, shell (interpretador de comandos) e etc. além de ser extensível. O fato de já vir integrado e configurado, inclusive com seu middleware (ZeroMQ) cuja a leveza de sua biblioteca serve como framework de concorrência, sem falar no fato da comunicação ser nativamente segura entre o master.

Conclusão desse critério

o Salt levou uma grande vantagem nesse item, por essa funcionalidade já vir integrada e utilizar técnicas que permitem escalabilidade e velocidade na execução remota de suas tarefas, com uma linguagem bastante homogênea em virtude de sua agregação, ao contrário do MCollective no Puppet, ficando em segundo lugar como opção nesse item.

Dashboard

Após toda contextualização sobre automatização ou gerenciamento de configurações e orquestração, esse item é de fundamental importância para o nosso ambiente. O envio de relatórios, classificação externa e acompanhamento do ciclo de vida dos ativos em tempo real, ou seja, toda a visibilidade do que acontece no nosso ambiente após aplicação de alguma nova configuração. Tudo isso é esperado em um Dashboard.

Nesse quesito apenas uma ferramenta externa atendeu nossas expectativas. O Foreman é a ferramenta ideal para nosso ambiente, pois consiste em um gerenciamento do ciclo de vida desde provisionamento, configuração para orquestração e monitoramento. Tem interação nativa com o Puppet e sua interface web oferece várias informações com gráficos e formatos bastantes intuitivos, assim como muito mais recursos que os prórpios painéis oferecidos pelos próprios projetos das três ferramentas observadas.

A documentação do Foreman mencionar suporte também para o Salt e Chef, mas com limitação de certos recursos, isso sem falar na interação nativa que ele tem apenas com o Puppet, a qual contribuiu para promovê-lo como opção mais vantajosa em comparação às outras duas ferramentas nesse item.

Quem usa

Observamos quais as organizações/empresas que usam todas as três soluções e chegamos a conclusão que o Puppet tem um conjunto de usuários mais próximos da nossa organização, além de ter um número de “grandes players” bem superior as outras.

Conclusão final

Com base em tudo que foi explanado até então, principalmente no que tange a quem usa a ferramenta e existência de um ótimo suporte ao Dashboard que atende nossas expectativas, fica evidente que a solução que mais atende nossa necessidade é de fato o Puppet, mesmo o Salt tendo demonstrado ser uma alternativa bem mais simples.

Fonte

Esse texto foi construído com base no relatório final apresentado pelo bolsista Péricles Júnior, que trabalha na Coordenação de Redes e Infraestrutura de Superintendência de Tecnologia da Informação da Universidade Federal da Bahia.

  • Daniel Santos

    Ola,

    Pelo que entendi lendo o texto, o Puppet foi escolhido por caracteristicas nao tecnicas tendo em vista que o Salt ganhou em quase todos os aspectos. Tenho experiencia com Puppet e estou atualmente migrando pra Salt por alguns simples motivos:

    – A gerencia de dependencia e ordem de execucao no Puppet eh um caos! Voce simplesmente nao sabe em que ordem o seu manifest sera executado. Isso eh parte culpa da linguagem utilizada, Ruby. Voce precisa fazer diversas gambiarras pra que um simples array seja corretamente ordenado em um template pra garantir que em todas as execucoes o resultado seja o mesmo, caso contrario, a cada execucao o Puppet ira gerar uma ordem diferente. Imagine uma configuracao do Apache que tem a configuracao de ServerAlias gerenciada pelo Puppet e a cada execucao a ordem dos ServerAlias muda e o servico eh reiniciado!
    – Puppet eh lento e em praticamente todas as vezes que voce atualizar de versao voce tera problemas.
    – A curva de aprendizagem do Puppet eh muito maior, pois voce tem que aprender a linguagem declarativa dele. No Salt, tudo eh YAML (States) e Jinja2 (Templates).

    Enfim, na minha opiniao, nao existem razoes tecnicas para se escolher o Puppet ao inves do Salt, tendo em vista que o Salt eh mais simples, mais rapido e ao mesmo tempo mais completo.

    • Gomex

      Muito obrigado pelo seu retorno! 🙂 Adoro escrever sobre decisões, pois geralmente as pessoas apresentam contraponto! Isso é sensacional 🙂 Obrigado mesmo.

      Um dos argumentos técnicos é a inexistência de um dashboard maduro o suficiente para usarmos em produção.

      Vou considerar sua opinião e simular em nosso ambiente, para ver como ele se comporta. Logo quem sabe não lanço uma notícia falando sobre nossa migração? rs Não tenho medo de errar e mudar, tenho medo de parar de tentar 🙂

  • Fernando Vieira

    Ótimo artigo, minha escolha também foi o Puppet, por se mostrar um software mais robusto, confiável e maduro com uma comunidade grande.
    Atualmente tenho um Puppet master em produção com 90 nodes, também utilizo o Puppet Dashboard para questão de gráficos, tive uma grande melhora na agilidade, documentação e padronização.

    Quanto aos pontos que o Daniel referiu acima alguns fazem sentindo outros não, também tive dificuldades em entender a ordem que os manifests são executados, mas podem ser muito bem regulados com opções “require, notify, subscribe” que o puppet oferece.
    Não concordo com o caos da gerência de dependência, quando utilizados ou criados módulos de forma correta, podemos muito bem defini-las de forma bem clara.
    Não conheço a ferramenta Salt a fundo, mas da se a perceber que ela é uma ferramenta mais fácil e simples de se usar, mas não quer dizer que seja melhor em todos os aspectos técnicos.

    No mais é isso um grande abraço

    • Daniel Santos

      Oi Fernando,

      Meu ponto nao foi dizer que o Puppet eh terrivel e o Salt eh perfeito. Tenho bastante experiencia com Puppet e sigo todos os itens de “Best practices” deles.
      Voce disse que a ordem de execucao dos manifests podem ser bem controladas com o uso de “require, notify, subscribe”… Isso nao eh de todo verdade, pois esses item controlam basicamente a dependencia e callbacks entre os recursos e nao diretamente a ordem de execucao dos mesmos. Outro ponto que me referi foi com relacao aos templates, no qual voce tem que fazer sort_by em tudo pra forcar a ordem em que arrays serao populados.
      Por exemplo, como voce garante que o modulo que cuida da instalacao do MySQL deve rodar obrigatoriamente antes do modulo que instala a sua aplicacao web e precisa criar o schema no banco e que so depois disso voce pode subir o apache (que deve ser outro modulo)?
      Quantos modulos voce possui no seu ambiente? Pois dependendo da quantidade de modulos, voce vai ter bastante dor de cabeca pra nao criar uma dependencia ciclica.
      No Salt voce tem a opcao “order” em que vc estabelece uma sequencia numerica em que seu state sera parseado e executado.
      Coisas simples como criar uma hierarquia de diretorios como por exemplo um mkdir -p /esse/diretorio/nao/existe/ainda, no Puppet voce tem que criar um resource pra cada subdiretorio E forcar a ordem deles dizendo que diretorio depende de esse, que nao dependen de diretorio, que existe depende de nao e que ainda depende de existe. Insano nao?!.
      Enfim, uma vez que voce comeca a trabalhar com Salt eh que voce se depara o quao estupido o Puppet chega a ser, apesar de ser um excelente software.

      • Gomex

        Eu ainda não posso dar minha opinião sobre o assunto, mas acho ótimo o debate entre quem já conhece, pois me colocará em uma posição bema frente das que vocês tiveram. Irei testar ele de forma bem mais direcionada! Muito obrigado! 🙂

        Assim que testar ele, farei um texto sobre nossa experiência aqui.

    • Apenas para esclarecer essas questões de ordenação no Puppet, alguns pontos.

      Os metaparametros require, before, notify, subscribe existem justamente para impor ordem quando ela for necessária, e o resultado final é que um resource só será “executado” (o termo correto é sincronizado) após o outro e se o anterior não falhar.

      Em relação a ordenar tarefas mais complexas como configurar um banco de dados antes de configurar o Apache, por exemplo, existem diversas maneiras de se fazer isso de maneira sólida e descomplicada.

      Por não ser uma linguagem de programação propriamente dita, a DSL do Puppet tem recursos visuais que facilitam a identificação e ordenação.

      Um exemplo mais comum é esse:

      Class['produto_mysql'] -> Class['produto_apache']

      Isso te garante que tudo que estiver na classe produto_mysql, digamos que ela fará toda a sua configuração de banco, aconteça antes da configuração do seu servidor web.

      Em relação a diretórios, não é necessário especificar todas essas dependências como o colega citou. Dentro de um mesmo resource type, o Puppet resolve as dependências sozinho. Você não precisa se preocupar em escrever na ordem e também não precisa se preocupar em defini-las também.

      Por exemplo:

      file {'/tmp/dir1/dir2':
      ensure => directory,
      }

      file {'/tmp/dir1':
      ensure => directory,
      }

      file {'/tmp/dir1/dir2/dir3':
      ensure => directory,
      }

      Note que a criação está fora de ordem no código e também não declarei nenhuma dependência entre os mesmos. Veja o resultado:


      Notice: Compiled catalog for test.local in environment production in 0.44 seconds
      Notice: /Stage[main]/Main/File[/tmp/dir1]/ensure: created
      Notice: /Stage[main]/Main/File[/tmp/dir1/dir2]/ensure: created
      Notice: /Stage[main]/Main/File[/tmp/dir1/dir2/dir3]/ensure: created
      Notice: Finished catalog run in 0.26 seconds

      O Puppet tem inteligência para resolver esse caso, e muitos outros.

      Convido o colega a ler a documentação a cerca desse tópico para constatar que nessa questão de ordem, na realidade o Puppet é superior, pois existem diversos mecanismos que garantem ordenação automática, liberando o administrador para se preocupar com outras questões.

      <a href="https://docs.puppetlabs.com/puppet/latest/reference/lang_relationships.html

      • Gomex

        Obrigado Miguel!

  • Fernando Vieira

    No puppet eu trabalho com uma mistura de classes singulares e módulos, trabalho atualmente com 15 (classes/módulos) com 90 servidores em produção e não tive problemas.
    Para fazer uma dependência como você citou acima simplesmente utilizo
    “require => Class[“apache”]” onde tenho apache com uma outra classe
    Mas claro que tive que desenvolver toda minha estrutura a partir dos meus próprios módulos e classes para deixar da forma que me atenda.

    De qualquer forma seus argumentos são válidos para que eu possa testar o Salt mais adiante e ter uma noção destas diferenças, mas por enquanto estou muito satisfeito com o Puppet.

    Um abraço

  • Diego R. Santos

    Você chegou a testar o ansible?

    • Gomex

      Não profundamente.