O Puppet realmente se presta muito bem a ambientes com vários mestres, com ressalvas. O principal? Muitas partes do Puppet gostam de ser centralizadas. A autoridade de certificação, os serviços de inventário e painel / relatório, a coleta de arquivos e as configurações armazenadas - todas estão no seu melhor (ou simplesmente exigem) uma configuração em que há apenas um lugar para conversar.
No entanto, é bastante viável fazer com que muitas dessas partes móveis funcionem em um ambiente multimestre, se você concorda com a perda graciosa de algumas das funcionalidades quando perde o site principal.
Vamos começar com a funcionalidade básica para obter um relatório de nó para um mestre:
Módulos e Manifestos
Esta parte é simples. Versão controlá-los. Se for um sistema de controle de versão distribuído, centralize e sincronize, e altere o fluxo push / pull conforme necessário no site de failover. Se for o Subversion, você provavelmente desejará svnsynco repo no seu site de failover.
Autoridade de Certificação
Uma opção aqui é simplesmente sincronizar os arquivos da autoridade de certificação entre os mestres, para que todos compartilhem o mesmo certificado raiz e sejam capazes de assinar certificados. Isso sempre me pareceu "fazer errado";
- Um mestre deve realmente ver seu próprio certificado apresentado na autenticação do cliente para uma conexão de entrada de outro mestre como válida?
- Isso funcionará de forma confiável para o serviço de inventário, painel, etc?
- Como você adiciona nomes alternativos de DNS válidos adicionais no caminho?
Não posso dizer honestamente que fiz testes completos dessa opção, pois parece horrível. No entanto, parece que o Puppet Labs não está buscando incentivar essa opção, conforme a nota aqui .
Então, o que resta é ter um mestre da CA central. Todas as relações de confiança permanecem funcionando quando a CA está inativa, pois todos os clientes e outros mestres armazenam em cache o certificado da CA e a CRL (embora não atualizem a CRL com a frequência que deveriam), mas não será possível assinar novos certificados até você faz o backup do site primário ou restaura o mestre da CA a partir de backups no site de failover.
Você escolherá um mestre para atuar como CA e terá todos os outros mestres desativados:
[main]
ca_server = puppet-ca.example.com
[master]
ca = false
Então, você deseja que esse sistema central obtenha todo o tráfego relacionado ao certificado. Existem algumas opções para isso;
- Use o novo
SRVsuporte de registro no 3.0 para apontar todos os nós do agente para o local certo para a CA -_x-puppet-ca._tcp.example.com
- Configure a
ca_serveropção de configuração em puppet.conftodos os agentes
Proxy todo o tráfego de solicitações relacionadas a CA dos agentes para o mestre correto. Por exemplo, se você estiver executando todos os seus mestres no Apache via Passenger, configure isso nas não CAs:
SSLProxyEngine On
# Proxy on to the CA.
ProxyPassMatch ^/([^/]+/certificate.*)$ https://puppet-ca.example.com:8140/$1
# Caveat: /certificate_revocation_list requires authentication by default,
# which will be lost when proxying. You'll want to alter your CA's auth.conf
# to allow those requests from any device; the CRL isn't sensitive.
E isso deveria bastar.
Antes de prosseguirmos para os serviços auxiliares, uma nota lateral;
Nomes DNS para certificados principais
Penso que esta é a razão mais convincente para mudar para a 3.0. Digamos que você queira apontar um nó para "qualquer outro mestre de trabalho".
Em 2.7, você precisaria de um nome DNS genérico como puppet.example.com, e todos os mestres precisam disso em seus certificados. Isso significa definir dns_alt_namesem sua configuração, reemitir o certificado que eles possuíam antes de serem configurados como mestre, reemitir o certificado novamente quando você precisar adicionar um novo nome DNS à lista (como se você quisesse vários nomes DNS). agentes preferem mestres em seu site) .. feia.
Com o 3.0, você pode usar SRVregistros. Dê a todos os seus clientes isso;
[main]
use_srv_records = true
srv_domain = example.com
Então, não são necessários certificados especiais para os mestres - basta adicionar um novo registro ao seu SRVRR em _x-puppet._tcp.example.come pronto, é um mestre ao vivo no grupo. Melhor ainda, você pode facilmente tornar a lógica da seleção principal mais sofisticada; "qualquer mestre de trabalho antigo, mas prefira o do seu site", configurando conjuntos de SRVregistros diferentes para sites diferentes; não é dns_alt_namesnecessário.
Relatórios / Painel
Este funciona melhor centralizado, mas se você pode viver sem ele quando o site principal está inativo, então não há problema. Basta configurar todos os seus mestres com o local correto para colocar os relatórios.
[master]
reports = http
reporturl = https://puppetdash.example.com/reports/upload
..e está tudo pronto. A falha no upload de um relatório não é fatal para a execução da configuração; apenas será perdido se o servidor do painel brindar.
Inventário de fatos
Outra coisa interessante a ser colada no painel é o serviço de inventário. Com o facts_terminusconjunto restconforme recomendado na documentação, isso realmente interromperá a configuração quando o serviço central de inventário estiver inoperante. O truque aqui é usar o inventory_serviceterminal nos mestres não centrais, o que permite falhas graciosas.
facts_terminus = inventory_service
inventory_server = puppet-ca.example.com
inventory_port = 8140
Configure seu servidor de inventário central para armazenar os dados de inventário por meio do ActiveRecord ou do PuppetDB e mantenha-se atualizado sempre que o serviço estiver disponível.
Portanto, se você estiver de acordo com um ambiente de gerenciamento de configurações bastante barebones, no qual não pode nem usar a CA para assinar um novo certificado de nó até que seja restaurado, isso pode funcionar muito bem - embora seja muito bom se alguns desses componentes fossem um pouco mais amigáveis para serem distribuídos .