Prós e contras de uma arquitetura de marionetes descentralizada

14

Atualmente, temos cerca de 300 servidores RHEL conectados a um servidor Puppetmaster. No entanto, observamos alguns gargalos de desempenho e é o ponto de falha em nosso sistema. Eu sou bastante novo no Puppet em geral e estou pensando em criar uma arquitetura de fantoche descentralizada em vez de ter clientes Puppet conectados ao servidor Puppetmaster. Além do que eu suspeitaria que acontecesse, como ganho de desempenho e falta de assinatura e troca de certificados SSL por novas máquinas, quais são os outros prós e contras na configuração de uma arquitetura descentralizada?

redhat puppet puppetmaster

— JMeterX
fonte

3

Existe uma razão para que tenha que ser de um jeito ou de outro? Você já considerou opções em algum lugar? Com tantos servidores e uma preocupação com um único ponto de falha, por que você não configurou mestres adicionais? A configuração de vários servidores fantoches com balanceamento de carga é abordada no livro 'Pro Puppet'. Há muita flexibilidade, deve ser possível configurar uma hierarquia de servidores fantoches, se isso fizer sentido.

— Zoredache

@ Zoredache Realmente não há uma razão para que isso tenha que ser de uma maneira ou de outra, eu estava procurando mais informações sobre uma arquitetura descentralizada em geral para ajudar a facilitar a decisão. Eu considerei mestres adicionais, mas o principal da idéia, que peço desculpas por não mencionar, é reduzir a contagem de servidores, uma vez que afeta diretamente nosso orçamento. Concordo que o balanceamento de carga dos servidores fantoches faz sentido, mas se eu conseguir me livrar de um servidor todos juntos, essa seria a melhor solução.

— JMeterX

7

Vá descentralizado.

Em vez de assinar certificados, faça chaves ssh. Não dê as chaves para não administradores

Você pode usar o Git como seu transporte em vez de subversão e, em seguida, pode ramificar para diferentes máquinas / funções e, em seguida, versão suas alterações, bem como permitir ... mas você deve conhecer o discurso do DVCS neste momento.

É mais rápido e menos complicado de configurar. Adicione alguns ganchos de confirmação para verificação de integridade.

Agora, nesse ponto, você substituiu o puppetmaster, por seu modelo cliente-servidor, por ssh e git, ambos com melhor escala que o puppetmaster.

Agora, pode haver uma necessidade em sua organização de hierarquia. Não tem problema, basta armazenar o repositório git que contém o ramo definitivo em algum lugar seguro.

Bônus:

git blame

permitirá que você veja quem fez uma alteração.

http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control

https://www.braintreepayments.com/braintrust/decentralize-your-devops-with-masterless-puppet-and-supply-drop ?

— chiggsy
fonte

3

Você está executando fantoches em passageiros? configurações armazenadas? Você realmente não deve ter problemas de escalabilidade com 300 nós, desde que lide com problemas básicos de configuração.

— czervik
fonte

1

Estamos usando a configuração do Apache + Passenger. Também estamos usando o subversion para enviar as alterações para o Puppetmaster

— JMeterX 17/07/12

1

Descentralizado é o melhor caminho a percorrer, pois cada cliente compila seu próprio manifesto a partir de uma cópia local da fonte do manifesto. Isso é atualizado sempre que você envia atualizações do servidor say git. Uso muito mais eficiente da largura de banda, pois os clientes não precisam entrar em contato com o puppetmaster a cada corrida. Também elimina pontos únicos de falha, pois os clientes podem ser atualizados de qualquer lugar.

— What'sTheStoryWishBone
fonte