Repo-Betrieb

Einleitung

Einzelne Tools kennst du schon. Hier geht es um die Betriebslogik in groupdir-infra: zwei getrennte Ausspielwege (NixOS vs. Terraform), CI, State und automatische Host-Updates. Quellen: README, operations.md, tofu/dns/README.md, .gitlab-ci.yml.

Zwei Ausspielwege

Merksatz: Host-Config = Colmena / autoUpgrade. Öffentliches DNS und Proxmox-VM-Bootstrap = tofu + gemeinsamer Remote-State.

Wo liegt der State?

Der Terraform-State liegt nicht als Datei im Git-Checkout. In CI (und analog für Team-Applies) nutzt das Repo das GitLab HTTP State Backend (backend "http" {} in tofu/*/providers.tf).

• DNS-Stack: State-Name groupdir-dns (Variable TOFU_DNS_STATE_NAME in .gitlab-ci.yml)
• Proxmox-Stack: State-Name groupdir-proxmox

CI setzt u. a. TF_HTTP_ADDRESS auf die GitLab-API (…/terraform/state/<name>) und authentifiziert mit Job-Token. Lokal brauchst du dasselbe Backend (oder bewusst init -backend=false nur zum Validate, ohne echten Shared-State).

Was die Pipeline tut

Stages grob: check → plan → apply (siehe .gitlab-ci.yml).

• check: Format, nix flake check (inkl. der pure Eval-Tests aus tests/, flake.nix-Output checks), NixOS-Builds (u. a. Hosts), tofu validate
• plan: bei Token/Variablen tofu-dns-plan / tofu-proxmox-plan auf Branches und MRs
• apply: auf dem Default-Branch manuelle Jobs; sie wenden das Plan-Artifact derselben Pipeline an

Öffentliches DNS erscheint also nicht „von selbst“ nach Merge: erst Plan, dann bewusster Apply (CI oder lokal).

Updates: was läuft wie?

Abhängigkeits-Updates (Renovate)

Renovate ist ein Bot: wenn neue Versionen von Nix-Abhängigkeiten (Flake-Inputs, z. B. nixpkgs) oder von OpenTofu-Providern verfügbar sind, öffnet er Merge Requests. Die MRs mergen nicht von selbst. Jemand prüft und merged bewusst.

Nach dem Merge laufen die üblichen CI-Checks. Die Hosts übernehmen die neuen Versionen erst beim nächsten Deploy bzw. autoUpgrade. Öffentliches DNS ändert sich dadurch nicht von allein: dafür braucht es weiterhin einen tofu-Plan und Apply.

Host-Updates (NixOS)

lab-gateway und vps haben labEdge.autoUpgrade (Modul auto-upgrade.nix). Das bedeutet: Der Host spielt regelmäßig den aktuellen Stand von main ein. Er holt das Repo per SSH (read-only Deploy-Key), baut daraus sein NixOS und aktiviert die neue Generation. Details: operations.md („Automatic host upgrades“).

Zeitplan (Defaults im Modul): Start ca. 03:15 Uhr, plus zufällige Verzögerung bis 45 Minuten. Darf der Host für die neue Generation neu starten, passiert das nur im Reboot-Fenster 03:00–05:30. Danach läuft Garbage Collection (nix-gc).

Was wird aktualisiert? Nur das, was schon in main steht: eure Konfiguration und die dort gepinnten Paketversionen (flake.lock). Neue Upstream-Versionen kommen nicht von allein auf den Host. Dafür muss erst jemand (oft Renovate) die Pins im Repo anheben und nach main mergen. autoUpgrade verteilt diesen Repo-Stand; Renovate liefert die Versions-Updates im Repo.

Das ersetzt nicht jeden manuellen colmena apply: für sofortige Deploys (oder Hosts ohne autoUpgrade) bleibst du bei Colmena (Lesson 0007).

Was autoUpgrade nicht macht

• Kein automatisches tofu apply für Hetzner-DNS
• Keine Secrets aus dem Repo (Tokens bleiben CI/Host-lokal)

Kurz: Lebenszyklus einer Änderung

1. MR → CI check (+ tofu plan, wenn Secrets da)
2. Merge nach main
3. NixOS: Colmena und/oder nächster autoUpgrade-Lauf auf dem Host
4. Öffentliches DNS / Proxmox: manueller tofu-Apply (CI-Job oder lokal am GitLab-State)

Üben

Primärquelle

operations.md (autoUpgrade), tofu/dns/README.md (State + CI), .gitlab-ci.yml (State-Namen, Stages).

Kompakt: Referenz: Repo-Betrieb.