ansible-tui/README.md

🚀 TUI-Ansible-Installer

Kurzbeschreibung

Dieses Projekt stellt eine Terminal User Interface (TUI) zur Verfügung, die auf dem bestehenden Ansible‑Workflow aufsetzt.
Ziel ist nicht, eine komplett eigenständige Alternative zu Ansible zu sein, sondern eine Bedienoberfläche, die
die vorhandenen Ansible‑Playbooks, Inventories und Konfigurationen nutzt und für Interaktion, Auswahl und Ausführung vereinfacht.

Wichtige Designentscheidung

Die TUI erweitert und orchestriert Ansible; alle Aktionen werden über Ansible (ansible-playbook, Inventory, Callback Plugins) ausgeführt.
Änderungen an Playbooks oder Inventories sollten weiterhin über die bekannten Ansible‑Mechanismen erfolgen (git, CI, editing).
Die TUI übernimmt keine proprietäre Konfiguration, sondern bietet eine Bedien‑ und Automatisierungsschicht für den etablierten Workflow.

Ein Sonderfall: Lokaler Modus (Standalone)

Zusätzlich zur Integration in bestehende Ansible‑Infrastrukturen bietet die TUI einen optionalen "Lokalen Modus".
Im Lokalen Modus kann die TUI auf einem Einzelrechner (z. B. Raspberry Pi) Playbooks installieren und ausführen, ohne dass dieser Rechner Teil eines zentralen Verbunds sein muss
oder zusätzliche Management‑Features (z. B. von "anvbe") genutzt werden. Das ist praktisch für Einzelinstallationen oder wenn kein zentrales Inventar vorhanden ist.

Kurz über die Funktionsweise

- Die TUI liest Playbooks aus einer konfigurierbaren Playbook‑Root (z. B. /playbook/playbooks) und zeigt die Struktur als Baum an.
- Auswahl und Ausführung von Playbooks erfolgen durch Aufruf von ansible‑playbook (mit passendem Inventory oder im connection=local Modus).
- Zielsysteme werden über das vorhandene Ansible‑Inventar oder über einfache, in der TUI gepflegte Host‑Einträge ausgewählt.
- SSH‑Schlüsseltransfer, Tests und optionale Synchronisation von /playbook/data werden über Ansible‑Mechanismen oder Standard‑Tools (scp/rsync) umgesetzt.

Verzeichnisstruktur (Beispiel)
/playbook/
├── roles/
├── playbooks/
│   ├── system/
│   │   ├── update.yml
│   │   └── upgrade.yml
│   ├── docker/
│   │   └── install.yml
│   └── ...
└── data/
    ├── templates/
    ├── binaries/
    └── ...

Bedeutung der Ordner

/playbook/playbooks/
Beinhaltet die Playbooks und deren Ordnerstruktur → wird 1:1 als Tree im TUI angezeigt.

 /playbook/data/
Dateien, die Playbooks benötigen (z. B. Konfigurationen, Installations‑Binaries, Templates).
Diese Dateien werden nicht direkt im Playbook‑Tree angezeigt, können aber optional vor dem Ausrollen synchronisiert werden.

Funktionen der TUI

1. Autocheck beim Start
- Prüft, ob Ansible, Python3, erforderliche pip‑Module, SSH‑Client und optional scp/rsync verfügbar sind.
- Bietet an, fehlende Abhängigkeiten automatisch zu installieren (mit Zustimmung des Nutzers).

2. Playbook‑Browser
- Durchsucht die konfigurierte Playbook‑Root und zeigt Playbooks als baumartige Liste.
- Auswahl einzelner oder mehrerer Playbooks, Markierung für wiederkehrende Aufgaben.

3. Server‑/Zielsystemverwaltung
- Nutzen Sie bevorzugt das vorhandene Ansible‑Inventory.
- Zusätzlich kann die TUI einfache Host‑Einträge verwalten (Name, Host, User, optionales Passwort, SSH‑Key‑Setup).
- SSH‑Key‑Setup wird über Standard‑Mechanismen umgesetzt (ssh‑copy‑id oder Ansible modules).

4. Ausführung von Playbooks
- Ausführung über ansible‑playbook. Wenn ein Host als lokal markiert ist, wird Verbindung als local/connection=local ausgeführt.
- Live‑Output, Fehlermeldungen und Exit‑Status werden in der TUI dargestellt.
- Optional: Synchronisation von /playbook/data vor dem Ausrollen.

5. Lokaler Modus
- Einrichtung des lokalen Inventars und Möglichkeit, Playbooks direkt auf dem aktuellen Rechner auszuführen.
- Nützlich, wenn der Rechner nicht in einen zentralen Verbund eingebunden werden soll oder wenn Features von "anvbe" nicht genutzt werden.

Bedienkonzept (Tasten)

↑/↓ Navigation
→ Ordner öffnen / Auswahl bestätigen
← Zurück
S Server-/Zielsystemverwaltung
Enter Playbook starten / Menüpunkt auswählen
Space Playbook markieren
Q Beenden

Hinweise für Entwickler

- Die TUI sollte die vorhandenen Ansible‑Kommandos, Inventories und Playbooks verwenden. Keine eigenen proprietären Formate.
- Anpassungen an Integrationen (z. B. “anvbe”) sollten optional sein, nicht Voraussetzung.
- Tests sollten sowohl gegen echten Ansible‑Aufrufen als auch gegen Mock‑Stubs laufen (für CI).

Geplante Erweiterungen

- Logging/Reporting in /var/log/tui-ansible/
- Plugin‑System für zusätzliche Menüfunktionen
- Profile pro Zielsystem
- Zeitgesteuertes Ausrollen
- Git‑Pull von Playbooks aus der TUI

Voraussetzungen

- Linux (Raspberry Pi empfohlen)
- Python 3.9+
- Ansible installiert
- SSH/SCP (optional rsync)
- Bibliothek für TUI (z. B. textual, urwid, rich)