watermaps/infra/opentofu/README.md

Watermaps auf Hetzner Cloud

Diese OpenTofu-Konfiguration erstellt einen einzelnen Ubuntu-24.04-Server mit fester IPv4-Adresse, vorgeschalteter Hetzner-Firewall und einem persistenten ext4-Volume für die Routingdaten von Deutschland und den Niederlanden. Kartenkacheln, DNS-Einträge und Anwendungsdeployment sind bewusst nicht Teil dieses Infrastrukturmoduls.

Konfiguration

Die lokale Datei terraform.tfvars ist bereits angelegt und wird durch die lokale .gitignore ausgeschlossen. Vor dem ersten Plan müssen dort mindestens folgende Werte ersetzt werden:

• hcloud_token: Read/Write-API-Token des richtigen Hetzner-Cloud-Projekts
• ssh_public_key: vollständiger Inhalt des öffentlichen SSH-Schlüssels
• admin_cidrs: öffentliche Administrator-IP mit /32 beziehungsweise ein bewusst gewähltes Netz

terraform.tfvars.example bleibt als geheimnisfreie Vorlage versioniert. Da terraform.tfvars den Token im Klartext enthält, sollte sie nur für den lokalen Benutzer lesbar sein:

chmod 600 terraform.tfvars

Auch terraform.tfstate bleibt lokal und wird nicht nach Git oder auf den Anwendungsserver übertragen. Nach dem ersten Apply sollte die State-Datei verschlüsselt gesichert werden, weil OpenTofu sie für spätere Änderungen an denselben Ressourcen benötigt.

Infrastruktur erzeugen

cd infra/opentofu
tofu init
tofu fmt -check
tofu validate
tofu plan -out=watermaps.tfplan
tofu apply watermaps.tfplan

Die feste IPv4-Adresse und den erforderlichen manuellen DNS-Eintrag zeigt OpenTofu anschließend an:

tofu output server_ipv4
tofu output dns_a_record
tofu output ssh_command

Der A-Record watermaps.incoso.eu kann direkt nach dem Apply auf server_ipv4 gesetzt werden. Das eigentliche SSL-Livegehen erfolgt erst durch das separate Deployment-Skript, nachdem DNS propagiert ist und die Routingdaten bereitstehen.

Auf dem Server

Cloud-init installiert Docker einschließlich Compose v2, curl, jq und rsync. Der Benutzer deploy erhält Zugriff per SSH und auf Docker. Das persistente Volume wird nach dem Anhängen unter /srv/watermaps-data gemountet und enthält die vom Produktions-Stack verwendeten Verzeichnisse geofabrik, local und certbot. Ein systemd-Drop-in lässt Docker bei jedem Start auf den erfolgreichen Volume-Mount warten, bevor bestehende Container neu gestartet werden.

Der Status des ersten Starts lässt sich so prüfen:

ssh deploy@"$(tofu output -raw server_ipv4)" \
  "cloud-init status --wait && systemctl status watermaps-volume-setup --no-pager"