[Musik]
Hallo und herzlich willkommen zur 20. Tür des Focus und Niedungsadventskalenders.
Heute geht es um ein Tool, das noch nicht unbedingt so bekannt ist,
aber durchaus seine Daseinsberechtigung hat.
Es geht nämlich um Ansible Semaphore.
Dazu habe ich mir den Felix eingeladen.
Moin.
Felix, du bist eher so Ansible Tower-Ultra, wenn ich das richtig in Erinnerung habe, oder?
Zumindest ist das die Ecke, aus der wir kommen, Ansible Tower und AWX.
Das ist interessant an der Semaphore, dass ich damit ein Tool in den Bereich eines anderen Tools vorwarte,
was da schon manchmal passiert, aber auch nicht so häufig.
Man muss damit ein bisschen abwägen, oder alle Praktiker so ein bisschen abwägen.
Ist das jetzt für meine Nische, für das, was ich benutze, ein Ersatz zum Beispiel?
Will ich jetzt mein altes Tool ablösen?
Das ist ja wahrscheinlich meistens eher nicht der Fall sein wird.
Aber vor allen Dingen für Neueinsteiger oder Leute, die sich noch nie damit beschäftigt haben,
wie kann ich Ansible weiter automatisieren?
Was kann ich dafür Tools zum Rumbauen, außer eben das normale Kommando-Zuallentool?
Und die müssen sich jetzt natürlich fragen, wo gehe ich jetzt hin?
Reicht für mich zum Beispiel Semaphore? Will ich zu AWX?
Brauche ich direkt quasi Tower Enterprise? Oder vielleicht ist es ja auch gar so.
Vielleicht lassen sie sich auch gar nicht so in der Stufe einordnen.
Vielleicht ist es ja so ein bisschen eine andere Sortierung.
Ich glaube, darum müssen wir uns mal ein bisschen unterhalten.
Und vor allen Dingen möchtest du uns das Tool einfach mal vorstellen.
Genau. Lass uns aber gerade nochmal kurz abstecken.
Ansible Tower bzw. so wie es jetzt heißt, Ansible Automation Platform 2.0.
Wo setzt du das denn ein?
Und hast du vielleicht auch schon mal Kundinnen vorgefunden, für die das ein bisschen oversized war?
Oder ist das deine Lösung für alle Kundinnen, mit denen du zu tun hast?
In dem Gebiet gibt es auf jeden Fall eine große Bandbreite von Automatisierungslösungen, die man einsetzen kann.
Also wir haben ja verschiedenste Asse im Ärmel, was man da irgendwie bauen kann.
Vor allen Dingen für die Automation Platform brauchen wir ja noch ein paar Randbedingungen drumrum.
Also zum Beispiel müssen wir ja inzwischen Kubernetes-Cluster bauen und solche Sachen.
Das ist ja ein bisschen doll manchmal als Hürde.
Und je nachdem, was da schon an Vorbedingungen gegeben sind.
Wir können ja eben ähnliche Prozesse auch abbilden über andere Pipeline-Lösungen.
Ob das jetzt einfach nur die Features ist von GitLab, irgendwelche Pipelines, ob das jetzt ein Jenkins ist, alles Mögliche.
Nur halt wenn es dann in die feingranulare Richtung geht, also feingranulare Abstimmung.
Wer darf was wann wie ausführen?
Wer darf auf welche Ressourcen zugreifen?
Vor allen Dingen halt auf Inventories, auf bestimmte Secrets und solche Sachen.
Da braucht man natürlich dann so dedizierte Lösungen.
Und vor allen Dingen eben im Enterprise-Umfeld ist dann, ja, Tauern oder der kleine Bruder AWX eine, ja, Pragmat oder eine gute Lösung auf jeden Fall.
Ja, ist echt prinzipiell ähnlich.
Also ich habe das ganz häufig, dass ich bei Kund*innen irgendwie eine Ansible-Schulung halte und dann machen die ihre ersten Schritte damit, finden das toll.
Und aber irgendwann, wenn sie dann im Team zu dritt oder viert damit arbeiten wollen, dann stellen sie fest, naja, das nur auf der Kommandozeile ist dann vielleicht doch ein bisschen schwierig.
Ja, weil da muss man sich immer genau absprechen und koordinieren, wer was wann macht.
Und da ist halt eben Tauern oder AWP eine gute Lösung bzw. das kostenlose Upstream-AWX.
Aber das ist halt oftmals mit Kanonen auf Spatzen geschossen, wie du sagst.
Man braucht da halt einen Kubernetes oder irgendwas Vergleichbares.
Und wenn du wirklich ein kleines Team hast mit einigen wenigen Usern, ist das zu viel.
Und diesen Gap kann halt eben Ansible Simr4 schließen.
Genau, deswegen lasst uns mal schauen, was es damit so auf sich hat.
Also Ansible Simr4 ist ein weiteres Projekt, das jetzt nicht unbedingt von den gleichen Entwickler*innen kommt, die auch eben an AWX oder AWP arbeiten.
Ist eine Anwendung, die in GoLang und Vue.js geschrieben ist.
Ist also eine Applikation, die eine Web-Oberfläche hat.
Das heißt, man braucht dann halt eben nicht mehr die Kommandozeile, auf der man die ganzen Playbox und Rollen usw. ausführt.
Und diese Oberfläche, die unterstützt mehrere Datenbank-Backends.
Also man kann da definieren, welcher User darf welche Dinge tun.
Und da ist einmal unterstützt MySQL, PostgreSQL oder BoltDB.
Also das ist hier so ein Asset-Key-Value-Datenbank-Backend, das in Go geschrieben ist.
Und der Haupt-Use-Case für dieses Tool ist es eben, Playbooks auszuführen.
Das heißt man hat mann, man hat eine GUI, kann dann halt eben auswählen, welche Playbooks da zur Verfügung stehen, kann die dann mann, auch ausführen.
Oder halt eben auch gescheduled, dass man zum Beispiel so Dinge tut, wie einmal am Tag immer einen Rollout auf einer Reihe von Servern durchführen beispielsweise.
Ein Playbook allein macht ja auch nicht glücklich, dazu braucht man natürlich noch weitere Informationen, wie so ein Inventory, wo eben drin steht, welcher Server in welcher Gruppe wo, über welche IP-Adresse zu erreichen ist.
Es gibt eine Benutzer- und Credentials-Verwaltung, also Benutzer im Sinne von die Anwender*innen, die die GUI benutzen dürfen.
Credentials im Sinne von, mit welchem Benutzernamen und Passwort oder mit welchem Key logge ich mich auf dem Datenbank-Server oder auf anderen Systemen ein, die ich fernsteuern will.
Und die Playbooks, die wir ausführen wollen, oder die Enzylrollen, die sind ja in der Regel in einem Git Repository hinterlegt.
Auch das wird dann hier entsprechend gepflegt.
Das Ganze kann sich dabei auch in ein LDAP integrieren, das heißt man muss diese ganzen Benutzer nicht lokal anlegen, da kommen wir gleich noch drauf zu, das ist nämlich gar nicht so benutzerfreundlich wie es sein könnte.
Also man kann das auch einfach sich direkt aus einem LDAP-Verzeichnis ziehen. Das Ding hat selbst auch wieder eine Rest-API, das heißt die Knöpfe in der GUI, die kann man sich auch theoretisch wieder in einem Skript zusammenbauen, dass das automatisiert geschieht beispielsweise.
Man könnte auch ein Enzyl-Playbook schreiben, das über die Rest-API auf Enzyl-Simr-Forum ein anderes Enzyl-Playbook ausführt.
Also so viel dazu. Und es gibt eine Telegram-Integration für Benachrichtigungen. Das sind so die fünf Key-Features, die wir hier mal zusammenfassen können.
Und das ist natürlich nur eine Teilmenge von dem, was eben AAP kann, ne Felix?
Ja genau. Das ist, wo es zum Beispiel, die Frage könnte ich schon mal stellvertretend stellen, also stellvertretend für alle stellen, um da so einen Unterschied mehr herauszuarbeiten.
Bei Semaphore gibt es keine Ausführungsumgebung, oder? Also keine Execution-Container oder ähnliches, sondern im Prinzip passiert alles auf dem Host, auf dem ich das halt installiert habe.
Genau, richtig. Das ist ein großer Unterschied. Man kann ja dann so, Enzyl nennt das ja Execution-Environments, dass man sich so einen kleinen Container baut,
wo eben deiner Enzyl-Runtime mit spezifischen Plugins auch installiert ist, Dinge, die du von der Enzyl-Galaxy zum Beispiel haben möchtest.
Das gibt es hier nicht. Also das ist auch einfach nicht für so große Setups gedacht, muss man ganz ehrlich sagen.
Deswegen, auf der Maschine, wo man es installiert, oder in dem Container, wo das Ganze ausgerollt wird, da ist eben ein Enzyl Core installiert.
Bei dem Container Image ist es die 2.13.6. Ja und dann kann man natürlich auch auf die Konsole und kann sich da Enzyl-Module nachinstallieren.
Genau. Aber dadurch, dass es zum Beispiel, also viele Enzyl-Nutzer werden das kennen, man spürt an vielen Stellen oder eigentlich an jeder Stelle von Enzyl immer den unterliegenden Core.
Das haben nicht alle Tools, dass man halt tatsächlich so doll merkt, quasi in welcher Sprache es geschrieben hat und wo eigentlich das Ganze herkommt.
Bei Enzyl ist diese Kopplung zu Python halt sehr stark. Also man merkt unter anderem relativ häufig das Paket, also dass man bestimmte Dependencies von Pip braucht oder zum Beispiel solche Sachen,
dass bestimmte Dinge halt mit bestimmten Python-Versionen einfach besser funktionieren, einfach weil dazwischen keine Kompilierungsschicht steht, sondern weil halt die Plugins, die man halt oder die Module, die man in den Playbooks benutzt, direkt an den Interpreter des Host-Systems halt gehen.
Und ja, das ist halt vor allem, wenn die Umgebung wächst und man halt viele verschiedene Playbooks hat, verschiedene Collections verwendet, die zum Teil eben auf bestimmte Pip-Pakete angewiesen sind,
dann wird man hier halt nicht drum herumkommen, eben bestimmte Sachen auf der Plattform zu installieren, auf dem Host zu installieren, der das Ganze ausführt.
Aber es ist in dem Sinne tatsächlich, also wenn man überlegt, okay, wie fängt man meistens an?
Die meisten Leute, die halt eben mit der automatisieren, also da mit Enzyl-Sachen anfangen, haben ja im Prinzip zwei Einstiegspunkte.
Entweder man macht das halt von seiner Entwicklermaschine aus, das heißt tatsächlich gibt es einen Host, der eben zugreifen kann auf alle zu automatisierenden Hosts. Das ist dann, beim Laptop, das hängt dann ein bisschen von der Netzwerkerarchitektur ab, ob das überhaupt möglich ist, ob man auf diesem Weg halt anfangen kann.
Oder wenn das eben nicht möglich ist, wenn der quasi erste Entwickler, der halt anfängt, diesen Zugriff gar nicht hat, dann wird meistens eine initiale VM aufgesetzt, die eben in dem entsprechenden Zielnetz die Rolle des Automation-Controllers hat.
Und da liegen dann die Playbooks lokal auf der Platte.
Dann kommt man relativ schnell auf dieser Reise eben, wenn man halt dann das Team dazu holt, man zeigt es dem zweiten, dem dritten Kollegen zu dem Punkt, dass man eben auf einem Repo, also auf einem Repo arbeitet oder am Anfang vielleicht noch nicht mal mit einem Repo in einem Folder arbeitet.
So, dann kommen die ersten Themen, vielleicht sollten wir es versionieren.
Und an dem Punkt kann es dann durchaus sinnvoll sein, okay, wir haben halt hier eben unseren Automation-Controller, unsere bestehende VM, die hat die Netzwerkanbindung, wir haben die Playbooks.
Und wir machen jetzt eben voll eine Migrationsfahrt, wir schieben unsere Playbooks in Git, wir installieren uns hier das Semaphore.
Das macht im Prinzip dasselbe, was wir vorher auch gemacht haben, führt halt die Sachen hier auf unserem Host aus.
Aber wir haben halt eben die Möglichkeit lokal zu entwickeln, unsere IDEs zu verwenden, zum Beispiel in Git zu pushen und dann halt auf Play zu drücken und schon mal eben diese erste Evolutionsstufe zu machen auf diesem Fahrteil zur Automatisierung, also mit Ansible.
Also von daher sehe ich genau an der Stelle eigentlich einen Sweet Spot für dieses Tool, weil eben auch die Integration von AWX dann wieder schon ein Step ist, vor allen Dingen eben seit die Installation primär eben ein Kubernetes erfordert.
Weil es noch ein Ta auspacken war, war das vielleicht nicht so ein großes Ding, aber damit holt man sich dann natürlich noch mal einen großen Stack rein.
Also da kann schon mal so ein Projekt eskalieren und sagen, ok, was brauchen wir denn jetzt alles, um sicher eine Kubernetes zu betreiben, wenn man dann zum Thema Kubernetes Storage kommt für die Datenpacken darunter, dann hat man schon mal ein ganzes anderes Projekt an der Backe.
Ja, das eskaliert halt gnadenlos und das halt super, super schnell.
Also ich kenne echt irgendwie Kunden, die ein bisschen Ansible gemacht haben und dann haben sie gesagt, ja, jetzt hätten wir gerne hier Ansible Automation Platform und das Ganze nach best practices.
Und dann war auf einmal stand da eine Zahl im Raum, die war dann doch deutlich höher auch als erwartet.
Von daher für den Anfang ist das sicherlich eine nette Sache.
Kommen wir vielleicht noch mal gerade kurz auf die Paket Formate.
Wir haben ja gerade schon ein bisschen über die Tatsache geredet, dass es hier keinen Execution Environments gibt.
Und ich habe schon gesagt, dass es das auch als Container Image gibt für Docker und Podman.
Primär vertreiben die das Tool über SnapCraft, wenn man das denn möchte.
Es gibt aber auch auf GitHub, das haben wir auch entsprechend verlinkt, Debian Pakete, RPM Pakete und targz-Files.
Das Ganze gibt es neben Linux auch für BSD, für Mac OS und Windows und das halt jeweils auch für x86, 64-bit und für ARM.
Also ARM 32 und 64-bit finde ich mich recht im Sinne.
Das heißt, es ist auch für HomeLab User bestimmt ganz interessant.
Wenn man so eine kleine GUI haben will, kann man das irgendwo deployen und hat dann halt einen schicke GUI und muss ich nicht erst noch ein K8S hochziehen für AWX.
Da bin ich tatsächlich noch ein bisschen durchstolper am Anfang, weil normalerweise erwartet man ja von einem, eigentlich ist es aus meiner Sicht ein Server und kein Desktop-Projekt.
Weil wenn ich das lokal auf dem Desktop, um nur meine Runs zu sehen und zu folgen, kommt als Teaser in den nächsten Folgen noch ein bisschen anderes Tool.
Ich würde es mir jetzt lokal selbst nicht instillieren, für mich alleine, weil in dem Sinne könnte ich also auf meinem Desktop nicht.
Weil da kann ich ja im Prinzip die Playbook-Runs gut über die CLI steuern, da weiß ich ja genau, was ausgeführt wurde, da habe ich halt Versionierung mit Git, also dafür sehe ich es eigentlich wenig.
Das heißt, wenn, dann wäre es ja Snap-on-Server und da waren wir.
Also vielleicht haben wir noch einen Trend ein bisschen verpasst, aber das Snap-on, dass das jetzt so ein Ding wäre Ubuntu Snap-on-Server.
Deswegen hat mich das ein bisschen erstaunt, dass normalerweise wäre bei so einem Tool eigentlich die erste Installationsvariante eben eigentlich Docker.
Theoretisch hier, um zu starten, das ist deine Line, Play-on-Docker, eben um die Hürde relativ gering zu halten.
Irgendwie interessante Wahl, das so prominent zu platzieren, wirklich direkt in die ersten Zeile install-wisc.
Na gut, es gibt ja mehrere Möglichkeiten. Du hast ja immer noch die nativen Pakete, aber Snap-Craft ist ja ursprünglich mal für IoT-Use-Cases und Devices gebaut worden.
Das hat man ja nachträglich erst für den Desktop re-used, kann man sagen.
Also damals hatte man nur IoT-Geräte im Blick und deswegen kannst du halt auch so Serverdienste über Snap beziehen.
Also auch der ganze Printerstack ist ja auch Server-based und deswegen auch als Snap-Paket beispielsweise.
Von daher, auf dem Desktop weiß ich jetzt auch nicht, ob das Anwender*innen machen würden, aber wenn du irgendwo einen Ubuntu Server hast,
dann ist das sicherlich eine ganz interessante Sache, wenn du da eh schon Snaps am Start hast.
Gut, kommen wir mal zu meiner Kritik an dem Tool.
Ich hatte es schon kurz angedeutet, dass die Benutzerverwaltung, wenn man das nicht ans Elder pinned, ein bisschen komplex ist.
Also es gibt eine Semaphore CLI, die man halt eben benutzen kann.
Beispielsweise in diesem Docker-Container kann man ja zwischen Shell aufmachen, kann dann das Semaphore-Commando benutzen.
Und die CLI, die dient halt einfach dazu, dass man die Anwendung konfigurieren kann und kann auch nach Upgrades dann so Datenbankschema, Upgrades und Migrationskripte ausführen.
Und die Userverwaltung, die Lokale, die geht halt derzeit nur über die CLI.
Das ist in der GUI ein bisschen verwirrend, weil es gibt da ein User-Management, es gibt da auch einen App-Knopf, aber der dient nicht dazu, neue Benutzer anzulegen,
sondern der dient halt einfach dazu, die User, die man vorher auf der Kommandezeit angelegt hat, entsprechend zu berechtigen, damit die Accounts Dinge tun dürfen in der GUI.
Und wenn ich jetzt einen User anlegen will, dann muss ich halt tippen, Semaphore User@--name paula-pinkepunk--login gefolgt vom Login-Name--email und dann am Ende noch--passwort.
Ja, also das ist--könnte schöner sein, wenn man das direkt in der GUI drin hätte, fände ich das eigentlich ein bisschen zielführender.
Und ansonsten, was ich auch ein bisschen unschön finde, wenn man jetzt so einen Public-Git-Repository hinterlegen will,
dann muss man zwingend immer eine Authentifizierungskonfiguration hinterlegen, also dann so dummy credentials sich anlegen,
so Test-User mit dem Test-Passwort oder mit dem leeren Passwort, das dann halt einfach dann nicht benutzt wird beispielsweise.
Und zu den Termini generell können wir vielleicht noch sagen, es gibt auch wie bei AWX Projekte, das ist so die Übermeta-Ressource,
die beinhaltet dann ein Task-Template, was dann eben beispielsweise so eine Kombination ist aus einem Playbook, aus einem Inventory, aus einem Repository und eben ein Environment.
Das Environment, das muss auch gesetzt werden, das dient dazu zusätzliche Umgebungsvarianten zu definieren.
Auch wenn euer Playbook das überhaupt nicht braucht, müsst ihr halt ein leeres Dummy-Environment definieren, sonst funktioniert das Ganze eben nicht, sonst kann man hier kein Task-Template anlegen.
Also in der GUI ist da ein Feld und man darf das nicht leer lassen, auch wenn man es überhaupt nicht braucht, wie auch bei den Credentials.
Also das finde ich von der UX ein bisschen unschön. Schade, weil genau die UI und die UX, die wird ja, wie wir gerade festgestellt haben im Vorgespräch, auf der Startseite so gepriesen.
Und das ist halt ein bisschen unschön, das könnte man noch mal verbessern, aber solange gibt es das Projekt auch noch nicht, von daher denke ich mal, da gibt es noch Luft nach oben.
Aber prinzipiell denke ich, kann das ein sehr nettes kleines Tool sein, wenn man eben einfach mit dem Answill-Thema gestartet ist und jetzt nicht direkt sich einen AWX ans Bein binden will,
aber eine GUI in einem kleinen Team haben will. Also ich würde mir das auf jeden Fall mal anschauen, wenn das was ist, das ihr gebrauchen könnt und wenn ihr eben sagt, ein AWX ist euch too much.
Wäre das auch was für dich, Felix, für eine Lab-Umgebung oder so?
Auf jeden Fall. Also ich finde, es hat so einfach seinen Use-Case, der auch ein bisschen durch die Lücke entstanden ist, eben, dass die Installation von AWX schwieriger geworden ist.
Also einfach mal AWX installieren ist halt nicht mehr, also kommt auf an, wer man ist, aber ich würde jetzt sagen, für Leute, die gerade erst mit dem Thema einsteigen und sich mit dem Thema anfangen mit Answill zu beschäftigen,
ist die Installation von AWX schon eine Hürde und eben diese Lücke füllt das Tool eigentlich gut, bietet die wesentlichen Features, die man eben braucht für diesen Start,
hat eben tatsächlich durch die API sogar die Möglichkeit als erste Automatisierungsplattform zumindest zu dienen, auch um Webhooks von externen Tools anzunehmen.
Also ich kann halt relativ einfache Workflows bauen, z.B. mein Jira meldet sich halt eben mit einem Webhook bei meinem Semaphore und führt halt dann ein Playbook aus,
so habe ich in, keine Ahnung, ein paar Stunden direkt meinen ersten Self-Service-Job gebaut. Also eigentlich cool, cooles Tool.
Ja. In dem Kontext, liebe Zuhörer, würde uns natürlich auch interessieren, was ihr von dem Tool haltet. Habt ihr es schon mal ausprobiert?
Kennt ihr vielleicht noch einen besseren Catch für diesen Use-Case? Lasst es uns sehr gerne wissen.
Gerne wieder per E-Mail an die altbekannte Adresse podcast@sva.de und dann hören wir uns morgen mit einem neuen Thema wieder.
[Musik]