es ist nicht einfach zu beginnen, da ich nicht genau weiß was ein guter Einstiegspunkt zu dieser Themenstellung ist.
Überall tönt es: “Ansible ist einfach”. Überall wird die Simplizität von Ansible gelobt und hervorgehoben. Jedoch ist es mein Eindruck dass Ansible nicht so einfach ist. Ich kann mich irren, deshalb lege ich meine Sichtweise hier dar und hoffe dass mir neue Perspektiven eröffnet kann.
Wenn ich das richtig verstanden habe soll ein Ansible Playbook eine kompakte und übersichtliche deklarative Aufgabenbeschreibung sein, die mehr oder weniger selbsterklärend sein sollen. Die Abbildung komplexer Kontrollstrukturen, so fern möglich, führen schnell zur Unübersichtlichkeit. Das habe ich versucht, z.B. mit verschachtelten Includes, und dies führte zu schwer lesbaren Playbooks. Nun experimentiere ich mit Ansible Modulen um eine komplexe Automatisierungslogik abzubilden. Jedoch verschiebt das nach meinem Dafürhalten die Komplexität, die ja abgebildet werden muss, aus dem Ansible Playbook heraus an eine andere Stelle, dem Ansible Modul. Ergänzend erwähnen möchte ich noch, dass ich eine Kollektion die den von mir gewünschten Aufgabenumfang abdeckt nicht finden konnte. Nun nehme ich zwei Tätigkeitsrollen ein, die des Automatisierers und die des Software-Entwicklers. Was mir bisher nicht klar war ist die Trennung der Abbildung von einfacher und komplexer Automatisierungslogik.
Dies führt mich zu folgenden Fragen:
Ist es tatsächlich so, dass in den Ansible Playbooks die einfache Automatisierungssequenz abgebildet wird, während in Ansible Modulen, Rollen, etc. die Komplexität abgebildet wird, die für die Automatisierung notwendig ist, die dann vom Playbook verwendet wird?
Wenn dem so ist, bezieht sich dann die Aussage, dass Ansible einfach sei, auf die Playbook-Perspektive, d.h. unter Vernachlässigung der Komplexität die in den Modulen, Rollen, etc. abgebildet sind aber vom Playbook genutzt werden?
Wenn dem so ist folgere ich daraus, wenn ich einen komplexen IT-Prozess mit Ansible automatisiere und für meinen Anwendungsfall steht keine öffentliche Ansible Kollektion oder ähnliches zur Verfügung habe ich zwei Tätigkeitsrollen zu bedienen: Die des Automatisierers für das Ansible Playbook und die des Software-Entwicklers für die Ansible Module, etc. Sehe ich das richtig?
Nun noch eine Frage die mich sehr beschäftigt aber außerhalb des oben beschriebenen Kontextes steht:
Es werden sehr viele Kollektionen, Rollen, etc. angeboten. Das Finden der Richtigen stellt sich für mich ein bischen wie die Suche der Nadel im Heuhaufen dar. Nicht nur das, oftmals verwenden unterschiedliche Kollektionen für gleiche oder ähnliche Anwendungsfälle völlig andere Ansätze oder andere Bezeichnungen. Manchmal ist eine Dokumentation unvollständig, falsch oder gar nicht vorhanden. So ist es manchmal erforderlich den Quelltext zu analysieren. Gibt es bewährte Verfahren um damit effektiv umzugehen?
Entschuldigen Sie mein Deutsch, ich benutze ein Übersetzungsprogramm.
Zunächst würde ich nicht sagen, dass „Ansible einfach ist“, sondern dass Ansible auf einem einfachen Prinzip basiert: Führen Sie eine Aufgabe auf einem Host aus, erweitern Sie dies dann auf Listen von Hosts und Aufgaben und durchlaufen Sie diese. Doch so sehr Ansible selbst versucht, die Dinge zu vereinfachen, so komplex ist die Realität, mit der es umgehen muss.
Ansible zu beherrschen bedeutet zu wissen, wo man diese Komplexität kapseln kann. Module und andere Plugins sind dafür gut geeignet, da Programmierer normalerweise an Komplexität gewöhnt sind, während Playbooks lesbar und leicht überprüfbar sein sollen. Manchmal kann man diese Komplexität in die Daten selbst (Inventar und Variablen) verlagern, manchmal ist eine Rolle oder eine Gruppe von Rollen der beste Ort dafür. Es gibt keine einfache Antwort darauf, sondern nur die Hoffnung, dass Ansible es Ihnen ermöglicht, dies auf eine Weise zu tun, die wartbar, reproduzierbar, zuverlässig ist und Ihre Nerven schont.
Was die von der Community verfügbaren Rollen und Collections betrifft, habe ich auch keine gute Antwort. Die Kern- und Community-Tools von Ansible haben stets betont, dass die Dokumentation genauso wichtig ist wie der Code. Deshalb ist die Plugin-Dokumentation direkt mit dem Code verknüpft, und unsere Validierungstools sind diesbezüglich sehr streng. Allerdings halten sich nicht alle Rollen oder Collections an die Regeln des Kernteams oder der Community, und wir haben derzeit keine gute Möglichkeit, die Qualität jeder Rolle oder Collection zu bewerten oder anzuzeigen. Normalerweise findet man einen guten Autor oder eine Gruppe von Autoren und nutzt deren Beiträge weiterhin.
vielen Dank für Deine Antwort, das hilft mir weiter. Deine Perspektive unterstützt mich den Ansatz von Ansible besser zu verstehen.
Du schreibst: “Zunächst würde ich nicht sagen, dass „Ansible einfach ist“, sondern dass Ansible auf einem einfachen Prinzip basiert … Doch so sehr Ansible selbst versucht, die Dinge zu vereinfachen, so komplex ist die Realität, mit der es umgehen muss.”
Weiterhin schreibst Du: “Ansible zu beherrschen bedeutet zu wissen, wo man diese Komplexität kapseln kann. Module … sind dafür gut geeignet, da Programmierer normalerweise an Komplexität gewöhnt sind, während Playbooks lesbar und leicht überprüfbar sein sollen.”
Weiterhin schreibst Du: “Was die von der Community verfügbaren Rollen und Collections betrifft, habe ich auch keine gute Antwort.”
Für mich sind diese Erkenntnisse aus Deiner Erfahrung sehr wertvoll. Das hat mir bisher noch keiner so direkt vermittelt. Vielmehr wurde eher der Eindruck erzeugt das alles (einfach) in Ansible Playbooks umzusetzen sei und im Bedarfsfall (einfach) auf bestehende Module zurückgegriffen werden kann.
I really appreciate you taking the effort to read the text and reply in German.
Thank you very much for that.
Interessante Frage. Ich denke, Ansible macht einige Dinge wirklich einfach obwohl es selbst nicht immer und unbedingt einfach zu benutzen ist. Kommt halt drauf an, was man machen will. Du sprichst ja selbst von komplexen Kontrollstrukturen und komplexer Automatisierungslogik… da ist Ansible nicht unbedingt wahnsinnig gut drin. Ich bin mir aber auch nicht sicher, ob es Tools gibt die das wirklich besser machen. Es ist halt auch verdammt schwierig, wirklich komplexe Sachen einfach zu machen. Entweder man abstrahiert so weit, das keiner mehr was damit anfangen kann oder die Komplexität schlägt doch irgendwie wieder durch.
Allerdings ist die Idempotenz von Ansible (so denn sauber umgesetzt, kommt immer auf das jeweilige Modul an) schon sehr hilfreich meiner Meinung nach. Wir haben Playbooks die wir gerne laufen lassen einfach nur um zu checken, dass alles so aussieht und konfiguriert ist wie es soll. Kann man sich auch alles selber von Hand zu Fuß coden, da hat man dann deutlich mehr Flexibilität- aber einfacher ist dann nicht unbedingt.
Ich bin mir nicht so ganz sicher, ob sich “deklarativ” und “Aufgabenbeschreibung” nicht gegenseitig ausschließen. Deklarativ heisst doch eher “ich will dass A so konfiguriert ist und B so”, während eine Aufgabenbeschreibung ja eher Richtung “tue X und dann Y” geht. Deklarativ ist IMHO definitiv besser aber funktioniert leider doch nicht immer in der richtigen Welt.
Open Source halt, jeder darf. Muss man sich halt genauer ansehen, wem man vertraut. Also nicht nur, dass da kein Schmuhfix passiert sondern auch dass die Collection einigermaßen zukunftssicher ist.
vielen Dank für Deine Antwort, Deine Gedanken helfen mir weiter.
Die “deklarative Aufgabenbeschreibung” benennt Red Hat als “deklarative Programmierung”, im Gegensatz zur “imperativen Programmierung”, z.B. hier in diesem Blog zu einem Vergleich von Ansible und Terraform. Aus dieser Perspektive habe ich dieser Wortfolge eher keine maßgebliche Bedeutung beigemessen.
Mein Eindruck ist dass generell bei der Erschließung eines neuen Themas, in meinem Fall eben die IT-Prozessautomatisierung mit Ansible, zu Beginn ein eher reflektives Verhalten zutage tritt. So werden Begrifflichkeiten wiederverwendet wie sie verstanden wurden, ohne deren Sinnhaftigkeit zu hinterfragen, sie werden als definiert akzeptiert. Dies mag auch seine Ursache in einer Kultur haben in der die vermeintlich Wissenden eben diese als trendige Schlagworte verwenden. Beim näheren Kennenlernen stellen sich jedoch genau diese Fragen, die dann eine Realität zeigen die sich deutlich anders darstellt als vermittelt.
Nochmals vielen Dank für Deine Ausführungen, für mich ist es eine Perspektive einer Erkenntnisreise.
