Vor- und Nachteile einer dezentralen Puppenarchitektur

14

Wir haben ungefähr 300 RHEL-Server, die derzeit eine Verbindung zu einem Puppetmaster-Server herstellen. Wir haben jedoch einige Leistungsengpässe festgestellt und es ist der Punkt, an dem unser System versagt. Ich bin für Puppet im Allgemeinen ziemlich neu und denke darüber nach, eine dezentrale Puppet-Architektur zu erstellen, anstatt Puppet-Clients mit dem Puppetmaster-Server zu verbinden. Abgesehen von dem, was ich vermuten würde, wie Leistungsgewinn und das Fehlen des Signierens und Austauschs von SSL-Zertifikaten gegen neue Computer, was sind andere Vor- und Nachteile beim Aufbau einer dezentralen Architektur?

redhat puppet puppetmaster

— JMeterX
quelle

3

Gibt es einen Grund, warum es so oder so sein muss? Haben Sie irgendwo dazwischen über Optionen nachgedacht? Warum haben Sie bei so vielen Servern und der Sorge um einen einzelnen Fehlerpunkt keine zusätzlichen Master eingerichtet? Das Einrichten mehrerer lastverteilter Puppenserver wird im Buch "Pro Puppet" behandelt. Es gibt viel Flexibilität, es sollte sogar möglich sein, eine Hierarchie von Puppenservern einzurichten, wenn dies sinnvoll wäre.

— Zoredache

@Zoredache Es gibt wirklich keinen Grund, warum es so oder so sein muss. Ich habe nach weiteren Informationen zu einer dezentralen Architektur im Allgemeinen gesucht, um die Entscheidung zu erleichtern. Ich habe über zusätzliche Master nachgedacht, aber der Kern der Idee, die ich entschuldige, ist die Reduzierung der Serveranzahl, da sie sich direkt auf unser Budget auswirkt. Ich stimme zu, ein Lastausgleich der Puppet-Server ist sinnvoll, aber wenn ich einen Server alle zusammen loswerden kann, wäre das die beste Lösung.

— JMeterX

7

Gehen Sie dezentral.

Erstellen Sie ssh-Schlüssel, anstatt Zertifikate zu signieren. Geben Sie die Schlüssel nicht an Administratoren weiter

Sie können Git als Transport anstelle von Subversion verwenden und dann für verschiedene Maschinen / Rollen verzweigen und dann Ihre Änderungen versionieren sowie zulassen ... aber Sie müssen das DVCS-Spiel an dieser Stelle kennen.

Es ist schneller und einfacher einzurichten. Fügen Sie einige Commit-Hooks für die Überprüfung der Vernunft hinzu.

Jetzt haben Sie den Puppenmeister durch das Client-Server-Modell mit ssh und git ersetzt, die beide besser skalieren als der Puppenmeister.

Möglicherweise besteht in Ihrer Organisation ein Bedarf an Hierarchien. Kein Problem, bewahren Sie einfach das Git-Repo mit dem definitiven Zweig an einem sicheren Ort auf.

Bonus:

git blame

Damit können Sie sehen, wer eine Änderung vorgenommen hat.

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

https://www.braintreepayments.com/braintrust/decentralize-your-devops-with-masterless-puppet-and-supply-drop ?

— chiggsy
quelle

3

Laufen Sie Marionette im Passagier? gespeicherte configs? Sie sollten wirklich überhaupt keine Skalierbarkeitsprobleme mit 300 Knoten haben, solange Sie grundlegende Setup-Probleme behandeln.

— czervik
quelle

1

Wir verwenden die Apache + Passenger-Konfiguration. Wir verwenden auch Subversion, um die Änderungen an Puppetmaster

— JMeterX 17.07.12

1

Dezentral ist der beste Weg, da jeder Client sein eigenes Manifest aus einer lokalen Kopie der Manifestquelle kompiliert. Dies wird jedes Mal aktualisiert, wenn Sie Updates vom say git-Server herunterladen. Viel effizientere Nutzung der Bandbreite, da Kunden nicht bei jedem Lauf Kontakt mit dem Puppenspieler aufnehmen müssen. Beseitigt auch einzelne Fehlerquellen, da Clients von überall aus aktualisiert werden können.

— What'sTheStoryWishBone
quelle