Frage Warum verwenden Menschen Puppet / Chef mit Amazon Cloud Formation statt nur CloudInit?


Wir planen, AMI EC2-Instanzen zu verwenden, die nicht "vorgebacken" sind. I.e. Wenn sie hochgespielt werden, sind sie bare Installationen von AWS Linux. Unser Bootstrap-Prozess zieht die verschiedenen Installationen an, die wir z.B. Python, Kater. Wir haben mindestens 3 Instanzen und maximal 8.

Würden Puppet / Chef angesichts dieser Anforderungen eher nützlich sein als Amazon Cloud Formation (CloudInit) zu verwenden?

Am besten kann ich sehen, wenn wir Puppet verwenden, dann hätten wir eine deklarative Programmierung, die einfacher zu auditieren ist, um zu sehen, was im Vergleich zu einem Skript passiert. Auch CloudInit hat ein 16k-Skript-Größenlimit, auf das wir möglicherweise nicht stoßen.

Hat jemand von CloudInit zu Puppet oder Chef aus einem bestimmten Grund gewechselt, den sie hier als Antwort auf meine Frage angeben können?


76
2017-08-16 20:55


Ursprung


Antworten:


Gibt es einen Vorteil gegenüber CloudInit? Ja, absolut, viele von ihnen!

Sicher, Sie können von oben nach unten laufen lassen, sobald CloudInit-Skripte einen Server bereitstellen. Was passiert aber, wenn Sie eine Konfigurationsdatei ändern, einen Benutzer hinzufügen, ein Paket aktualisieren oder ein neues Paket installieren müssen? Sie werden sich am Ende bei Servern anmelden oder Skripte schreiben, um dies zu tun, und unvermeidlich einen inkongruenten Status von Servern.

CloudInit ist keine Konfigurationsverwaltung. Wenn Sie sich dafür entscheiden, die Konfigurationsverwaltungssoftware zu verwenden, verwenden Sie cloud init nur für eine Aufgabe: um den Puppet / Chef / anderen Agenten zu booten.

Puppet hilft Ihnen nicht nur dabei, Pakete zu installieren, ssh-Schlüssel einzurichten oder Ihren Tomcat-Heap zu optimieren. Es sichert den Zustand der Dinge. Wenn ein Entwickler eine Java-App um 3:00 Uhr morgens behebt und Ihre Tomcat-Konfiguration ändert, wird Puppet diese zurücksetzen. Sie können die Version von Python für alle oder Gruppen von Knoten schnell ändern, und wenn jemand eine andere Version installiert, wird Puppet diese zurück ändern.

Wenn sich der Anwendungsstapel ändert und Sie beginnen, RabbitMQ oder Jetty oder ein neues RDBMS zu verwenden, können Sie die Änderungen problemlos auf mehreren zehn oder tausend Servern testen und bereitstellen.

Es gibt viele andere Gründe, Konfigurationsverwaltungssoftware zu verwenden, z. B. Back-End-Berichterstellung, Auditing und Sicherheitskonformität.


75
2017-08-17 00:50



Der ganze Sinn des Konfigurationsmanagements besteht darin, Maschinen vorhersehbar und konsistent hochzufahren. CloudFormation und cloudinit eignen sich hervorragend, wenn Sie nur auf AWS beschränkt sind (obwohl das Debuggen von CloudFormation-Vorlagen ein Problem darstellt) miserable Erfahrung), aber was ist mit Anwendungen, die sowohl Rechenzentrumsressourcen als auch AWS oder lokale Testumgebungen oder Entwicklungsmaschinen verwenden?

Wenn Sie nur in AWS existieren, können Sie Cloudinit und sonst nichts durchgehen, aber ich bin nicht davon überzeugt, dass es für Anwendungen jeglicher Größenordnung realistisch ist (Netflix zum Beispiel backt ihre AMIs mit OSS-Technologien, die sie geschrieben haben und in die Welt entlassen, bedenke Dieses Video für Details). Hochverfügbare Anwendungen sind überregional und basieren häufig auf VPCs. Sie tendieren dazu, Backups zu Datencentern über VPNs hinweg durchzuführen, und dies betrifft nicht einmal Demo-, Staging-, Test- oder Entwicklungsumgebungen. Als jemand, der mit der Bereitstellung von Maschinen beauftragt ist letzte Dinge, die ich tun möchte, sind die Arbeit zu wiederholen oder stecken Fehler beim Debuggen mehrerer Provisionierungsmethoden.

Daher Chef oder Marionette. Sie funktionieren genauso gut für AWS wie für mein Rechenzentrum und genauso gut für meine Entwicklungsmaschine Landstreicher wie für die Demo-Umgebungen brauche ich gelegentlich im laufenden Betrieb. Ich würde viel lieber Koch oder Marionette aus Cloudinit starten, als sowohl Cloudinit als auch Chef oder Puppet beizubehalten.


61
2017-08-17 12:08



Für wegwerfende Server, sagen wir hinter einer Autoscaling-Gruppe zu laufen, würde ich sagen Cloudinit ist wahrscheinlich genug. Linux-Shell-Skripte oder Windows-Powershell-Skripte sollten den Trick machen.

Wenn es ein lang laufender Server ist, den Sie planen zu managen, könnte Ihnen ein Chef, eine Puppe oder ein Hafenarbeiter einen Vorteil verschaffen, wie in der angenommenen Antwort erwähnt. Wenn Sie den Vorteil nach der Verwendung nicht sehen können, benötigen Sie das Tool wahrscheinlich nicht.


5
2018-02-04 20:09



Meiner Erfahrung nach gibt es einfache Dinge, die mit den von AWS bereitgestellten Out-of-the-Box-GUI-Tools leicht erledigt werden können. Wenn Sie jedoch mit komplexeren Dingen konfrontiert werden, werden Sie feststellen, dass es Einschränkungen gibt, was Sie tun können ihre Werkzeuge.

An diesem Punkt können Sie entweder aufhören oder Sie können andere Tools (wie Chef oder Puppet) finden, die Ihnen helfen können, diese komplexeren Ziele zu erreichen und einfachere Dinge zu tun.

Deine Entscheidung.


0
2018-04-22 22:45