Ansible vs. maßgeschneiderte Lösung
Ich habe einen Pool von ungefähr einem Dutzend Workstations unter Linux und ich brauche ein System, um sie irgendwie synchron zu halten (gleiche Software installiert, gleiche Konfiguration, gleiche Benutzer, ...) und mir auch zu ermöglichen, sie rechtzeitig weiterzuentwickeln (denken Sie an Konfigurationsänderungen , Treiberupdates, neue Software ...). Der Trick ist, dass manchmal einige von ihnen offline geschaltet und erst nach Wochen, sogar Monaten reaktiviert werden und manchmal neue Workstations hinzugefügt werden und von Grund auf neu konfiguriert werden müssen.
Ich habe über die Verwendung von Ansible nachgedacht und es scheint großartig zu sein, aber für meinen Anwendungsfall hat es zwei Nachteile:
- Es gibt keine automatische Aktualisierungsfunktion (wenn eine Box nach einer langen Zeit der Inaktivität gestartet wird, muss ich das Playbook manuell auf der Controller-Station ausführen).
- Nach Jahren in der Produktion würde das Spielbuch sehr lang werden. Es wäre sehr ineffizient, es auf einer Workstation ausführen zu müssen, auf der nur wenige Updates verpasst wurden. Selbst wenn alle Aufgaben idempotent sind, müsste jede von ihnen an die Workstation gesendet werden, um zu sehen, ob sie ausgeführt wurde oder nicht. Das Aufteilen des Playbooks in kleinere Teile ist ebenfalls nicht ideal, da es erforderlich wäre, den Überblick darüber zu behalten, was wo ausgeführt wurde.
Die Alternative, an die ich denke, besteht darin, ein Repository mit Skripten zu haben und diese mit GNU Make auszuführen. Make wird zum Aktualisieren von Zielen aus Quellen verwendet. Grundsätzlich wird ein Befehl für eine Quelldatei ausgeführt, um eine Ausgabe zu erzeugen (z. B. ein C-Programm in eine Binärdatei kompilieren). Wenn ich Skripte als Quellen behandle, würde ein Makefile wie dieses den Job erledigen:
TASKS= \
install_apps \
start_services \
add_users
TARGETS=$(TASKS:=.done) all: $(TARGETS)
%.done: %.sh
echo "running $<" ./$<
touch $@
Wenn eine der Workstations gestartet wird, kann sie automatisch das Skript-Repo abrufen und make ausführen . Mit diesem System werden die Aufgaben nur einmal und in der angegebenen Reihenfolge ausgeführt.
Fragen
- Denken Sie, dass die von mir aufgeführten Nachteile falsch sind? Vielleicht gibt es einen Weg / eine Problemumgehung, um mein Ziel mit Ansible zu erreichen
- Sehen Sie Probleme mit der von mir vorgeschlagenen Alternative? Beachten Sie jedoch, dass das oben genannte Makefile vereinfacht und nicht produktionsbereit ist.
Antworten
Der erste Nachteil, Ansible ist ein Push-basiertes System, kann durch die Verwendung von Ansible-Pull gemindert werden .ansible-pull
Ruft Playbooks aus einem VCS-Repo ab und führt sie für den lokalen Host aus
ansible-pull könnte durch cron oder ein Startskript ausgelöst werden.
Der zweite Nachteil von lang laufenden Playbooks ist irgendwie wahr. Ansible ist nicht das schnellste Konfigurationsmanagementsystem auf dem Markt. Die Ausführungszeit von Ansible kann jedoch mit Mitogen reduziert werden, und es ist relativ einfach, Bedingungen zu implementieren , um Teile eines Spielbuchs zu überspringen, um das Spiel wie folgt zu beschleunigen:
- name: Register a variable
ansible.builtin.shell: cat /etc/motd
register: motd_contents
- name: Use the variable in conditional statement to run long running play
include: otherplays.yaml
when: motd_contents.stdout.find('hi') != -1
Wenn Sie Playbooks mit Blick auf die Ausführungszeit schreiben, kann dies so schnell wie einfaches Bash sein.
Im Allgemeinen bietet Ansible viele hilfreiche Tools zum Konfigurieren von Systemen. Es gibt wahrscheinlich nichts in Ansible, was mit so etwas wie Makeund nicht implementiert werden könnte Bash. Der Vorteil von Ansible gegenüber Bash ist, dass viele Leute es einfacher finden, damit zu arbeiten, und dass der Code besser lesbar ist.