Nettailor.net

Infrastruktur – Netzwerk, DNS & CI/CD

3 Min. Lesezeit

Themen, die für Gewächshaus (intern, NAS) und Schaugarten (öffentlich, Hetzner) gleichermaßen gelten. Beide Standorte sind über WireGuard VPN verbunden.

Netzwerk & DNS

ZoneTypZweck
interne ZoneInternNur im LAN/VPN auflösbar
dynamische externe ZoneExternÖffentliche IPs (Dyn-DNS)
öffentliche DomainExternÖffentliche Websites/Dienste

DNS wird über eine eigene BIND-Instanz verwaltet (Details zum BIND-Host). Die Records der dynamischen Zone hält der Dyn-DNS-Updater auf der aktuellen WAN-IP.

Docker-Container mit eigener LAN-IP

Für Container, die als eigenständiges Gerät im LAN auftreten müssen (z. B. AdGuard Home), kommt auf der NAS Docker Macvlan statt Bridge zum Einsatz. Details, Setup und die dabei aufgetretenen Stolperfallen (Host-Isolation, Shim-Interface) siehe Docker-Macvlan.

CI/CD

Seit Juli 2026 laufen die eigenen Container-Deployments über Komodo (Builds/Repos/Procedures), getriggert per Forgejo-Webhook bei Push auf main:

  • Image-Builds (tally, inventar, dyn-dns-updater): Komodo Build → Forgejo-Registry → Deployment.

  • Git-Repo-Stack (ki-trading-ibkr → Stack ki-trading-stack): Komodo Stack mit Git-Source (klont das Forgejo-Repo, baut das build:-Image bei jedem Deploy neu via „Pre Build Images”, up -d recreated). Runtime-Daten liegen absolut außerhalb des Klons (/volume1/docker/ki-trading-data), Env im Komodo-Stack-Feld. Aug 2026 von „Files on Server” umgestellt. (Der frühere ki-trading/Alpaca-Stocks-Agent ist seit Aug 2026 stillgelegt.)

  • Git-Pull + Restart (crypto-ki-trading): Komodo Repo mit on_pull.

  • Statische Sites (garden, lost): Komodo Repo baut/kopiert nach /opt/npm/site/, NPM serviert statisch.

  • Forgejo als SCM (eigene Instanz, SSH auf einem eigenen Port; Oktober 2026 von Gitea migriert, Backup per Pull auf die NAS).

🔧 Lessons Learned: Docker Compose – Mount-Änderungen brauchen --force-recreate

Datum: Juli 2026

Nach der Migration von Caddy zu NPM funktionierten garden.nettailor.net und potentiell weitere statisch ausgelieferte Seiten nicht mehr (404). Ursache: der static-Container (nginx:alpine) lief noch mit dem alten Bind-Mount aus der Caddy-Zeit (/var/lib/docker/volumes/caddy_data/_data/site), obwohl das compose.yml längst auf /opt/npm/site umgestellt war.

Grund: Docker liest Volume-/Bind-Mounts nur bei der Erstellung eines Containers ein. Ein reines docker compose restart oder docker restart übernimmt Änderungen an volumes: im compose.yml nicht – der Container muss neu erstellt werden.

Fix:

docker compose up -d --force-recreate <service>

Debugging-Vorgehen, das zum Fehler geführt hat:

  1. docker exec -it static curl -H "Host: garden.nettailor.net" http://localhost:80/ → 404
  2. docker exec -it static ls -la /usr/share/nginx/site/digitalgarden → “No such file or directory”
  3. Host-Seite (ls -la /opt/npm/site/) zeigte aber korrekten Inhalt → Diskrepanz
  4. docker inspect static --format '{{json .Mounts}}' offenbarte den alten Mount-Pfad

Merke: Bei jeder Änderung an volumes: in einem compose.yml grundsätzlich --force-recreate verwenden (oder docker compose down && up -d), nicht nur restart. Betrifft potentiell auch andere Container, die während der Caddy→NPM-Migration nicht neu erstellt wurden – ggf. stichprobenartig mit docker inspect <container> --format '{{json .Mounts}}' gegenprüfen.

Graphansicht

Backlinks