O que NÃO deve ser gerenciado por fantoches?

Estou aprendendo o meu caminho através do gerenciamento de configuração em geral e usando o puppet para implementá-lo em particular, e estou imaginando que aspectos de um sistema, se houver, não devem ser gerenciados com o puppet?

Como exemplo, geralmente tomamos por garantido que os nomes de host já estão configurados antes de emprestar o sistema ao gerenciamento de marionetes. A conectividade IP básica, pelo menos na rede usada para acessar o puppetmaster, deve estar funcionando. Usar o fantoche para criar automaticamente arquivos de zona DNS é tentador, mas os ponteiros reversos do DNS já devem estar no local antes de iniciar a coisa ou os certificados serão engraçados.

Então, devo deixar de fora a configuração IP do fantoche? Ou devo configurá-lo antes de iniciar o fantoche pela primeira vez, mas gerenciar os endereços IP com o fantoche? E os sistemas com vários IPs (por exemplo, para WAN, LAN e SAN)?

E o IPMI ? Você pode configurar a maior parte, se não todas, com o ipmitool , evitando que você obtenha acesso ao console (físico, serial-over-lan, KVM remoto, qualquer que seja) para que possa ser automatizado com o fantoche. Mas verificar novamente seu estado a cada execução de agente fantoche não me parece legal, e o acesso básico ao sistema é algo que eu gostaria de ter antes de fazer qualquer outra coisa.

Outra história completa é sobre a instalação de atualizações. Não vou neste ponto específico, já existem muitas perguntas sobre SF e muitas filosofias diferentes entre diferentes administradores de sistemas. Decidi não permitir que o marionete atualize as coisas (apenas. Por exemplo ensure => installed) e faça as atualizações manualmente como já estamos acostumados, deixando a automação dessa tarefa para um dia posterior, quando estivermos mais confiantes com o marionete (por exemplo, adicionando MCollective ao A mistura).

Esses foram apenas alguns exemplos que tenho agora em mente. Existe algum aspecto do sistema que deve ser deixado de fora do alcance das marionetes? Ou, dito de outra forma, onde está a linha entre o que deve ser definido no momento do provisionamento e o "estaticamente" configurado no sistema e o que é tratado pelo gerenciamento centralizado de configurações?

Regra geral: se você estiver usando o gerenciamento de configuração, gerencie todos os aspectos da configuração que puder. Quanto mais você centralizar, mais fácil será dimensionar seu ambiente.

Exemplos específicos (extraídos da pergunta, todas as narrativas "É por isso que você deseja gerenciá-la"):

Configuração de rede IP

OK, claro, você configurou um endereço / gateway / NS na máquina antes de colocá-lo no rack. Quero dizer, se você não fez, como você executaria o fantoche para fazer o resto da configuração?

Mas digamos que agora você adiciona outro servidor de nomes ao seu ambiente e precisa atualizar todas as suas máquinas - Você não deseja que seu sistema de gerenciamento de configuração faça isso por você?

Ou diga que sua empresa é adquirida e sua nova empresa-mãe exige que você mude do endereço 192.168.0.0/24 para 10.11.12.0/24 para se ajustar ao sistema de numeração deles.

Ou, de repente, você obtém um contrato governamental massivo - A única vantagem é que você precisa ativar o IPv6 RIGHT FREAKIN 'NOW ou o negócio está fechado ....

Parece que a configuração de rede é algo que gostaríamos de gerenciar ...

Configuração IPMI

Assim como nos endereços IP, tenho certeza de que você configurou isso antes de colocar a máquina no rack - é apenas bom senso habilitar IPMI, console remoto etc. em qualquer máquina com capacidade e essas configurações não mude muito ...

... Até a aquisição hipotética que mencionei na Configuração de IP acima - O motivo pelo qual você foi forçado a desocupar esses endereços de rede 192.168 é porque é IPMI-land de acordo com seus novos overlords corporativos e você precisa atualizar todos os seus cartões IPMI AGORA, porque eles vão pisar no espaço IP reservado de alguém.

OK, é um pouco exagerado aqui, mas como você disse - tudo pode ser gerenciado ipmitool, então por que não o Puppet executa a ferramenta e confirma a configuração enquanto faz todas as outras coisas? Quero dizer, não vai doer nada, então podemos incluir o IPMI também ...

Atualizações

As atualizações de software são mais uma área cinzenta - em minha organização, avaliamos o fantoche para isso e o achamos "extremamente ausente"; portanto, usamos radmindpara esse fim. Não há nenhuma razão para o Puppet não poder chamar radmind - na verdade, se / quando migrarmos para o Puppet para gerenciamento de configurações, é exatamente isso que vai acontecer!

O importante aqui é ter todas as suas atualizações instaladas de maneira padrão (padrão em toda a organização ou padrão em plataformas) - Não há motivo para o Puppet não iniciar o processo de atualização, desde que você tenha testado minuciosamente tudo para garantir que o Puppet não estrague nada.
Também não há razão para que o Puppet não possa chamar uma ferramenta mais adequada para esta tarefa se você determinou que o Puppet não pode fazer um bom trabalho por conta própria ...

Não reinvente a roda.

Sim, você pode ter 50 recursos fantásticos de usuário virtual e realizá-los conforme necessário em seus módulos ... mas, se puder, use LDAP.

Falo por experiência amarga. Embora o ldap ainda não seja uma opção aqui.

Outro exemplo é enviar arquivos de hosts, em vez de apenas usar DNS.

• Puppet não é um sistema de orquestração. Em particular:
  • O Puppet não é adequado para a orquestração de VMs, pois as VMs têm um ciclo de vida próprio que deve ser respeitado.
  • O Puppet não é adequado para o gerenciamento de liberação de aplicativos / atualizações complexas. Execuções autônomas de fantoches podem ser exploradas para isso, mas, pelo menos, não está o Puppet no controle, mas seus scripts de invólucro ou um robô humano, o que é bom.
• O Puppet não é um bom sistema de gerenciamento de usuários (ele precisa gerenciar todas as entradas de usuários, mesmo os usuários excluídos, para ser eficaz. Portanto, encontre outra solução)
• O Puppet não é um bom banco de dados de configuração (veja como usar um banco de dados externo de algum tipo e uma ENC, Hiera ou cola similar)

Claro que você pode fazer todas essas coisas com o Puppet .. mas simplesmente não é a melhor solução para elas. Às vezes, você deve largar o martelo e procurar uma chave inglesa.

No entanto, o Puppet é extremamente bom em manter a configuração básica de uma máquina e instalar as ferramentas que permitem fazer VM e liberar orquestração, gerenciamento de usuários etc.

Eu concordo principalmente com o voretaq7, mas com algumas ressalvas.

• Eu raramente configuro o endereçamento IP no fantoche, a menos que o sistema use DHCP (presumo que a maioria dos grandes provedores de "nuvem" faça isso). Eu tive situações em que quebrei configurações de rede com o fantoche, mas não consegui corrigi-las com o fantoche, porque o nó não tinha como entrar em contato com o puppetmaster.

• Estou bastante convencido de que o gerenciamento de atualizações está nas mãos das ferramentas do sistema, e não vejo o uso do puppet como um cron glorificado para melhorar.

No meu caso, eu tenho um script de bootstrap que carrega a configuração mínima do sistema (Ubuntu): Ruby, Rubygems, essencial para compilação, git, etc. Meus manifestos do Puppet são mantidos sob controle de versão e simplesmente clono o repositório. A partir daí, meu script de autoinicialização supõe que hostname --shorté válido e tenta puppet apply /root/infrastructure/puppet/hosts/$( hostname --short ).pp.

Para responder sua pergunta:

• Meus scripts assumem a conectividade básica de rede (DNS, IP) e não a gerenciam nem a alteram;
• Meus scripts assumem que a identidade da máquina está correta e não a altera;
• Meus scripts assumem que Ruby / Rubygems / Git está presente, mas eles são gerenciados posteriormente.

Pense que você não precisa usar fantoches para configuração de rede. É uma vez uma coisa configurada normalmente. Além disso, você pode obter alguma porcaria se você tiver um erro com IP ou MAC ou algo semelhante que o boneco trará.