Dem Admin stehen heute zahlreiche spezielle Werkzeuge zur Orchestrierung und Automatisierung in der Cloud zur Verfügung. Doch oft braucht es die kostspieligen Neuanschaffungen aber gar nicht. Denn sind Tools wie Ansible, Salt, Puppet oder Chef bereits lokal im Einsatz, leisten diese auch viel bei der automatischen Verwaltung und Orchestrierung von Cloud-Workloads.
Automatisierung ist aus der IT der Gegenwart schlicht nicht mehr wegzudenken. "Was nicht automatisiert ist, existiert auch nicht" lautet eines der vielen Mantras, die die strengen Verfechter der Automation immer wieder anbringen. Angesichts eines weiterhin zunehmenden Fachkräftemangels bleibt Unternehmen heute praktisch ohnehin keine Wahl mehr – denn wer teures Personal einsetzt, um die immer selben banalen Wartungsaufgaben zu erledigen, erreicht den hohen notwendigen Grad an Innovation der Gegenwart ganz einfach nicht mehr.
Dass viele große und kleine Anbieter Stücke und Krümel dieses Kuchens abhaben wollen, verwundert nicht. Einem Unterthema der Automatisierung ist dabei in den vergangenen Jahren besonders viel Aufmerksamkeit zuteilgeworden: Work-loads in Clouds. Hier hat sich sogar eine eigene Untergattung der Automation herausgebildet, die "Orchestrierung", die zwar die Automatisierung in der Tat um mehrere Faktoren erweitert – letztlich aber doch wieder nur Automation ist.
Spezielle Cloudwerkzeuge oft nicht notwendig
Das Angebot an Orchestrierern und Automatisierern für die Verwaltung von Workloads in Clouds ist so vielfältig wie die verfügbaren Clouds selbst. Für jeden der großen Public-Cloud-Anbieter existieren spezifische Lösungen und für private Clouds etwa auf Basis von OpenStack gibt es weitere Werkzeuge. Da geraten Admins bisweilen ins Strudeln. Welche Lösung ist für den persönlichen Einsatzzweck die beste? Und lohnt es sich überhaupt, Unsummen für zusätzliche Software auszugeben?
Automatisierung ist aus der IT der Gegenwart schlicht nicht mehr wegzudenken. "Was nicht automatisiert ist, existiert auch nicht" lautet eines der vielen Mantras, die die strengen Verfechter der Automation immer wieder anbringen. Angesichts eines weiterhin zunehmenden Fachkräftemangels bleibt Unternehmen heute praktisch ohnehin keine Wahl mehr – denn wer teures Personal einsetzt, um die immer selben banalen Wartungsaufgaben zu erledigen, erreicht den hohen notwendigen Grad an Innovation der Gegenwart ganz einfach nicht mehr.
Dass viele große und kleine Anbieter Stücke und Krümel dieses Kuchens abhaben wollen, verwundert nicht. Einem Unterthema der Automatisierung ist dabei in den vergangenen Jahren besonders viel Aufmerksamkeit zuteilgeworden: Work-loads in Clouds. Hier hat sich sogar eine eigene Untergattung der Automation herausgebildet, die "Orchestrierung", die zwar die Automatisierung in der Tat um mehrere Faktoren erweitert – letztlich aber doch wieder nur Automation ist.
Spezielle Cloudwerkzeuge oft nicht notwendig
Das Angebot an Orchestrierern und Automatisierern für die Verwaltung von Workloads in Clouds ist so vielfältig wie die verfügbaren Clouds selbst. Für jeden der großen Public-Cloud-Anbieter existieren spezifische Lösungen und für private Clouds etwa auf Basis von OpenStack gibt es weitere Werkzeuge. Da geraten Admins bisweilen ins Strudeln. Welche Lösung ist für den persönlichen Einsatzzweck die beste? Und lohnt es sich überhaupt, Unsummen für zusätzliche Software auszugeben?
Oft genug ist die Antwort auf diese Frage ein klares Nein. Denn wenn ein Unternehmen bereits ein Automatisierungswerkzeug wie Ansible einsetzt, stehen die Chancen gut, dass dieses auch die Cloud beherrscht. Oft genug ist den Administratoren, die mit solchen Tools täglich arbeiten, das aber gar nicht bewusst. Dieser Artikel verfolgt entsprechend mehrere Ziele: Wir wollen die Sinne schärfen dafür, dass viele Automatisierer ab Werk mit Clouds gut umgehen können, und geben einen Überblick über die Cloudfähigkeiten der wichtigsten etablierten Anwendungen Puppet, Chef, Ansible und Salt. Daraus wiederum entsteht eine Marktübersicht, die Admins als Leitfaden für Automation in der Cloud dienen kann.
Vorher ist allerdings eine kleine Klarstellung notwendig: Denn natürlich haben die Automations- wie auch die Cloudanbieter längst bemerkt, dass Admins heute oft im Meer der vielen verfügbaren Ansätze untergehen. Passend dazu haben viele Hersteller mit den Cloudprovidern ein Wunschlos-glücklich-Paket geschnürt: Die jeweilige Automatisierung steht dann als Software-as-a-Service-Angebot innerhalb weniger Mausklicks zur Verfügung. Der Systemverwalter erspart sich etwa das teils komplexe Setup, zum Beispiel bei Puppet das Ausrollen des Puppet-Masters. Wo es solche Lösungen gibt, weisen wir auf sie hin. Im Fokus stehen jedoch klar die Fähigkeiten der einzelnen Automatisierer, Cloud-Workloads zu starten und zu verwalten.
Alle Werkzeuge, die wir betrachten, sind Open-Source-Software, die seitens ihrer Anbieter kostenlos zur Verfügung steht. Wir untersuchen, wie gut die einzelnen Automationslösungen mit den Public Clouds von AWS, Azure und GCP zurechtkommen. In Sachen Unterstützung privater Clouds werfen wir zudem einen Blick auf die OpenStack-Fähigkeiten der Anwendungen.
Puppet verbessert sich stetig
Puppet genießt bei Admins einen ausgezeichneten Ruf, auch weil die Software kontinuierlich besser geworden ist. War Puppet noch vor ein paar Jahren allzu sorglos im Umgang mit den zur Verfügung stehenden Ressourcen, haben die Entwickler dieses Problem mittlerweile in den Griff bekommen. Dabei hat die Puppet-Architektur sich in jüngerer Zeit kaum noch verändert. Die Entwickler raten nach wie vor zu einem Master-Agenten-Ansatz, bei dem den größten Teil der auf den Zielsystemen anzuwendenden Systemkonfiguration eine zentrale Instanz berechnet und an die Agenten weiterleitet.
Das klingt im Cloudkontext erstmal etwas absonderlich, denn schließlich sind die Zielsysteme hier ja keine Systeme an und für sich, sondern beispielsweise die AWS-APIs, die durch entsprechenden Zuruf Ressourcen anlegen oder löschen sollen. In der Tat ist die Cloudintegration in Puppet generell etwas komplexer, denn Puppet selbst bündelt das Thema Cloud gleich mit einer Vielzahl verschiedener kommerzieller Angebote, die meisten davon klar auf AWS gemünzt.
Puppet für AWS
So steht Puppet Enterprise etwa als Click-and-Collect-Anwendung im Marketplace von AWS zur Verfügung, Abrechnung über das AWS-Konto inbegriffen. Puppet Enterprise ist die große Automationslösung des Herstellers mit einer GUI und allen Schikanen, die in der AWS-spezifischen Version freilich gleich auch an die AWS-APIs angepasst ist, von diesen ihr Inventar über zu verwaltende Systeme pflegt und so weiter. Dass es zudem aus einer laufenden Puppet-Enterprise-Instanz in AWS möglich ist, AWS-Instanzen zu provisionieren, versteht sich da praktisch von selbst.
Wer es nicht ganz so umfassend braucht, greift besser zu OpsWorks, das sich aus dem AWS-Marktplatz heraus ebenfalls sehr schnell starten lässt. OpsWorks verfügt über deutlich weniger Features als Puppet Enterprise. Es handelt sich im Wesentlichen um einen durch AWS automatisch gemanagten Puppet-Master, der auf Zuruf des Admins mit verschiedenen Funktionen ausgestattet ist. Durch die Nutzung von OpsWorks erspart der Administrator sich Setup- wie Wartungsaufwand, den er andererseits dann aber an Amazon und Puppet bezahlt.
Was in Sachen Puppet und AWS auffällt: Das Themengebiet ist mit kommerziellen Angeboten so gepflastert, dass der "Selbermacher"-Use-Case gar nicht so einfach zu realisieren ist. Gemeint ist damit ein Ansatz, bei dem der Admin unter Benutzung der Puppet-FL/OSS-Komponenten ein minimales Setup baut und im Anschluss aus diesem seine AWS-Ressourcen steuert. Zweifelsohne hätte solch ein Ansatz den Vorteil, dass er ohne die Komplexität von OpsWorks oder Puppet Enterprise daherkommt, doch der Weg ist einigermaßen steinig. Was nicht zuletzt daran liegt, dass Puppet die benötigten Komponenten beinahe schon zu verstecken scheint. So gibt es in Puppet Forge etwa AWS-Module, die sich in ein lokales Puppet problemlos integrieren lassen, auch wenn deren letzte Version schon ein paar Tage auf dem Buckel hat. Und mit jenen Modulen ist es dann durchaus auch möglich, Ressourcen in AWS zu steuern.
Puppet auch für Azure und GCP
Deutlich weniger stark im Kreuzfeuer des Kommerzes finden sich Admins, die ihren Workload auf Microsoft Azure statt auf AWS betreiben. Hier zeigt sich, dass es weitreichende kommerzielle Bande zwischen Amazon und Puppet gibt. Denn wer einfach nur nach "Puppet" und "Azure" googelt, landet dort, wo der geneigte Systemverwalter eigentlich landen möchte, nämlich auf der Puppet-Forge-Seite mit den Azure-Modulen. Diese bieten grundlegende Features im Hinblick auf das Verwalten von Azure-Instanzen. Sie decken zwar nicht den kompletten Umfang der Azure-APIs ab, für den Alltag findet der Administrator hier aber alles, was er braucht. Die Forge-Module lassen sich wie üblich aus einer normalen Puppet-Installation heraus verwenden, sie sind mit Diensten wie Hiera integriert.
Wer weder bei AWS noch bei Azure sein Geld lässt, greift stattdessen vielleicht zu Googles Cloudangebot (GCP). Dessen Integration in Puppet ist mit der von Azure vergleichbar: In Ermangelung zentraler Marktplätze und ähnlicher Features steht auch hier ein einzelnes Puppet-Modul von Puppet Forge im Vordergrund, mit dem sich die meisten GCP-Dienste steuern lassen. Das gilt für die PaaS-Angebote von GCP ebenso wie für dessen Compute-Engine. Doch weil die Google-Module "community best-effort" sind, beherrschen sie nicht sämtliche aktuellen API-Befehle von GCP.
Bild 1: Chef kommt mit einer Mantelapplikation namens Automate daher, die eine GUI enthält, die für die Nutzung mit AWS notwendig ist.
Gute Zusammenarbeit zwischen Puppet und OpenStack
Eine private Cloud meistert Puppet mit Bravour – und nicht von ungefähr: Open-Stack und Puppet haben schon deshalb traditionell eine eher enge Bindung, denn die ersten Werkzeuge zum automatisierten Ausrollen von OpenStack basierten auf Puppet. Wer Red Hats Open-Stack-Distribution kauft, bekommt noch heute "OpenStack on OpenStack" ("Triple O") als Installationswerkzeug, das unter der Haube auf eine Mischung aus Puppet und Ansible setzt. Die OpenStack-Module, die Systemverwalter ebenfalls auf Puppet Forge finden, sind an die aktuellen OpenStack-APIs und ihre Befehle gut angepasst und unterstützen deren Funktionen beinahe vollständig.
Was Puppet und Cloudsupport angeht, ergibt sich somit ein heterogenes Bild: Für Azure, GCP und OpenStack bietet die Software Unterstützung über freie Module ohne viele kommerzielle Bande mit viel Unterstützung der Community. Puppet und AWS hingegen ist erkennbar darauf getrimmt, ein kommerziell erfolgreiches Produkt zu sein, dessen Funktionsumfang den der "Bastellösungen" bei Weitem übersteigt.
Chef: Besser als sein Ruf
Chef gilt hierzulande nicht unbedingt als sehr beliebtes Automatisierungswerkzeug. Das mag daran liegen, dass Puppet sehr früh in seiner Entwicklung den europäischen Markt bereits voll im Fokus hatte, während sich Chef eher darum kümmerte, das US-Geschäft nachhaltig zu entwickeln. Technisch gibt es allerdings keinen Grund, Puppet zu feiern und Chef zu verdammen. Wie üblich haben beide Lösungen stattdessen ihre eigenen Vor- wie Nachteile und die Nabelschau im Hinblick auf Cloudsupport stellt zum Teil sogar dieselben Herausforderungen in den Vordergrund.
So wird bei genauerer Betrachtung der AWS-Fähigkeiten von Chef schnell klar, dass auch Chef und AWS kommerziell im Bett liegen. Ein unmittelbares Pendant zur Kombination aus Puppet Enterprise und AWS gibt es für Chef zwar nicht. Ein direktes Gegenstück zu AWS OpsWorks for Puppet existiert in Form von AWS OpsWorks for Chef aber durchaus. Und hier bekommt der Administrator exakt das, was er in den meisten Fällen erwartet: Einen Chef-Master, den AWS pflegt und wartet, sodass es mit Chef ohne große Vorbereitungen losgehen kann.
Ganz so eng wie beim Konkurrenten Puppet scheinen die Bande zwischen Chef und AWS allerdings nicht zu sein. Denn beim Aufbau einer Chef-Umgebung mittels der FL/OSS-Komponenten finden sich Cookbooks und Recipes für den Umgang mit den drei großen Public Clouds online und von der Community gewartet ebenso vor wie auch für OpenStack. Der Hands-on-Charakter spielt hier also eine größere Rolle als bei der Konkurrenz.
Chef ist geeignet für alle Clouds
Wie für Puppet gilt auch für Chef: Wer seine Automatisierung neu plant und implementiert, wird sich zunächst mit der Chef-Infrastruktur befassen müssen. Chef selbst vermarktet ein kommerzielles Produkt namens "Automate", das aus mehreren Komponenten besteht. Dazu zählt auch eine GUI, unter der Haube werkelt bei Chef Automate aber das normale Chef, das sich auch ohne die anderen Chef-Komponenten nutzen lässt. Wer Chef so einsetzt, lässt sich aber eine Vielzahl von Features entgehen.
Chef InSpec ist ein Werkzeug zur automatischen Überprüfung physischer wie virtueller Umgebungen auf bestimmte Compliance-Faktoren. Und so wie der Hersteller Community-Module für die Steuerung von AWS-, Azure- und GCP-Ressourcen direkt aus Chef heraus anbietet, lassen sich via InSpec auch Ressourcen in diesen Clouds im Hinblick auf ihre Compliance prüfen. Hier bietet "inspec-aws" zweifelsohne den größten Funktionsumfang, doch auch für Azure und GCP stehen basale Implementierungen zur Verfügung. Bei Chef gibt sich insofern nicht nur die Software selbst cloudfreundlich, sondern auch ihr schmückendes Beiwerk.
Insgesamt ist die Steuerung von Cloud-ressourcen aus Chef heraus mithin sehr zufriedenstellend. Wer Chef bereits einsetzt, sollte jedenfalls Möglichkeiten evaluieren, dieses auch die eigenen Cloud-Workloads steuern zu lassen, statt für ein anderes Produkt eines Drittanbieters einzutreten.
Einfacher mit Ansible
Im Zirkus der kommerziellen Automatisierer nimmt Ansible heute sowas wie die Position "Back to the roots" ein. Das ist freilich kein Zufall, denn Ansible ist vor einigen Jahren überhaupt erst aus der Motivation heraus entstanden, eine leichtfüßige Alternative zu Puppet und Chef in die Welt zu bringen. Puppet und Chef boten seinerzeit bereits einen jeweils riesigen Funktionsumfang. Wer sich mit Automation noch nicht beschäftigt hatte, tat sich beim Einstieg in das Thema mit einer der beiden Anwendungen aber oft schwer. Denn neben der Automatisierung per se bekommt der Admin es sowohl bei Chef als auch bei Puppet mit einer eigenen deklarativen Skriptsprache zu tun, die in beiden Fällen gängigen Programmiersprachen zwar ähnelt, jedoch im Detail trotzdem deutliche Unterschiede aufweist.
Ansible macht es Automationsneulingen sehr viel leichter. Denn selbst auf einem frisch installierten Linux-System vergehen nur wenige Minuten, bis sich "ansible" aufrufen lässt – und zwar so, dass es auf anderen Systemen auch tatsächlich Konfigurationsschritte durchführt. Dafür ist kaum mehr nötig als das Ansible-Programm selbst, eine Angabe der Zielsysteme ("Inventar") sowie eine Anweisung, was Ansible auf den Zielsystemen tun soll ("playbook").
Dabei hat Ansible den Vorteil, dass es intern auf YAML setzt und die Struktur der Dateien, die die inhaltlichen Aufgaben enthalten, im Grunde der eines Shell-Skripts entspricht. Nacheinander definiert der Nutzer in seinen Ansible-Rollen und Playbooks die Befehle, zur Seite steht ihm in Form von Jinja wie auch bei anderen Werkzeugen eine Template-Engine, die den Umgang mit Konfigurationsdateien erleichtert.
Gutes Duo: AWS und Ansible
Die AWS-Module zur Steuerung von AWS-Ressourcen per Ansible kommen von Entwicklern aus der Open-Source-Szene. Das mindert allerdings nicht ihre Qualität: Neben zwei Plug-ins, mittels derer sich aus der Liste vorhandener EC2-Instanzen und S3-Buckets ein Inventar erstellen lässt, existieren auch diverse Ansible-Module für die Manipulation von Ressourcen. Das Anlegen eines Buckets in S3 ist damit ebenso möglich wie das Starten oder Löschen einer virtuellen Compute-Instanz.
Auch ein Bindeglied zu "CloudFormation" hat Ansible in seinen Modulen. CloudFormation ist Amazons Orchestrierer, sodass der Admin hier per Automatisierer den Orchestrierer steuert. Streng genommen ist das zwar doppelt gemoppelt, doch wer einerseits auf die Features von CloudFormation nicht verzichten will, andererseits aber dessen Syntax nicht erlernen möchte, freut sich über die Funktionalität.
Bild 2: Ansible Tower oder dessen freie Variante AWX nutzen die Module der Ansible-Community, um bestmögliche Unterstützung für öffentliche Clouds zu erreichen.g
Ansible unterstützt auch Azure und GCP gut
In Sachen Azure zeigt sich für Ansible ein sehr ähnliches Bild wie bei der Unterstützung für AWS, wobei die Azure-Module für Ansible sogar noch deutlich mehr As-a-Service-Dienste in Azure unterstützen als die Gegenstücke in AWS. Auch hier existiert ein Werkzeug, um ein Inventar laufender Instanzen abzufragen und unmittelbar zu nutzen. Wie im AWS-Beispiel wird es dadurch leichter, Ansible auch innerhalb der virtuellen Instanzen einzusetzen, weil es eine Liste dieser Instanzen hat.
Darüber hinaus lassen sich Ressourcen mittels Ansible auch in Azure sehr umfassend manipulieren. Das Starten und Stoppen von Instanzen ist ebenso wie das Anlegen und Anhängen persistenter, virtueller Speicherlaufwerke kein Problem. Über das Modul "azure_rm_resource" lassen sich sogar beliebige Azure-Ressourcen direkt aus Ansible heraus erzeugen, wobei das Autmationstool hier ein Stück weit schummelt: Die Ansible-Funktion setzt nämlich ein DICT (Dictionary Server Protocol) für die Instanz mit allen relevanten Werten voraus, und dann ließe sich das Ganze im Grunde auch per "curl"- oder "wget"-Befehl erreichen. Die meisten Azure-Module in Ansible machen dem Admin das Leben allerdings in der Tat leichter, weil sie nur wenige Parameter brauchen und den Rest autark aus der jeweiligen Azure-Umgebung herausfinden.
Ansible bietet auch umfassende Features im Hinblick auf die Public Cloud von Google. Der Umfang der ebenfalls von der Community gepflegten Google-Cloudmodule entspricht in etwa jenem der Azure-Module, ist also gut ausgebaut und weitgehend vollständig. Insgesamt präsentiert sich Ansible damit für die Standard-Public-Clouds als deutlich vielseitiger als die Konkurrenz.
Noch mehr Ansible verfügbar
Nicht unerwähnt bleiben soll an dieser Stelle, dass Ansible über Module aus der Community weitere Public Clouds und Virtualisierer unterstützt. OpenStack gehört dabei ebenfalls mit großem Funktionsumfang dazu und so erlaubt Ansible, mit den APIs etwa von Hetzner oder Cloudscale in der Schweiz zu arbeiten. Damit ist insgesamt erkennbar, dass Ansible offenbar auch andere Zielgruppen anspricht, die sich von der eher unkomplizierten Ansible-Struktur ein schnelles Vorankommen erhoffen – ein schnelleres jedenfalls als bei Puppet, Chef oder Salt.
Ansible mit GUI und als umfassendes Produkt existiert darüber hinaus in Form von Red Hats Ansible Tower. Dieses nutzt unter der Haube exakt jene Module, die wir bereits beleuchtet haben, kommt aber mit mehr Lametta daher. Ansible Tower gibt es ebenfalls als freie Version in Form von "AWX". Natürlich bietet Red Hat Tower auch für verschiedene Cloudplattformen an. Das Werkzeug steht mithin in Konkurrenz zu Produkten wie Puppet Enterprise oder SaltStack auf AWS.
Summa summarum präsentiert sich Ansible als der unkomplizierteste Automatisierer mit viel Cloudfunktionalität, dessen Funktionsumfang jenen der anderen Anwendungen deutlich übersteigt.
Mit Salt wird es kompliziert
Wo Ansible auf einfache Befehle und simple Syntax setzt, kommt Salt mit einer Server-Agent-Architektur daher. Intern nutzt Salt Python, sodass von einer simplen Syntax keine Rede sein kann. Wer Module für Salt entwickeln oder bestehende Module verstehen will, muss entsprechend Python beherrschen.
Wie die anderen Lösungen verfügt Salt zudem über eine Mantelanwendung namens "SaltStack", die eine eigene GUI mitbringt und neben der puren Automation auch weitere Features zur Verfügung stellt. Von größerem Interesse für diesen Artikel ist allerdings die Cloudfunktionalität und hier landet SaltStack nur knapp hinter Ansible. VMware hat SaltStack 2020 (damals noch als Teil von Dell) gekauft, um das eigene Portfolio in Sachen Cloudautomation deutlich zu erweitern. Und das hat ganz offensichtlich funktioniert, denn Salt gibt sich vielseitig.
Es sei noch darauf hingewiesen, dass die Begriffe Salt und SaltStack oft zwar synonym gebraucht werden, es aber nicht sind. SaltStack ist eine Art Gegenstück zu Chef Automate, Ansible Tower oder Puppet Enterprise und umfasst mehr Features als die bloße Automation. SaltStack ist als fertig gepacktes Bundle mittlerweile auf AWS allerdings nicht mehr verfügbar.
Bild 3: Dank umfangreicher Community-Arbeit unterstützen alle Werkzeuge – wie hier Ansible – auch OpenStack als Zielplattform.
Salt kann mit allen Clouds arbeiten
Salt ist die einzige hier betrachtete Anwendung, die einzelne API-Operationen unmittelbar auf die Kommandozeile des Systemverwalters durchreicht, ohne dabei die Salt-internen Aufzeichnungen durcheinanderzubringen. Von einer laufenden VM lässt sich aus Salt heraus dadurch ein Volume per AWS-API entfernen, und zwar so, dass Salt sich diese Änderung auch merkt und den neuen Status der Ressource auf AWS in Erinnerung behält. Darüber hinaus funktionieren sämtliche Standard-API-Aufrufe für EC2 auch aus Salt heraus, weil der Hersteller selbst die EC2-Integration entsprechend pflegt. Praktisch: Legt der Admin mit Salt eine VM in AWS an, bekommt diese gleich auch einen "Minion" installiert, also den Salt-Agenten.
Praktisch identisch verhält es sich mit der Unterstützung von Azure sowie GCP. Hier ist erkennbar, dass der Hersteller intern offenbar eine Liste von Basis-Features pflegt, die er für jede Cloudumgebung konsequent abdeckt. Hilfreich ist zudem, dass für Azure, AWS & Co. so genannte Development-Kits für Python exisitieren, die einen großen Teil der benötigten Funktionalität bieten. Und ganz im Sinne echter FL/OSS-Software erfindet Salt bei seiner Integration von Azure & Co. nicht das Rad neu, sondern setzt auf eben jene Komponenten. Das vermeidet nicht nur doppelten Code in Salt, sondern führt indirekt auch dazu, dass der Python-Code besser wird. Denn Fehlerkorrekturen spielt Salt an dessen Entwickler zurück.
Private Cloud mit Salt
Wer Salt auf eine private Cloud loslassen möchte, findet in der Software ausgezeichnete Unterstützung für OpenStack. Weil die OpenStack-APIs offen und gut dokumentiert sind, ist es für Anbieter leicht, entsprechenden Support in die eigenen Produkte zu integrieren.
Und genau das haben die Salt-Entwickler im Hinblick auf OpenStack auch getan. Instanzen und Volumes lassen sich dadurch ebenso leicht anlegen und löschen wie Abbilder. Und auch augenscheinlich eher weniger relevante Sonderfunktionen wie die mittels SSH exponierten Schnittstellen sind so aus Salt heraus steuerbar.
Fazit
Ansible, Chef, Puppet und Salt stellen eindrücklich unter Beweis, dass es nicht immer ein Spezialwerkzeug sein muss, um Workloads in Clouds zu starten und zu verwalten. Ein paar Kombinationen stechen dabei allerdings heraus: Puppet und AWS machen erkennbar gemeinsame Sache und bieten selbst Produkt-Bundles an, die normale Automation im Hinblick auf die verfügbaren Features klar übertrumpfen. Dafür greift der Administrator allerdings auch tief in die Tasche. Chef, Ansible & Salt geben sich etwas hemdsärmeliger und bieten zwar ähnliche Produkte wie Puppet, rücken diese kommerziell allerdings nicht so rabiat in den Vordergrund.
Indirekt gilt damit aber natürlich auch: Wer noch vor der Wahl des geeigneten Automatisierers für die eigene Umgebung steht, sollte das Thema Cloud zumindest als einen Faktor mit auf der Rechnung haben. Die Pflicht erledigen die Probanden ohne Makel. Im Detail ergeben sich aber Unterschiede, die eine der Lösungen für einzelne Einsatzzwecke geeigneter oder auch weniger geeignet erscheinen lassen können. Immerhin: Weil alle genutzten Lösungen auf Open-Source-Software basieren, ist ausgiebiges Testen vor einer Entscheidung möglich – und dringend empfohlen.