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.
puppetd -tpara testar algumas caixas antes de enviar para todos os servidores. Nunca falha que um casal tenha algo único que cause falhas nas minhas atualizações. O Puppet é muito mais fácil quando você tem um ambiente controlado e consistente desde o início.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:
fonte
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.
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."
fonte
Parece uma boa idéia começar cedo - o Puppet é mais do que apenas gerenciamento de configurações, é uma forma de documentação.
Eles precisam de um ajuste de atitude.
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 .
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'.
Isso não parece um problema de marionetes, mas mais ainda um problema de organização ou documentação?
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?
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.
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 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.
fonte
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?
fonte
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á.
fonte
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.
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 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.
... 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.
fonte