Como os pequenos podem efetivamente aprender e usar o Puppet? [fechadas]

Question

Seis meses atrás, em nosso projeto sem fins lucrativos, decidimos começar a migrar nosso gerenciamento de sistemas para um ambiente controlado por Marionetes, porque esperamos que nosso número de servidores cresça substancialmente entre agora e daqui a um ano.

Desde que a decisão foi tomada, nossos funcionários de TI ficaram um pouco irritados demais. Suas maiores objeções são:

• "Não somos programadores, somos sysadmins";
• Os módulos estão disponíveis online, mas muitos diferem uns dos outros; rodas estão sendo reinventadas com muita freqüência, como você decide qual delas se encaixa no projeto;
• O código em nosso repositório não é transparente o suficiente para descobrir como algo funciona para recorrer a manifestos e módulos que eles podem ter escrito há algum tempo;
• Um novo daemon requer a criação de um novo módulo; as convenções precisam ser semelhantes a outros módulos, um processo difícil;
• "Vamos apenas executá-lo e ver como funciona"
• Toneladas de 'extensões' pouco conhecidas em módulos da comunidade: 'trocla', 'augeas', 'hiera' ... como nossos administradores podem acompanhar?

Eu posso ver porque uma grande organização enviaria seus administradores para cursos de Marionetes para se tornarem mestres de Marionetes. Mas como os jogadores menores aprendem Puppet a um nível profissional se não vão a cursos e basicamente aprendem através de seu navegador e editor?

    

Answer 1

Comecei a usar o Puppet antes de implantar uma nova infraestrutura e simplesmente comprei um livro ( bem conceituado ) sobre o tópico. Eu não acho que a maioria das pessoas realmente obtém treinamento profissional de Puppet. Eu trabalhei em exemplos até que eu pudesse moldar o processo para o meu ambiente. Isso foi em dezembro de 2011, então, em poucas semanas, consegui entender o básico e criar uma estrutura de produção. Eu não era novo no gerenciamento de configuração, tendo um background de CFEngine , mas muitas das preocupações de seus administradores de sistemas ressoam. Eu cometi erros e tive que refatorar várias vezes, mas consegui fazer as coisas funcionarem satisfatoriamente.

Algumas notas sobre seus pontos ...

• A função de administração de sistemas tradicional está mudando. Adaptar ou ficar para trás. Eu fui um engenheiro de sistemas bem-sucedido, mas estou tendo que me adaptar também (aprender Python, por exemplo). O foco em servidores individuais é reduzido à medida que a abstração de hardware por meio da virtualização e dos serviços de nuvem pública e privada ganham força. Isso significa a automação de tarefas de sistemas e o uso de gerenciamento de configurações para obter o controle de um número maior de servidores. Adicione conceitos DevOps à mistura, e você verá que o expectativas do cliente / usuário final e os requisitos estão mudando.

• Os módulos de fantoches disponíveis online diferem em estilo e estrutura e, sim, vi muita sobreposição, redundância e esforços duplicados. Um desenvolvedor com quem trabalhei disse: "você poderia ter desenvolvido suas próprias ferramentas no tempo que passou procurando por algo que funciona!" Isso me deu uma pausa quando percebi que o Puppet parece apelar mais para os desenvolvedores do que para os administradores que procuram uma abordagem best-practices ou certo .

• Documente bastante para ter uma ideia de como as coisas estão conectadas. Dadas as definições instáveis e a falta de uma maneira padrão de fazer as coisas, sua estrutura de gerenciamento de configurações é realmente única em seu ambiente. Essa transparência terá que ser desenvolvida internamente.

• Eu diria que é razoavelmente fácil duplicar um módulo para acomodar um novo daemon ou adicionar um serviço a um manifesto existente, dependendo de como você organizou seus servidores e funções.

• Passei muito tempo testando em um único alvo antes de enviar alterações para grupos maiores de servidores. Executar puppetd manualmente em um servidor representativo permitiu-me depurar alterações e avaliar seu impacto. Talvez seja um pouco conservador, mas foi necessário.

• Não sei quanto dependeria dos módulos da comunidade. Eu tive que começar a usar Augeas para algum trabalho , e lamentou o fato de que foi uma funcionalidade que eu dei como certo na CFEngine.

No geral, sinto que não há um padrão bem definido quando se trata de Puppet. Tive problemas para descobrir como organizar a estrutura de diretórios no meu Puppetmaster, entendendo como gerenciar a assinatura de certificados, obtendo DNS inverso adequado no lugar em todos os lugares, obtendo o Puppet adequadamente para o ambiente e entendendo quando aproveitar os módulos da comunidade versus construir o meu próprio. É uma mudança de pensamento e vejo como isso faria um pânico sysadmin. No entanto, isso também foi solução construída do zero, então eu tive o luxo de avaliar ferramentas. A decisão de seguir esse caminho foi baseada em mindshare e no momentum por trás de Puppet. Valeu a pena o esforço para aprender algo novo.

Lembre-se de que este site também é um bom recurso.

    

Answer 2

Em um trabalho anterior, recebi a tarefa de realizar uma implementação piloto do Puppet. Agora, tenho experiência em programação, apesar de não ser Ruby, então não tenho tanto problema quanto os outros.

No entanto, é interessante notar que programadores sem experiência com paradigmas não tradicionais têm problemas com Puppet também, porque Puppet é declarativo , não imperativo. Nesse sentido, o Puppet funciona praticamente como qualquer arquivo de configuração: você diz como as coisas deveriam ser, e o Puppet cuida do resto.

Após o piloto, tive a oportunidade de treinar uma dúzia de outros administradores com o Puppet, além de fazer apresentações sobre ele em dois eventos. Minha opinião sobre essa experiência é que alguns administradores fizeram isso, e outros não. Estes eram todos os administradores tradicionais, sem habilidades de programação e diferentes níveis de especialização.

Uma coisa que eu notei é que o Puppet requer a prática constante . Pessoas que foram treinadas, escreveram módulos, e depois passaram um mês ou dois fazendo outra coisa voltaram para o Puppet com pouca habilidade útil. As pessoas que continuavam fazendo pequenas coisas toda semana nunca perdiam a habilidade.

Com base nessas duas observações, recomendo que você se certifique de que todos continuem adicionando alguma classe de Puppet, definição ou módulo toda semana (preferencialmente pelo menos duas ou três vezes). Aqueles que ainda não conseguem se acostumar com isso podem realmente não ter a habilidade para fazê-lo.

Então, novamente, se Puppet foi imposto a eles de cima para cima, eles podem simplesmente estar reagindo ao que eles percebem como uma gerência se intrometendo em como eles fazem seu trabalho - o que seria verdade, na verdade. Pode ser o caso de permitir que eles escolham o qual sistema de gerenciamento de configuração a ser usado para melhorar as coisas. Aqui estão algumas alternativas:

• ANSIBLE : Isso é novo, mas é baseado em comandos shell e ssh, o que pode atrair os administradores tradicionais.
• Chef : Talvez o problema deles seja declarativo, caso em que o Chef seria melhor se eles tivessem experiência com o Ruby.
• SaltStack : baseado em Python e de código aberto
• CFEngine : velho, rápido, tradicional - pode conquistá-los nesses locais.

Answer 3

Eu tenho usado Puppet um pouco mais de dois anos em pequenas lojas onde eu era o único administrador de sistemas. O maior obstáculo que tive foi aprender a desenvolver software adequadamente. Não houve uma semana que eu não estraguei algo que eu disse aos desenvolvedores para não fazer uma dúzia de vezes. Eu verifiquei o código em demasia, eu não quebrei checkins, eu não tag, eu não ramifiquei, não corri o verificador de sintaxe, não usei um padrão, etc. Se você está apenas começando Eu recomendaria algumas das seguintes opções.

1. Perceba que você está desenvolvendo um software que você não sabe fazer ou está fazendo mal. Isso é esperado porque é novo.
2. Infra-estrutura como código é a realidade e, uma vez superada, é bastante poderosa. Gostaria de convidar alguns desenvolvedores, mostrar a eles o seu processo de desenvolvimento atual (ou a falta dele), não se ofenda quando eles levantarem as sobrancelhas, e levar os seus sugestão a sério. Eu recomendaria usar qualquer sistema e processo que seus desenvolvedores usem, a menos que seja completamente inadequado.
3. Módulos de terceiros de marionetes sugam 90% do tempo. Eu os li. Eu roubaria ideias deles. Eu não os colocaria no meu sistema sem grandes edições. No entanto, eu puxava o fantoche stdlib que adiciona algumas funcionalidades legais.
4. augeas e hiera. Aprenda os dois. O primeiro permite a edição complexa de arquivos existentes no local. O segundo é um armazenamento de dados externo.
5. Separe o código dos dados. Este é um dos conceitos mais difíceis de aprender. A codificação de valores, como o monitoramento de hosts no código do seu módulo, é ruim. Colocá-los em um armazenamento de dados (db, yaml (Hiera usa isso ser padrão), csv, qualquer) que seus módulos podem consumir é bom. Um exemplo é um webapp que usa o Mysql. O que isso permite é a capacidade de enviar códigos e dados separadamente. Isso simplifica o processo de desenvolvimento.
6. validar o parser de fantoches e fantoche-lint como parte de seu processo de check-in pré ou pós-código. Também os testes de rspec podem ser uma boa ideia, uma vez que você esteja atualizado.
7. escreva um guia de estilo / código padrão e use-o. "onde está o código que instala o Apache" é um problema comum. Se os seus módulos são basicamente os mesmos, deve ser fácil.

Em resumo, eu acertei todos esses problemas e tenho a maioria dos meus amigos de administrador de sistema. Vai levar algum tempo para ficar bom em usar um sistema de gerenciamento de configuração. Depois disso, você se perguntará como você viveu sem um. "Faça o login em um servidor e faça as alterações manualmente? Ick."

    

Answer 4

Six months ago, in our not-for-profit project we decided to start migrating our system management to a Puppet-controlled environment because we are expecting our number of servers to grow substantially between now and a year from now.

Parece uma ótima idéia começar cedo - Puppet é mais do que apenas gerenciamento de configuração, é uma forma de documentação.

Since the decision has been made our IT guys have become a bit too annoyed a bit too often.

Eles precisam de um ajuste de atitude.

"We're not programmers, we're sysadmins";

Novamente, atitude. Você pode fazer um arquivo conf para um servidor certo? Você pode facilitar o uso do template / 'programmer' conforme suas necessidades e complexidade evoluem .

Modules are available online but many differ from one another; wheels are being reinvented too often, how do you decide which one fits the bill;

Difícil de responder - eu sempre prefiro os módulos de fantoches sobre a maioria - e mesmo assim, eu não uso tantos. Julgamento de certeza. Na minha opinião, alguns módulos são "muito babados".

Code in our repo is not transparent enough, to find how something works they have to recurse through manifests and modules they might have even written themselves a while ago;

Isso não parece um problema de marionete, mas é mais um problema organizacional ou de documentação?

One new daemon requires writing a new module, conventions have to be similar to other modules, a difficult process;

Esse daemon pode ser uma classe, se for simples o suficiente para gerenciar. Eu não tenho certeza do que você quer dizer com convenções, fantoche impõe convenções em você muito bem, não é? Ou estamos falando nas linhas de formatação de código?

"Let's just run it and see how it works"

Não é uma idéia tão ruim se você levar isso devagar e em segurança. Eu ainda começaria com uma VM para entender a essência das coisas.

Tons of hardly known 'extensions' in community modules: 'trocla', 'augeas', 'hiera'... how can our sysadmins keep track?

postfix, exim, sendmail, mysql, postgresql, iftop, iptraf, perl, perl módulos .. Escolha o que você quer e use? Eu acho que isso soa mais como uma coisa de atitude de novo ...

I can see why a large organisation would dispatch their sysadmins to Puppet courses to become Puppet masters. But how would smaller players get to learn Puppet to a professional level if they do not go to courses and basically learn it via their browser and editor?

Eu não participei de nenhum curso - enquanto eu sou um programador mais do que um administrador de sistema, eu achei que não precisava de muita habilidade de programação para realizar qualquer coisa.

A documentação do Puppet, quando seguida, é bastante completa. Apenas preste atenção aos tipos incorporados e passe algum tempo observando como outros módulos são colocados juntos. Eu não diria que é super fácil, mas também não é difícil. É um pouco demorado preparar sua infraestrutura para o fantoche, mas é garantido que o tempo investido será bem gasto na expansão.

    

Answer 5

KISS (Mantenha-o simples e estúpido) - Não use novas tecnologias apenas porque elas estão lá, porque você tem um requisito para elas, use o mínimo que sua implantação requer, atualize conforme necessário, não tente acompanhar com a borda do sangramento. Se você começar com uma configuração básica e construir com base nela, é mais fácil pegá-la e não precisar de um curso (eles estão disponíveis?).

A outra área que você pode ver são os seus administradores de sistema. Se eles não podem programar também, eles são avançados o suficiente para uma grande implantação, onde a maior parte do trabalho precisa ser roteirizada de qualquer ferramenta que você use?

    

Answer 6

Eu também trabalho sem fins lucrativos e fui responsável inicialmente por trazer as caixas Linux internamente e, logo em seguida, pelo Puppet, para administrá-las. Existem algumas coisas específicas que fizemos que realmente ajudaram a fazer as coisas acontecerem.

Antes de tudo, tentei me afastar dos módulos de terceiros. As ferramentas embutidas lidam com 90% da nossa gestão. O maior utilitário de terceiros que uso é o módulo de firewall. Quaisquer fatos personalizados, etc, são desenvolvidos com toda a equipe envolvida. Desenvolvemos um módulo de template e mantemos o gerenciamento de arquivos, pacotes, serviços, etc, todos padronizados neste template.

Em segundo lugar, depois de padronizar o uso dos módulos internos, começamos a usar o Git e o Crucible da Atlassian - sem fins lucrativos, por sinal - para realizar revisões de todas as alterações de configuração. Isso fornece a transparência desejada.

Em terceiro lugar, automatizei a configuração do Puppet para que novos hosts possam ser adicionados automaticamente com um conjunto padrão de opções. Existem várias maneiras de resolver isso. Como eu já tinha um ambiente Kickstart completo, optei por adicionar um script lá.

    

Answer 7

"We're not programmers, we're sysadmins"

Meu como os tempos mudaram, para pior: um greybeard como eu era esperado para ser um programador melhor do que programadores profissionais, ou nunca seria capaz de passar por um sistema administrador .

Agora, temos "administradores de sistema", que são basicamente usuários de área de trabalho do Windows que, em algum momento, foram convertidos para o Linux e não podem programar, e não encontram nada de errado com isso.

O elefante na sala é por que a gerência tolera uma atitude tão destrutiva. Destrutiva para quem ou o quê? Para o negócio e para a infra-estrutura.

De volta ao Puppet [ CFEngine, Chef] assunto: assim que alguém define uma solução como essa, perde-se. Todo mundo perde. Por quê? Porque quem tiver a ideia não é capaz de projetar o gerenciamento de configuração encapsulado na forma de pacotes do sistema operacional Kickstart [ JumpStart, Automated Installer, AutoYaST, Ignite-UX, NIM]. Quando você tem que usar uma ferramenta de hacker automatizada como Puppet (ou Chef, ou CFEngine), significa que você não tem os recursos para projetar e implementar um processo que, por esse mesmo design, reforça completamente os sistemas gerenciados e totalmente apagados, totalmente automatizados e completamente não-interativos.

Outro ponto importante é, se você tem que ter Puppet ou alguma outra solução para corrigir alguém hacking sistema ou configuração de aplicativo manualmente, isso também volta a não ter a experiência para projetar um processo e, nesse processo, um framework onde a configuração é empacotada em componentes discretos. Com efeito, quem implementa Puppet e similares, não tem nenhum conceito de proprietários de componentes, releases, gerenciamento de configuração, Capability Maturity Model. Isso está se tornando rapidamente um problema muito sério na indústria.

Working with Puppet also helped me learn Ruby, which has come to replace Bash as my default system tools language."

Por que o Ruby é necessário, quando um gerenciamento de configuração abrangente e de ponta a ponta pode ser encapsulado em pré-instalação, pós-instalação, pré-remoção e pós-remoção de pacotes do sistema operacional, apenas usando programas shell Bourne, AWK e sed? Que alguém estudasse uma linguagem esotérica de Ruby, e um dialeto dela no contexto de Puppet, é completamente desnecessário. O problema de gerenciamento de configuração é facilmente solucionável (e, a princípio, foi resolvido) com programas shell e AWK, e um pouco sed (1) aqui e ali como cola.

It's a cool feeling to see your Puppet manifest configure an entire machine or a new service from scratch.

É uma coisa ainda mais legal ver isso feito pelo Kickstart, AutoYaST ou JumpStart, sem uma única linha de código , e ser capaz de consultar o sistema operacional usando ferramentas embutidas , sem precisar de nenhum software esotérico ou extra , nenhuma arquitetura cliente-servidor (o SSH é mais do que bom, muito mais que bom), e ver seu sistema operacional ciente de cada um mudança feita a ele.

5.Separate code from data. This is one of the harder concepts to learn. Hardcoding values like Monitoring Hosts into your module code is bad. Putting them in a data store (db, yaml (Hiera uses this be default), csv, whatever) that your modules can consume is good. An example is a webapp that uses Mysql. What this allows is the ability to push code and data separately. This makes your development process simpler.

... Ou você poderia apenas modelar seus arquivos de configuração com variáveis de shell, mesmo backquotes (por exemplo ls -1 ... ) e escrever um script de shell que usa o AWK para chamar eval (1) e expandir todas as variáveis no modelo, aproveitando o mesmo analisador poderoso que os shells incorporaram. Por que tornar isso complexo, quando pode ser muito, muito simples? Onde você armazenará os valores de configuração? Por que, em qualquer lugar que você queira, como, por exemplo, arquivos pkginfo (4), ou um banco de dados como o Oracle, ou praticamente em qualquer lugar . Não há necessidade de soluções ultracomplexas. A biblioteca mencionada acima poderia simplesmente ser originada das seções de pré-instalação ou pós-instalação nos pacotes do sistema operacional, removendo assim a duplicação e aproveitando uma parte central do código ...

Mas acima de tudo, acho que a citação acima é um exemplo da próxima geração de administradores de sistemas que precisam de tutoria não por administradores de sistemas, mas por engenheiros de sistemas . Encontre-se um greybeard e assine como um aprendiz.