Gestione delle marionette globale vs locale

8

Qualcuno ha mai gestito diversi sistemi geograficamente distribuiti con Puppet?

Ho diverse distribuzioni quasi esattamente simili (tranne gli IP del server), che gestione sto cercando di convertire in Puppet.

Ho 2 opzioni:

Avere ogni distribuzione per ospitare il proprio PuppetMaster per fornire configurazioni locali, quindi sincronizzare in qualche modo i PuppetMaster (forse di nuovo con PuppetMaster)
Ospita PuppetMaster su AWS EC2 per l'alta disponibilità e fornisci configurazioni a tutte le implementazioni da un unico punto

Qualcuno ha provato la seconda opzione e come ha funzionato? Sono particolarmente interessato alle prestazioni ad alta disponibilità in tale ambiente.

Grazie.

puppet

— SyRenity
fonte

7

Non c'è niente di sbagliato in nessuno dei due approcci che proponi. Abbiamo tre burattinai, tutti situati in un unico sito e che servono nodi in tutto il mondo - li separiamo in base al fatto che il nodo fantoccio di connessione sia in dev / test / prod. Altre persone preferiscono gestire un burattinaio per regione geografica. Altre persone hanno molti burattinai, alcuni gestiscono solo un nodo!

La cosa fondamentale è che è fondamentale archiviare e gestire l'albero manifest di Puppetmaster in un sistema di controllo della versione: trattalo come qualsiasi altro codice gestito dalla tua azienda. Consiglierei Git, ma Subversion farà anche il trucco se sei più abituato. Il burattinaio è semplicemente un servizio che offre la sua visione particolare del tuo VCS, piuttosto che essere un database centrale stesso.

Con i tuoi contenuti in un VCS, puoi quindi distribuire i manifest / moduli richiesti ai rispettivi burattinai e mantenerli facilmente sincronizzati. La convenzione sembra essere per le persone che hanno un repository git / svn / modulo per modulo fantoccio, anche se non c'è niente che ti impedisce di mettere l'intero albero sotto un repository / modulo.

Le mie domande per te sarebbero:

Quanti nodi ci sono in ogni distribuzione? Se stai parlando di 50+, varrebbe sicuramente la pena avere un burattinaio locale di sicuro.
Le implementazioni hanno terze parti che le usano oltre alla tua azienda? Il burattinaio deve avere una sicurezza molto elevata: considera le chiavi della porta di tutti i tuoi sistemi e conterrà informazioni molto sensibili.
Allo stesso modo, per i PM basati sulla distribuzione, li ospitereste sul proprio server / VM o sarebbe necessario assegnare un compito a una macchina esistente? Consiglio vivamente che il server fantoccio abbia quel ruolo da solo, per sicurezza.
Come pensi che EC2 ti offrirà una maggiore disponibilità? Da quanto ho capito, le istanze EC2 non sono HA, anche se dovrebbe essere possibile eseguire 2+ burattinai dietro il servizio di bilanciamento del carico AWS.
Le distribuzioni sono molto diverse? Vuoi cambiarli in diversi momenti della giornata? Più burattinai ti offrono un livello di controllo più preciso.

— Mike Pountney
fonte

1

Ciao. Parliamo di 10-20 nodi al massimo in ogni distribuzione, le distribuzioni sono in tutto il mondo. Non sono consentite terze parti all'interno delle distribuzioni. In realtà sono interessato a concentrare tutti i dati relativi a Puppet su una macchina dedicata, quindi il PM sarebbe ospitato sull'istanza EC2. Probabilmente userò Heartbeat + DRBD per l'HA. Le distribuzioni sono sostanzialmente le stesse appliance, come detto solo l'IP del server è diverso. Grazie ancora.

— SyRenity,

Sembra proprio che un cluster di burattinai in EC2 probabilmente farà il trucco per te. Assicurati solo di usare Git o Subversion per archiviare i tuoi manifest in modo sicuro :)

— Mike Pountney,

2

Puoi anche usare un sistema senza Puppetmaster usando un VCS distribuito come Git, usando lo schema qui descritto:

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

— John Arundel
fonte

Se non disponi di un burattinaio, perdi il supporto dei protocolli memorizzati, che è una delle funzionalità più potenti di Puppet. Pensa alla raccolta di informazioni cross-machine integrata negli aggiornamenti; ad esempio, puoi raccogliere automaticamente informazioni sui servizi in esecuzione su tutti gli host (gestiti dalle marionette) per generare regole di firewalling, regole di routing, monitoraggio delle configurazioni, backup basati su pull ecc.

— David Gardner,

Sì, questo è un punto giusto. Certamente ci sono vantaggi nell'esecuzione di un sistema completo basato su Puppetmaster, e di solito lo faccio. Riesco a vedere situazioni in cui un sistema molto leggero basato su VCS come questo sarebbe utile però.

— John Arundel,

Se si sta optando per un'installazione senza master, è possibile farlo e configurare il server puppetmaster solo per ricevere l'inventario solo dai facters, quindi non deve essere molto disponibile.

— timurb

0

Abbiamo anche un certo numero di burattinai, ambienti diversi che sincronizziamo. Per fare ciò gestiamo tutti i nostri moduli fantoccio e manifest in sovversione e quindi distribuiamo i moduli fantoccio sui burattinai usando i normali manifest fantoccio e un modulo chiamato vcsdeploy che esegue il checkout:

http://www.practicalclouds.com/content/guide/pclouds-vcsdeploy-deploy-stuff

Quando vogliamo sincronizzare, contrassegniamo una versione e quindi aggiorniamo nodes.pp per il burattinaio.

Saluti

Dave

— user1238985
fonte