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.
This commit is contained in:
@@ -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).
|
||||
@@ -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`.
|
||||
Reference in New Issue
Block a user