Frage Konfigurationsmanagement: Push- und Pull-basierte Topologie


Die etablierteren Konfigurationsmanagementsysteme (CM) wie Puppet und Chef verwenden einen pull-basierten Ansatz: Kunden fragen regelmäßig einen zentralen Master nach Updates ab. Einige von ihnen bieten ein herrenlos (push-based), aber es ist "nicht für die Produktion" (Saltstack) oder "weniger skalierbar" (Puppet). 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 Pull-Master als Push-Agenten hinzuzufügen?

Zum Beispiel, agiletesting.blogspot.nl schreibt:

In einem Pull-System kontaktieren Clients den Server unabhängig voneinander, so dass das System insgesamt skalierbarer ist als ein Push-System

Auf der anderen Seite zeigt Rackspace, dass sie es können handhaben 15K Systeme mit einem Push-basierten Modell.

infastrukturen.org schreibt:

Wir schwören auf eine Pull-Methode zur Pflege von Infrastrukturen mit einem Tool wie SUP, CVSup, einem rsync-Server oder cfengine. Anstatt die Änderungen an die Kunden weiterzuleiten, muss jeder einzelne Client-Rechner dafür verantwortlich sein, den Gold-Server beim Booten abzufragen, und regelmäßig danach, um seine eigene Rev-Ebene aufrechtzuerhalten.   Bevor wir diesen Standpunkt einnahmen, haben wir umfangreiche Push-basierte Skripte entwickelt, die auf ssh, rsh, rcp und rdist basieren.   Das Problem, das wir mit den r-Befehlen (oder ssh) fanden, war folgendes: Wenn Sie ein r-befehlsbasiertes Skript ausführen, um eine Änderung auf Ihre Zielmaschinen zu übertragen, ist die Wahrscheinlichkeit groß, dass wenn Sie mehr als 30 Zielhosts haben zu jeder Zeit unten sein. Die Wartung der Liste der in Auftrag gegebenen Maschinen wird zum Albtraum.   Im Laufe des Schreibens von Code, um dies zu korrigieren, werden Sie mit aufwendigem Wrapper-Code enden, mit dem Sie umgehen müssen: Timeouts von toten Hosts; tote Hosts protokollieren und erneut versuchen; Forking und Ausführen von parallelen Jobs, um zu versuchen, viele Hosts in einer angemessenen Zeit zu treffen; und schließlich das Erkennen und Verhindern des Falls, alle verfügbaren TCP-Sockets auf dem Quellrechner mit allen ausgehenden rsh-Sitzungen zu belegen.   Dann haben Sie immer noch das Problem, das, was Sie gerade gemacht haben, in die Installationsabbilder für alle neuen Hosts zu übernehmen, die in der Zukunft installiert werden sollen, sowie für alle Hosts, die sterben und morgen neu erstellt werden müssen.   Nach den Schwierigkeiten, die wir durchführten, um die r-Befehl-basierte Replikation zu implementieren, fanden wir heraus, dass es sich einfach nicht lohnt. Wir planen nicht, eine Infrastruktur erneut mit r-Befehlen zu verwalten oder mit irgendeinem anderen Push-Mechanismus. Sie skalieren nicht so gut wie Pull-basierte Methoden.

Ist das nicht ein Implementierungsproblem statt eines architektonischen Problems? Warum ist es schwieriger, einen Thread-Push-Client als einen Thread-Pull-Server zu schreiben?


21
2018-01-18 10:13


Ursprung


Nur eine Anmerkung, Ansible kann auch per Pull ziehen ansible-pull. - ceejayoz
Ein großer Vorteil ist das Durchqueren von NATs und Firewalls. Dies ist oft kein Hindernis, aber manchmal ist es ein Game Changer. - Dan Garthwaite
SALT verwendet Pub / Sub ZeroMQ. Was ist anders. - Dan Garthwaite
Es gab eine ausführliche Debatte darüber in der Anwendungsbereitstellung versus Systemkonfiguration thread auf der Mailingliste [devops-toolchain] [1]. [1]: code.google.com/p/devops-toolchain - sciurus
btw - HP Server Automation ist Push-modelliert und kann Zehntausende von Geräten verwalten {Offenlegung - Ich bin ein Automatisierungsarchitekt für einen HP Partner} - warren


Antworten:


Das Problem mit Push-basierten Systemen ist, dass Sie ein vollständiges Modell der gesamten Architektur auf dem zentralen Push-Knoten haben müssen. Sie können nicht auf eine Maschine stoßen, von der Sie nichts wissen.

Es kann natürlich funktionieren, aber es braucht viel Arbeit, um es synchron zu halten.

Mit Dingen wie Mcollective können Sie Puppet und andere CMs in einen Push verwandeln basiertes System. Im Allgemeinen ist es trivial, ein Pull-System in ein Push-System zu konvertieren, aber nicht immer einfach in die andere Richtung zu gehen.

Es gibt auch die Frage der Organisationspolitik. Ein Push-basiertes System legt alle Kontrollhände der zentralen Admins. Es kann sehr schwierig sein, die Komplexität auf diese Weise zu verwalten. Ich denke, das Skalierungsproblem ist ein Ablenkungsmanöver, beide Ansätze skalieren, wenn man sich nur die Anzahl der Clients anschaut. In vielerlei Hinsicht ist Push einfacher zu skalieren. Die dynamische Konfiguration bedeutet jedoch mehr oder weniger, dass Sie mindestens eine Pull-Version der Client-Registrierung haben.

Letztendlich geht es darum, welches System dem Workflow und der Eigentümerschaft in Ihrer Organisation entspricht. Pull-Systeme sind in der Regel flexibler.


8
2018-01-19 17:49



Vielen Dank! Aber warum würde die dynamische Konfiguration Pull beinhalten? Ansible verwendet beispielsweise dynamischen Push. Es scheint also, dass die Tatsache, dass Puppet keinen dynamischen Push machen kann, eine Beschränkung der Implementierung ist, keine Einschränkung der Architektur, oder? - Willem
@Willem Eine wirklich "dynamische" Umgebung bedeutet, dass eine neue Maschine jederzeit und überall angezeigt werden kann und eine Konfiguration erfordert. Bei einem Push-basierten System müssen Sie dieses System auf dem zentralen Knoten konfigurieren. Ein pull-basiertes System kann eine (generische) Konfiguration abrufen, ohne dass der Umgebungsadministrator etwas an den Konfigurationsservern vornehmen muss. - voretaq7
Zabbix entdeckt Hosts, Ansible kann ein dynamisches Inventar verwenden, um eine Pull-Konfiguration an neu entdeckte Hosts zu übertragen. - bbaassssiiee
yea, ansible kann viele Quellen für sein dynamisches Inventar verwenden, also zum Beispiel die ESX API. Auf diese Weise wissen Sie sofort nach der Erstellung einer VM Bescheid und können Spiele mit einer Musterübereinstimmung ausführen. - J. M. Becker


Für den Fall, dass es für irgendjemanden von Interesse ist, kann ich zumindest einen Benutzererfahrungsbericht geben, nachdem ich zum ersten Mal die Push-Funktion von Ansible im Kontext des Patch-Managements von Multi-Host-Setups für unternehmenskritische Systeme genutzt habe in der Amazon Cloud. Um meine Vorurteile oder Voreingenommenheiten zu verstehen, sollte ich erklären, dass ich eine Vorliebe für Ruby auf der Automation-Scripting-Ebene habe und in der Vergangenheit Projekte eingerichtet habe, um die Master-Agent-Marionettenkonfiguration pro-Projekt-VPC zu verwenden. Meine Erfahrung täuscht also über vergangene Vorurteile hinweg, wenn es welche gibt.

Meine jüngsten Erfahrungen waren sehr günstig, um dynamisch auf einen sich ändernden Stand von Dutzenden bis zu Hunderten von Servern zu gelangen, die nach oben oder unten skaliert, beendet und aktualisiert werden können. In meiner Situation war ein einfacher Ansible 1.7 Ad-hoc-Befehl alles, was ich brauchte, um den Patch zu machen. Im Hinblick auf die Effektivität der Einrichtung eines AnsibleControllers (auf einem t2.micro) pro VPC für den Zweck, beabsichtige ich in Zukunft, die Technik für komplexere Anforderungen zu erweitern.

Lassen Sie mich zu der in diesem Thread gestellten Frage zurückkehren: Vor- und Nachteile von Push in einem sich dynamisch verändernden Nachlass.

Die Annahmen der Art von Server-Estate, auf die ich abzielte, waren:

  • Keine Annahme, dass IP-Adressen oder von Amazon generierte lokale Hostnamen dauerhaft sind - sie können kommen und gehen
  • Alle Instanzen wurden aus Maschinenabbildern erstellt, die bereits die Möglichkeit hatten, ssh-Zugriff von einem einzigen privilegierten administrativen Benutzer aus möglich zu machen
  • Um Server zu individualisieren und sie möglicherweise in Gruppen entsprechend ihrer Funktion oder gemäß dem Entwicklungsstadium (z. B. Test oder Prod) zu partitionieren, würde dies durch das Starten von spezifischen Amazon-Tags von vereinbarten konventionellen Namen erfolgen
  • Dass ich Linux- und Windows-Server separat mit verschiedenen Ad-hoc-Befehlen patch-administrieren würde, sodass Linux-spezifische Logins einfach fehlschlagen können, wenn ich einen Windows-Server kontaktiere, war vollkommen akzeptabel

Unter diesen Voraussetzungen ist es sehr einfach, ein Maschinenabbild eines AnsibleControllers zu erstellen, um es in zahlreiche VPCs zu laden und (innerhalb der vorhandenen Serverkonten) mit den Anmeldeinformationen zu konfigurieren. Automatisiert innerhalb jeder Instanz erstellt aus dem Bild ist

  1. Ein Cron-Job, um den Patch in regelmäßigen Abständen auf laufende Server zu übertragen, so dass in regelmäßigen Abständen auf den erforderlichen Status zugegriffen wird
  2. Eine Möglichkeit, das Ansible-Inventar in jedem dieser Intervalle zu berechnen.

Der zweite Artikel kann bei Bedarf relativ ausgefeilt werden (über die Info-Struktur des Ansible-Inventars). Wenn jedoch keine Ausgereiftheit benötigt wird, ist hier ein sehr einfaches Beispiel für ein Skript zur Berechnung aller Amazon EC2-Instanzen in jedem Cronintervall und zur Weiterleitung der Ergebnisse in eine entsprechende Inventardatei (z. B. / etc / ansible / hosts) ...

#!/bin/bash
# Assumes aws-cli/1.3.4 Python/2.6.9 Linux/3.4.73-64.112.amzn1.x86_64 or greater
# http://aws.amazon.com/releasenotes/8906204440930658
# To check yum list aws-cli
# Assumes that server is equipped with AWS keys and is able to access some or all
# instances in the account within it is running.
# Provide a list of host IPs each on a separate line
# If an argument is passed then treat it as the filename, whether local or absolute 
# path, to which the list is written

function list-of-ips {
    /usr/bin/aws ec2 describe-instances --filters '[ {"Name": "instance-state-code", "Values": [ "16" ] } ]' | grep -w PrivateIpAddress | awk  '{x=$2; gsub("\"","", x); gsub(",","", x); if(x && FNR!=1){print x;}}' | uniq
 }

if [ -n "$1" ]; then
   list-of-ips > "$1"
else
   list-of-ips
fi

Die einzige Einschränkung für den Anwendungsfall ist, dass der Patch-Befehl idempotent sein sollte. Es ist wünschenswert, vorab zu testen, um sicherzustellen, dass dies erfüllt ist, um sicherzustellen, dass das Pflaster genau das tut, was beabsichtigt ist.

Zusammenfassend habe ich einen Anwendungsfall illustriert, in dem dynamischer Push gegen die gesetzten Ziele wirksam ist. Es ist eine wiederholbare Lösung (in dem Sinne, dass es in ein Bild eingekapselt ist, das in mehreren Konten und Regionen ausgerollt werden kann). Nach meiner bisherigen Erfahrung ist die dynamische Push-Technik viel einfacher zu erstellen und in Aktion zu setzen als die Alternativen, die uns derzeit zur Verfügung stehen.


10
2017-10-12 15:20



//, @jonz, das ist die Art von Diskussion, für die erfahrene Entwickler das Stack-Exchange-Modell lieben. Ich mag besonders die Begriffe, die Sie gewählt haben, und dass diese Antwort zuerst Annahmen auflistet. - Nathan Basanese