Puppetize tudo ou não?

Question

Aviso: há muitas questões teóricas.

Recentemente, estou lendo sobre o Puppet (e sistemas similares), o que, como acredito, pode facilitar muito o meu trabalho. Mas eu tento - e infelizmente não consigo - entender o que tudo eu posso "fantocalizar". Eu posso imaginar "nuvens" ou clusters de HA, onde está a mesma configuração em mais servidores. Mas e as estações de trabalho? Eu tenho um pc (centos com kvm), um notebook (fedora) e servidor pessoal, posso (ou devo) ser fantocalizado? Quais são (des) vantagens? Ou em nossa empresa temos centenas de servidores (principalmente com centos), mas cada um deles é um pouco diferente. Não é possível decidir se é melhor ter muitas configurações em um único lugar. (Des) vantagens? Ficarei feliz por todas as suas opiniões ou links com este tópico.

    

Answer 1

O grau em que você pode fantocalizar um ambiente inteiro depende de várias variáveis:

• A disposição da equipe de automação de escrever automação para todos. pequeno. coisa.
• O condicionamento cultural que permite "Eu vou apenas mudar essa coisa, é uma coisa única de qualquer maneira" para transformar em "Eu vou apenas mudar essa coisa neste manifesto de marionete, e aplicá-la agora; é apenas uma único. "
• O grau de heterogeneidade em um ambiente.

É definitivamente possível fazer uma marionete em cada coisa que pode ser manipulada, mas chegar lá requer a cultura e a aceitação de todos que podem tocar em um dispositivo capaz de fazer fantoches. Alguns dispositivos são fundamentalmente difíceis de gerenciar dessa maneira, coisas como estações de trabalho, e o fantoche é melhor como uma ferramenta de teste do que um mecanismo de gerenciamento de configuração.

O Puppet é incrível quando você gerencia uma frota de VMs, fazendo basicamente a mesma coisa. Vitória total e não muito esforço para chegar lá.

No outro extremo do espectro, você tem o que eu tinha no meu último emprego, que era de mais de 200 servidores fornecendo 130 serviços e apenas um pequeno grupo deles fazia isso com mais de uma máquina. Existem absolutamente empresas (e universidades) que realizaram esse tipo de coisa, mas é muito trabalhoso e exige muito buy-in. Isso requer que o primeiro passo do seu processo de implementação de nova máquina não seja "Instalar o SO", mas "criar manifestos".

Em última análise, é uma questão cultural de esforço versus eficiência que você terá que resolver entre toda a sua equipe de TI.

    

Answer 2

Qualquer coisa que seja razoavelmente semelhante em todos os sistemas (ou um subconjunto deles), ou que você possa basear um modelo em um fato que você pode tirar de facter é um jogo justo.

Coisas que são realmente únicas, você provavelmente não deveria se incomodar, e deveria apenas servir as configurações de um filebucket.

O que cai em qualquer categoria é uma decisão que não podemos tomar sem conhecer o seu ambiente intimamente, então é para você descobrir.

    

Answer 3

Eu acho que os outros cobriram o porquê, então eu vou dar um tiro no como. Acho que, ao entender como alguém pode usar o Puppet para fazer o que você quer, isso tornará a decisão mais clara.

Faça o caso básico primeiro

Seu módulo Puppet para o Apache não deve fazer muito por padrão. Instale o Apache, configure-o em um padrão mínimo e inicie o serviço. Faça este trabalho em todas as distros que você precisa apoiar.

Adicione segunda flexibilidade

Precisamos adicionar vhosts. Você vai acabar com um sistema que pode soltar arquivos ou removê-los de um conjunto de diretórios conf.d ou vhosts.d / de acordo com o que você precisa. Mesma coisa com a ativação ou configuração de módulos.

Use as classes de função ou de grupo de host para unir seus blocos de construção

Acho que a melhor maneira de usar o Puppet é ter certeza de que é aditivo. Usando os exemplos acima, devemos ter um módulo que faça

1. Instalar o Apache
2. Definir configurações básicas
3. Adicionar vhosts ao apache
4. Configure qualquer configuração extra
5. Iniciar o Apache

Em vez de sobrecarregar nosso módulo padrão do Apache para fazer exatamente o que precisamos para um determinado host ou grupo, devemos lidar com isso como uma função ou classe de grupo de host.

class role::web_cust1 {
  include apache
  apache::vhost {'www.domain.com': }
  apache::vhost {'www.domain2.com': priority => '99', }
  include php
  include php-fpm
  include mysql
}

Novamente aditivo.

Colocar casos especiais em Hiera

Sou um grande fã de deixar o Puppet's Hiera, pensar nele como um banco de dados para o Puppet, armazenar os bits especiais. Se um determinado host ou grupo de host precisar de uma configuração especial, primeiro insira um padrão sã no módulo para que os usuários normais não precisem saber disso. Em seguida, insira dados para esses hosts especiais ou grupos de host para que o Hiera possa consumi-los para o Puppet, conforme necessário.

Meu caso de uso é porta de escuta. Alguns servidores têm um verniz ou haproxy na frente deles. Por padrão, o módulo Puppet faz com que o Apache use a porta 80, mas, se o Hiera encontrar dados, ele substituirá esse padrão.

    

Answer 4

Atualmente estou na transição entre Puppetize sistemas razoavelmente semelhantes para Puppetize tudo e estou convencido de que a longo prazo, Puppetize tudo é uma abordagem melhor.

Se a sua versão controlar seus manifestos Puppet (todos nós fazemos isso, certo), você obtém todos os benefícios do controle de versão para sua infraestrutura. Sua equipe se torna engenheiros de operações. Isso é tão importante para sistemas especiais e únicos quanto fazendas de gado homogêneas. Você recebe um registro de quem mudou alguma coisa, quando a alterou, qual foi a alteração exata e a capacidade de reverter a alteração.

Pessoalmente, também acho que me forçar a fazer todas as mudanças através do Puppet me faz pensar com mais cuidado sobre a mudança. Como estou escrevendo manifestos, estou mais atento a cada mudança do que normalmente estou hackeando na linha de comando.

Seus módulos de marionetes também se tornarão melhores. Você tem mais de um módulo Nginx? Talvez isso signifique que o seu módulo Nginx não é tão bom, e você precisa torná-lo flexível o suficiente para lidar com todas as suas necessidades especiais. Pelo menos, abstrair as semelhanças em um módulo Nginx principal que você estende para módulos "personalizados".

Além disso, qual a sua confiança de poder restaurar todos os seus servidores de necessidades especiais ao estado atual (em relação à configuração) quando o desastre acontece? Se cada mudança necessária para obter um servidor Ubuntu de fábrica em seu wiki interno for Puppetized, você poderá reconstruir facilmente o estado atual do seu wiki, o Tweak de memória do Tomcat de ontem incluído por Bob.

Finalmente, isso pode ser muito difícil. Gerenciar muitos servidores diferentes pode levar a algum código fantoche hacktastic se você não tiver tempo para fazer as coisas direito. Se você não estiver usando o Puppet Enterprise, considere hiera e / ou um ENC, como o Foreman, para ajudar a separar seus dados de seus manifestos. Sempre dia Puppetize outra coisa. Peça a um colega de trabalho que explique como isso funciona no Puppet. Cada alteração será mais fácil.