From f470e88e9f0e03678d8ace51d053f79ea70c4ae5 Mon Sep 17 00:00:00 2001 From: Stefan Mogeritsch Date: Thu, 12 Feb 2026 12:01:59 +0100 Subject: [PATCH] docs: add roadmap for Zora infrastructure deployment and "Hello-World" test guide Added two new documents, `Zora_Infrastructure&Deployment_02-2026.md` and `Temp.md`, detailing the strategic roadmap for Zora's infrastructure setup and deployment phases, alongside a "Hello-World" test project guide to validate CI/CD pipelines and ARM64 compatibility. --- docs/Temp.md | 87 +++++++++++++++++++ .../Zora_Infrastructure&Deployment_02-2026.md | 60 +++++++++++++ 2 files changed, 147 insertions(+) create mode 100644 docs/Temp.md create mode 100644 docs/Zora_Infrastructure&Deployment_02-2026.md diff --git a/docs/Temp.md b/docs/Temp.md new file mode 100644 index 00000000..29e12b2b --- /dev/null +++ b/docs/Temp.md @@ -0,0 +1,87 @@ +# **„Hello-World“-Testprojekt** + +Bevor das **"Meldestelle"-Projekt** auf **Zora** losgelassen wird, erstellen wir ein **"Hallo Welt"-Projekt**. Das spart Zeit beim Debugging, wenn der Test-Build fehlschlägt, wissen wir sofort, es liegt an der Infrastruktur (Runner/Registry) und nicht an komplexen Gradle-Abhängigkeiten. + +## Plan für "Sandbox-Projekt“, um die CI/CD-Leitung auf **Zora** zu testen. + +--- + +### 1. Runner-Stabilisierung: Der „Herz-Check“ + +Bevor das Testprojekt gepusht wird, müssen wir sicherstellen, dass der Runner nicht nur „jetzt“ online war, sondern als stabiler Dienst im Hintergrund läuft. + +**Checke das im Container `infra-runner`:** + +```bash +incus exec infra-runner -- systemctl status act_runner + +``` + +* **Wenn „active (running)“:** Alles bestens. +* **Falls nicht:** Starte ihn mit `systemctl enable --now act_runner`. +* **Gitea-Check:** Im Browser sollte der Status jetzt von **Inaktiv** (Grau/Gelb) auf **Aktiv** (Grün) springen, sobald der Dienst läuft. + +--- + +### 2. Das Test-Projekt: „Zora-Proof-of-Concept“ + +Erstelle in deiner IDEA (oder direkt in Gitea) ein neues, leeres Repository namens `zora-test`. + +#### A. Die minimale Dockerfile + +Wir nehmen ein extrem kleines Image, um die ARM64-Fähigkeit zu testen: + +```dockerfile +FROM alpine:latest +RUN echo "Zora hat dieses Image gebaut!" > /hello.txt +CMD ["cat", "/hello.txt"] + +``` + +#### B. Der Workflow (`.gitea/workflows/test.yaml`) + +Hier nutzen wir deine neuen Secrets `REGISTRY_TOKEN` und `REGISTRY_USER`. + +```yaml +name: Zora Test Build +on: [push] +jobs: + build-and-push: + runs-on: ubuntu-latest # Dein Runner erkennt das Label + steps: + - name: Checkout + uses: actions/checkout@v4 + + - name: Login to Registry + uses: docker/login-action@v3 + with: + registry: git.mo-code.at + username: ${{ secrets.REGISTRY_USER }} + password: ${{ secrets.REGISTRY_TOKEN }} + + - name: Build and Push + uses: docker/build-push-action@v5 + with: + context: . + push: true + tags: git.mo-code.at/${{ secrets.REGISTRY_USER }}/zora-test:latest + +``` + +--- + +### 3. Warum dieser Test so wertvoll ist + +1. **Registry-Rechte:** Wir prüfen, ob dein neuer Token wirklich Pakete schreiben darf. +2. **LXC-Docker-Check:** Wir sehen, ob Docker im Container `infra-runner` mit dem `fuse-overlayfs` Treiber wirklich Images bauen kann. +3. **ARM64-Verifizierung:** Wir bestätigen, dass der Runner das Image nativ für dein Biest baut. + +--- + +### Was wir kontrollieren müssen (Erfolgskriterien): + +* [ ] Erscheint in Gitea unter dem Reiter **„Actions“** ein neuer Eintrag nach dem Push? +* [ ] Läuft der Build ohne Fehler durch? +* [ ] Taucht unter deinem Profil in Gitea ein neues **„Paket“** namens `zora-test` auf? + +**Soll ich dir, sobald du das Testprojekt in Gitea angelegt hast, helfen das Log-Streaming des Runners zu analysieren, falls er beim `docker login` hängen bleibt?** (Das ist oft die Stelle, an der falsche Secret-Namen auffallen). diff --git a/docs/Zora_Infrastructure&Deployment_02-2026.md b/docs/Zora_Infrastructure&Deployment_02-2026.md new file mode 100644 index 00000000..abb517b0 --- /dev/null +++ b/docs/Zora_Infrastructure&Deployment_02-2026.md @@ -0,0 +1,60 @@ +--- + +Hier ist eine strategische Roadmap für den Ausbau des „Empires“ auf **Zora**. Da du aktuell im „Mo’s Territory“ bist, dient dieser Plan als Vorbereitung für deine nächste Session am Gerät. + +:white_check_mark: +--- + +# Roadmap: Zora Infrastructure & Deployment (Februar 2026) + +## Phase 1: Identity & CI/CD "Green Light" + +**Ziel:** Den automatisierten Workflow scharf schalten und Berechtigungskonflikte lösen. + +* ✅ **Gitea Secrets Finalisierung:** Erstellen der Secrets + * `REGISTRY_TOKEN` und + * `REGISTRY_USER` im Repository „Meldestelle“ (Umgehung der `GITEA_`-Namenssperre). +*[ ] **Runner-Stabilisierung:** + * Prüfen des Systemd-Status von `act_runner` im Container `infra-runner`. +*[ ] Sicherstellen, dass der Status im Gitea-Interface von „Inaktiv“ auf „Aktiv“ springt. +*[ ] **Erster Test-Build:** + * Erstellen eines Test-Projekts und + * Push aus der IDEA auslösen und das Log-Streaming in Gitea Actions verfolgen. +*[ ] Verifizieren, dass das Docker-Image in der Gitea-Registry (`git.mo-code.at`) landet. + +--- + +## Phase 2: Core-Infrastructure Deployment + +**Ziel:** Die Basis-Dienste (Datenbanken, Auth) in der `prod-meldestelle` zum Laufen bringen. + +*[ ] **Umgebungs-Konfiguration:** * Vervollständigen der `/home/grandmo/meldestelle/.env` mit echten Passwörtern und + Keycloak-Secrets. +*[ ] **Stack-Launch (dc-infra.yaml):** * Start von **Postgres**, **Keycloak** und **Valkey** (Redis-Alternative). +*[ ] **Wichtig:** Kontrolle der Logs auf ARM64-Kompatibilität (`exec format error` vermeiden). +*[ ] **Netzwerk-Check:** * Testen der Erreichbarkeit von Zoras Mail-Relay (`10.0.6.1:25`) aus dem neuen Stack heraus. + +--- + +## Phase 3: Application & Gateway Launch + +**Ziel:** Den Ping-Service über das Spring Cloud Gateway erreichbar machen. + +*[ ] **Backend-Start (dc-backend.yaml):** * Deployment des **api-gateways** und des **ping-services**. +*[ ] **Cloudflare-Tunnel Update:** * Hinzufügen der Route `api.mo-code.at`, die auf die IP der Meldestelle (`10.0.6.50`) + und den Port des Gateways (`8080`) zeigt. +*[ ] **Keycloak-Veredelung:** * Konfiguration des Realms und Erstellen des Clients für die Meldestelle im + Keycloak-Admin-Panel (via `auth.mo-code.at`). + +--- + +## Phase 4: Resilience & Hardening + +**Ziel:** Das System gegen äußere Einflüsse und Datenverlust absichern. + +*[ ] **USV-Anbindung (NUT):** * Installation und Konfiguration der Network UPS Tools für die **Eaton 3S850D**. +*[ ] Test des Shutdown-Szenarios bei kritischem Akkustand. +*[ ] **Monitoring-Integration (dc-ops.yaml):** * Start von **Prometheus** und **Grafana**. +*[ ] Anbindung des Alertmanagers an das Postfix-Relay für E-Mail-Alarme. +*[ ] **Backup-Vollendung:** * Erweiterung des nächtlichen 03:00-Uhr-Skripts um die Sicherung der neuen Docker-Volumes in + `prod-meldestelle`.