Rancher mit viel Herausforderung

Ein ehrlicher Erfahrungsbericht über KI-gestütztes DevOps - die Wahrheit zwischen Hype und Realität. Spoiler vorweg: Es war kein Copy-Paste-Erfolg. Aber genau das macht diese Erfahrung wertvoll.

## Das Vorhaben

Ziel: Ein produktionsreifes Kubernetes-Cluster mit Rancher Management auf mehreren VPS-Servern, verbunden über Tailscale VPN.

Stack:

$ cat stack.txt
- Ubuntu 24.04 LTS
- K3s (Lightweight Kubernetes)
- Rancher (Kubernetes Management Platform)
- Ansible (Automatisierung) ← Der MVP!
- Tailscale (Private Networking)

---

## Warum Ansible? Die richtige Wahl

Bevor wir zu den Fehlern kommen: Ansible war die perfekte Wahl für dieses Projekt. Ohne Ansible wäre das ein Nightmare gewesen.

### Was Ansible richtig gut macht:

$ deployment_comparison
┌─────────────────────────────────────────────┐
│  MIT ANSIBLE vs. OHNE ANSIBLE               │
├─────────────────────────────────────────────┤
│  Mit Ansible:                               │
│    • Fehler fixen: 10 Minuten               │
│    • Idempotent: Ja                         │
│    • Reproduzierbar: 100%                   │
│                                             │
│  Shell Scripts:                             │
│    • Fehler fixen: 2+ Stunden               │
│    • Idempotent: Nein                       │
│    • Reproduzierbar: Viel Glück             │
│                                             │
│  Manuell:                                   │
│    • Fehler fixen: Halber Tag               │
│    • Idempotent: LOL                        │
│    • Reproduzierbar: Unmöglich              │
└─────────────────────────────────────────────┘

---

## Die Fehler (und was wir daraus gelernt haben)

### 1. Problem: Falsche IP-Adressen im Cluster

Die Worker-Nodes wurden mit öffentlichen IPs (203.0.113.x) statt mit Tailscale-IPs (100.64.x.x) im Cluster registriert.

Warum?
K3s nutzt standardmäßig die erste gefundene Netzwerkschnittstelle. Das war die öffentliche IP, nicht die Tailscale-IP.

Die Lösung mit Ansible:

- name: Get Tailscale IP automatically
  shell: ip addr show tailscale0 | grep 'inet ' | awk '{print $2}' | cut -d/ -f1
  register: tailscale_ip

- name: Install K3s with correct IP
  shell: |
    curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server \
      --node-ip={{ tailscale_ip.stdout }} \
      --node-external-ip={{ tailscale_ip.stdout }}" sh -

# Mit Shell-Scripts? Manuell auf JEDEM Server.
# Mit Ansible? Einmal schreiben, überall ausführen!

### 2. Problem: Tippfehler in 600+ Zeilen YAML

$ kubectl 11get nodes master-node
error: unknown command "11get" for "kubectl"

Did you mean this?
    get

Ein simpler Tippfehler (11get statt get) hat das komplette Playbook zum Absturz gebracht.

Die AI hat perfekten Code generiert, aber beim Kopieren ist ein menschlicher Fehler passiert. Classic PEBKAC.

Die Lösung:

$ ansible-playbook --syntax-check playbook.yml
# Ansible kann Syntax validieren!

$ git init && git add . && git commit -m "Working version"
# Versionskontrolle rettet Leben

### 3. Problem: Token-Übergabe zwischen Ansible Plays

Der K3s-Token wurde im Master-Play gesetzt, war aber im Worker-Play nicht verfügbar.

Ansible's Facts-System zur Rettung:

- name: Store token for all plays
  set_fact:
    k3s_node_token: "{{ k3s_token_encoded.content | b64decode | trim }}"
    cacheable: yes  # <-- Das ist der Magic Trick!

# Facts-System = Service-Discovery zwischen Nodes
# Perfekt für Multi-Server-Deployments!

### 4. Problem: NodePort funktioniert nicht

$ curl -k https://10.43.32.119:443
curl: (7) Failed to connect to server: Couldn't connect

$ debugging_issues=(
    "K3s Networking"
    "Docker Container conflicts"
    "Firewall/iptables"
    "kube-proxy Issues"
    "Port already in use?"
    "Cosmic rays?"
)

echo "Status: WTF IS GOING ON?!"

Plan B: Port-Forward mit Ansible deployen

- name: Create port-forward systemd service
  copy:
    dest: /etc/systemd/system/rancher-portforward.service
    content: |
      [Unit]
      Description=Rancher Port Forward
      [Service]
      ExecStart=/usr/local/bin/kubectl port-forward ...
      Restart=always

- name: Enable and start service
  systemd:
    name: rancher-portforward
    enabled: yes
    state: started

# Mit Shell-Scripts? Stunden.
# Mit Ansible? 5 Minuten.

### 5. Problem: Helm war nicht installiert

Ansible's Idempotenz ist Gold wert:

- name: Check if Helm exists
  stat:
    path: /usr/local/bin/helm
  register: helm_binary

- name: Install Helm
  shell: curl ... | bash
  when: not helm_binary.stat.exists

# Idempotent! Wenn Helm da ist: Skip.
# Wenn nicht: Install.
# Bei Shell-Scripts: Manuell prüfen = Fehleranfällig

### 6. Problem: Kaputte Kubeconfig

$ kubectl get nodes
dial tcp: lookup 100.100.64.1.10: no such host

# Expected: 100.64.1.10
# Got:      100.100.64.1.10
# WTF sed?!

Ansible's Templating > fragile sed:

# Bad: sed mit fragilen Regexes
$ sed 's/127.0.0.1/100.64.1.10/' config  # Chaos

# Good: Ansible Jinja2 Templating
- name: Update kubeconfig
  copy:
    content: "{{ kubeconfig | regex_replace('https://127.0.0.1:6443',
                                            'https://' + master_ip + ':6443') }}"
    dest: ./kubeconfig

# Robust. Lesbar. Ansible FTW!

### 7. Problem: "API Aggregation not ready"

Rancher-UI zeigte einen kryptischen Error. Panik-Modus aktiviert!

Die Wahrheit?
Rancher braucht Zeit. 3-5 Minuten. Webhooks, API Extensions, Zertifikate. Nicht alles ist sofort kaputt - manchmal ist es einfach noch nicht fertig.

Ansible's Wait-Mechanismen:

- name: Wait for Rancher
  shell: kubectl wait --for=condition=ready pod ...
  retries: 2
  delay: 30

# Built-in Retry-Logic + Delay
# Perfekt für Distributed Systems!

---

## Was hat die KI gut gemacht?

### ✓ Starke Bereiche

### ✗ Schwache Bereiche

---

## Die Wahrheit über KI-gestütztes DevOps

### Was KI NICHT ist:

$ ai_myths=(
    "❌ Replacement für DevOps-Wissen"
    "❌ Fehler-frei"
    "❌ Magisch selbstlernend"
    "❌ Production-ready ohne Review"
)

echo "Reality: Du brauchst immer noch Skills!"

### Was KI IST:

---

## Das finale Ergebnis

$ deployment_stats
┌───────────────────────────────────────┐
│   FINAL DEPLOYMENT STATISTICS         │
├───────────────────────────────────────┤
│ Lines of Code:        600+            │
│ Iterationen:          20+             │
│ Total Time:           ~4 hours        │
│ Success Rate (v1):    0%              │
│ Success Rate (final): 100%            │
│ Coffee consumed:      Too much        │
│ Ansible MVP Status:   Confirmed ✓     │
└───────────────────────────────────────┘

Nach 20+ Iterationen hatten wir ein produktionsreifes Ansible-Playbook:

---

## Empfehlungen

### 1. Iterativer Ansatz

Plan → KI Code → Review → Test → Fix → Repeat

# NICHT:
Plan → KI Code → Production → 💥

### 2. Wähle die richtigen Tools

# Ansible für:
- Configuration Management
- Multi-Server Deployments
- Orchestrierung
- Quick Prototyping

# Terraform für:
- Infrastructure Provisioning
- Cloud Resources
- State Management

### 3. Version Control & Testing

$ git init && git commit -m "Working"
$ ansible-playbook --syntax-check playbook.yml
$ ansible-playbook --check playbook.yml  # Dry-run

# Future-You wird es dir danken!

---

## Fazit

### Die Wahrheit:

• KI ist kein Silver Bullet, aber ein verdammt gutes Tool
• Ansible war der MVP - ohne es wäre alles viel härter gewesen
• Zusammen ermöglichen sie produktive, schnelle Iteration

Mit Ansible können wir das Setup jederzeit reproduzieren, neue Worker-Nodes hinzufügen, oder das komplette Cluster neu bauen. Alles mit einem Befehl:

$ ansible-playbook -i inventory.ini full-setup.yml

# Magic! 🎩✨

---