Was sind einige klare Vorteile der Ausführung des Master / Agent-Konfigurationsmanagements?

Ansible scheint einen klaren Vorteil gegenüber der Konkurrenz wie Koch und Marionette zu haben, da es agentenlos ist und ein gewisses Maß an Overhead spart.

Ich habe mehrere Vergleiche der verschiedenen Konfigurationstools gelesen und obwohl jedes Tool seine eigenen Stärken und Schwächen hat, ist mir klar, dass ein Großteil davon auf persönliche Vorlieben zurückzuführen ist.

Der Vorteil, ohne Agenten zu sein, ist ein Kinderspiel. Gibt es jedoch Vorteile der Master / Agent-Architektur in Bezug auf Konfigurationsmanagement-Tools?

Ich habe eine interessante Diskussion zum Thema Konfigurationsmanagement Pull vs. Push-Topologie gefunden

Ein Mitwirkender schreibt, dass Pull-Systeme (Master / Agent) mehr Flexibilität bieten und einfacher zu skalieren sind.

IMHO ist der einzige Vorteil einer Master / Agent-Pull-Architektur, dass sie in einem Firewall-Netzwerk verwendet werden kann (wenn sich die eigentliche Konfiguration außerhalb dieses Netzwerks befindet), ohne Löcher in der Firewall zu öffnen, während die Push-Architektur dies nicht kann.

In Bezug auf die Flexibilität denke ich, dass das wichtigste Problem die minimale Einrichtung ist, die auf einem Knoten erforderlich ist, um remote verwaltet werden zu können. Sobald diese Anforderung erfüllt ist, können beide Architekturen Aktualisierungen verarbeiten. Für eine Master / Agent-Architektur muss der Agent installiert, konfiguriert und ausgeführt werden. Einerseits sind Puppet und Chef (noch) nicht standardmäßig auf den meisten Systemen installiert, während sshd (von Ansible benötigt) installiert ist. Auf der anderen Seite benötigt sogar Ansible sshd-Ausführung und auf dem Knoten konfigurierte Anmeldeinformationen, um darauf zugreifen zu können. Daher würde ich sagen, dass es aus dieser Perspektive keinen großen Unterschied gibt - insbesondere, wenn das minimale Setup über angepasste System-Images erreicht wird.

In Bezug auf die Skalierbarkeit würde ich die Master / Agent-Architektur als weniger skalierbar betrachten (aber nur ein bisschen):

• Wenn der Master versucht, einen aktiven Systemstatus (dh die Karte aller Agenten und ihrer Status) aktiv beizubehalten, würde dies einige Zeit / Ressourcen kosten. Ohne Master ist Ansible für solche Skalierbarkeitsprobleme nicht anfällig. Zugegeben, sogar Master / Agent-Architekturen können einen skalierbaren Ansatz bieten, um einen Gesamtsystemstatus bereitzustellen, der dem von Ansible ähnelt (und wahrscheinlich tun dies heutzutage alle).

• In früheren Zeiten, als der Master tatsächlich die Agentenkonfigurationsaufgaben ausführte (wie in dem Beitrag erwähnt, auf den Sie in Ihrer Antwort verwiesen haben), konnte die Skalierbarkeit einer solchen Architektur stark leiden. Dies ist jedoch keine große Sache mehr, da für alle in Ihrer Frage genannten Tools die Konfiguration nur auf den lokalen Knoten übertragen wird, der dann die Aufgaben ausführt.

• Wenn es darum geht, die Konfigurationen auf die lokalen Knoten zu übertragen, ist eine Pull-Architektur nur durch die Kapazität begrenzt, diese Konfigurationen zu bedienen (die beiden Architekturen gemeinsam sind), aber ein Master / Agent muss auch die logischen Treiberübertragungen ausführen und die tatsächlich durchführen Gegebenenfalls Übertragungen (es ist möglich, die Agenten nur anzuweisen, ihre eigenen Konfigurationen abzurufen), wodurch begrenzt wird, wie schnell der Master Konfigurationen an eine große Anzahl von Agenten weitergeben kann.

IMHO läuft die Idee, einen Agenten oder Master oder beides zu haben, auf Folgendes hinaus:

Ein Mechanismus zum kontinuierlichen Verwalten von Zuständen der Knoten.

Wenn ein solches Werkzeug dies zulässt, ist die Fähigkeit zur "Selbstheilung" der offensichtliche Vorteil.

Im Fall von Ansible gibt es meines Erachtens keine eingebauten Mechanismen, um die Selbstheilungskräfte bereitzustellen (da keine Dämonen kontinuierlich laufen, um die Zustände abzurufen und auf sie zu reagieren).

Selbstheilung klingt jedoch nicht nach dem Problem, das ein Konfigurationsmanagement-Tool lösen sollte. Vielleicht ist es nicht etwas, das man als "Vorteil" anderer Tools gegenüber Ansible betrachten könnte.