Puppet in realtà si presta molto bene ad ambienti multi-master, con avvertimenti. Quello principale? Molte parti di Puppet amano essere centralizzate. L'autorità di certificazione, i servizi di inventario e dashboard / report, il filebucketing e le configurazioni memorizzate: sono tutti al loro meglio (o semplicemente richiedono) una configurazione in cui c'è solo un posto dove parlare.
È abbastanza fattibile, tuttavia, far funzionare molte di queste parti mobili in un ambiente multi-master, se stai bene con la perdita graziosa di alcune funzionalità quando hai perso il tuo sito principale.
Cominciamo con la funzionalità di base per ottenere un nodo che riporta a un master:
Moduli e manifesti
Questa parte è semplice. La versione li controlla. Se si tratta di un sistema di controllo della versione distribuita, è sufficiente centralizzare e sincronizzare e modificare il flusso push / pull secondo necessità nel sito di failover. Se è Subversion, probabilmente vorrai svnsyncil repository sul tuo sito di failover.
Autorità di certificazione
Un'opzione qui è semplicemente sincronizzare i file dell'autorità di certificazione tra i master, in modo che tutti condividano lo stesso certificato root e siano in grado di firmare i certificati. Questo mi ha sempre colpito come "sbagliare";
- Un master dovrebbe davvero vedere valido il proprio certificato presentato nell'autenticazione client per una connessione in entrata da un altro master?
- Funzionerà in modo affidabile per il servizio di inventario, dashboard, ecc.?
- Come si aggiungono ulteriori nomi alt DNS validi lungo la strada?
Onestamente non posso dire di aver fatto test approfonditi di questa opzione, dal momento che sembra orribile. Tuttavia, sembra che Puppet Labs non stia cercando di incoraggiare questa opzione, come indicato nella nota qui .
Quindi, ciò che rimane è avere un master CA centrale. Tutte le relazioni di trust rimangono attive quando la CA è inattiva poiché tutti i client e gli altri master memorizzano nella cache il certificato CA e il CRL (sebbene non aggiornino il CRL tutte le volte che dovrebbero), ma non sarà possibile firmare nuovi certificati fino a quando si ottiene il backup del sito primario o si ripristina il master CA dai backup nel sito di failover.
Sceglierai un master che fungerà da CA e che tutti gli altri master lo disabiliteranno:
[main]
ca_server = puppet-ca.example.com
[master]
ca = false
Quindi, vorrai che il sistema centrale ottenga tutto il traffico relativo al certificato. Ci sono alcune opzioni per questo;
- Utilizzare il nuovo
SRVsupporto per i record in 3.0 per indirizzare tutti i nodi agente nella posizione corretta per la CA:_x-puppet-ca._tcp.example.com
- Imposta l'
ca_serveropzione di configurazione in puppet.conftutti gli agenti
Proxy di tutto il traffico per le richieste relative alla CA dagli agenti al master corretto. Ad esempio, se esegui tutti i tuoi master in Apache tramite Passenger, configuralo sui non-CA:
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 così dovrebbe andare.
Prima di passare ai servizi ausiliari, una nota a margine;
Nomi DNS per certificati master
Penso che questo qui sia il motivo più convincente per passare alla 3.0. Supponiamo che tu voglia puntare un nodo su "qualsiasi vecchio maestro funzionante".
Sotto 2.7, avresti bisogno di un nome DNS generico come puppet.example.com, e tutti i master ne hanno bisogno nel loro certificato. Ciò significa impostare dns_alt_namesnella loro configurazione, riemettere il certificato che avevano prima di essere configurato come master, emettere nuovamente il certificato quando è necessario aggiungere un nuovo nome DNS all'elenco (come se si volessero più nomi DNS per gli agenti preferiscono i padroni nel loro sito) .. brutti.
Con 3.0, puoi usare i SRVrecord. Dai a tutti i tuoi clienti questo;
[main]
use_srv_records = true
srv_domain = example.com
Quindi, non sono necessari certificati speciali per i maestri: basta aggiungere un nuovo record al tuo SRVRR _x-puppet._tcp.example.come sei pronto, è un maestro dal vivo nel gruppo. Meglio ancora, puoi facilmente rendere più sofisticata la logica di selezione principale; "qualsiasi vecchio master funzionante, ma preferisci quello nel tuo sito" impostando diversi set di SRVrecord per siti diversi; non dns_alt_namesnecessario.
Rapporti / Dashboard
Questo funziona meglio centralizzato, ma se puoi vivere senza di esso quando il tuo sito principale è inattivo, allora nessun problema. Basta configurare tutti i tuoi master con il posto giusto per mettere i rapporti.
[master]
reports = http
reporturl = https://puppetdash.example.com/reports/upload
..e sei pronto. Il mancato caricamento di un report non è fatale per l'esecuzione della configurazione; andrà semplicemente perso se il server del dashboard brinda.
Inventario dei fatti
Un'altra cosa interessante da incollare nella tua dashboard è il servizio di inventario. Se facts_terminusimpostato su restcome consigliato nella documentazione, questo interromperà effettivamente l'esecuzione della configurazione quando il servizio di inventario centrale è inattivo. Il trucco qui è usare il inventory_servicecapolinea sui maestri non centrali, che consente un grazioso fallimento.
facts_terminus = inventory_service
inventory_server = puppet-ca.example.com
inventory_port = 8140
Avere il server di inventario centrale impostato per archiviare i dati di inventario tramite ActiveRecord o PuppetDB e dovrebbe essere aggiornato ogni volta che il servizio è disponibile.
Quindi - se stai bene con un ambiente di gestione della configurazione piuttosto barebone in cui non puoi nemmeno usare la CA per firmare il certificato di un nuovo nodo fino a quando non viene ripristinato, allora questo può funzionare bene - anche se sarebbe davvero bello se alcuni di questi componenti fossero un po 'più facili da distribuire .