Pro e contro di un'architettura decentralizzata di marionette

14

Abbiamo circa 300 server RHEL che si stanno attualmente connettendo a un server Puppetmaster. Tuttavia, abbiamo notato alcuni colli di bottiglia nelle prestazioni ed è il punto di errore nel nostro sistema. Sono abbastanza nuovo per le marionette in generale e sto pensando di creare un'architettura di marionette decentralizzata invece di avere i client Puppet collegati al server Puppetmaster. A parte ciò che sospetto possa accadere, come il guadagno in termini di prestazioni e la mancanza di firma e scambio di certificati SSL per nuove macchine, quali sono gli altri vantaggi e svantaggi di creare un'architettura decentralizzata?

redhat puppet puppetmaster

— JMeterX
fonte

3

C'è un motivo per cui deve essere in un modo o nell'altro? Hai preso in considerazione le opzioni da qualche parte nel mezzo? Con così tanti server e una preoccupazione per un singolo punto di errore, allora perché non hai impostato master aggiuntivi? La configurazione di più server fantoccio con bilanciamento del carico è descritta nel libro "Pro Puppet". C'è molta flessibilità, dovrebbe anche essere possibile impostare una gerarchia di server fantoccio se ciò avesse senso.

— Zoredache,

@Zoredache Non c'è davvero alcun motivo per cui debba essere in un modo o nell'altro, stavo cercando maggiori informazioni su un'architettura decentralizzata in generale per facilitare la decisione. Ho preso in considerazione altri master, ma il nucleo dell'idea, che mi scuso per non aver menzionato, è quello di ridurre il conteggio dei server poiché influisce direttamente sul nostro budget. Sono d'accordo, il bilanciamento del carico dei server fantoccio ha senso, ma se riesco a sbarazzarmi di un server tutti insieme sarebbe la soluzione migliore.

— JMeterX,

7

Vai decentralizzato.

Invece di firmare i certificati, crea chiavi ssh. Non dare le chiavi ai non amministratori

Puoi usare Git come mezzo di trasporto invece di sovversione, quindi puoi diramare per macchine / ruoli diversi, quindi versione delle modifiche, oltre a consentire ... ma a questo punto devi conoscere lo spiel DVCS.

È più veloce e meno complicato da configurare. Aggiungi alcuni hook di commit per il controllo di integrità.

Ora, a questo punto, hai sostituito il burattinaio, con il suo modello client-server, con ssh e git, entrambi i quali scalano meglio del burattinaio.

Ora, potrebbe esserci una necessità nella tua organizzazione per la gerarchia. Nessun problema, basta archiviare il repository git contenente il ramo definitivo in un posto sicuro.

Bonus:

git blame

ti permetterà di vedere chi ha apportato una modifica.

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

Stai correndo un burattino nel passeggero? configurazioni memorizzate? Non dovresti assolutamente avere problemi di scalabilità con 300 nodi purché gestisca i problemi di installazione di base.

— Czervik
fonte

1

Stiamo usando la configurazione di Apache + Passenger. Stiamo anche utilizzando Subversion per

— inviare

1

Decentrato è il modo migliore di procedere perché ogni client compila il proprio manifest da una copia locale della fonte manifest. Questo viene aggiornato ogni volta che si inviano aggiornamenti dal server say git. Uso molto più efficiente della larghezza di banda in quanto i clienti non devono contattare il burattinaio ad ogni corsa. Elimina anche singoli punti di errore poiché i client possono essere aggiornati da qualsiasi luogo.

— What'sTheStoryWishBone
fonte