ghostnet.ai/infrastructure
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Encoding: Ansible-Projekt und Grundzustand für gn-encoding eingerichtet und verifiziert.

Browse Source 
llm-server/encoding/ansible/ verwaltet mit video-encoding.yml und der Rolle
video_encoding den CPU-Only-Grundzustand des gesperrten Kontos gn-encoding
(UID/GID 982): Konto-Identität und Passwortsperre, subordinate ID-Bereiche,
Verzeichnisstruktur, Quadlet-Verzeichnis, Linger, getrennter rootless
Podman-Store sowie verwehrter GPU-Zugriff (keine render/video-Gruppe, kein
Lesezugriff auf /dev/kfd oder DRM-Render-Nodes). Ohne beschlossene
Encoder-Entscheidungen stellt die Rolle sicher, dass kein Workload definiert
ist. Check-Mode und zwei Läufe auf ghostnet-ki: jeweils ok=30 changed=0
failed=0. Preflight, host.yml (2x ok=55 changed=0) und ROCm-Probe
(ok=33 changed=0) nach der Projekt-Aufteilung erneut bestanden.
GNENC-000/001, GNAI-000 und GNAI-013 aktualisiert.

Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
This commit is contained in:
spektr
2026-10-19 14:42:14 +02:00
parent 92c846f527
commit ba7d829410
12 changed files with 556 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/GNAI-000-DOC_Index.md
+7 -2
View File
@@ -48,7 +48,8 @@ jeweiligen Fachdokumenten. Die priorisierte weitere Umsetzung beschreibt der
| [GNAI-008](platform/llm-server/ai/GNAI-008-PLAN_Ansible-Deployment.md) | detaillierter Ansible-/Gitea-Planungsstand und Implementierungshistorie |
| [GNAI-009](platform/llm-server/ai/GNAI-009-PLAN_Llama-Model-Evaluation.md) | reproduzierbarer Modellvergleich |
| [GNAI-010](platform/llm-server/ai/GNAI-010-TECH_Llama-Serving.md) | technische Sollkonfiguration des Testing-Servings |
| [LLM-Server-Ansible](../llm-server/ansible/README.md) | ausführbare Host-/ROCm-Playbooks und Rollen für `10.0.0.90` |
| [LLM-Server-Host-Ansible](../llm-server/host/ansible/README.md) | ausführbare Host-/ROCm-Playbooks und Rollen für `10.0.0.90` |
| [Encoding-Ansible](../llm-server/encoding/ansible/README.md) | ausführbares Ansible-Projekt für den CPU-Encoding-Workload auf `10.0.0.90` |
| [Keycloak-Ansible](../proxmox/lxc/ct-102-keycloak/ansible/README.md) | ausführbare Provisionierungs-, Restore- und Prüfautomation für CT 102 |
### Video-Encoding
@@ -66,6 +67,10 @@ Am 22.09.2026 wurden KI-Host und Proxmox-LXCs in getrennte Unterverzeichnisse
Am 05.10.2026 wurde die Dokumentation geräteorientiert neu geordnet:
`platform/proxmox-server/` bildet den Proxmox-Kontext und seine LXCs ab,
`platform/llm-server/` den physischen KI-Server mit AI und Encoding.
Am 19.10.2026 wurde das ausführbare LLM-Server-Projekt in die fachlichen
Hauptverzeichnisse `llm-server/host/` (Grundkonfiguration des Servers),
`llm-server/llm/` (LLM-Stack) und `llm-server/encoding/` (Encoding) aufgeteilt;
die Dokumentation folgt derselben Dreiteilung.
## 2. Belegter Stand
@@ -79,7 +84,7 @@ Am 05.10.2026 wurde die Dokumentation geräteorientiert neu geordnet:
| DNS / Pi-hole | CT 100 unter `10.0.0.14` mit digest-gepinntem Pi-hole 2026.09.0 als Podman-Quadlet; SSH/nftables, UDP/TCP-DNS, Split-DNS, Blocking/Allowlist, FRITZ!Box-Cutover, LXC-Reboot und Stop-Mode-Backup am 01.10.2026 abgenommen | vollständige App-/OIDC-Regression, praktischer FRITZ!Box-Rollback, mobile DuckDuckGo-/IPv6-Strategie, WireGuard-Profile und hostunabhängiger Restore-Test |
| Reverse Proxy | CT-103-Zugänge, SSH-/Firewall-Baseline, Reboot und lokales Backup abgenommen; NPM 2.15.1 routet öffentlichen OIDC- und internen Admin-vHost getrennt; öffentliche Keycloak-Administration liefert 403 | Fail2Ban-Jails/Bans und Wiederanlauf; hostunabhängige Backupkopie/Restore-Test |
| Keycloak | CT 102 unter `10.0.0.4` reproduzierbar per Ansible aufgebaut; gepinntes Keycloak 26.2.4 und PostgreSQL 16.15, Restore von CT 104, Container-/DB-Härtung, NPM-Cutover, interner Adminzugang, öffentliche Admin-Sperre, realer Vaultwarden-OIDC-Login und LXC-Neustart abgenommen | 14-tägige Stabilisierungsphase, praktischer NPM-Rückfall auf CT 104, Betriebs-/Backup-/Restore-SOP und anschließende Rückfallbereinigung |
| Encoding | Konto, Pfade und eigener rootless Store | Workload, Zeitsteuerung, Ressourcenlimits und Lasttest |
| Encoding | Konto, Pfade, eigener rootless Store und CPU-Isolation per Ansible verwaltet und verifiziert | Workload, Zeitsteuerung, Ressourcenlimits und Lasttest |
Ein Zielbild, eine Betreiberangabe oder ein erfolgreicher Teiltest gilt nicht als
vollständige Abnahme. Datierte Details stehen im zuständigen Fachdokument.
docs/GNAI-013-PLAN_Security-Closure-and-Repository-Restructure.md
+27 -2
View File
@@ -39,7 +39,10 @@ Die ausführbare Infrastruktur ist seit 14.10.2026 ebenfalls hostbezogen:
```text
ghostnet.ai-infrastructure/
├── llm-server/ansible/ # physischer KI-Server
├── llm-server/
│ ├── host/ansible/ # Grundkonfiguration des physischen KI-Servers
│ ├── llm/ # LLM-Stack (entsteht mit dem AI-Vertical-Slice)
│ └── encoding/ansible/ # CPU-Encoding-Workload
├── proxmox/
│ ├── shared/scripts/ # nur LXC-übergreifende PVE-Helfer
│ └── lxc/
@@ -130,12 +133,34 @@ hostbezogenen Playbooks oder Inventare.
Pi-hole-Pfad abstimmen.
- [x] Lokale Ansible-`.venv` wegen des veralteten Repository-Pfads neu
erstellen und alle Syntaxprüfungen regulär ausführen.
- [ ] Lesenden Preflight sowie Host-/ROCm-Verifikation wiederholen.
- [x] Lesenden Preflight sowie Host-/ROCm-Verifikation wiederholen.
- [ ] Internes, nicht öffentliches `llama.cpp`-Testing-Vertical-Slice nach
GNAI-010 implementieren und bei 64k abnehmen.
## 4. Arbeitsnachweise
### 19.10.2026 – LLM-Server erreichbar, Projekt fachlich aufgeteilt, Encoding-Grundzustand
- Das Netzwerkkabel des KI-Servers war versehentlich gezogen; nach dem
Wiederanschluss ist `10.0.0.90` aus dem LAN erreichbar. Lesender Preflight
aus dem neuen Pfad `llm-server/host/ansible/`:
`ok=5 changed=0 unreachable=0 failed=0` (ghostnet-ki, Debian 13.6, 14 vCPUs,
64 GiB RAM, zwei Navi-21-PCI-Geräte `1002:73bf`).
- Das LLM-Server-Projekt wurde in die fachlichen Hauptverzeichnisse `host/`,
`llm/` und `encoding/` aufgeteilt (analog zu `docs/platform/llm-server/`).
`host.yml` lief zweimal aus `llm-server/host/ansible/` mit jeweils
`ok=55 changed=0 unreachable=0 failed=0`; der gepinnte ROCm-Container-Probe
(`verify-rocm-container.yml`) meldete `ok=33 changed=0 failed=0`.
- Encoding: `video-encoding.yml` aus `llm-server/encoding/ansible/` verifiziert
den `gn-encoding`-Grundzustand (gesperrtes Konto UID/GID 982, subordinate
ID-Bereiche, Verzeichnisse, Linger, rootless Podman-Store, keine GPU-Gruppen
und kein Zugriff auf `/dev/kfd` oder DRM-Render-Nodes). Check-Mode und zwei
aufeinanderfolgende Läufe meldeten jeweils `ok=30 changed=0 failed=0`. Es
existiert weiterhin kein Encoding-Image, -Container, -Quadlet und -Timer.
- Offen bleibt in Abschnitt E: die Resolver-Abstimmung des KI-Servers auf den
Pi-hole-Pfad. Ein kontrollierter Kaltstart des Servers wurde nicht
durchgeführt; der Server lief durch, nur das Netzwerkkabel war gezogen.
### 05.10.2026 – Struktur, Geheimnisse und lokaler VPN-Client
- Dokumente geräteorientiert verschoben; lokaler Linkvalidator meldet
docs/platform/llm-server/encoding/GNENC-000-DOC_Index.md
+3
View File
@@ -22,6 +22,9 @@
automatisch ausgeführt werden.
- Das gesperrte Servicekonto `gn-encoding` mit UID/GID 982 und eigenem
rootless Podman-Store ist eingerichtet und verifiziert.
- Das Encoding-Ansible-Projekt unter `llm-server/encoding/ansible/` verwaltet
und verifiziert den Encoding-Grundzustand (Konto, Pfade, CPU-Isolation,
rootless Store); Check-Mode und Idempotenzlauf meldeten jeweils `changed=0`.
- Es sind noch kein Encoding-Image, kein Container, keine Quadlet-Unit und kein
Timer eingerichtet.
docs/platform/llm-server/encoding/GNENC-001-PLAN_Architecture.md
+41 -20
View File
@@ -24,7 +24,7 @@ unabhängig konkurrierende Sollzustände auf denselben Host anwenden.
| Repository | Host- und Deployment-Ansible bleibt im bestehenden Infrastructure-Repository | angenommen |
| Dokumentation | Encoding liegt unter `docs/platform/llm-server/encoding/` und verwendet die Kennung `GNENC` | umgesetzt |
| Ausführungsidentität | eigenes gesperrtes Konto `gn-encoding`, UID/GID 982 | eingerichtet und mit rootless Podman geprüft |
| Containertrennung | eigener rootless Podman-Store und eigener rootverwalteter Quadlet-Pfad | eingerichtet; noch keine Workload definiert |
| Containertrennung | eigener rootless Podman-Store und eigener rootverwalteter Quadlet-Pfad | eingerichtet; Grundzustand per Ansible verwaltet und verifiziert; noch keine Workload definiert |
| Rechenressource | Encoding ist nach Betreiberfestlegung rein CPU-basiert und erhält keinen GPU-Zugriff | Planungsentscheidung; reale Last noch nicht gemessen |
| Parallelität | darf parallel zu AI Production oder AI Testing laufen | Planungsentscheidung |
| Zeitsteuerung | automatische Ausführung ausschließlich außerhalb der Stoßzeiten, zunächst nachts | Richtung festgelegt; konkrete Uhrzeiten fehlen |
@@ -77,29 +77,39 @@ in GPU-Gruppen und keine `/dev/kfd`- oder `/dev/dri`-Weitergabe.
## 5. Repository-Grenzen
Vorgesehene Ansible-Struktur:
Am 19.10.2026 wurde das LLM-Server-Projekt fachlich in ein Hauptverzeichnis pro
Aufgabe aufgeteilt; die Struktur folgt den Bereichen unter
`docs/platform/llm-server/`:
```text
llm-server/ansible/
├── playbooks/
│ ├── host.yml
│ ├── ai.yml
│ ├── video-encoding.yml
│ └── site.yml
└── roles/
├── host_baseline/
├── podman_runtime/
├── workload_accounts/
├── ai_stack/
├── ai_environment_switch/
└── video_encoding/
llm-server/
├── host/ansible/ # gemeinsame Plattform des physischen Servers
│ ├── playbooks/
│ │ ├── host.yml # host_baseline, podman_runtime (shared), workload_accounts, amd_gpu_access
│ │ ├── preflight.yml
│ │ ├── bootstrap-deploy-account.yml
│ │ ├── verify-deploy-access.yml
│ │ └── verify-rocm-container.yml
│ └── roles/
│ ├── host_baseline/
│ ├── workload_accounts/
│ ├── amd_gpu_access/
│ └── rocm_container_probe/
├── llm/ # LLM-Stack; entsteht mit dem AI-Vertical-Slice (GNAI-001 Meilenstein 2)
└── encoding/ansible/ # CPU-Encoding-Workload
├── playbooks/
│ └── video-encoding.yml # video_encoding
└── roles/
└── video_encoding/
```
`host.yml` verwaltet ausschließlich gemeinsame Plattformzustände.
`ai.yml` darf nur KI-Zustände verändern. `video-encoding.yml` verwaltet nur das
Konto `gn-encoding`, seine Pfade, Images, Quadlets, Timer und Health Checks. Ein
späteres `site.yml` kann die unterstützte Gesamtkonfiguration in definierter
Reihenfolge anwenden.
`host.yml` verwaltet ausschließlich gemeinsame Plattformzustände; die
gemeinsame Rolle `workload_accounts` legt dabei auch das Konto `gn-encoding`
an. `video-encoding.yml` verwaltet den Encoding-spezifischen Zustand des Kontos
`gn-encoding` — seine Pfade, Images, Quadlets, Timer und Health Checks — und
setzt die Host-Baseline voraus. Ein künftiges `ai.yml` im `llm/`-Projekt darf nur
KI-Zustände verändern. Ein späteres `site.yml` kann die unterstützte
Gesamtkonfiguration in definierter Reihenfolge anwenden.
Ein separates Quellcode-Repository wird erst benötigt, wenn eigene
Encoding-Software, eine Oberfläche oder ein Queue-Dienst entwickelt wird. Ein
@@ -126,6 +136,17 @@ dank Linger unabhängig von einer Anmeldung. Der Podman-Store wurde als
rootless und getrennt von beiden KI-Stores geprüft. Es wurden noch keine Images
oder Container angelegt.
Am 19.10.2026 wurde das Encoding-Ansible-Projekt unter
`llm-server/encoding/ansible/` eingerichtet. `video-encoding.yml` verwaltet und
verifiziert seitdem den Encoding-Grundzustand: Konto-Identität und Passwort-
sperre, subordinate ID-Bereiche, Verzeichnisstruktur, Quadlet-Verzeichnis,
Linger und aktiver User-Manager, getrennter rootless Podman-Store sowie die
CPU-Isolation (keine GPU-Gruppenmitgliedschaft, kein Lesezugriff auf `/dev/kfd`
oder DRM-Render-Nodes). Solange die offenen Entscheidungen in Abschnitt 7 nicht
getroffen sind, stellt die Rolle zusätzlich sicher, dass weder Quadlet-Dateien
noch Container für `gn-encoding` existieren. Check-Mode und zwei
aufeinanderfolgende Läufe meldeten jeweils `ok=30 changed=0 failed=0`.
## 7. Offene Entscheidungen
1. Welcher Encoder und welches fest versionierte Container-Image werden genutzt?