🧭 Crumbpage 32: Zustand — Wo der Wald sich erinnert

Subtitle: Ein Terminal, ein Wald, ein Zustand
Pfad: 32 — Die Wurzelkarte
Schwierigkeit: ⭐⭐⭐⭐ (4/5)
Zeit: ~2 Stunden
Voraussetzungen: Pfad 07: SSH Basics, Pfad 08: SSH Keys, Pfad 24: Docker, Pfad 31: Ansible

„Ein Krümel verliert seinen Raspi nicht mehr, wenn das Gerät kaputtgeht.
Der Zustand wohnt im Wald.“ 🌲


🌟 Wer dich auf diesem Pfad begleitet

Kein Krümel geht allein durch den Wald. Auf dem Zustand-Pfad sind dabei:

Crew Rolle hier
🦉 Krümeleule Fragt: Was bleibt, wenn ein Gerät geht?
🐱 CloudCat Sucht die Wahrheit zwischen Git, NetBox und Playbook.
🕷️ Spider Verbindet die Bäume über SSH, Netzwerk und Fäden.
🐌 Schnecki Erinnert: Erst schauen, dann ändern. --check ist Geduld.
🦡 GitBadger Bewahrt den erklärten Zustand im Git.
🧠 Deepbit Prüft, ob der Zustand wiederholbar, testbar und sicher ist.
🧰 Schraubär Baut daraus Werkzeug: Backup, Restore, Umzug, Spiegelung.

📋 Was du in diesem Pfad lernst

Du lernst, warum ein Computer nicht nur aus Metall, SD-Karte und Strom besteht.

Ein Computer im Crumbforest besteht aus:

Gerät
  + Name
  + Rolle
  + Netzwerk
  + Konfiguration
  + Daten
  + Backup
  + Geschichte
  + gewünschtem Zustand

Das Gerät kann kaputtgehen.

Der Zustand darf nicht verschwinden.


🌱 Grundidee: Zustand ist nicht Kontrolle

Zustand bedeutet nicht:

„Ich kontrolliere alles.“

Zustand bedeutet:

„Ich kann erklären, was da ist, warum es da ist, und wie es wieder wachsen kann.“

Das ist ein großer Unterschied.

Kontrolle macht den Wald eng.

Zustand macht den Wald erinnerbar.

Darum gilt im Crumbforest:

Zählen ist nicht Kontrolle.
Inventar ist nicht Besitz.
Dokumentation ist kein Käfig.
Zustand ist Fürsorge.


🪵 Die fünf Zustände des Waldes

Wenn du einen Raspi, Server oder Pelikan-Koffer anschaust, gibt es nicht nur einen Zustand. Es gibt mehrere Schichten.

1. Ist-Zustand

Das ist, was gerade wirklich da ist.

ansible all -m setup

Ansible fragt:

Welches Betriebssystem?
Wie viel RAM?
Welche IP?
Welche MAC-Adresse?
Welche Mounts?
Welche Interfaces?

Der Ist-Zustand ist die Momentaufnahme.

Er sagt:

„So steht der Baum gerade im Wald.“


2. Soll-Zustand

Das ist, was der Baum sein soll.

Ein Playbook sagt nicht nur:

Installiere nginx.

Es sagt:

nginx soll installiert sein.
nginx soll laufen.
Port 443 soll offen sein.
Dieses Verzeichnis soll existieren.
Dieser Benutzer soll SSH-Zugang haben.

Das ist der große Unterschied zwischen Skript und Zustand.

Ein Skript ruft:

„Mach! Mach! Mach!“

Ein Playbook fragt ruhig:

„Bist du schon so, wie du sein sollst?“

Wenn ja: nichts tun.

Wenn nein: sanft ändern.


3. Erinnerter Zustand

NetBox ist die Wurzelkarte.

Dort steht nicht nur:

Da ist ein Gerät.

Dort steht:

Name
Rolle
Standort
Cluster
Interface
IP-Adresse
MAC-Adresse
vCPUs
RAM
Disk
Kommentar
Beziehung zu anderen Dingen

NetBox ist kein totes Wiki.

NetBox ist der Ort, an dem der Wald sagt:

„Ich weiß, wer zu mir gehört.“


4. Erklärter Zustand

Git ist das Gedächtnis.

Ein Playbook ohne Git ist ein Zettel im Wind.

Ein Playbook im Git ist ein Baumring.

Warum wurde etwas geändert?
Wer hat es geändert?
Wann wurde es geändert?
Was war vorher?
Was ist jetzt?

GitBadger sagt:

„Ein Zustand, der nicht erklärbar ist, wird irgendwann wieder Rätsel.“

Darum gehört jeder wichtige Zettel ins Git.


5. Wiederbringbarer Zustand

Backup ist der Samen.

Ein Backup ist nicht nur eine Kopie.

Ein gutes Backup beantwortet die Frage:

„Kann dieser Baum nach einem Sturm wieder wachsen?“

Dazu gehören:

Daten
Konfiguration
Secrets
Images
Playbooks
Inventory
Dokumentation
Restore-Test

Ohne Restore-Test ist ein Backup nur Hoffnung.

Mit Restore-Test wird es ein Samen.


🧭 Der neue Satz

Nach Pfad 31 wissen wir:

Ansible ist der Gärtner.

Nach Pfad 32 wissen wir:

NetBox ist die Wurzelkarte.
Git ist das Gedächtnis.
Backup ist der Samen.
Das Terminal ist der Eingang.

Und zusammen wird daraus:

Ein Terminal
  ↓
ein Wald
  ↓
ein Zustand

🧩 Warum das für viele Krümel wichtig ist

Ein einzelner Raspi ist schön.

Viele Raspis sind ein Wald.

Aber viele Raspis ohne Zustand werden schnell wild:

Welcher Raspi gehört zu wem?
Welche IP hat er?
Welche SD-Karte ist alt?
Welcher Kurs nutzt ihn?
Ist Docker installiert?
Gibt es ein Backup?
Was passiert, wenn er kaputtgeht?

Mit NetBox und Ansible wird daraus:

kruemel01
  Rolle: lern-node
  Ort: OZM
  Netzwerk: kursnetz
  Playbook: raspi_node
  Backup: aktiv
  letzter Check: ok

kruemel02
  Rolle: scanner-node
  Ort: Werkstatt
  Netzwerk: esp-netz
  Playbook: scanner_node
  Backup: fehlt
  letzter Check: Achtung

Jetzt kann die Crew helfen.

Nicht weil sie alles auswendig weiß.

Sondern weil der Wald lesbar wird.


🔧 Die praktische Wurzel

Ein einfaches Inventory könnte so aussehen:

[raspis]
kruemel01 ansible_host=10.60.0.31
kruemel02 ansible_host=10.60.0.32
pelikan01 ansible_host=10.60.0.40

[rz]
backbone
nullfeld

[ozm]
seed01

[backup_clients:children]
raspis
rz
ozm

Die IP-Adressen, Tokens und Geheimnisse gehören nicht ins öffentliche Handbuch.

Der Keks zeigt das Prinzip.

Die echten Krümel-Secrets bleiben geschützt.


🧪 Erst Doktor, dann Gärtner

Schnecki-Regel:

ansible all -m ping

Dann:

ansible all -m setup

Dann:

ansible-playbook playbooks/doktor.yml

Dann erst:

ansible-playbook site.yml --check

Und erst danach:

ansible-playbook site.yml

Das ist keine Bürokratie.

Das ist Respekt vor dem Wald.


🌲 Beispiel: Ein Raspi zieht um

Früher:

SD-Karte suchen
altes Passwort suchen
SSH versuchen
Pakete nachinstallieren
Configs kopieren
Fehler vergessen
nachts fluchen

Heute:

Raspi flashen
SSH-Key setzen
Inventory ergänzen
Playbook laufen lassen
Backup zurückholen
NetBox aktualisieren
Doktor laufen lassen
fertig

Der Raspi ist nicht magisch zurückgekehrt.

Aber sein Zustand hat einen Weg nach Hause gefunden.


🪞 Spiegeln: Testbaum statt Angstbaum

Ein Zustand, der beschrieben ist, kann gespiegelt werden.

Das bedeutet:

ansible-playbook site.yml --limit test-raspi --check

Der Test-Raspi bekommt dieselbe Rolle wie ein echter Raspi.

Nicht um ihn zu ersetzen.

Sondern um ohne Angst zu lernen.

Im Crumbforest testen wir nicht, weil wir misstrauen.

Wir testen, weil wir Verantwortung tragen.


🧰 Rollen: Kleine Zettel für wiederkehrende Dinge

Eine Rolle ist ein wiederverwendbarer Zustand.

Zum Beispiel:

roles/
  common/
  raspi_node/
  docker_host/
  backup_client/
  node_exporter/
  crumb_portal/
  scanner_node/
  lora_node/

common sagt:

Grundpakete sind da.
SSH ist sauber.
Zeit stimmt.
Updates sind möglich.

backup_client sagt:

Dieser Baum kann seine Samen ablegen.

crumb_portal sagt:

Dieser Baum kann Kindern eine Tür öffnen.

So werden aus einzelnen Befehlen Waldregeln.


🧠 ∂W/∂t = 0

Der Wert des Waldes bleibt.

Die Form verändert sich.

Das ist die Idee hinter:

∂W/∂t = 0

Der Wald ist nicht eingefroren.

Er wächst.

Aber sein Kern bleibt:

offen
lernbar
wiederholbar
lokal-first
kinderfragend
nicht im Kopf einer Einzelperson versteckt

Darum brauchen wir nicht „Version 1, Version 2, Version 3“ wie harte Mauern.

Wir können mit Release Candidates wachsen:

RC0
RC1
RC2
RC3

Nicht fertig.

Nicht unfertig.

Sondern lebendig.

Baumringe statt Endpunkte.


🐌 Die Schnecki-Formel

Wenn du unsicher bist, gilt:

read-only vor write
--check vor echt
Backup vor Umbau
Git vor Geheimwissen
NetBox vor Raten
Restore-Test vor Vertrauen

Oder kürzer:

Erst schauen. Dann verstehen. Dann ändern.


🧒 Für kleine Krümel erklärt

Ein Raspi ist wie ein Schulrucksack.

Im Rucksack liegen:

Hefte
Stifte
Brotdose
Lieblingsstein
Zettel

Wenn der Rucksack verloren geht, ist das traurig.

Aber wenn wir vorher aufgeschrieben haben, was drin war, können wir einen neuen Rucksack packen.

Ansible ist der Helfer, der den Rucksack packt.

NetBox ist die Liste, wem welcher Rucksack gehört.

Git ist das Heft, in dem steht, warum wir etwas geändert haben.

Backup ist die Brotdose für später.

Und das Terminal ist die Tür, durch die wir fragen:

Bist du da?

Wenn der Raspi antwortet:

pong

dann sagt der Wald:

„Ich höre dich.“


🧪 Hands-On Übung: Zustand sehen

Aufgabe:

Finde heraus, welche Bäume leben, ohne dich einzeln einzuloggen.

ansible all -m ping

Dann frage nach der freien Festplatte:

ansible all -m shell -a "df -h / | tail -1"

Wichtig:

Das shell-Modul meldet oft CHANGED, auch wenn du nur liest.

Darum ist für echte Doktor-Playbooks besser:

- name: Freien Platz auf / anzeigen
  ansible.builtin.command: df -h /
  changed_when: false

So lernt Ansible:

„Ich habe nur geschaut.“


🧪 Hands-On Übung: Zustand notieren

Schreibe für einen Raspi eine kleine Karte:

name: kruemel01
role: raspi_node
ort: OZM
netz: kursnetz
backup: true
portal: true
owner: crew

Dann frage:

Welche Teile davon gehören ins Inventory?
Welche Teile gehören nach NetBox?
Welche Teile gehören ins Playbook?
Welche Teile gehören ins Backup?
Welche Teile dürfen niemals öffentlich ins Git?

Das ist der Moment, in dem Infrastruktur kein Nebel mehr ist.

Sie wird lesbar.


🛡️ Die Geheimnis-Regel

Nicht jeder Zustand gehört überall hin.

Es gibt öffentlichen Zustand:

Name
Rolle
Doku
Playbook-Struktur
Lernpfad

Es gibt internen Zustand:

IP-Adressen
Standorte
Gerätenamen
Netzpläne

Und es gibt geheimen Zustand:

Passwörter
Tokens
Private Keys
API Keys
Recovery Codes

Geheimnisse gehören nicht in normale Playbooks.

Geheimnisse brauchen eigene Werkzeuge, eigene Rechte und besondere Ruhe.

Krümel-Regel:

Ein Wald ist offen.
Ein Schlüssel ist nicht offen.


🧭 Die Wurzelkarte

Wenn alles zusammenkommt, sieht der Weg so aus:

Ansible Facts
     ↓
Ist-Zustand

Playbooks
     ↓
Soll-Zustand

NetBox
     ↓
erinnerter Zustand

Git
     ↓
erklärter Zustand

Backup
     ↓
wiederbringbarer Zustand

Terminal
     ↓
Eingang für die Crew

Das ist der Unterschied zwischen „Computer verwalten“ und „Wald pflegen“.


🧡 Der Satz für die Crew

Ein Gerät ist Hardware.
Ein Zustand ist Erinnerung.
Ein Playbook ist ein Versprechen.
Ein Backup ist ein Samen.
Eine Wurzelkarte ist Vertrauen.

Und darum sagen wir:

ein Terminal
ein Wald
ein Zustand

Nicht weil alles gleich sein muss.

Sondern weil alles wiedergefunden werden kann.


✅ Abschluss-Check

Am Ende dieses Pfades kannst du erklären:

Was ist Ist-Zustand?
Was ist Soll-Zustand?
Warum ist NetBox eine Wurzelkarte?
Warum ist Git Gedächtnis?
Warum ist Backup erst mit Restore-Test echt?
Warum schützt --check vor blinden Änderungen?
Warum verliert ein Krümel seinen Raspi nicht mehr, wenn der Zustand im Wald wohnt?

Wenn du diese Fragen beantworten kannst, hast du Kapitel 32 verstanden.

Nicht mit Kontrolle.

Mit Fürsorge.


🌲 Letzter Krümel

Der Wald wird nicht stark, weil jeder Baum perfekt ist.

Der Wald wird stark, weil jeder Baum wiedergefunden werden kann.

Und weil ein Krümel irgendwann vor einem neuen Raspi sitzt, das Terminal öffnet und fragt:

ansible all -m ping

Dann antwortet der Wald:

pong

Und die Eule flüstert:

„Du bist kein Alias.
Du bist ein Zustand.“

Krümel on.
Mauern off.
Wurzel sichtbar.