Por que usar Chef / Puppet sobre scripts de shell?

Novo nas ferramentas Puppet e Chef. Parece que o trabalho que eles estão fazendo pode ser feito com scripts de shell. Talvez tenha sido feito em scripts de shell até que eles surgissem.

Eu concordo que eles são mais legíveis. Mas, existem outras vantagens sobre os scripts de shell, além de serem legíveis?

Uma linguagem específica de domínio faz uma grande diferença na quantidade de código que você escreve. Por exemplo, você pode argumentar que não há muita diferença entre:

chmod 640 /my/file

e

file { "/my/file":
    mode => 640,
}

mas há muita diferença entre estes:

FILE=/my/file
chmod 640 $FILE
chown foo $FILE
chgrp bar $FILE
wget -O $FILE "http://my.puppet.server/dist/$FILE"
     # where the URL contains "Hello world"

e

file { "/my/file":
    mode => 640,
    owner => foo,
    group => bar,
    content => "Hello world",
}

O que acontece se o wget falhar? Como seu script lidará com isso? E o que acontece se houver algo depois disso em seu script que exija que $ FILE esteja lá com o conteúdo correto?

Você pode argumentar que é possível simplesmente inserir echo "Hello world" > $FILEo script, exceto que, no primeiro exemplo, o script deve ser executado no cliente, enquanto o puppet compila tudo isso no servidor. Portanto, se você alterar o conteúdo, precisará alterá-lo apenas no servidor e para todos os sistemas que desejar. E o fantoche lida com dependências e transfere problemas automaticamente para você.

Simplesmente não há comparação - as ferramentas de gerenciamento de configuração adequadas economizam tempo e complexidade. Quanto mais você tenta fazer, mais scripts de shell parecem inadequados e mais esforço você economizará ao fazê-lo com o fantoche.

Esta será uma opinião impopular, mas os sistemas de gerenciamento de configuração não são necessariamente melhores. Às vezes simples é realmente o melhor.

Há uma curva de aprendizado definida e uma sobrecarga administrativa associada ao sistema de configuração que você escolher. Afinal, você está introduzindo uma dependência. Como em qualquer automação, você também deve ter cuidado para que a segurança seja mantida nas configurações implementadas.

Eu só tive algumas instâncias em que implantamos o gerenciamento de configuração e ele ficou parado. Era sempre quando havia um grande número de sistemas com configuração repetitiva e a necessidade de executar implantações configuráveis ​​de cortadores de biscoito.

Você respondeu sua própria pergunta ...

A automação está se tornando mais escalável e formalizada . Atualmente, Puppet e Chef são considerados padrões (consulte os anúncios de emprego ).

Scripts shell-juntos calçada têm o seu lugar, mas eles são não escalável no contexto do movimento DevOps. A legibilidade faz parte disso.

O Chef facilita muito o gerenciamento e a versão da configuração de uma infraestrutura complexa, especialmente em qualquer tipo de ambiente em nuvem, em comparação com a necessidade de ftp ou scp manualmente de vários scripts de shell organizados de maneira não padronizada. Dependendo de quantas dependências você precisa gerenciar, o tamanho dessa vitória pode variar bastante, tornando a decisão de mudar para uma solução CM uma solução não óbvia para muitas pessoas.

O benefício real (muitas vezes desconhecido) do Chef é a idempotência . Ser capaz de ter certeza do estado de um recurso, independentemente da combinação de receitas executadas com interesses sobrepostos, é um grande benefício sobre a configuração do script de shell. Se você possui scripts de shell para configuração agora, pergunte-se quantos deles podem ser executados várias vezes sem consequências indesejadas / indesejadas?

Uma solução CM adequada ajuda a garantir o sucesso em escala, simplificando a automação de plataforma cruzada e a colaboração da equipe. Embora seja possível realizar tudo isso com um grupo de scripts de shell bem organizado, com manutenção adequada e com versão; você precisa se perguntar "por que". O Chef / Puppet e tecnologias similares surgiram porque um grupo de SysOps talentosos estava cansado de ter que resolver esses mesmos problemas repetidamente e se propôs a nos dar uma opção melhor.

Peças-chave:

• Idempotência
• Gerenciamento de Facilidade de Dependência (versionamento)
• Organização padronizada (aceita no nível do setor)
• Abstração para separar tarefas de configuração do servidor dos detalhes no nível do sistema
• Capacidade de alavancar o conhecimento da comunidade (que garante a adoção de todos os princípios acima)

Ferramentas modernas de gerenciamento de configuração, como Puppet e Chef, permitem definir o estado de um sistema em vez de se preocupar com as atividades necessárias para obter um servidor configurado.

Por exemplo, seu comando chmod assume que o arquivo existe, que o usuário que possui o arquivo existe, que os diretórios foram criados e assim por diante. Portanto, seu script deve considerar todos esses pré-requisitos.

As ferramentas de gerenciamento de configuração baseadas em estado são mais simples: você apenas se importa que o arquivo tenha as permissões corretas. Como isso é alcançado é o problema da ferramenta.

Se os servidores são descartáveis ​​para você ou você tem motivos para resistir mais de um par de cada vez, um sistema CM completo atenderá melhor às suas necessidades do que uma série de scripts de shell.

Se suas necessidades de compilação são modestas (ou gostam de criar artesanalmente servidores orgânicos de livre comércio orgânicos), mantenha-o simples.

Pessoalmente, depois de usar extensivamente o Chef em um show passado, tentei 'simplificar' esse show, mas realmente senti falta das primitivas, abstrações e poder que o Chef fornecia. Mesmo que você chegue a uma situação em que você pode obter o que precisa de alguns comandos do shell, você pode simplesmente executá-los com um bloco 'command', inserindo os comandos do shell exatamente como você os escreveria no shell.

Com isso dito, você pode executar o Chef sem um servidor (chef-solo), e tenho certeza de que o Puppet tem um análogo, onde você ainda pode aproveitar os livros de receitas e receitas de outras pessoas sem executar um servidor central.

Outro benefício é a comunidade: há muitas pessoas (muitas das quais serão mais inteligentes e / ou mais experientes que você). Pessoalmente, adoro quando outra pessoa faz o meu trabalho por mim, muitas vezes mais extensivamente do que eu faria.

Criei uma estrutura de automação de servidor baseada em script de shell: https://github.com/myplaceonline/posixcube

Tenho certeza de que não sou o primeiro a fazer esse tipo de projeto, mas não consegui encontrar algo parecido para atender às minhas necessidades, então achei que outras pessoas poderiam achar isso útil. Eu só tinha experiência com o Chef, mas quando comecei a olhar para o Ansible e outros, queria dar uma chance aos scripts de shell e gosto do resultado até agora.