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

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

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

• "Não somos programadores, somos administradores de sistemas";
• Módulos estão disponíveis online, mas muitos diferem entre si; as rodas estão sendo reinventadas com muita frequência; como você decide qual delas se encaixa na conta;
• O código em nosso repositório não é transparente o suficiente, para descobrir como algo funciona, eles precisam recursar por meio de manifestos e módulos que eles podem ter escrito por si mesmos há um tempo atrás;
• Um novo daemon requer a criação de um novo módulo; as convenções devem ser semelhantes a outros módulos, um processo difícil;
• "Vamos rodar e ver como funciona"
• Toneladas de 'extensões' pouco conhecidas nos módulos da comunidade: 'trocla', 'augeas', 'hiera' ... como nossos administradores de sistemas podem acompanhar?

Eu posso ver por que uma grande organização enviaria seus administradores de sistema para cursos de marionetes para se tornarem mestres de marionetes. Mas como os jogadores menores aprenderiam o Puppet a um nível profissional se não freqüentassem os cursos e o aprendessem basicamente através do navegador e do editor?

Comecei a usar o Puppet antes de implantar uma nova infraestrutura e simplesmente comprei um livro ( bem conceituado ) sobre o assunto. Eu não acho que a maioria das pessoas realmente obtenha treinamento profissional de marionetes. Trabalhei em exemplos até conseguir moldar o processo ao meu ambiente. Como era dezembro de 2011, em poucas semanas consegui entender o básico e criar uma estrutura de produção. Eu não era novo no gerenciamento de configurações, com experiência em CFEngine , mas muitas das preocupações de seus administradores de sistemas ressoam. Cometi erros e tive que refatorar várias vezes, mas consegui que as coisas funcionassem satisfatoriamente.

Algumas notas sobre seus pontos ...

• A função tradicional de administração de sistemas está mudando. Adapte-se ou fique para trás. Sou engenheiro de sistemas bem-sucedido, mas também estou precisando refazer (aprendendo Python, por exemplo). O foco em servidores individuais diminui à medida que a abstração de hardware através da virtualização e os serviços de nuvem pública e privada ganham força. Isso significa a automação das tarefas do sistema e o uso do gerenciamento de configurações para recuperar o controle de um número maior de servidores. Adicione conceitos de DevOps ao mix e você verá que as expectativas e os requisitos do cliente / usuário final estão mudando.

• Os módulos fantoches disponíveis on-line diferem em estilo e estrutura e, sim, vi muitas sobreposições, redundâncias e esforços duplicados. Um desenvolvedor com quem trabalhei disse: "você poderia ter desenvolvido suas próprias ferramentas no tempo que passou procurando online algo que funcione!" Isso me fez pausar quando percebi que o Puppet parece atrair mais os tipos de desenvolvedores do que os administradores que procuram práticas recomendadas ou a abordagem correta .

• 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ção é realmente exclusiva do seu ambiente. Essa transparência terá que ser desenvolvida dentro.

• 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 destino antes de fazer alterações em grupos maiores de servidores. Executar o puppetd manualmente em um servidor representativo me permitiu depurar alterações e avaliar seu impacto. Talvez isso seja um pouco conservador, mas era necessário.

• Não sei ao certo quanto dependeria dos módulos da comunidade. Eu tive que começar a usar o Augeas para algum trabalho e lamentava o fato de que era uma funcionalidade que eu dava como certa no CFEngine.

Ao todo, sinto que não há um padrão bem definido quando se trata de Puppet. Eu tive problemas para descobrir como organizar a estrutura de diretórios no meu Puppetmaster, entender como gerenciar a assinatura de certificado, colocar o DNS reverso adequado em todos os lugares, fazer o Puppet dimensionar adequadamente para o ambiente e entender quando aproveitar os módulos da comunidade em vez de criar o meu. É uma mudança de pensamento e vejo como isso faria um administrador de sistemas entrar em pânico. No entanto, essa também foi uma solução criada do zero, então tive o luxo de avaliar ferramentas. A decisão de seguir esse caminho foi baseada no compartilhamento de ideias e no momento por trás do Puppet. Valeu a pena o esforço para aprender algo novo.

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

Em um trabalho anterior, fui designada para executar uma implementação piloto do Puppet. Agora, tenho experiência em programação, embora não seja Ruby, por isso não tenho tanto problema quanto os outros.

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

Depois do piloto, tive a oportunidade de treinar uma dúzia de outros administradores com o Puppet, além de fazer apresentações sobre isso em dois eventos. Minha opinião sobre essa experiência é que alguns administradores aceitaram e outros não. Todos eram administradores tradicionais, sem habilidades de programação e níveis variados de conhecimento.

Uma coisa em particular que notei é que o Puppet exige prática constante . As pessoas que foram treinadas, escreveram módulos e depois passaram um mês inteiro ou dois fazendo outra coisa voltaram ao Puppet com pouca habilidade útil. As pessoas que continuavam fazendo pequenas coisas todas as semanas nunca perdiam a capacidade.

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

Por outro lado, se Puppet lhes fosse imposto de cima, eles poderiam simplesmente estar reagindo ao que consideram uma gerência intrometida na maneira como fazem seu trabalho - o que seria verdade o suficiente. Pode ser o caso de deixá-los escolher qual sistema de gerenciamento de configuração usar melhoraria as coisas. Aqui estão algumas alternativas:

• RESPONSÁVEL : Isso é novo, mas é baseado em comandos do shell e ssh, que podem atraí-lo para os administradores de sistema tradicionais.
• Chef : Talvez o problema seja o estilo declarativo; nesse caso, o Chef seria melhor se eles tivessem experiência com Ruby.
• SaltStack : baseado em Python e de código aberto
• CFEngine : antigo, rápido, tradicional - pode conquistá-los com esses fundamentos.

Estou usando o Puppet há 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 corretamente. Não havia uma semana que eu não estraguei algo que eu disse aos desenvolvedores para não fazer uma dúzia de vezes. Verifiquei muito código, não quebrei os check-ins, não codifiquei, não ramifiquei, não executei o verificador de sintaxe, não usei um padrão etc. Se você está apenas começando Eu recomendaria alguns dos seguintes.

1. Perceba que você está desenvolvendo um software que você não sabe fazer ou está fazendo mal. Isso é esperado porque é novo.
2. A infraestrutura como código é a realidade e, uma vez superado o problema, é bastante poderoso. Convido alguns desenvolvedores, mostro a eles seu processo de desenvolvimento atual (ou a falta dele), não se ofenda quando levantam as sobrancelhas e leve a sério suas sugestões. Eu recomendo usar qualquer sistema e processo que seus desenvolvedores usem, a menos que seja completamente inapropriado.
3. Os módulos de bonecos de terceiros sugam 90% do tempo. Eu os li. Eu roubaria idéias deles. Eu não os colocaria no meu sistema sem grandes edições. No entanto, eu puxaria o fantoche stdlib, que adiciona algumas funcionalidades interessantes.
4. augeas e hiera. Aprenda esses dois. O primeiro permite a edição complexa de arquivos existentes. O segundo é um armazenamento de dados externo.
5. Separe o código dos dados. Este é um dos conceitos mais difíceis de aprender. Valores codificados como o Monitoring Hosts no código do módulo são ruins. Colocá-los em um armazenamento de dados (db, yaml (o Hiera usa isso como padrão), csv, qualquer que seja) que seus módulos possam consumir é bom. Um exemplo é um aplicativo da web que usa o Mysql. O que isso permite é a capacidade de enviar códigos e dados separadamente. Isso simplifica seu processo de desenvolvimento.
6. o analisador de marionetes valida e fiapos de marionetes como parte do processo de check-in pré ou pós-código. Os testes rspec também podem ser uma boa ideia quando você estiver em dia.
7. escreva um guia de estilo / padrão de código e use-o. "onde está o código que instala o Apache" é um problema comum. Se seus módulos são basicamente os mesmos, deve ser fácil.

Em resumo, eu enfrentei todos esses problemas e a maioria dos meus amigos do administrador de sistemas também. Levará algum tempo para ser bom em usar um sistema de gerenciamento de configurações. Depois de fazer isso, você se perguntará como viveu sem um. "Conecte-se a um servidor e faça alterações manualmente? Ick."

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

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

Desde que a decisão foi tomada, nossos funcionários de TI ficaram um pouco irritados e com muita frequência.

Eles precisam de um ajuste de atitude.

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

Mais uma vez, atitude. Você pode criar um arquivo conf para um servidor, certo? Você pode facilitar as coisas de modelagem / 'programador' à medida que suas necessidades e complexidade evoluem .

Módulos estão disponíveis online, mas muitos diferem entre si; as rodas estão sendo reinventadas com muita frequência; como você decide qual delas se encaixa na conta;

Difícil de responder - eu sempre prefiro os módulos do Puppetlabs ao invés da maioria - e mesmo assim, eu não uso tantos. Julgamento com certeza. Na minha opinião, alguns módulos são 'muito babados'.

O código em nosso repositório não é transparente o suficiente, para descobrir como algo funciona, eles precisam recursar por meio de manifestos e módulos que eles podem ter escrito por si mesmos há um tempo atrás;

Isso não parece um problema de marionetes, mas mais ainda um problema de organização ou documentação?

Um novo daemon requer a criação de um novo módulo; as convenções devem ser semelhantes a outros módulos, um processo difícil;

Esse daemon pode ser uma classe se for simples o suficiente para gerenciar. Não sei bem o que você quer dizer com convenções, fantoches impõem convenções muito bem a você, 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 é tão ruim assim se você a leva devagar e com segurança. Eu ainda começaria com uma VM para entender a essência das coisas.

Toneladas de 'extensões' pouco conhecidas nos módulos da comunidade: 'trocla', 'augeas', 'hiera' ... como nossos administradores de sistemas podem acompanhar?

módulos postfix, exim, sendmail, mysql, postgresql, iftop, iptraf, perl, perl .. Escolha o que deseja e use-o? Eu acho que isso soa mais como uma atitude novamente ...

Eu posso ver por que uma grande organização enviaria seus administradores de sistema para cursos de marionetes para se tornarem mestres de marionetes. Mas como os jogadores menores aprenderiam o Puppet a um nível profissional se não freqüentassem os cursos e o aprendessem basicamente através do navegador e do editor?

Eu não tenham frequentado qualquer curso - enquanto eu sou um programador mais do que um administrador de sistema, achei que não precisava de muita habilidade de programação para conseguir algo realizado.

A documentação do Puppet, quando seguida, é bastante completa. Preste atenção aos tipos internos e passe algum tempo observando como os outros módulos são reunidos. Eu não diria que é super fácil, mas também não é difícil. É um pouco demorado para preparar sua infraestrutura para marionetes, mas o tempo investido certamente será bem gasto quando você expandir.

BEIJO (mantenha as coisas simples estúpidas) - Não use novas tecnologias apenas porque elas existem, e sim porque você tem um requisito, use o mínimo necessário para sua implantação, atualize conforme necessário, não tente acompanhar o sangramento Beira. Se você começar com uma configuração básica e se basear nisso, é mais fácil captá-lo à medida que avança, e eles não precisam de um curso (eles estão disponíveis?).

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

Também trabalho para uma organização sem fins lucrativos e fui responsável por trazer inicialmente as caixas Linux para casa e, pouco depois, a Puppet por gerenciá-las. Temos feito algumas coisas específicas que realmente ajudaram a fazer as coisas rolarem.

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

Segundo, depois de padronizar o uso dos módulos embutidos, começamos a usar o Git e o Atlassian's Crisol - sem fins lucrativos, por sinal - para realizar revisões de todas as alterações de configuração. Isso fornece a transparência desejada.

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

"Não somos programadores, somos administradores de sistemas"

Como os tempos mudaram, para pior: esperava -se que um barbudo como eu fosse um programador melhor do que programadores profissionais, ou então nunca seria capaz de passar por um administrador de sistema .

Agora, temos "administradores de sistema", que são basicamente usuários de desktops do Windows que em algum momento se converteram no Linux e não podem programar, e não encontram nada de errado nisso.

O elefante na sala é o motivo pelo qual a administração tolera uma atitude tão destrutiva. Destrutivo para quem ou o quê? Para os negócios e para a infraestrutura.

Voltando ao assunto Puppet [, CFEngine, Chef]: assim que alguém coloca uma solução como essa, perde-se. Todo mundo perde. Por quê? Como quem cria a idéia não é capaz de projetar o gerenciamento de configuração encapsulado na forma de pacotes de sistema operacional agradáveis ​​e limpos, Kickstart [, JumpStart, Instalador Automatizado, AutoYaST, Ignite-UX, NIM]. Quando você precisa usar uma ferramenta de hacking automatizada como Puppet (ou Chef ou CFEngine), isso significa que você não tem os meios necessários para projetar e implementar um processo que, por esse mesmo design, imporia sistemas gerenciados completamente limpos e totalmente apagados , totalmente automatizado e completamente não interativo.

Outro ponto importante é que, se você precisar do Puppet ou alguma solução desse tipo para corrigir manualmente alguém que invadiu a configuração do sistema ou do aplicativo, isso também volta a não ter a experiência necessária para projetar um processo, e nesse processo uma estrutura em que a configuração é empacotada em componentes discretos. De fato, quem implementa o Puppet e similares, não tem conceito de proprietários de componentes, lançamentos, gerenciamento de configuração, Modelo de Maturidade de Capacidade. Isso está se transformando rapidamente em um problema muito sério no setor.

Trabalhar com o Puppet também me ajudou a aprender o Ruby, que substituiu o Bash como minha linguagem padrão de ferramentas do sistema. "

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

É uma sensação legal ver seu manifesto Puppet configurar uma máquina inteira ou um novo serviço do zero.

É uma coisa ainda mais bacana vê-lo feito pelo Kickstart, AutoYaST ou JumpStart, sem uma única linha de código , e poder consultar o sistema operacional usando ferramentas integradas, sem a necessidade de nenhum software esotérico ou extra , nenhum servidor cliente arquitetura necessária (o SSH é mais do que bom, muito mais do que bom) e ver o sistema operacional atento a todas as alterações feitas nele.

Código 5.Separate dos dados. Este é um dos conceitos mais difíceis de aprender. Valores codificados como o Monitoring Hosts no código do módulo são ruins. Colocá-los em um armazenamento de dados (db, yaml (o Hiera usa isso como padrão), csv, qualquer que seja) que seus módulos possam consumir é bom. Um exemplo é um aplicativo da web que usa o Mysql. O que isso permite é a capacidade de enviar códigos e dados separadamente. Isso simplifica seu processo de desenvolvimento.

... Ou você pode simplesmente modelar seus arquivos de configuração com variáveis ​​de shell, inclusive aspas posteriores (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 exatamente o mesmo poder analisador cujas conchas foram incorporadas. Por que torná-lo 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 em um banco de dados como Oracle, ou em praticamente qualquer lugar . Não há necessidade de soluções ultracomplexas. A biblioteca que eu mencionei acima pode simplesmente ser obtida nas seções de pré-instalação ou pós-instalação nos pacotes do sistema operacional, removendo assim a duplicação e aproveitando um pedaço de código central ...

Acima de tudo, porém, 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 sistema, mas por engenheiros de sistema . Encontre um barbeiro e entre como aprendiz.