Migration Kino-Projekt: VM207 → Docker-CT201

Datum: 21.08.2026 Status: erfolgreich migriert; VM207 gestoppt, nicht gelöscht

Zielzustand

Komponente	Neuer Ort	Port/Status
Kino-Projekt	Docker-CT201 `docker`, `192.168.178.224`	`8099`, Container `kino-projekt`, healthy
Token-Monitor	Docker-CT201	`8098`, Container `token-monitor`, healthy
Öffentlicher Kino-Tunnel	CT201 systemd `kino-vps-tunnel.service`	aktiv, Remote-Port `8892`
Jellyfin-Ziel	CT100, `192.168.178.222`	rsync als `kino-transfer` weiterhin aktiv
Alte VM	VM207 `kino-projekt`, `192.168.178.213`	gestoppt, Disk für Rollback erhalten

Live-Dienste, Daten, Umgebungsdateien, SSH-Transferkeys, Reverse-Tunnel und aktive Jobs auf VM207 inventarisiert.
Keine laufenden Importe vor dem Cutover festgestellt; zwei vorhandene Jobs waren bereits done.
Quellcode, SQLite-Datenbank, Export-Staging, Browser-Erweiterung, Transferkey, Token-Monitor-Daten und Tunnelkey gesichert übertragen.
Rollbackfähigen Docker-Stack unter /srv/kino-stack/ auf CT201 aufgebaut.
Kino-Image auf Python 3.12 mit ffmpeg, rsync, OpenSSH, yt-dlp und Playwright/Chromium gebaut.
Build-Test: 45 Tests bestanden, eine unkritische Starlette/httpx-Deprecation-Warnung.
Container laufen im Host-Netz, da Docker-Portweiterleitung auf CT201 von den bestehenden Meshguard-/Docker-Regeln für neue Ports nicht zuverlässig erreichbar war.
Jellyfin-SSH-Regel um kino-transfer@192.168.178.224 ergänzt; alter VM207-Zugang für Rollback beibehalten.
Reverse-Tunnel von VM207 auf CT201 übertragen; NPM-Container erreicht headscale-tunnel-sshd:8892/health mit {"status":"ok"}.
Alte Dienste auf VM207 gestoppt und deaktiviert; finalen Datenstand danach erneut synchronisiert.
VM207 kontrolliert heruntergefahren.

http://192.168.178.224:8099/health → HTTP 200 {"status":"ok"}
http://192.168.178.224:8099/ → HTTP 200
http://192.168.178.224:8099/api/auth/status → bisheriges Verhalten erhalten (enabled=false)
http://192.168.178.224:8098/ → HTTP 200
Playwright/Chromium-Start im Container → PLAYWRIGHT_OK
Analyse einer öffentlichen Internet-Archive-Seite → erlaubter direkter MP4-Kandidat erkannt
SSH-/rsync-Schreibtest aus dem Kino-Container nach /jellyfin → erfolgreich
Realer Testimport einer öffentlichen MP4-Datei → Job done, Datei per rsync auf Jellyfin angekommen; Testjob und Testmedium anschließend entfernt
Container-Restart → beide Container erneut healthy
Tunnel-Restart → aktiv; NPM-interner Upstream-Healthcheck weiterhin OK
Öffentlicher Schutz unverändert: HTTP → HTTPS 301, HTTPS ohne Zugangsdaten → 401
Nach Abschaltung von VM207: alte Ports 192.168.178.213:8099/8080 nicht mehr erreichbar; neue Ports weiterhin HTTP 200

CT201 Stack: /srv/kino-stack/
CT201 Vorbereitungsbackup: /root/kino-stack-backups/pre-migration-20260821-172103
VM207 Rollbackbackup: /root/kino-migration-backup-20260821-154102
PVE-Konfigurationssnapshot: /root/decommissioned-vm-configs/vm207-kino-projekt-20260821-175059.conf
VM207 wurde nicht gelöscht; ein Start ist als schneller Infrastruktur-Rollback weiterhin möglich.

Auf CT201 kino-vps-tunnel.service stoppen und /srv/kino-stack herunterfahren.
VM207 starten.
Auf VM207 kino-projekt.service, token-monitor.service und kino-vps-tunnel.service wieder aktivieren/starten.
Health, rsync und NPM-Tunnel erneut prüfen.

Die vorhandene Token-Monitor-Datenbank wurde unverändert übernommen. Ihr Hermes-History-Snapshot war bereits vor der Migration nicht aktuell; die Provider-Liveabfragen und Alarmzustände laufen weiter. Eine erneuerte automatische Synchronisation der Hermes-state.db ist ein separates Folgeprojekt.
Für den Kino-Dienst ist die neue LAN-Adresse http://192.168.178.224:8099. Der öffentliche Hostname https://kino.dasposchi.de bleibt unverändert.