mirror of
https://github.com/Memo-2023/mana-monorepo.git
synced 2026-05-18 12:49:40 +02:00
docs: remove all Coolify references from codebase
Replace Coolify with Docker Compose throughout documentation. The project never used Coolify - a removal script was created but never executed, leaving incorrect documentation. Changes: - Delete 13 heavily Coolify-focused docs files - Update ~30 files replacing Coolify → Docker Compose - Remove obsolete removal script - Fix deployment references in active and archived projects 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Wuesteon
parent
79b4bb07ed
commit
c61dcb8ff9
42 changed files with 176 additions and 4741 deletions
|
|
@ -15,7 +15,7 @@ Das uLoad-Projekt war kürzlich komplett down, was zu kritischen Problemen gefü
|
|||
|
||||
- **Frontend:** SvelteKit 2.22 mit Svelte 5.0
|
||||
- **Backend:** PocketBase (https://pb.ulo.ad)
|
||||
- **Hosting:** Hetzner VPS mit Coolify
|
||||
- **Hosting:** Hetzner VPS mit Docker Compose
|
||||
- **Database:** PocketBase SQLite mit persistentem Volume
|
||||
- **Deployment:** Docker mit Supervisor (Multi-Service Container)
|
||||
|
||||
|
|
@ -29,7 +29,7 @@ Das uLoad-Projekt war kürzlich komplett down, was zu kritischen Problemen gefü
|
|||
2. **Single Server Setup**
|
||||
- Ein Hetzner VPS für gesamte Infrastruktur
|
||||
- Keine Redundanz oder Load Balancing
|
||||
- Coolify als Single Point of Failure
|
||||
- Single server as Point of Failure
|
||||
|
||||
3. **Container Architecture**
|
||||
- SvelteKit und PocketBase in einem Container
|
||||
|
|
@ -370,8 +370,8 @@ jobs:
|
|||
steps:
|
||||
- name: Deploy to Primary
|
||||
run: |
|
||||
# Coolify Deployment
|
||||
curl -X POST ${{ secrets.COOLIFY_WEBHOOK }}
|
||||
# Docker Deployment
|
||||
ssh deploy@server "cd /app && docker compose pull && docker compose up -d"
|
||||
|
||||
- name: Health Check
|
||||
run: |
|
||||
|
|
@ -389,7 +389,7 @@ jobs:
|
|||
if: failure()
|
||||
run: |
|
||||
# Automatisches Rollback bei Fehler
|
||||
curl -X POST ${{ secrets.COOLIFY_ROLLBACK_WEBHOOK }}
|
||||
ssh deploy@server "cd /app && git checkout HEAD~1 && docker compose up -d"
|
||||
```
|
||||
|
||||
### 2. Monitoring & Alerting
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
### 1. Environment Separation
|
||||
|
||||
- **Development**: `http://localhost:8090` (lokal)
|
||||
- **Production**: `https://pb.ulo.ad` (Coolify)
|
||||
- **Production**: `https://pb.ulo.ad` (Docker)
|
||||
- Automatische Umgebungserkennung basierend auf `dev` Flag
|
||||
|
||||
### 2. Code-Änderungen
|
||||
|
|
@ -181,10 +181,10 @@ Falls Probleme: Admin UI → Settings → API Rules
|
|||
| Aspekt | Development | Production |
|
||||
| -------------- | --------------------- | ----------------- |
|
||||
| PocketBase URL | http://localhost:8090 | https://pb.ulo.ad |
|
||||
| Datenbank | Lokal (SQLite) | Cloud (Coolify) |
|
||||
| Datenbank | Lokal (SQLite) | Cloud (Docker) |
|
||||
| Auth | Test-Accounts | Echte User |
|
||||
| Stripe | Test-Keys | Live-Keys |
|
||||
| Redis | localhost:6379 | Coolify Redis |
|
||||
| Redis | localhost:6379 | Docker Redis |
|
||||
| SSL | Nein (HTTP) | Ja (HTTPS) |
|
||||
| CSP | Relaxed | Strict |
|
||||
|
||||
|
|
|
|||
|
|
@ -1,513 +0,0 @@
|
|||
Redis Cache für uLoad - Was bringt es
|
||||
wirklich?
|
||||
|
||||
Das Hauptproblem aktuell
|
||||
|
||||
Jedes Mal wenn jemand einen deiner
|
||||
Short-Links klickt, muss deine App:
|
||||
|
||||
1. PocketBase fragen "welche URL gehört zu
|
||||
diesem Short-Code?"
|
||||
2. Warten bis PocketBase in der SQLite
|
||||
Datei sucht
|
||||
3. Antwort zurückgeben und weiterleiten
|
||||
|
||||
Das dauert 50-100ms pro Klick. Bei vielen
|
||||
Klicks wird PocketBase zum Flaschenhals.
|
||||
|
||||
Was Redis ändern würde
|
||||
|
||||
Redis ist wie ein ultra-schneller
|
||||
Zwischenspeicher. Statt jedes Mal
|
||||
PocketBase zu fragen, schaust du erst in
|
||||
Redis nach. Das ist 20-50x schneller!
|
||||
|
||||
Die 3 größten Verbesserungen
|
||||
|
||||
1. Link-Redirects (90% deines Traffics)
|
||||
|
||||
Problem: Jeder Klick = PocketBase Query =
|
||||
langsam
|
||||
Lösung: Beliebte Links werden in Redis
|
||||
gespeichert
|
||||
|
||||
Beispiel:
|
||||
|
||||
- Dein Link "ulo.ad/meeting" wird 100x am
|
||||
Tag geklickt
|
||||
- Ohne Redis: 100x PocketBase Query (100x
|
||||
80ms = 8 Sekunden Serverzeit)
|
||||
- Mit Redis: 1x PocketBase + 99x Redis (1x
|
||||
80ms + 99x 2ms = 0.28 Sekunden)
|
||||
|
||||
Ergebnis: 30x schneller, 95% weniger
|
||||
PocketBase Last
|
||||
|
||||
2. Dashboard Performance
|
||||
|
||||
Problem: Dein Dashboard lädt alle deine
|
||||
Links aus PocketBase
|
||||
Lösung: Links werden für 5 Minuten gecacht
|
||||
|
||||
Beispiel:
|
||||
|
||||
- Du hast 50 Links, checkst Dashboard 20x
|
||||
am Tag
|
||||
- Ohne Redis: 20x komplette Liste laden =
|
||||
langsam
|
||||
- Mit Redis: 1x laden, 19x aus Cache =
|
||||
blitzschnell
|
||||
|
||||
3. Analytics & Statistiken
|
||||
|
||||
Problem: Click-Zahlen berechnen ist langsam
|
||||
(viele Datenbankabfragen)
|
||||
Lösung: Statistiken werden live berechnet
|
||||
und gecacht
|
||||
|
||||
Beispiel:
|
||||
|
||||
- "Zeige Clicks der letzten 7 Tage" braucht
|
||||
normalerweise komplizierte Queries
|
||||
- Mit Redis: Zahlen werden kontinuierlich
|
||||
aktualisiert, sofort verfügbar
|
||||
|
||||
Rate Limiting Verbesserung
|
||||
|
||||
Aktuell: Dein Rate Limiter vergisst alles
|
||||
bei Server-Restart
|
||||
Mit Redis: Rate Limits bleiben bestehen,
|
||||
auch über Restarts hinweg
|
||||
|
||||
Das bedeutet: Angreifer können nicht mehr
|
||||
durch Server-Restart deine Limits umgehen.
|
||||
|
||||
Konkrete Zahlen für dich
|
||||
|
||||
Traffic-Verteilung schätzen:
|
||||
|
||||
- 90% Redirects (Leute klicken deine Links)
|
||||
- 8% Dashboard/API (Du managst deine Links)
|
||||
|
||||
- 2% Sonstiges (Login, Settings, etc.)
|
||||
|
||||
Performance ohne Redis:
|
||||
|
||||
- Redirect: 80ms durchschnittlich
|
||||
- Dashboard laden: 300ms
|
||||
- Bei 1000 Klicks/Tag: PocketBase ist
|
||||
gestresst
|
||||
|
||||
Performance mit Redis:
|
||||
|
||||
- Redirect: 5ms (95% aus Cache)
|
||||
- Dashboard laden: 20ms (meist aus Cache)
|
||||
- Bei 10.000 Klicks/Tag: PocketBase
|
||||
entspannt
|
||||
|
||||
Wann merkst du den Unterschied?
|
||||
|
||||
Sofort spürbar:
|
||||
|
||||
- Dashboard lädt viel schneller (besonders
|
||||
mit vielen Links)
|
||||
- Redirects sind blitzschnell
|
||||
- Analytics laden sofort statt zu "denken"
|
||||
|
||||
Bei mehr Traffic:
|
||||
|
||||
- Server bleibt entspannt auch bei
|
||||
Viral-Links
|
||||
- Keine Timeouts mehr bei hoher Last
|
||||
- PocketBase überlastet nicht
|
||||
|
||||
Skalierung:
|
||||
|
||||
- Ohne Redis: ~500 Redirects/Minute machbar
|
||||
- Mit Redis: ~5000+ Redirects/Minute
|
||||
machbar
|
||||
|
||||
Kosten vs. Nutzen
|
||||
|
||||
Option 1: Kostenlos starten
|
||||
|
||||
- Upstash Redis (10k Commands/Tag gratis)
|
||||
- Perfekt zum Testen
|
||||
- Upgrade wenn nötig
|
||||
|
||||
Option 2: Minimale Kosten
|
||||
|
||||
- €5-15/Monat für ordentlichen Redis
|
||||
- Dafür 10x bessere Performance
|
||||
|
||||
Was du sparst:
|
||||
|
||||
- Weniger Server-Stress = längere
|
||||
Hardware-Lebensdauer
|
||||
- Bessere User Experience = mehr zufriedene
|
||||
Nutzer
|
||||
- Skalierung möglich ohne neuen Server
|
||||
|
||||
Die Realität für uLoad
|
||||
|
||||
Jetzt: Bei 100 Klicks gleichzeitig würde
|
||||
dein Server wahrscheinlich strugglen
|
||||
Mit Redis: Bei 1000 Klicks gleichzeitig
|
||||
läuft alles smooth
|
||||
|
||||
Jetzt: Dashboard mit 100 Links braucht eine
|
||||
Sekunde zum Laden
|
||||
Mit Redis: Dashboard lädt in 0.1 Sekunden
|
||||
|
||||
Jetzt: Click-Statistiken berechnen dauert
|
||||
ewig
|
||||
Mit Redis: Statistiken sind immer aktuell
|
||||
und sofort da
|
||||
|
||||
Meine ehrliche Einschätzung
|
||||
|
||||
Für uLoad ist Redis ein No-Brainer:
|
||||
|
||||
- Minimaler Aufwand (2-3 Tage Setup)
|
||||
- Maximaler Nutzen (10x Performance)
|
||||
- Kosten fast null (kann gratis starten)
|
||||
|
||||
Der größte Gewinn ist bei Redirects - das
|
||||
ist dein Kernfeature und wird damit
|
||||
ultra-schnell. Plus du bist ready für
|
||||
Viral-Links die plötzlich 1000x geklickt
|
||||
werden.
|
||||
|
||||
Bottom Line: Redis macht aus deinem "hobby
|
||||
project" eine professionelle, skalierbare
|
||||
Anwendung für praktisch null Zusatzkosten.
|
||||
Das ist vermutlich das beste ROI was du
|
||||
kriegen kannst! 🎯
|
||||
|
||||
> super danke. wir können ja reddis auch
|
||||
> einfach auf unserem hetzter vps mit coolify
|
||||
> hochfahren oder? was brucht es an
|
||||
> reccourcen? was mus man beachten? sollte es
|
||||
> lieber auf einem adnere server liegen?
|
||||
> sollte es im gleichen project in coolify
|
||||
> liegen?
|
||||
|
||||
⏺ Redis auf Hetzner VPS mit Coolify -
|
||||
Perfekte Idee!
|
||||
|
||||
Ja, absolut machbar und sinnvoll!
|
||||
|
||||
Dein aktueller Hetzner VPS kann Redis
|
||||
problemlos mit hosten. Coolify macht das
|
||||
super einfach.
|
||||
|
||||
Resource-Bedarf von Redis
|
||||
|
||||
RAM (das Wichtigste):
|
||||
|
||||
- Redis lädt alles in den RAM - das macht
|
||||
es so schnell
|
||||
- Für uLoad geschätzt: 50-200MB RAM
|
||||
- Link Cache: ~1MB pro 10.000 Links
|
||||
- Session Cache: ~10MB für 1000 aktive
|
||||
User
|
||||
- Analytics: ~20-50MB je nach History
|
||||
- Rate Limiting: ~5-10MB
|
||||
|
||||
CPU:
|
||||
|
||||
- Minimal! Redis ist extrem CPU-effizient
|
||||
- Für uLoad: <1% CPU Auslastung
|
||||
- Nur bei komplexen Operationen mehr
|
||||
|
||||
Disk:
|
||||
|
||||
- Persistence: 100-500MB für Dumps
|
||||
- Logs: 10-50MB
|
||||
- Total: <1GB
|
||||
|
||||
Dein CX21 VPS Kapazität:
|
||||
|
||||
- RAM: 8GB total, aktuell ~2GB verwendet →
|
||||
6GB frei!
|
||||
- CPU: 2 vCPUs, aktuell <20% → Mehr als
|
||||
genug
|
||||
- Disk: 40GB, Redis braucht <1GB → Kein
|
||||
Problem
|
||||
|
||||
Fazit: Dein Server kann Redis locker
|
||||
verkraften! 🎯
|
||||
|
||||
Coolify Setup - zwei Optionen
|
||||
|
||||
Option 1: Gleiches Projekt (Empfohlen für
|
||||
Start)
|
||||
|
||||
# Einfach Redis Service zu deinem
|
||||
|
||||
bestehenden docker-compose hinzufügen
|
||||
services:
|
||||
app: # Deine bestehende App
|
||||
|
||||
redis:
|
||||
image: redis:7-alpine
|
||||
command: redis-server --appendonly yes
|
||||
|
||||
--maxmemory 512mb --maxmemory-policy
|
||||
allkeys-lru
|
||||
volumes: - redis-data:/data
|
||||
restart: unless-stopped
|
||||
healthcheck:
|
||||
test: ["CMD", "redis-cli", "ping"]
|
||||
interval: 30s
|
||||
timeout: 10s
|
||||
retries: 3
|
||||
|
||||
volumes:
|
||||
redis-data:
|
||||
|
||||
Option 2: Separates Projekt in Coolify
|
||||
|
||||
- Vorteil: Unabhängiges Deployment von
|
||||
deiner App
|
||||
- Nachteil: Etwas komplizierter zu
|
||||
verwalten
|
||||
|
||||
Ich empfehle Option 1 - Redis ist so
|
||||
stabil, das macht keinen Unterschied.
|
||||
|
||||
Coolify Konfiguration
|
||||
|
||||
Redis Environment Variables:
|
||||
|
||||
# In Coolify für Redis Service setzen:
|
||||
|
||||
REDIS_PASSWORD=dein-sicheres-passwort-hier
|
||||
REDIS_MAXMEMORY=512mb
|
||||
REDIS_SAVE_INTERVAL=900 # Auto-save alle
|
||||
15 Min
|
||||
|
||||
Deine App erweitern:
|
||||
|
||||
# Environment Variable für deine App
|
||||
|
||||
hinzufügen:
|
||||
REDIS_URL=redis://:dein-passwort@redis:6379
|
||||
|
||||
Networking in Coolify:
|
||||
|
||||
- Redis und App sind automatisch im
|
||||
gleichen Docker Network
|
||||
- Deine App kann Redis über redis:6379
|
||||
erreichen
|
||||
- Kein Port nach außen öffnen nötig
|
||||
(Sicherheit!)
|
||||
|
||||
Wichtige Redis Konfiguration
|
||||
|
||||
Memory Management:
|
||||
|
||||
# Redis Config (über Command Parameter):
|
||||
|
||||
--maxmemory 512mb # Begrenze RAM Nutzung
|
||||
--maxmemory-policy allkeys-lru # Alte Keys
|
||||
löschen wenn voll
|
||||
|
||||
Persistence:
|
||||
|
||||
# Zwei Optionen kombinieren:
|
||||
|
||||
--appendonly yes # AOF für Durability
|
||||
--save 900 1 # RDB Snapshot alle 15
|
||||
Min
|
||||
|
||||
Security:
|
||||
|
||||
# Passwort setzen:
|
||||
|
||||
--requirepass dein-starkes-passwort
|
||||
|
||||
# Gefährliche Commands deaktivieren:
|
||||
|
||||
--rename-command FLUSHDB ""
|
||||
--rename-command FLUSHALL ""
|
||||
|
||||
Monitoring in Coolify
|
||||
|
||||
Redis Logs überwachen:
|
||||
|
||||
- Coolify zeigt Redis Logs in Echtzeit
|
||||
- Achte auf Memory Warnings
|
||||
- Connection Errors beobachten
|
||||
|
||||
Wichtige Redis Metriken:
|
||||
|
||||
# Commands zum Monitoring (über redis-cli):
|
||||
|
||||
INFO memory # RAM Nutzung
|
||||
INFO stats # Operations/sec
|
||||
INFO clients # Verbindungen
|
||||
MONITOR # Live Commands (nur
|
||||
zum Debugging!)
|
||||
|
||||
Backup Strategy
|
||||
|
||||
Automatische Redis Backups:
|
||||
|
||||
# Script in deinem Container:
|
||||
|
||||
#!/bin/bash
|
||||
|
||||
# redis-backup.sh
|
||||
|
||||
DATE=$(date +%Y%m%d_%H%M%S)
|
||||
redis-cli --rdb
|
||||
/backups/redis_backup_$DATE.rdb
|
||||
|
||||
# In Coolify als Cron Job alle 6 Stunden
|
||||
|
||||
Oder einfacher:
|
||||
|
||||
# Volume Mount für Persistence reicht:
|
||||
|
||||
volumes: - redis-data:/data # Redis saved
|
||||
automatisch hier
|
||||
|
||||
Separater Server - wann sinnvoll?
|
||||
|
||||
Bleib bei einem Server wenn:
|
||||
|
||||
- <10.000 Requests/Tag (definitiv dein
|
||||
Fall)
|
||||
- <1000 gleichzeitige User
|
||||
- Development/Early Stage (definitiv dein
|
||||
Fall)
|
||||
|
||||
Separater Redis Server nur bei:
|
||||
|
||||
- > 100.000 Requests/Tag
|
||||
- Multi-Region Setup
|
||||
- Dedicated Redis Cluster mit Failover
|
||||
|
||||
Für uLoad: Ein Server reicht völlig!
|
||||
|
||||
Coolify Deployment Steps
|
||||
|
||||
1. Docker Compose erweitern:
|
||||
|
||||
# Zu deiner bestehenden docker-compose.yml
|
||||
|
||||
hinzufügen:
|
||||
services: # ... deine bestehenden Services
|
||||
|
||||
redis:
|
||||
image: redis:7-alpine
|
||||
command: >
|
||||
redis-server
|
||||
--appendonly yes
|
||||
--maxmemory 512mb
|
||||
--maxmemory-policy allkeys-lru
|
||||
--requirepass ${REDIS_PASSWORD}
|
||||
volumes:
|
||||
- redis-data:/data
|
||||
restart: unless-stopped
|
||||
networks:
|
||||
- app-network
|
||||
healthcheck:
|
||||
test: ["CMD", "redis-cli", "-a",
|
||||
|
||||
"${REDIS_PASSWORD}", "ping"]
|
||||
interval: 30s
|
||||
timeout: 10s
|
||||
retries: 3
|
||||
|
||||
volumes:
|
||||
redis-data:
|
||||
|
||||
networks:
|
||||
app-network:
|
||||
driver: bridge
|
||||
|
||||
2. Environment Variables in Coolify:
|
||||
|
||||
# Für Redis:
|
||||
|
||||
REDIS_PASSWORD=SuperSecurePassword123!
|
||||
|
||||
# Für deine App:
|
||||
|
||||
REDIS_URL=redis://:SuperSecurePassword123!@
|
||||
redis:6379
|
||||
|
||||
3. Deploy & Test:
|
||||
|
||||
- Coolify deployed automatisch
|
||||
- Teste Connection aus deiner App
|
||||
- Check Redis Logs für Errors
|
||||
|
||||
Was beachten?
|
||||
|
||||
Security:
|
||||
|
||||
- Passwort setzen (Redis hat standardmäßig
|
||||
keins!)
|
||||
- Port nicht öffentlich machen (nur intern)
|
||||
- Command Renaming für gefährliche Commands
|
||||
|
||||
Performance:
|
||||
|
||||
- Memory Limit setzen (512MB reicht für
|
||||
Start)
|
||||
- LRU Policy aktivieren (alte Keys werden
|
||||
gelöscht)
|
||||
- Connection Pooling in deiner App
|
||||
|
||||
Monitoring:
|
||||
|
||||
- Redis Logs in Coolify beobachten
|
||||
- Memory Usage im Auge behalten
|
||||
- Hit Rate messen (wie oft Cache getroffen
|
||||
wird)
|
||||
|
||||
Troubleshooting
|
||||
|
||||
Häufige Probleme:
|
||||
|
||||
1. Connection refused: Redis Service nicht
|
||||
gestartet
|
||||
2. Auth failed: Passwort falsch oder nicht
|
||||
gesetzt
|
||||
3. Memory full: Maxmemory erreicht, LRU
|
||||
Policy prüfen
|
||||
|
||||
Debug Commands:
|
||||
|
||||
# In Coolify Terminal (Redis Container):
|
||||
|
||||
redis-cli -a dein-passwort info
|
||||
redis-cli -a dein-passwort ping
|
||||
redis-cli -a dein-passwort client list
|
||||
|
||||
Meine Empfehlung
|
||||
|
||||
Setup für uLoad:
|
||||
|
||||
1. Gleicher Server (Hetzner VPS) ✅
|
||||
2. Gleiches Coolify Projekt ✅
|
||||
3. 512MB Memory Limit ✅
|
||||
4. Passwort-geschützt ✅
|
||||
5. Persistence aktiviert ✅
|
||||
|
||||
Vorteile:
|
||||
|
||||
- Einfachste Lösung
|
||||
- Keine Extra-Kosten
|
||||
- Latenz minimal (gleicher Server)
|
||||
- Easy zu verwalten
|
||||
|
||||
Nachteile:
|
||||
|
||||
- Keine (für deine Use Case)
|
||||
|
||||
Redis auf deinem bestehenden Setup ist der
|
||||
perfekte nächste Schritt! 🚀
|
||||
Loading…
Add table
Add a link
Reference in a new issue