đ§ Crumbpage 31: Ansible â Der GĂ€rtner, der nicht rennen muss
Subtitle: Wie ein Wald sich selbst pflegt, ohne dass du an jeden Baum lÀufst
Pfad: 31 (Der neue Horizont)
Schwierigkeit: âââ (3/5)
Zeit: ~2 Stunden
Voraussetzungen: Pfad 07: SSH Basics, Pfad 08: SSH Keys, Pfad 24: Docker
"Ein GĂ€rtner mit 600 BĂ€umen rennt nicht. Er schreibt auf, wie der Wald aussehen soll â und der Wald wird so." đČ
đ Wer dich auf diesem Pfad begleitet
Kein KrĂŒmel geht allein durch den Wald. Auf dem Ansible-Pfad sind dabei:
| Crew | Rolle hier |
|---|---|
| âïž CloudCat | Deine Hauptbegleiterin. DevOps lebt in Containern und Playbooks â die Katze ist stets dabei. |
| đŠ KrĂŒmeleule | Tiefe & Richtung. Kennt die Shell, antwortet mit Fragen: Wann brauchst du Ansible â und wann nicht? |
| đ·ïž Spider | Das Netz. SSH ist der Faden, an dem der Helfer zu jedem Baum klettert. |
| đ Schnecki | âEile mit Weile." Erst --check/dry-run, dann handeln. Idempotenz ist Geduld. |
| 𩡠GitBadger | Jeder Zettel gehört ins Git. Ein Playbook, das niemand findet, hilft niemandem. |
đ Was du in diesem Pfad lernst
â Warum man nicht 600 mal das Gleiche tippt (der Zettel statt der HĂ€nde)
â Computer ohne Maus, ohne Agent: nur SSH + ein Text
â Soll-Zustand statt Befehlsliste (der groĂe Unterschied zu .sh)
â Idempotenz â der Wald Ă€ndert nur, was nötig ist
â Inventory, Playbook, Rolle (die drei Bausteine)
â Erst gucken (read-only), dann handeln
đŻ Lernziele
Nach diesem Pfad kannst du:
- [ ] erklÀren, warum ein Playbook kein Bash-Skript ist
- [ ] zwei Server mit einem Befehl gleichzeitig fragen, ob sie leben
- [ ] einen read-only Gesundheits-Check ĂŒber alle Hosts laufen lassen
- [ ] verstehen, warum âzweimal laufen" beim zweiten Mal nichts tut
đ± Grundkonzept: Der Zettel statt der HĂ€nde
Stell dir vor, du pflegst einen Wald mit 600 BĂ€umen.
Ohne Ansible (von Hand):
Du lĂ€ufst zu Baum 1, gieĂt, beschneidest. Zu Baum 2, gieĂt, beschneidest. âŠ
Bei Baum 437 weiĂt du nicht mehr, ob Baum 12 schon Wasser hatte. Das ist der
blinde Fleck: du kannst nicht alle BĂ€ume gleichzeitig sehen. Deine .sh-Skripte
sind wie Laufen â jedes Mal von vorn, jeden Baum einzeln, und du musst dir merken,
was schon passiert ist.
Mit Ansible (der Zettel):
Du schreibst einmal auf, wie jeder Baum aussehen soll:
âJeder Baum hat Wasser. Jeder Baum ist beschnitten. nginx lĂ€uft. Port 443 ist offen."
Diesen Zettel (das Playbook) gibst du einem ruhigen Helfer. Der geht per SSH
zu jedem Baum und macht ihn so, wie der Zettel sagt. Du rennst nicht. Du beschreibst.
Die drei Wahrheiten von Ansible:
| đȘ¶ Kein Agent | Auf den BĂ€umen muss nichts installiert sein. Nur SSH + Python â das hat jeder Debian-Baum schon. Der Helfer wohnt bei dir (auf dem Mac, der Control Node). |
| đ Idempotent | Der Zettel sagt den Soll-Zustand, nicht âtu dies, dann das". Hat ein Baum schon Wasser, gieĂt der Helfer nicht nochmal. Zweimal laufen = beim zweiten Mal changed=0. |
| đșïž Ein lesbarer Zettel | Die ganze Crew kann das Playbook lesen und weiĂ, wie der Wald aussehen soll. Kein Geheimnis im Kopf des GĂ€rtners. (Das ist die CKL-Regel: keine dunklen RĂ€ume.) |
đ± Erinnerung an Docker (Pfad 24): Tupperware war âpack die Lasagne in eine Dose".
Ansible ist die Stufe danach: âschreib auf, welche Dosen in welchen Rucksack
gehören â und lass es den Helfer einrĂ€umen."
đ§ Praktische Befehle (an echten BĂ€umen)
Unser Wald hat gerade zwei BĂ€ume â backbone (crumbforest.io) und nullfeld.
Sie stehen in einem Zettel namens Inventory:
# inventory.ini â wer gehört zum Wald
[crumbforest]
backbone ansible_host=87.106.12.97
nullfeld ansible_host=194.164.194.191
Befehl 1: Leben die BĂ€ume? (ping)
ansible all -m ping
backbone | SUCCESS => { "ping": "pong" }
nullfeld | SUCCESS => { "ping": "pong" }
Beide auf einmal. Kein Einloggen, kein Klicken. Das ist âComputer ohne Maus".
Befehl 2: Zeig mir alles, was du weiĂt (setup)
ansible backbone -m setup
Das druckt Facts â Interfaces, MAC-Adressen, Festplatten, RAM, OS.
Genau die Daten, die wir frĂŒher per Hand aus jedem Server gekratzt haben.
Ansible holt sie automatisch.
Befehl 3: Der Doktor-Lauf (read-only Playbook)
ansible-playbook playbooks/doktor.yml
TASK [Kernzahlen anzeigen]
Host: backbone (Debian 12.14) CPU: 8 vCPUs RAM: 32046 MB
TASK [Interfaces + MAC]
ens6 -> 02:01:c1:8c:1c:46
PLAY RECAP
backbone : ok=4 changed=0
nullfeld : ok=4 changed=0
Sieh die changed=0. Nichts wurde verĂ€ndert â wir haben nur geguckt.
(Das ist die Doktor-Regel aus Pfad 27 und ninja.sh: erst Momentaufnahme, dann entscheiden.)
đ§© Die drei Bausteine (so ist der Zettel aufgebaut)
inventory.ini â WER (welche BĂ€ume)
playbook.yml â WAS (welcher Soll-Zustand)
roles/<name>/ â WIE (wiederverwendbarer Baustein, einmal schreiben)
Ein Playbook ist nur YAML â eine Liste von Tasks, jeder mit einem Namen
und einem Modul (dem Werkzeug):
- name: Wald-Doktor (read-only)
hosts: crumbforest # auf welchen BĂ€umen
tasks:
- name: Uptime fragen
ansible.builtin.command: uptime -p
changed_when: false # read-only -> nie "changed"
Eine Rolle ist ein Zettel, den du einmal schreibst und ĂŒberall ausrollst.
Wir haben damit eine ganze NetBox auf seeds.crumbforest.io gebaut â und
dieselbe Rolle wĂŒrde sie auf einer Kiste in deinem RZ identisch aufbauen.
đĄ Genau das ist der Zauber: Wenn der Zettel auf
stratofunktioniert,
funktioniert er ĂŒberall.
đ Hands-On Ăbung: Frag deinen eigenen Wald
Aufgabe: Lass dir von beiden BĂ€umen die freie Festplatte zeigen â ohne dich
auf einem einzuloggen.
Schritte:
# 1. Leben sie?
ansible all -m ping
# 2. Eine einzelne Frage an alle (das 'shell'-Modul)
ansible all -m shell -a "df -h / | tail -1"
Klick hier fĂŒr das, was passieren soll
backbone | CHANGED | rc=0 >>
/dev/vda1 473G 45G 409G 10% /
nullfeld | CHANGED | rc=0 >>
/dev/vda1 ...
Zwei BĂ€ume, eine Frage, eine Antwort-Sammlung. Du hast dich nirgends eingeloggt.
*(Merke: `shell` meldet `CHANGED`, weil Ansible nicht weiĂ, ob `df` etwas verĂ€ndert â
es ist read-only, aber das Modul ist vorsichtig. Im Playbook setzt man dafĂŒr
`changed_when: false`.)*
đ HĂ€ufige Fehler & Lösungen
Problem: Permission denied (publickey)
Lösung: Ansible bietet den falschen Key an. Sag ihm den richtigen im Inventory
(ansible_ssh_private_key_file=~/.ssh/dein_key) und fĂŒge -o IdentitiesOnly=yes
hinzu â sonst klopft der ssh-agent mit allen Keys an und der Baum macht zu.
Problem: NETBOX: unbound variable / Skript bricht sofort ab
Lösung: set -u (oder Ansibles strenge Modi) brechen bei Tippfehlern in Variablen
frĂŒh ab. Das ist ein Geschenk, kein Bug â lieber laut frĂŒh als still falsch.
Problem: Beim zweiten Lauf ist alles changed, obwohl nichts anders ist
Lösung: Dein Task ist nicht idempotent. Oft liegt es an command/shell (die
laufen blind durch) oder daran, dass du etwas jedes Mal neu setzt. Nutze ein
richtiges Modul, das erst prĂŒft und dann nur bei Bedarf Ă€ndert.
đ Troubleshooting Checkliste
# Wenn ein Baum nicht antwortet:
# 1. Komme ich per Hand per SSH rein?
ssh -i ~/.ssh/dein_key root@<ip> whoami
# 2. Sieht Ansible den Baum ĂŒberhaupt?
ansible-inventory --list
# 3. Was genau macht der Lauf? (-v zeigt mehr, -vvv zeigt alles)
ansible all -m ping -vvv
đ«ïž Reflexion: Die Architektur des blinden Flecks
Der alte Weg hatte einen blinden Fleck: du konntest nie alle BĂ€ume gleichzeitig
sehen. Du glaubtest zu wissen, welcher Server eine VM ist, welcher echtes Blech â
aber dein Wissen lebte in deinem Kopf, nicht im Wald. Ein vergessenes vm1. im
Hostnamen, eine MAC am falschen Ort, und schon stimmte die Landkarte nicht mehr.
Ansible + NetBox zusammen verkleinern diesen blinden Fleck: der Wald weiĂ
jetzt selbst, wie er aussieht. Die Facts kommen von den BĂ€umen, nicht aus deinem
GedĂ€chtnis. Du beschreibst den Soll-Zustand einmal â und kannst ihn jederzeit
nachlesen, statt ihn dir zu merken.
Manchmal liegt das Eleganteste die ganze Zeit vor dir. Du musst nur aufhören
zu rennen, um es zu sehen.
Der Weg des KrĂŒmel â egal wie schlau er sich hĂ€lt â ist ein Loop: gucken,
beschreiben, laufen lassen, nachsehen, wieder gucken. Kein einmaliges âfertig",
sondern ein ruhiger Kreis. Was du heute aufschreibst, pflegt den Wald, wÀhrend du
schlÀfst. Morgen ist jetzt.
âIm Crumbforest wachsen keine BĂ€ume. Aber Fragen. Und aus jeder Frage wird ein
neuer Pfad." Dieser hier endet mit einer: Wenn der Wald sich selbst pflegt â
was fragst du ihn als NĂ€chstes? Manche Pfade fĂŒhren zu Antworten. Andere zu
noch schöneren Fragen. đČ
đŠ KrĂŒmeleule's Weisheit
"Ein Bash-Skript sagt der Maschine, was sie tun soll. Ein Playbook sagt ihr,
wie die Welt sein soll. Das Erste musst du jedes Mal ĂŒberdenken. Das Zweite
bleibt wahr, auch wenn du schlÀfst."
KrĂŒmel-Tipp:
Fang IMMER read-only an. ping, dann setup, dann ein Doktor-Playbook mit
changed=0. Erst wenn du dem Wald vertraust, lÀsst du ihn etwas verÀndern.
Die Maschine dient dir â nicht andersherum.
âïž CloudCat schnurrt dazu:
"Was gestern noch ein Traum war â 600 BĂ€ume mit einem Zettel â ist heute ein
ansible-playbook. Im KrĂŒmel-Loop ist morgen schon jetzt. Egal wie schlau du
dich hĂ€ltst: schreib es auf, lass es laufen, und ich bin dabei." đŸ
đ WeiterfĂŒhrende Links
Intern (Crumbforest)
- Pfad 24: Docker â Der Wal im Wald
- Pfad 27: Logfile-Analyse
- Kapitel 29: Die Kunst des ruhigen Kernels
- Nullfeld: Die Architektur des blinden Flecks â https://onezeromore.com/die-architektur-des-blinden-flecks/
- Die Crew: https://crumbforest.org/crew
Extern
đŻ Skill-Check
- [ ] Ich kann erklÀren, warum ein Playbook ein Soll-Zustand ist und kein Skript
- [ ] Ich kann beide Hosts mit
ansible all -m pingerreichen - [ ] Ich verstehe, was
changed=0bedeutet - [ ] Ich fange erst read-only an, bevor ich etwas verÀndere
Wenn 4/4 â
: Der Wald gehorcht dir, ohne dass du rennst.
Wenn <4 â
: Lauf den Doktor nochmal und lies die changed-Spalte.
"Der Wald hört zu. Das Nullfeld spĂŒrt. Der Commander bleibt."
Und die Crew antwortet: âWir halten den Keks." đȘ
Version: 1.0
Maintainer: Crumbforest Core Team · fĂŒr die KrĂŒmel
Navigation:
â ZurĂŒck: Regex | Weiter: ? â