Etwas was ich schon immer über Ansible wissen wollte, aber nie zu fragen wagte

International Communities Deutsche (German)
1

Hallo zusammen, :waving_hand:

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?

Vielen Dank für die Beantwortung meiner Fragen.

Beste Grüße
Stefan

CfgMgmtCamp 2026
2

Hallo Stephan,

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.

Ich hoffe, das hilft Ihnen weiter.

Brian Coca

3 Likes
3

Hallo Brian [ @bcoca ], :waving_hand:

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. :folded_hands:

Beste Grüße
Stefan

4

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.

1 Like
5

Hallo Mario [ @mariolenz ],

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.

Beste Grüße
Stefan

6

Ich habe mir Puppet und Ansible vor über 10 Jahren mal angeschaut gehabt und mich abgewendet. YAML ist mir ein Graus, und ich fand die Tools beide total überladen und kompliziert, aber gleichzeitig auch nicht mächtig genug, und habe mein eigenes Konfigurationsmanagement in ad-hōc-Shell geschrieben. (Als Entwickler einer Korn-Shell-Variante bin ich da durchaus qualifiziert für, und mehrere Arbeitskollegen kamen aber auch damit klar.)

Jetzt, im neuen Job, wurde ich auf Ansible geworfen… und leider hat sich mein Eindruck von damals bestätigt. (Es ist aber immer noch weniger schlimm als Puppet.)

Alleine fehlende Features wie… einfach mal nen String in ne Datei schreiben… oder https://github.com/ansible/ansible/issues/83512… oder ähnliche Quality-of-Life-Hindernisse nerven. Daß dann noch Sachen wie https://github.com/ansible/ansible/issues/85959 hinzukommen, die mal taten, aber anscheinend nur durch Zufall, und wo die Lösung dann „dokumentieren wir halt, daß es das nicht tut“ ist, ist nervig. Und langsam ist’s.

Noch nerviger ist, daß die Menge an unterstützten Releases so extrem eingeschränkt ist. Wobei das seit py3k in der Python-Welt so üblich geworden zu sein scheint… :pouting_cat:

Außerdem regt Ansible zu sehr schlechtem, schlecht wartbarem, Code an, indem es bestimmte Sachen verhältnismäßig schwerer macht, als sie sein müßten: die meisten Nutzer nehmen files/ und templates/, um die Zielsysteme zu befüllen, statt die Defaultkonfig der Distros zu patchen (was wartbar wäre und vorallendingen upgradefester). Ansible bietet hier lineinfile, was für nicht total einfache Fälle nicht reicht und für alle Fälle, in denen es reicht, viel zu kompliziert ist, blockinfile, das leider noch viel eingeschränkter ist, und… nix, zumindest nicht in Core. Mehr habe ich mir noch nicht angeschaut, vielleicht ist in den Collections was, aber wie Du schon schriebst erschlagen die einen in schierer Vielfalt und man weiß nicht, wie gut die sind. Ich neige dazu, einfach perl -pi -e 'regex' in ner remote shell ausführen zu lassen, demfalls. Aber das ist vielleicht auch „schlechter Stil“ oder nicht wartbar?

Und, erwähnte ich bereits YAML? Das Format, das so kompliziert ist, daß ein Mensch es nicht schreiben kann. Normalerweise konvertiere ich YAML immer nach JSON, wenn ich es bearbeiten muß… dummerweise bin ich nicht allein an dem Repo am arbeiten.

Also… ich komme klar. Ich habe auch schon Python3-Code geschrieben, um um Sachen herumzuwerkeln. Aber: „einfach“ ist Ansible in mehreren Dimensionen definitiv nicht.

(Und ich bin FOSS-Mensch. Entwickler, Admin, Trainer, Lizenzanalyst, teilweise Architekt, Conslutant, Buildsystemspezialist, Versionsverwaltungsspezialist… alles schon gewesen. Nur „Cloud“ mache ich nicht.)

Achso, und die Doku… sie existiert, sie ist sehr umfangreich… sie läßt bei mir aber dennoch oft viele Fragen offen und ist sehr rudimentär… und irgendwie auch immer veraltet, obwohl ich schon auf der Debian-stable-Version bin.

1 Like
7

@mirabilos kurzer Hinweis zu regression: difference filter no longer keeps order · Issue #85959 · ansible/ansible · GitHub : community.general hat seit ein paar Jahren explizite List-Versionen von einigen Set-Filtern, z.B. community.general.lists_difference filter – Difference of lists with a predictive order — Ansible Community Documentation

8

… ah, interessant. Da fällt wieder das „viel“ rein. Ich hatte es dann in Jinja2 kodiert, mit Varianten je nach Einsatzgebiet, das reichte auch.

9

… und, daß man immer noch nicht während ein Task läuft dessen Fortschritt (stdout/stderr) beobachten kann.

10

Hallo Thomas [ @mirabilos ],

vielen Dank für Deine detaillierte Antwort. Es ist schwierig für mich das einzuordnen, da ich mich noch “am Start” befinde, habe also gerade erst “den Fuss in der Tür”. Dabei bin ich auf die beschriebenen Probleme gestoßen, wir können es auch Herausforderungen nennen. Die von Dir umrissenen Themen und Deine fundierten Erfahrungen empfinde ich als sehr intensiv (mir fällt gerade kein treffenderes Wort ein), das finde ich sehr gut.

Nochmals vielen Dank für Deinen Beitrag.

Beste Grüße
Stefan

11

Ich bin auch erst seit zirka Juli dabei (habe aber vorher schon einiges über meine Freundin, die viel mit Ansible macht als Freelancer, mitbekommen, und wie gesagt mir das „ewig her“ schon mal angeschaut gehabt).

So ganz glücklich war ich nur mit meiner Sammlung an Shellskripten, aber im aktuellen Job müssen halt auch Kollegen und sogar MA der Kunden dran, darum halt Ansible und YAML. Ich kann mich damit abfinden, gibt Schlimmeres.

Gerade wieder was gefunden, das echt Quality of Life wäre: Module 'file' - would like a non-recursive directory delete for "state=absent" · Issue #7541 · ansible/ansible · GitHub

Ich mache das jetzt einmal mit ansible.builtin.shell: rmdir --ignore-fail-on-non-empty … von Hand und entferne die Zeile danach wieder, ist nicht so wichtig jetzt, aber wollte das Verzeichnis auf Altsystemen schon gerne weghaben.

Und gleich zweimal bin ich in with_first_found not skipped when "when:" conditional is false · Issue #17725 · ansible/ansible · GitHub reingelaufen. Bamm, einfach geschlossen, ohne dem Reporter zu sagen, wie man das umformulieren kann, daß es geht.

1 Like