Chef / Puppet com vários servidores de configuração

Question

O Puppet ou Chef suporta servidores puppetmasterd / Chef replicados? Parece muito surpreendente para mim que essas ferramentas forcem um único ponto de falha, mas não consegui encontrar nenhuma menção disso em seus documentos ou no Google.

Eu sei que Puppet e Chef podem ser executados sem um servidor (possivelmente atualizado com, eg, git como descrito em link ), mas isso parece um cidadão de segunda classe e, presumivelmente, perde alguma capacidade de monitoramento.

    

Answer 1

Para fantoches, você precisaria

1. Manifestos idênticos. Isso pode ser feito com mantendo seus manifestos no controle de versão e verificando-os em cada servidor, o que você deve estar fazendo assim mesmo.
2. Um único banco de dados para configuração armazenada , se você usá-lo. Isso é tão simples quanto mudar do padrão sqlite para MySQL ou PostgreSQL. Você poderia então usar as ferramentas desse banco de dados para replicar o banco de dados, se desejado.
3. Certificados da mesma autoridade de certificação em todos os mestres de fantoches. Dan Bode tem a melhor explicação que já vi. No entanto, pode não funcionar da maneira esperada. Além disso, não tenho certeza de como isso funciona com certificados de cliente (por exemplo, / var / lib / puppet / ssl / ca / signed / * ). Talvez a sua verificação seja sempre tratada pela CA única (introduzindo um único ponto de falha), ou talvez os arquivos pem sejam distribuídos para cada mestre de fantoches depois de assinados pela CA.

Answer 2

O Chef foi projetado desde o início para ser executado com vários servidores, para todos os seus componentes de back-end, pois esse é um recurso principal da Opscode Platform - um Chef Server altamente escalável.

Os vários componentes principais do Chef Server:

• servidor de API
• Armazenamento de dados (CouchDB)
• Mecanismo de pesquisa (SOLR)

Assim, cada um desses componentes é capaz de funcionar em servidores separados, e o Chef pode ser configurado para usar servidores separados para cada componente. Para obter informações sobre configuração, consulte a página Configurações do Chef . Primeiramente, as configurações couchdb_url e solr_url podem apontar para um servidor (ou servidores) separado executando esses componentes ou um balanceador de carga parado na frente deles.

A API do Chef Server também precisará de acesso aos livros de culinária, que podem estar em um sistema de arquivos compartilhado.

    

Answer 3

Se você está preocupado com um único ponto de falha, crie um cluster de fantoches:)

1. Crie um cluster com corosync/pacemaker (ou pulsação da velha escola), torne-o ativo / passivo ou até ativo / ativo
2. Obtenha os dois (ou mais) dados importantes do servidor duplicados com o DRBD ou outro método
3. Lucro!

Os clientes de fantoches obtêm seus manifestos do servidor de fantoches identificado pelo DNS (a menos que você especifique um servidor no cliente, mas isso não é muito bom), então você tem muitas maneiras de garantir que nunca ficará sem um servidor, um cluster ativo / passivo em que o passivo obtém o endereço IP se o ativo falhar ou até mesmo alterar a entrada DNS para um novo servidor em caso de falha (a primeira opção é a mais elegante).

Um ótimo recurso para clusters nesses dias é o documento Cluster from Scratch de clusterlabs . O guia inclui exemplos de configuração do DRBD, então é muito prático.