Warum verwenden Menschen Puppet / Chef mit Amazon Cloud Formation, anstatt nur CloudInit zu verwenden?

Wir planen, AMI EC2-Instanzen zu verwenden, die nicht "vorgebacken" sind. Das heißt, wenn sie hochgefahren werden, handelt es sich um reine Installationen von AWS Linux. Unser Bootstrap-Prozess zieht die verschiedenen Installationen ein, die wir benötigen, z. B. Python, Tomcat. Wir haben mindestens 3 Instanzen und maximal 8.

Wäre die Verwendung von Puppet / Chef angesichts dieser Anforderungen sinnvoll, anstatt Amazon Cloud Formation (CloudInit) zu verwenden?

Das Beste, was ich sehen kann, ist, wenn wir Puppet verwenden, dann hätten wir eine deklarative Programmierung, die einfacher zu überprüfen ist, um zu sehen, was im Vergleich zu einem Skript passiert. Außerdem hat CloudInit eine Größenbeschränkung von 16.000 Skripten, auf die wir möglicherweise stoßen oder nicht.

Ist jemand aus einem bestimmten Grund von CloudInit zu Puppet oder Chef gewechselt, den er hier als Antwort auf meine Frage angeben kann?

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

Sicher, Sie können von oben nach unten laufen, sobald CloudInit-Skripte ausgeführt werden, um einen Server bereitzustellen. Aber was passiert, wenn Sie eine Konfigurationsdatei ändern, einen Benutzer hinzufügen, ein Paket aktualisieren oder ein neues Paket installieren müssen? Am Ende melden Sie sich bei Servern an oder schreiben dazu Skripte, was zwangsläufig zu einem inkongruenten Serverstatus führt.

CloudInit ist kein Konfigurationsmanagement. Wenn Sie sich für die Verwendung der Konfigurationsverwaltungssoftware entscheiden, verwenden Sie Cloud Init nur für eine Aufgabe: um den Puppet / Chef / anderen Agenten zu booten.

Puppet hilft Ihnen nicht nur dabei, die Installation von Paketen zu automatisieren, SSH-Schlüssel einzurichten oder Ihren Tomcat-Heap zu optimieren. Es stellt den Zustand der Dinge sicher. Wenn ein Entwickler um 3 Uhr morgens eine Java-App behebt und Ihre Tomcat-Konfiguration ändert, ändert Puppet sie zurück. Sie können die Version von Python schnell für alle oder Gruppen von Knoten ändern. Wenn jemand eine andere Version installiert, ändert Puppet sie zurück.

Wenn sich Ihr Anwendungsstapel ändert und Sie beispielsweise RabbitMQ oder Jetty oder ein neues RDBMS verwenden, können Sie die Änderungen problemlos auf Zehntausenden oder Tausenden von Servern testen und bereitstellen.

Es gibt viele andere Gründe für die Verwendung von Konfigurationsverwaltungssoftware, z. B. Back-End-Berichterstellung, Prüfung und Einhaltung von Sicherheitsbestimmungen.

Der gesamte Punkt des Konfigurationsmanagements besteht darin, Maschinen vorhersehbar und konsistent hochzufahren. CloudFormation und Cloudinit eignen sich hervorragend, wenn Sie sich ausschließlich auf AWS beschränken (obwohl das Debuggen von CloudFormation-Vorlagen eine miserable Erfahrung ist ). Was ist jedoch mit Anwendungen, die sowohl Rechenzentrumsressourcen und AWS als auch lokale Testumgebungen oder Entwicklungsmaschinen verwenden?

Wenn Sie nur in AWS existieren, könnten Sie wahrscheinlich mit Cloudinit und nichts anderem davonkommen, aber ich bin nicht davon überzeugt, dass dies für Anwendungen jeder Größenordnung realistisch ist (Netflix beispielsweise backt seine AMIs mithilfe der von ihnen geschriebenen OSS-Technologien vor und für die Welt freigegeben; betrachten Sie dieses Video für Details). Hochverfügbare Anwendungen sind überregional, basieren häufig auf VPCs und werden in der Regel über VPNs in Rechenzentren gesichert. Dies betrifft nicht einmal Demo-, Staging-, Test- oder Entwicklungsumgebungen. Als jemand, der mit der Bereitstellung von Maschinen beauftragt ist, möchte ich als letztes die Arbeit wiederholen oder beim Debuggen mehrerer Bereitstellungsmethoden stecken bleiben.

Daher Chef oder Marionette. Sie funktionieren für AWS genauso gut wie für mein Rechenzentrum und für meine Entwicklungsmaschine, auf der Vagrant ausgeführt wird, genauso wie für die Demo-Umgebungen, die ich gelegentlich im laufenden Betrieb benötige. Ich würde Chef oder Puppet viel lieber von Cloudinit aus starten, als sowohl Cloudinit als auch Chef oder Puppet zu pflegen.

Wenn Sie Server wegwerfen möchten, sagen wir, dass Sie hinter einer Autoscaling-Gruppe laufen, würde ich sagen, dass Cloudinit wahrscheinlich ausreicht. Linux-Shell-Skripte oder Windows-Powershell-Skripte sollten den Trick machen.

Wenn es sich um einen Server mit langer Laufzeit handelt, den Sie verwalten möchten, kann Ihnen ein Koch, eine Marionette oder ein Hafenarbeiter einen Vorteil verschaffen, wie in der akzeptierten Antwort angegeben. Wenn Sie den Vorteil nach der Verwendung nicht erkennen können, benötigen Sie das Tool wahrscheinlich nicht.

Nach meiner Erfahrung gibt es einfache Dinge, die mit den von AWS bereitgestellten Standard-GUI-Tools leicht erledigt werden können. Wenn Sie jedoch in komplexere Dinge eintauchen, stellen Sie fest, dass es Einschränkungen gibt, was Sie mit nur tun können ihre Werkzeuge.

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

Deine Entscheidung.