Frage Was sind die Vorteile von Chef-Server anstelle von Chef-Solo?


Ich betrachte automatisierte Bereitstellungslösungen für mein Team und habe in den letzten Tagen mit Chefkoch gespielt. Ich war in der Lage, eine einfache Web-App von einer Basis-Red Hat VM mit Chef-Solo zu laufen.

Unser Endziel ist die Verwendung von Chef (oder eines anderen Systems) zur automatischen Bereitstellung von Anwendungstopologien in der Cloud, während Builds ausgeführt werden. Unser Prozess würde grundsätzlich so laufen:

  1. Unser Web-App-Code, Abhängigkeiten und Kochbücher sind in SCM gespeichert
  2. Ein Build wird ausgeführt und erstellt ein einzelnes Paket für die Bilder, die erfasst und getestet werden sollen
  3. Die Build-Engine stellt dann neue Cloud-Images bereit, auf denen ein Chef-Client ausgeführt wird, um die Pakete zu installieren.
  4. Die Bilder erhalten die Kochbücher von SCM oder dem Chef-Server und installieren alles, um zum Laufen zu kommen

Was sind die Vorteile und / oder Anwendungsfälle für die Ausführung eines Chef-Servers?

Gibt es irgendwelche großen Vorteile, einen Chef-Server zu halten und die Kochbücher von SCM gegen das Verwenden von Chef-Solo zu erwerben und ein Skript zu haben, das die Kochbücher von SCM zieht?


32
2018-06-23 15:37


Ursprung




Antworten:


Ich werde diese Antwort so orientieren, als ob die Frage wäre: "Was sind die Vorteile von Chef-Solo?", Denn das ist der beste Weg, um die Unterschiede zwischen den Ansätzen zu erklären.

Meine zusammenfassende Empfehlung stimmt mit anderen überein: Verwenden Sie einen Chef-Server, wenn Sie eine dynamische, virtualisierte Umgebung verwalten müssen, in der Sie häufig Knoten hinzufügen und entfernen. Ein Chef-Server ist auch gut CMDBwenn du eins brauchst. Verwenden Sie Chef-Solo, wenn Sie eine weniger dynamische Umgebung haben, in der sich die Knoten nicht zu oft ändern, sondern die Rollen und Rezepte. Größe und Komplexität Ihrer Umgebung sind mehr oder weniger irrelevant. Beide Ansätze skalieren sehr gut.

Wenn Sie Chef-Solo bereitstellen, verwenden Sie einen Cronjob mit rsync, 'git pull' oder einem anderen idempotenten Dateiübertragungsmechanismus, um eine vollständige Kopie des Chef-Repositorys auf jedem Knoten zu verwalten. Der Cronjob sollte leicht konfigurierbar sein, um (a) überhaupt nicht zu laufen und (b) zu laufen, aber ohne das lokale Repository zu synchronisieren. Fügen Sie ein Knoten / Verzeichnis in Ihrem Chef-Repository mit einer JSON-Datei für jeden Knoten hinzu. Ihr Cronjob kann so hochentwickelt sein, wie Sie es wünschen, um die richtige Knotendatei zu finden (obwohl ich einfach $ (hostname -s) .json empfehlen würde. Sie könnten auch ein opscode-Konto erstellen und einen Client mit gehostetem Chef konfigurieren, wenn Kein anderer Grund, als mit einem Messer Community-Kochbücher herunterladen und Skelette erstellen zu können.

Dieser Ansatz bietet neben dem offensichtlichen "kein Server verwalten" mehrere Vorteile. Ihre Quellcodeverwaltung ist der letzte Zuteiler aller Konfigurationsänderungen, das Repository enthält alle Knoten und Runlisten, und jeder Server, der vollständig unabhängig ist, erleichtert einige praktische Testszenarien.

Chef-Server führt eine Lücke ein, in der Sie das "Messer-Upload" verwenden, um ein Kochbuch zu aktualisieren, und Sie müssen dieses Loch selbst patchern (z. B. mit einem Post-Commit-Hook) oder riskieren, dass Site-Änderungen von jemandem überschrieben werden, der "Messer hochladen" s ein veraltetes Rezept aus dem veralteten lokalen Repository auf seinem Laptop. Bei Chef-Solo ist dies weniger wahrscheinlich, da alle Änderungen direkt aus dem Master-Repository mit Servern synchronisiert werden. Das Problem hier ist Disziplin und Anzahl der Mitarbeiter. Wenn Sie ein Solo-Entwickler oder ein sehr kleines Team sind, ist das Hochladen von Kochbüchern über die API nicht sehr riskant. In einem größeren Team kann es sein, wenn Sie keine guten Kontrollen einsetzen.

Zusätzlich können Sie mit chef-solo alle Rollen, benutzerdefinierten Attribute und Runlisten Ihrer Knoten als node.json-Dateien in Ihrem Haupt-Chef-Repository speichern. Mit chef-server werden Rollen und Runlisten im laufenden Betrieb über die API modifiziert. Mit Chef-Solo können Sie diese Informationen in der Versionskontrolle verfolgen. Hier kann der Konflikt zwischen statischen und dynamischen Umgebungen deutlich gesehen werden. Wenn sich Ihre Liste von Knoten (egal wie lange sie ist) nicht häufig ändert, ist es sehr nützlich, diese Daten in der Versionskontrolle zu haben. Auf der anderen Seite, wenn Sie häufig neue Knoten erstellen und alte zerstören (nie wieder ihren Hostnamen oder fqdn sehen), ist die Revisionssteuerung nur ein unnötiger Ärger und eine API, um Änderungen vorzunehmen, ist sehr praktisch. Chef-Server verfügt über eine ganze Reihe von Funktionen, die auch auf die Verwaltung dynamischer Cloud-Umgebungen ausgerichtet sind, wie zum Beispiel die Namensoption auf "Messer Bootstrap", mit der Sie fqdn als Standardmethode zur Identifizierung eines Knotens ersetzen können. In einer statischen Umgebung sind diese Funktionen jedoch von begrenztem Wert, insbesondere im Vergleich zu Rollen und Runlisten in der Versionskontrolle mit allem anderen.

Schließlich können Rezepttestumgebungen im laufenden Betrieb fast ohne zusätzliche Arbeit eingerichtet werden. Sie können die auf einem Server laufenden Cronjobs deaktivieren und Änderungen direkt in ihrem lokalen Repository vornehmen. Sie können die Änderungen testen, indem Sie Chef-Solo ausführen, und Sie werden genau sehen, wie sich der Server in der Produktion selbst konfiguriert. Sobald alles getestet wurde, können Sie die Änderungen einchecken und die lokalen Cronjobs erneut aktivieren. Beim Schreiben von Rezepten können Sie jedoch nicht die API "Suchen" verwenden. Wenn Sie also dynamische Rezepte (z. B. Loadbalancer) schreiben möchten, müssen Sie diese Einschränkung umgehen und die Daten aus den JSON-Dateien sammeln Ihr Knoten / Verzeichnis, das wahrscheinlich weniger komfortabel ist und einige der Daten fehlen, die in der vollständigen CMDB verfügbar sind. Wiederum werden dynamischere Umgebungen den datenbankgestützten Ansatz bevorzugen, weniger dynamische Umgebungen werden mit JSON-Dateien auf lokalen Festplatten in Ordnung sein. In einer Serverumgebung, in der ein Chef-Manager API-Aufrufe an eine zentrale Datenbank ausführen muss, sind Sie auf die Verwaltung aller Testumgebungen innerhalb dieser Datenbank angewiesen.

Der letzte kann auch in Notfällen verwendet werden. Wenn Sie ein kritisches Problem auf Produktionsservern beheben und es mit einer Konfigurationsänderung lösen, können Sie die Änderung sofort im Repository des Servers vornehmen und es dann dem Master vorschalten.

Das sind die Hauptvorteile von Chef-Solo. Es gibt einige andere, wie nicht einen Server verwalten oder für gehostete Chefkoch zahlen müssen, aber das sind relativ kleine Bedenken.

Zusammenfassend: Wenn Sie dynamisch und hoch virtualisiert sind, bietet der Chef-Server eine Reihe von großartigen Funktionen (anderswo abgedeckt) und die meisten Koch-Solo-Vorteile werden weniger auffällig sein. Jedoch gibt es einige, oft nicht erwähnte Vorteile für Chef-Solo, besonders in traditionelleren Umgebungen. Beachten Sie, dass die Bereitstellung in der Cloud nicht unbedingt bedeutet, dass Sie eine dynamische Umgebung haben. Wenn Sie beispielsweise keine weiteren Knoten zu Ihrem System hinzufügen können, ohne eine neue Version Ihrer Software zu veröffentlichen, sind Sie wahrscheinlich nicht dynamisch. Schließlich kann eine CMDB aus einer höheren Perspektive für eine Reihe von Dingen nützlich sein, die nur tangential mit der Systemadministration und -konfiguration verbunden sind, wie z. B. Buchhaltung und Informationsaustausch zwischen Teams. Die Verwendung von Chef-Server könnte sich allein für diese Funktion lohnen.


66
2018-06-29 23:43



Wie würden Sie vertrauliche Daten (z. B. private Schlüssel / Passwörter) mit Chef-Solo speichern / verteilen? Wie kann ich es mit der Versionskontrolle verfolgen, ohne es als Klartext zu speichern? - Limbo Peng
@LimboPeng Sie können verschlüsselte Datensäcke im Chef Repo speichern. Sie müssen den Verschlüsselungsschlüssel jedoch extern speichern. - Willie Wheeler


Offenlegung: Ich arbeite für Opscode.

Der große Vorteil von Chef Server gegenüber Solo ist die Möglichkeit, die Suche mit Ihrer Infrastruktur zu nutzen. Das klassische Beispiel ist ein Load Balancer mit Webservern. Der Load Balancer kann seine Konfiguration automatisch aktualisieren, wenn Webserver zur Infrastruktur hinzugefügt und entfernt werden, indem einfach nach ihnen gesucht wird. Solo ist genau das, einzelne Maschinen, während Chef Server die Möglichkeit bietet, nach Dingen wie "alle Maschinen mit mehr als 4 GB RAM" oder "der Datenbank-Master" zu fragen.

Chef Server bietet Ihnen außerdem die Möglichkeit, Ihre Infrastruktur zu verwalten, ohne Tarballs zu kopieren, Ihre Infrastruktur mit der Verwaltungskonsole zu visualisieren und zu verwalten, welche Maschinen welche Versionen von Kochbüchern mit Environments ausführen. Es gibt noch andere Vorteile, aber das sind die, die ich nicht im Kopf habe. Wenn Sie den Chef Server ausprobieren möchten, ohne ihn zu installieren, melden Sie sich einfach für ein Opscode Hosted Chef Konto an, die ersten 5 Knoten sind kostenlos.


27
2018-06-24 16:51



Danke mray, diese Information hilft einem TON. Weißt du, wie man DevOps Philosophien bei der Verwendung des Chef-Servers annimmt? Was ich damit meine, ist es, alle unsere Kochbücher live in SCM zu haben. Gibt es eine einfache Möglichkeit, Chef-Server aktualisierte Kochbücher zu erhalten, wenn wir neuen Code liefern? - linusthe3rd
@ strife25 Du solltest bestimmt habe deine Kochbücher in einem Versionskontrollsystem. Wenn Sie einem nicht gehorchen, empfiehlt Opscode Git, da es für verteilte Teams einfach ist, mit Zweigen und Steinen zu arbeiten. Sie könnten einen Post-Commit-Hook schreiben, der Kochbücher auf den Chef-Server lädt. Sie klonen nicht nur Kochbücher auf dem Chef-Server, weil Sie sie über eine API hochladen, und dies ist sehr absichtlich beabsichtigt. - jtimberman


Chef-Server verwaltet Kochbücher und Konfigurationsdaten für Ihre Knoten.

Sie fügen Kochbücher mit dem Messerwerkzeug zu Chef-Server hinzu und geben dann jedem Knoten eine Ausführungsliste von Rezepten, damit sie die Kochbücher, die sie benötigen, wenn der Knoten sich selbst mit Chef-Client einstellt, greifen. Da der Chef-Client im Hintergrund läuft, überprüfen Ihre Knoten regelmäßig, ob auf Ihrem Chefserver aktualisierte Kochbücher vorhanden sind.

Der chef-server speichert auch Ihre Konfigurationsdaten und -variablen, so dass Sie die Einstellungen für die automatische Übernahme Ihrer Knoten ändern können. Dies ist gut für dynamischere Einstellungen, die in Ihren Rezepten nicht oder nicht fest codiert sein sollten.


1
2017-08-05 14:01