Vor ein paar Tagen hatte ich die Gelegenheit, einen ganzen Tag lang mit Salt(stack) zu arbeiten. Bei meinem aktuellen Projekt verwenden wir ein anderes Konfigurationsmanagement-Tool und meine Kollegen dort behaupteten, dass Salt einfacher und produktiver sei. Die Herausforderung war leicht gestellt. Sie behaupteten, dass ein paar Leute ohne Salt-Erfahrung, wenn auch mit ein wenig Konfigurationsmanagement-Wissen, an einem einzigen Tag produktiv sein würden.
Meine Vorbereitung war einfach, ich musste nichts über Salt wissen....done!
Während des Tages arbeitete ich Seite an Seite mit einem anderen Kollegen, der wenig bis gar nichts über Salt wusste. Als der Tag begann, war der ursprüngliche Plan, eine schnelle einstündige Einführung in Salt zu geben. Aber da wir uns gerne direkt in die Materie stürzen, wurde diese Einführung übersprungen und wir legten einfach los. Wir verwendeten eine bestehende Vagrant-Box, die einen Salt-Master und einen Salt-Minion hochfuhr, mit denen wir arbeiten konnten. Das Ziel war es, Salt dazu zu bringen, einen Rechner für XL Deploy bereitzustellen, komplett mit den Anpassungen, die wir bei unserem Kunden vorgenommen haben. Denken Sie an benutzerdefinierte Plugins, Protokollierungskonfigurationen und benutzerdefinierte Bibliotheken.Also legten wir los und führten die Schritte aus, die wir für die Installation von XL Deploy benötigten. Die Schritte waren relativ einfach: Erstellen Sie einen Benutzer und eine Gruppe, holen Sie sich die Installationsdateien von irgendwoher, installieren Sie den Server, initialisieren Sie das Repository und führen Sie es als Dienst aus.Das Erste, was mir auffiel, war, dass wir einfach loslegen konnten. Für die Aufgaben, die wir zu erledigen hatten (Herunterladen, Entpacken usw.), brauchten wir keine zusätzlichen Zustände. Tatsächlich haben wir während der gesamten Übung nie einen zusätzlichen Status heruntergeladen. Alles, was wir brauchten, wurde von Salt von Anfang an bereitgestellt. Zugegeben, wir haben nichts Besonderes gemacht, aber es ist nicht selbstverständlich, dass alles vorhanden ist.
Im Laufe des Tages sind wir bei der Entwicklung unseres Salt-Status wie bei einem Shell-Skript vorgegangen. Wir begannen von vorne und fügten die erforderlichen Schritte hinzu. Wenn wir auf Probleme mit der Reihenfolge der Schritte stießen, haben wir einfach etwas umgestellt, damit es funktionierte. Dinge wie das Anlegen eines Benutzers, bevor ein Dienst als dieser Benutzer ausgeführt wird, konnten auf diese Weise leicht gelöst werden.
Salt verwendet yaml, um einen Status zu definieren, und das war ziemlich einfach zu verwenden. Manchmal war die verwendete Benennung seltsam. Zum Beispiel verwendet salt.state.archive den Parameter "source" für den Quellort, aber "name" für den Zielort. In der Dokumentation ist zwar klar angegeben, wofür der Parameter verwendet wird, aber es ist trotzdem eine seltsame Konvention.
Wir haben auch festgestellt, dass die Rückmeldungen von Salt manchmal etwas dürftig sind. Mehr als einmal haben wir einen Befehl eingegeben, und es passierte eine ganze Weile lang nichts. Manchmal gab es schließlich eine Menge Ausgaben, manchmal aber auch nicht. Das ist mein größter Kritikpunkt an Salt: Sie erhalten nicht immer die Rückmeldung, die Sie sich wünschen. Dinge wie die Verwendung von Vorlagen und hierarchischen Daten (die so genannten Pillars) erwiesen sich als einfach zu verwenden. Salt verwendet jinja2 als Template-Engine. Da wir nur einfache Variablenersetzungen benötigten, ist es schwer zu sagen, wie nützlich jinja ist. Für unsere Zwecke war es gut geeignet. Die Verwendung von Pillars erwies sich als ebenso einfach. Das einzige Problem, auf das wir hier gestoßen sind, war, dass wir unseren Pillar zu unserer Maschinenrolle in der top.sls hinzufügen mussten. Danach konnten wir die Pillar-Daten bei Bedarf verwenden.
Das größte (und einzige wirkliche) Problem, auf das wir stießen, war, XL Deploy als Dienst laufen zu lassen. Wir haben zwei Ansätze ausprobiert, einen mit dem Standard-Service-Mechanismus von Linux und den zweiten mit Upstart. Mit Upstart war es sehr einfach, den Dienst zu starten, aber er ließ sich nicht richtig beenden. Mit dem Standardmechanismus konnten wir den Dienst nicht dazu bringen, während eines Salt-Laufs zu starten. Wenn wir ihm bestimmte Befehle schickten, startete (und stoppte) er ordnungsgemäß, aber nicht während eines Laufs. Wir fügten schließlich ein Post-Stop-Skript zur Uptart-Konfiguration hinzu, um sicherzustellen, dass alle (untergeordneten) Prozesse ordnungsgemäß gestoppt wurden.
Am Ende des Tages hatten wir einen Status, der eine Maschine mit XL Deploy einschließlich aller gewünschten Anpassungen bereitstellte. Salt tat im Grunde, was wir wollten. Abgesehen von dem Dienst lief alles reibungslos. Zugegeben, wir haben nichts Exotisches gemacht und uns auf rudimentäre Aufgaben wie Herunterladen, Entpacken und Kopieren beschränkt, aber die Implementierung dieser einfachen Aufgaben blieb einfach und unkompliziert. Insgesamt hat Salt das getan, was man erwarten kann.
Aus meiner Sicht wurde das Ziel, an einem einzigen Tag produktiv zu sein, leicht erreicht. Da die Implementierung so einfach war, bin ich zuversichtlich, Salt auch für komplexere Aufgaben einsetzen zu können. Alles in allem hat Salt also einen positiven Eindruck hinterlassen und ich würde gerne mehr damit machen.
