management/hosts/overmind.md

Overmind

Homelab-Host: GitLab (Dokploy-verwaltet) + CI-Runner. Nur im Lab erreichbar — git.lab löst außerhalb des Homelabs nicht auf; Produktion (Flux auf CFGMON/MATRIX) hängt nicht von diesem Host ab, nur neue Builds pausieren bei Ausfall.

Hostname	Overmind
DNS (Lab)	git.lab → 10.58.73.17 (TLS via Dokploy-Proxy, Zertifikate von der aXionLabs-CA: step-ca, 24h-Leaf, Intermediate bis 2035)
CPU/RAM	14 Kerne, 30 Gi (Stand 2026-07-31: ~11 Gi verfügbar)
Disk	444 G NVMe (~278 G frei, Stand 2026-07-31)
KVM	/dev/kvm vorhanden — Basis für die Windows-Build-VM
Stand	2026-07-31

Dienste

Dienst	Definition	Anmerkungen
GitLab CE 18.7.1 + Postgres 16 + Redis 7	Dokploy-Stack management-gitlabce	external_url https://git.lab, SSH 2224; TLS terminiert der Dokploy-Proxy (GitLab-nginx lauscht nur :80)
gitlab-runner lab-builder-1 (v18.7.0)	gleicher Stack, Service gitlab-runner	Docker-Executor + Socket, concurrent = 1. Stolpersteine, live gefunden: (1) Docker-interner DNS löst git.lab auf den GitLab-Container auf, wo 443 zu ist → extra_hosts: git.lab:10.58.73.17 nötig; (2) Lab-CA muss nach /etc/gitlab-runner/certs/git.lab.crt (Config-Volume, übersteht Redeploys)
gitlab-runner lab-windows-1	Windows-Gast in der Build-VM	Tags [windows], run_untagged=false, Shell-Executor PowerShell — siehe Runbook
Windows-Build-VM	Dokploy-Stack windows-runner (geplant/in Einrichtung)	Image rohana.axion1337.de/sorb/windows-vm:6662d55f (Eigenbau aus reviewtem Pin 7645a2b, Vendor-Repo git.lab/axion1337.chat/vendor/windows), on-demand (restart: "no", Start/Stop über CI-Jobs), 8G/6 Kerne/96G. Runbook: docs/axion-runner.md im Vendor-Repo

Repo-Topologie (Kontext)

git.lab ist seit 2026-07-31 kanonisch für die 5 gespiegelten Repos (ThreadNet-Web, threadnet-call, thread-net-git, threadnet-operating, axion1337.chat-gitops) — Push-Mirrors nach rohana/Gitea, direkte Gitea-Pushes tabu. Gitea bleibt: Flux-Source (via Mirror beliefert), Registry, Packages, Issues, Backlogs (dieses Repo, ungespiegelt).

OVERMIND-01 — GitLab-Container-Registry aktivieren, Images nach Konsument sortieren

Status: in Arbeit (2026-07-31)

Die eingebaute GitLab-Registry ist aus (kein registry_external_url im Omnibus-Config). Folge: lab-interne Build-Images (windows-vm, element-desktop-build) machen den Umweg Lab-CI → rohana (Prod, Internet) → zurück ins Lab — koppelt Lab-Infrastruktur unnötig an die Verfügbarkeit des Prod-Hosts.

Ziel-Sortierung nach Konsument:

• rohana (Gitea) behält: sorb/threadnet-web (App-Image — Flux/Prod pullt es), npm-Packages
• Lab-Registry (registry.git.lab) bekommt: windows-vm, element-desktop-build — beides konsumiert nur das Lab selbst

Umsetzung (TLS terminiert wie bei git.lab der Dokploy-Proxy):

1. Omnibus-Config: registry_external_url 'https://registry.git.lab', registry_nginx['listen_port'] = 5050, registry_nginx['listen_https'] = false; Port 5050 in der Compose exposen
2. Lab-DNS: registry.git.lab → 10.58.73.17
3. Dokploy: Domain registry.git.lab → GitLab-Service Port 5050 (Zertifikat von der aXionLabs-CA wie gehabt)
4. Docker-Daemon-Trust auf Overmind: CA-Kette nach /etc/docker/certs.d/registry.git.lab/ca.crt (Datei liegt schon als /tmp/git.lab.crt vom Runner-Setup — kopieren reicht; kein Daemon-Restart nötig)
5. CI-Umstellung: vendor/windows pusht nach registry.git.lab (Bonus: GitLabs eingebaute $CI_REGISTRY/$CI_JOB_TOKEN-Auth statt Gruppen-Secrets), desktop_image/desktop_linux in ThreadNet-Web folgen; Registry-Speicher liegt im gitlab_data-Volume (278 G frei)

Fortschritt 2026-07-31: Punkte 1–4 umgesetzt (Registry live auf registry.git.lab, 401/Bearer-Auth korrekt, CA-Trust auf dem Host); vendor/windows pusht per CI_JOB_TOKEN in die Lab-Registry — verifiziert, Tags 5bc25447 + stable vorhanden, Runbook referenziert stable.

Nächster Schritt: element-desktop-build von rohana in die Lab-Registry umziehen (ThreadNet-Web-CI: desktop_image-Push-Ziel + desktop_linux-Image-Referenz) — bewusst zurückgestellt, bis kein Auto-Job das alte Image parallel referenziert (Reihenfolge: erst neues Image bauen, dann Referenz umstellen).

---

Weitere CI-Betriebsthemen laufen über die Projekt-Issues (ThreadNet-Web#5 Windows-Strecke, threadnet-call#1 npm-Ziel) und CFGMON-11 (Gitea-CI-Rückbau).