d14f828aa5
Some checks failed
Deploy Marketing-Site / Build, Test und Deploy (push) Failing after 1m11s
Die Repo-Version war eine 'Wunsch-Version' aus dem Brief mit Logging, Cache-Headers und Status-Page-Auth-Placeholder. Tatsaechlich produktiv laufen die schlanken Bloecke aus diesem Commit, plus ein temporaerer Basic-Auth- Schutz fuer slimcore.io (User: demo / Pass: demo, bcrypt-Hash inline) solange die Site noch im Aufbau ist. Vor Live-Schaltung: basic_auth-Block + X-Robots-Tag-Zeile entfernen, committen, 'docker exec marketing-caddy caddy reload' auf marketing-VPS. |
||
|---|---|---|
| .. | ||
| Caddyfile | ||
| docker-compose.yml | ||
| README.md | ||
Marketing-VPS Konfiguration
Diese Verzeichnisinhalte werden auf den Marketing-VPS (marketing.digiformer.eu) deployt
und sind dort die Source of Truth für Caddy + Uptime Kuma.
Initial-Deploy auf den VPS
# Auf einem Rechner mit SSH-Zugang zum Marketing-VPS
rsync -avz --delete \
-e "ssh -i ~/.ssh/marketing-admin" \
infra/marketing-vps/ \
deploy@marketing.digiformer.eu:/home/deploy/marketing/
# Auf dem Marketing-VPS
ssh deploy@marketing.digiformer.eu
cd /home/deploy/marketing
sudo mkdir -p /var/www /var/log/caddy
sudo chown -R deploy:deploy /var/www /var/log/caddy
docker compose up -d
docker compose logs -f caddy
Caddyfile-Update
Caddy validiert und lädt neu mit:
docker compose exec caddy caddy validate --config /etc/caddy/Caddyfile
docker compose exec caddy caddy reload --config /etc/caddy/Caddyfile
Status-Page-Passwort setzen
docker compose exec caddy caddy hash-password
# Eingabe-Aufforderung, gibt bcrypt-Hash aus
# In Caddyfile bei `status.digiformer.eu` einsetzen, dann reload
Neue Marken-Site hinzufügen
- Caddyfile-Block ergänzen (analog zu
slimcore.io) caddy reload(siehe oben)- DNS A-Record für
<neue-domain>.<tld>auf VPS-IP zeigen - Forgejo-Workflow im jeweiligen Marken-Repo deployt automatisch nach
/var/www/<neue-domain>/
SSH-Berechtigungen für Forgejo-Runner
Der Runner braucht einen User mit rsync-only-Rechten auf /var/www/:
# Auf Marketing-VPS
sudo adduser --disabled-password --gecos "" rsync-deploy
sudo mkdir -p /home/rsync-deploy/.ssh
# rrsync ist Teil des rsync-Pakets
sudo apt install rsync
RRSYNC=$(find /usr -name 'rrsync' 2>/dev/null | head -1)
# authorized_keys mit Befehls-Restriktion: nur Schreiben in /var/www
echo "command=\"$RRSYNC -wo /var/www\",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty <forgejo-runner-public-key>" \
| sudo tee /home/rsync-deploy/.ssh/authorized_keys
sudo chmod 700 /home/rsync-deploy/.ssh
sudo chmod 600 /home/rsync-deploy/.ssh/authorized_keys
sudo chown -R rsync-deploy:rsync-deploy /home/rsync-deploy/.ssh
# rsync-deploy braucht Schreibrechte
sudo chown rsync-deploy:rsync-deploy /var/www
Disaster-Recovery
- Caddy-Container fällt aus →
docker compose restart caddy - VPS unreachable → siehe
docs/deployment.md(RTO ~45 min, statisches Build-Output reproduzierbar) - TLS-Cert-Problem →
caddy-data-Volume enthält Let's-Encrypt-Account. Bei Volume-Verlust holt Caddy automatisch neue Certs (~30 s pro Domain) - Uptime-Kuma-Daten verloren → kritischer Schaden gering, Monitor-Konfiguration neu anlegen (~10 min)