188 lines
7.4 KiB
Markdown
188 lines
7.4 KiB
Markdown
# Umgebungsvariablen Setup - Zusammenfassung
|
||
|
||
## Was wurde implementiert
|
||
|
||
Das Meldestelle-Projekt verfügt über eine vollständig zentralisierte Umgebungsvariablen-Konfiguration im `config/` Verzeichnis.
|
||
|
||
### 1. Zentrale Konfigurationsstruktur
|
||
|
||
- **`config/.env.template`** - Master-Vorlage mit allen verfügbaren Umgebungsvariablen
|
||
- **`config/.env.dev`** - Entwicklungsumgebung-Konfiguration
|
||
- **`config/.env.prod`** - Produktionsumgebung-Konfiguration
|
||
- **`config/.env.staging`** - Staging-Umgebung-Konfiguration
|
||
- **`config/.env.test`** - Testumgebung-Konfiguration
|
||
- **`config/README.md`** - Umfassende Dokumentation der Konfigurationsverwaltung
|
||
|
||
### 2. Aktualisierte Dateien
|
||
|
||
- **`docker-compose.yml`** - Alle Services verwenden Umgebungsvariablen mit Fallback-Werten
|
||
- **Symlink `.env`** - Verweist auf die aktuelle Umgebungskonfiguration
|
||
|
||
### 3. Konfigurierte Services
|
||
|
||
Die folgenden Services sind vollständig konfiguriert:
|
||
|
||
- **PostgreSQL** - Datenbank mit konfigurierbaren Zugangsdaten
|
||
- **Redis** - Event Store und Cache mit separaten Konfigurationen
|
||
- **Keycloak** - Authentifizierung mit konfigurierbaren Admin-Zugangsdaten
|
||
- **Kafka/Zookeeper** - Messaging-System mit konfigurierbaren Parametern
|
||
- **Grafana** - Monitoring mit konfigurierbaren Admin-Zugangsdaten
|
||
- **Prometheus** - Metriken-Sammlung
|
||
- **Zipkin** - Distributed Tracing
|
||
|
||
### 4. Umgebungsvariablen-Kategorien
|
||
|
||
- **Anwendungskonfiguration** (API_HOST, API_PORT, etc.)
|
||
- **Datenbank-Konfiguration** (DB_HOST, DB_PORT, DB_USER, etc.)
|
||
- **Redis-Konfiguration** (Event Store und Cache)
|
||
- **Sicherheitskonfiguration** (JWT_SECRET, API_KEY, etc.)
|
||
- **Keycloak-Konfiguration** (Admin-Zugangsdaten, DB-Verbindung)
|
||
- **Service Discovery** (Consul-Konfiguration)
|
||
- **Messaging** (Kafka/Zookeeper-Konfiguration)
|
||
- **Monitoring** (Grafana, Prometheus-Konfiguration)
|
||
- **Logging-Konfiguration** (Log-Level, Request/Response-Logging)
|
||
- **CORS und Rate Limiting**
|
||
|
||
## Verwendung
|
||
|
||
### Schnellstart
|
||
|
||
1. **Umgebung wählen:**
|
||
```bash
|
||
# Für Entwicklung
|
||
ln -sf config/.env.dev .env
|
||
|
||
# Für Produktion
|
||
ln -sf config/.env.prod .env
|
||
|
||
# Für Tests
|
||
ln -sf config/.env.test .env
|
||
```
|
||
|
||
2. **Services starten:**
|
||
```bash
|
||
docker compose up -d
|
||
```
|
||
|
||
3. **Services überprüfen:**
|
||
```bash
|
||
docker compose ps
|
||
```
|
||
|
||
### Anpassungen
|
||
|
||
- Kopieren und bearbeiten Sie die gewünschte `.env.*` Datei aus dem `config/` Verzeichnis
|
||
- Verwenden Sie verschiedene Ports für mehrere Entwickler (siehe `.env.test` für Beispiel)
|
||
- Ändern Sie alle `CHANGE_ME` Werte in Produktionsumgebungen
|
||
|
||
### Dokumentation
|
||
|
||
Vollständige Dokumentation finden Sie in:
|
||
- `config/README.md` - Zentrale Konfigurationsdokumentation
|
||
|
||
## Sicherheitshinweise
|
||
|
||
⚠️ **Wichtig:**
|
||
- Niemals Produktionsgeheimnisse in die Versionskontrolle einbinden
|
||
- JWT_SECRET in der Produktion ändern
|
||
- Starke Passwörter für Produktionsumgebungen verwenden
|
||
- API-Schlüssel regelmäßig rotieren
|
||
|
||
## Fehlerbehebung
|
||
|
||
Bei Problemen:
|
||
1. Überprüfen Sie die aktive Umgebungskonfiguration: `ls -la .env`
|
||
2. Validieren Sie die Docker-Compose-Konfiguration: `docker compose config`
|
||
3. Überprüfen Sie die Service-Logs: `docker compose logs -f`
|
||
4. Konsultieren Sie `config/README.md` für detaillierte Konfigurationsrichtlinien
|
||
|
||
### Keycloak startet neu (Restart-Loop) oder beendet sich mit Code 1
|
||
Das Problem tritt häufig auf, wenn das Keycloak-DB-Schema fehlt oder nicht zur aktuell gesetzten `KC_DB_SCHEMA` passt.
|
||
|
||
So gehen Sie vor:
|
||
|
||
- Logs erfassen (bitte im Fehlerfall mitschicken):
|
||
- Keycloak: `docker compose logs -f keycloak`
|
||
- Postgres: `docker compose logs -f postgres`
|
||
|
||
- Schema-Status prüfen und ggf. manuell anlegen (nur wenn das Volume bereits existierte, als die Init-Skripte eingeführt wurden):
|
||
1. In die Datenbank einloggen:
|
||
```bash
|
||
docker exec -it meldestelle-postgres psql -U "$POSTGRES_USER" -d "$POSTGRES_DB"
|
||
```
|
||
2. Folgende Befehle ausführen (ersetzen Sie den Benutzer bei Bedarf):
|
||
```sql
|
||
CREATE SCHEMA IF NOT EXISTS keycloak;
|
||
GRANT ALL PRIVILEGES ON SCHEMA keycloak TO "$POSTGRES_USER";
|
||
GRANT USAGE ON SCHEMA keycloak TO "$POSTGRES_USER";
|
||
ALTER DEFAULT PRIVILEGES IN SCHEMA keycloak GRANT ALL ON TABLES TO "$POSTGRES_USER";
|
||
ALTER DEFAULT PRIVILEGES IN SCHEMA keycloak GRANT ALL ON SEQUENCES TO "$POSTGRES_USER";
|
||
```
|
||
|
||
- Alternativ: Volumes zurücksetzen (Achtung: Datenverlust in Postgres und Keycloak-Volume!)
|
||
```bash
|
||
docker compose down -v
|
||
docker compose up -d postgres keycloak
|
||
```
|
||
Hinweis: Bei frischen Volumes legt Postgres via `docker/services/postgres/01-init-keycloak-schema.sql` das Schema automatisch an. Die Datei `02-init-keycloak-schema.sql` ist absichtlich ein No-Op, um Doppel-Initialisierungen zu vermeiden.
|
||
|
||
- Konfiguration prüfen:
|
||
- `KC_DB_SCHEMA` ist in `docker-compose.yml` parametrisiert und standardmäßig auf `keycloak` gesetzt. Sie können es in Ihrer `.env`-Datei überschreiben.
|
||
- In Staging/Prod muss `KC_DB_URL`, `KC_DB_USERNAME`, `KC_DB_PASSWORD` auf die jeweilige DB/Benutzer zeigen (siehe `config/.env.staging`, `config/.env.prod`).
|
||
|
||
### Postgres Healthcheck schlägt fehl
|
||
Der Healthcheck ist jetzt vollständig über Umgebungsvariablen parametrisiert und passt sich Dev/Staging/Prod automatisch an:
|
||
```yaml
|
||
healthcheck:
|
||
test: [ "CMD-SHELL", "pg_isready -U ${POSTGRES_USER:-meldestelle} -d ${POSTGRES_DB:-meldestelle}" ]
|
||
```
|
||
Stellen Sie sicher, dass `POSTGRES_USER` und `POSTGRES_DB` korrekt gesetzt sind.
|
||
|
||
### Compose-Warnung "The BUILD_DATE variable is not set"
|
||
Die Warnung ist in `docker-compose.yml` behoben. Für Build-Argumente wird nun ein Fallback verwendet:
|
||
```yaml
|
||
BUILD_DATE: ${BUILD_DATE:-unknown}
|
||
```
|
||
Wenn Sie ein Datum setzen möchten, fügen Sie `BUILD_DATE=2025-10-05T16:55:00Z` Ihrer `.env` hinzu.
|
||
|
||
### Logging/Health Optimierungen (optional)
|
||
- Aktuell ist `KC_LOG_CONSOLE_FORMAT` auf `plain` gesetzt, um Standard-Logs auszugeben. Für strukturierte Logs können Sie `KC_LOG_CONSOLE_FORMAT=json` setzen.
|
||
- `KC_HEALTH_ENABLED=true` und ein großzügiges `start_period` (180s) sind aktiv, um Realm-Importe abwarten zu können.
|
||
|
||
## Nächste Schritte
|
||
|
||
- Die zentrale Konfiguration ist bereits vollständig implementiert
|
||
- Wählen Sie die gewünschte Umgebung mit den Symlink-Befehlen oben
|
||
- Passen Sie Konfigurationswerte in den `config/.env.*` Dateien nach Bedarf an
|
||
- Für neue Umgebungen verwenden Sie `config/.env.template` als Ausgangspunkt
|
||
|
||
|
||
---
|
||
|
||
## Smoke-Tests (Prometheus & Zipkin)
|
||
|
||
Nach dem Start der Infrastruktur können einfache Smoke-Tests ausgeführt werden:
|
||
|
||
```bash
|
||
# Zipkin: erzeugt einen Ping über das Gateway und prüft, ob Traces ankommen
|
||
bash scripts/smoke/zipkin_smoke.sh
|
||
|
||
# Prometheus: prüft, ob Gateway und Ping-Service Metriken exponieren
|
||
bash scripts/smoke/prometheus_smoke.sh
|
||
```
|
||
|
||
Variablen:
|
||
- GATEWAY_URL (Default: http://localhost:8081)
|
||
- ZIPKIN_URL (Default: http://localhost:9411)
|
||
- PING_SERVICE_URL (Default: http://localhost:8082)
|
||
|
||
|
||
## Keycloak Healthcheck
|
||
|
||
- Der Keycloak-Container verwendet nun einen robusten Healthcheck, der nicht von curl abhängt.
|
||
- Ablauf: Zuerst wird curl verwendet, falls vorhanden; alternativ wget; fehlt beides, wird ein Bash-/dev/tcp-Fallback genutzt. In diesem Fall wird eine klare Fehlermeldung in den Healthcheck-Logs ausgegeben.
|
||
- Zeitparameter: interval 15s, timeout 30s, retries 10, start_period 180s – ausreichend, um längere Realm-Imports (30+ Sekunden) abzuwarten.
|
||
- Beispiel (vereinfacht):
|
||
- test: CMD-SHELL
|
||
- if curl vorhanden → GET /health/ready prüfen; sonst wget; sonst Bash /dev/tcp mit HTTP-Status „200 OK“ prüfen.
|