Die etablierteren Konfigurationsmanagementsysteme (CM) wie Puppet und Chef verwenden einen Pull-basierten Ansatz: Clients fragen regelmäßig bei einem zentralen Master nach Aktualisierungen. Einige von ihnen bieten auch einen meisterlosen Ansatz (also Push-basiert), geben jedoch an, dass er nicht für die Produktion (Saltstack) oder weniger skalierbar (Puppet) ist. Das einzige System, von dem ich weiß, dass es von Anfang an Push-basiert ist, ist der Zweitplatzierte Ansible.
Was ist der spezifische Skalierbarkeitsvorteil eines Pull-basierten Systems? Warum ist es angeblich einfacher, mehr Pullmaster als Pushagenten hinzuzufügen?
Beispielsweise schreibt agiletesting.blogspot.nl :
In einem Pull-System kontaktieren Clients den Server unabhängig voneinander, sodass das gesamte System skalierbarer ist als ein Push-System
Auf der anderen Seite demonstriert Rackspace, dass sie 15K-Systeme mit einem Push-basierten Modell handhaben können .
infastructures.org schreibt:
Wir schwören auf eine Pull-Methode für die Wartung von Infrastrukturen, die ein Tool wie SUP, CVSup, einen Rsync-Server oder Cfengine verwendet. Anstatt Änderungen an Clients weiterzuleiten, muss jeder einzelne Client-Computer dafür verantwortlich sein, den Gold-Server beim Start abzufragen und anschließend regelmäßig seine eigene Revisionsstufe beizubehalten. Bevor wir diesen Standpunkt übernommen haben, haben wir umfangreiche push-basierte Skripte entwickelt, die auf ssh, rsh, rcp und rdist basieren. Das Problem, das wir bei den r-Befehlen (oder ssh) festgestellt haben, war folgendes: Wenn Sie ein r-befehlsbasiertes Skript ausführen, um eine Änderung auf Ihre Zielcomputer zu übertragen, besteht die Wahrscheinlichkeit, dass einer von ihnen über 30 Zielhosts verfügt zu einem bestimmten Zeitpunkt nicht erreichbar sein. Das Führen der Liste der in Betrieb genommenen Maschinen wird zum Albtraum. Während Sie Code schreiben, um dies zu korrigieren, müssen Sie sich mit dem folgenden Code auseinandersetzen: Timeouts von toten Hosts; Protokollierung und Wiederholung von toten Hosts; Parallele Jobs forken und ausführen, um zu versuchen, viele Hosts in angemessener Zeit zu treffen; und schließlich den Fall zu erkennen und zu verhindern, dass alle verfügbaren TCP-Sockets auf dem Quellcomputer mit allen ausgehenden rsh-Sitzungen belegt werden. Dann haben Sie immer noch das Problem, alles, was Sie gerade getan haben, in die Installationsimages für alle neuen Hosts zu übernehmen, die in Zukunft installiert werden sollen, und es für alle Hosts zu wiederholen, die nicht mehr funktionieren und morgen neu erstellt werden müssen. Nachdem wir uns die Mühe gemacht hatten, eine R-Command-basierte Replikation zu implementieren, fanden wir, dass es sich einfach nicht lohnt. Wir planen nicht, eine Infrastruktur wieder mit R-Befehlen oder einem anderen Push-Mechanismus zu verwalten. Sie skalieren nicht so gut wie Pull-basierte Methoden. Parallele Jobs forken und ausführen, um zu versuchen, viele Hosts in angemessener Zeit zu treffen; und schließlich den Fall zu erkennen und zu verhindern, dass alle verfügbaren TCP-Sockets auf dem Quellcomputer mit allen ausgehenden rsh-Sitzungen belegt werden. Dann haben Sie immer noch das Problem, alles, was Sie gerade getan haben, in die Installationsimages für alle neuen Hosts zu übernehmen, die in Zukunft installiert werden sollen, und es für alle Hosts zu wiederholen, die nicht mehr funktionieren und morgen neu erstellt werden müssen. Nachdem wir uns die Mühe gemacht hatten, eine R-Command-basierte Replikation zu implementieren, fanden wir, dass es sich einfach nicht lohnt. Wir planen nicht, eine Infrastruktur wieder mit R-Befehlen oder einem anderen Push-Mechanismus zu verwalten. Sie skalieren nicht so gut wie Pull-basierte Methoden. Parallele Jobs forken und ausführen, um zu versuchen, viele Hosts in angemessener Zeit zu treffen; und schließlich den Fall zu erkennen und zu verhindern, dass alle verfügbaren TCP-Sockets auf dem Quellcomputer mit allen ausgehenden rsh-Sitzungen belegt werden. Dann haben Sie immer noch das Problem, alles, was Sie gerade getan haben, in die Installationsimages für alle neuen Hosts zu übernehmen, die in Zukunft installiert werden sollen, und es für alle Hosts zu wiederholen, die nicht mehr funktionieren und morgen neu erstellt werden müssen. Nachdem wir uns die Mühe gemacht hatten, eine R-Command-basierte Replikation zu implementieren, fanden wir, dass es sich nicht lohnt. Wir planen nicht, eine Infrastruktur wieder mit R-Befehlen oder einem anderen Push-Mechanismus zu verwalten. Sie skalieren nicht so gut wie Pull-basierte Methoden. und schließlich den Fall zu erkennen und zu verhindern, dass alle verfügbaren TCP-Sockets auf dem Quellcomputer mit allen ausgehenden rsh-Sitzungen belegt werden. Dann haben Sie immer noch das Problem, alles, was Sie gerade getan haben, in die Installationsimages für alle neuen Hosts zu übernehmen, die in Zukunft installiert werden sollen, und es für alle Hosts zu wiederholen, die nicht mehr funktionieren und morgen neu erstellt werden müssen. Nachdem wir uns die Mühe gemacht hatten, eine R-Command-basierte Replikation zu implementieren, fanden wir, dass es sich einfach nicht lohnt. Wir planen nicht, eine Infrastruktur wieder mit R-Befehlen oder einem anderen Push-Mechanismus zu verwalten. Sie skalieren nicht so gut wie Pull-basierte Methoden. und schließlich den Fall zu erkennen und zu verhindern, dass alle verfügbaren TCP-Sockets auf dem Quellcomputer mit allen ausgehenden rsh-Sitzungen belegt werden. Dann haben Sie immer noch das Problem, alles, was Sie gerade getan haben, in die Installationsimages für alle neuen Hosts zu übernehmen, die in Zukunft installiert werden sollen, und es für alle Hosts zu wiederholen, die nicht mehr funktionieren und morgen neu erstellt werden müssen. Nachdem wir uns die Mühe gemacht hatten, eine R-Command-basierte Replikation zu implementieren, fanden wir, dass es sich einfach nicht lohnt. Wir planen nicht, eine Infrastruktur wieder mit R-Befehlen oder einem anderen Push-Mechanismus zu verwalten. Sie skalieren nicht so gut wie Pull-basierte Methoden. Dann haben Sie immer noch das Problem, alles, was Sie gerade getan haben, in die Installationsimages für alle neuen Hosts zu übernehmen, die in Zukunft installiert werden sollen, und es für alle Hosts zu wiederholen, die nicht mehr funktionieren und morgen neu erstellt werden müssen. Nachdem wir uns die Mühe gemacht hatten, eine R-Command-basierte Replikation zu implementieren, fanden wir, dass es sich einfach nicht lohnt. Wir planen nicht, eine Infrastruktur wieder mit R-Befehlen oder einem anderen Push-Mechanismus zu verwalten. Sie skalieren nicht so gut wie Pull-basierte Methoden. Dann haben Sie immer noch das Problem, alles, was Sie gerade getan haben, in die Installationsimages für alle neuen Hosts zu übernehmen, die in Zukunft installiert werden sollen, und es für alle Hosts zu wiederholen, die nicht mehr funktionieren und morgen neu erstellt werden müssen. Nachdem wir uns die Mühe gemacht hatten, eine R-Command-basierte Replikation zu implementieren, fanden wir, dass es sich einfach nicht lohnt. Wir planen nicht, eine Infrastruktur wieder mit R-Befehlen oder einem anderen Push-Mechanismus zu verwalten. Sie skalieren nicht so gut wie Pull-basierte Methoden. oder mit irgendeinem anderen Druckmechanismus. Sie skalieren nicht so gut wie Pull-basierte Methoden. oder mit irgendeinem anderen Druckmechanismus. Sie skalieren nicht so gut wie Pull-basierte Methoden.
Ist das nicht ein Implementierungsproblem statt eines architektonischen? Warum ist es schwieriger, einen Threaded-Push-Client zu schreiben als einen Threaded-Pull-Server?
ansible-pull.