Files

128 lines
3.8 KiB
Markdown

# Auto-Deploy-Pipeline
Ziel: **`git push` = neue Version automatisch live**, ohne manuellen Eingriff.
## Überblick
```
Code ändern → git push (Gitea) → ┬─ Webhook → Hermes-Receiver → SSH → Dokploy → Build + Deploy
└─ Cron-Polling (alle 2 Min) → Dokploy → Build + Deploy
```
Es gibt **zwei unabhängige Trigger**, weil der Gitea-Webhook unzuverlässig ist (siehe
[„Warum zwei Trigger?"](#warum-zwei-trigger)):
| Mechanismus | Latenz | Zuverlässigkeit |
|-------------|--------|-----------------|
| Gitea-Webhook → Receiver | ~5 s | ⚠️ sporadisch |
| Cron-Polling | ≤ 2 min | ✅ garantiert |
---
## Komponenten
### 1. Gitea-Webhook
Per Gitea-API erstellt:
```bash
curl -X POST "https://git.kgessner.de/api/v1/repos/LuiiCode/techno-todo/hooks" \
-H "Authorization: token $GITEA_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"type": "gitea",
"config": {"url": "http://192.168.0.80:8002/hook", "content_type": "json"},
"events": ["push"],
"active": true
}'
```
Zeigt auf den Webhook-Receiver auf dem Hermes-Server (`192.168.0.80:8002`).
### 2. Webhook-Receiver (Hermes)
Datei: `/home/hermes/webhook-receiver.py`
- Python-Stdlib-`http.server` (keine Dependencies)
- Lauscht auf `0.0.0.0:8002`
- Bei `X-Gitea-Event: push` auf `refs/heads/main` des Ziel-Repos:
- startet **asynchron** (Thread) `ssh root@192.168.0.184 /opt/deploy-techno-todo.sh`
- antwortet sofort mit `200` (Gitea wartet nicht auf den Deploy)
- Loggt in `/home/hermes/webhook-receiver.log`
### 3. Deploy-Skript (Dokploy-Host)
Datei: `/opt/deploy-techno-todo.sh`
**Idempotent** — deployt nur, wenn es neue Commits gibt:
```bash
#!/bin/bash
set -euo pipefail
REPO_DIR="/opt/repos/techno-todo"
SERVICE_NAME="techno-todo-v2-mzs9mj"
cd "$REPO_DIR"
git fetch --all --prune >/dev/null 2>&1
LOCAL=$(git rev-parse HEAD)
REMOTE=$(git rev-parse origin/main)
[ "$LOCAL" = "$REMOTE" ] && { echo "UP-TO-DATE: $LOCAL"; exit 0; }
git reset --hard origin/main
COMMIT=$(git rev-parse --short HEAD)
docker build -t "techno-todo:${COMMIT}" .
docker tag "techno-todo:${COMMIT}" techno-todo:latest
docker service update --force --image "techno-todo:${COMMIT}" "$SERVICE_NAME"
echo "DONE: deployed ${COMMIT}"
```
Das Repo liegt persistent unter `/opt/repos/techno-todo` auf dem Dokploy-Host.
### 4. Cron-Polling (Fallback)
Auf dem Dokploy-Host:
```bash
*/2 * * * * /opt/deploy-techno-todo.sh >> /var/log/techno-todo-deploy.log 2>&1
```
Da das Skript idempotent ist, passiert bei „keine neuen Commits" nichts (exit 0).
---
## Warum zwei Trigger?
Der Gitea-Webhook erwies sich beim POC als **unzuverlässig**: Von mehreren Pushes wurden
nur einige ausgelöst, andere gingen verloren.
**Root-Cause:** Gitea läuft in einem **Kubernetes-Cluster (Talos)** auf Proxmox — also in
einem anderen Netzwerk-Kontext als der Dokploy-Docker-Swarm-Host (`192.168.0.184`) und der
Hermes-Server (`192.168.0.80`). Ausgehende Verbindungen aus dem K8s-Cluster zu internen
`192.168.0.x`-Adressen sind nicht zuverlässig möglich (CNI/NAT-Isolation).
Der Cron-Polling-Fallback umgeht das komplett: Er läuft direkt **auf** dem Dokploy-Host und
holt sich den Git-Stand aktiv ab, statt auf einen eingehenden Webhook zu warten.
---
## Setup-Reihenfolge (für eine neue App)
1. Repo persistent auf Dokploy klonen: `/opt/repos/<app>`
2. Deploy-Skript anpassen (Repo-Dir + Service-Name) → `/opt/deploy-<app>.sh`
3. Cron-Job auf Dokploy einrichten (alle 2 Min)
4. (Optional) Webhook-Receiver auf Hermes starten + Gitea-Webhook einrichten
## Verifikation
```bash
# 1. Push machen
git push
# 2. Nach ~2 Min prüfen:
ssh root@192.168.0.184 "docker service ls --format '{{.Name}} {{.Image}}' | grep techno"
# → techno-todo-v2-mzs9mj techno-todo:<neuer-commit>
# 3. Live testen:
curl -H "Host: techno-todo.192.168.0.184.sslip.io" http://192.168.0.184/
```