monatsplan - ckalender read fixed, developerpanel - rss feed implemented

This commit is contained in:
2026-08-29 21:22:09 +02:00
parent 79d857d686
commit b6c8831373
6 changed files with 804 additions and 503 deletions
+40 -46
View File
@@ -263,27 +263,21 @@ Dockerfile
docker-compose.yml
docker-compose.local.yml
web/
worker/
docker/
```
Die produktive `docker-compose.yml` wird lokal **nicht** verwendet. Dadurch werden insbesondere folgende Produktionsbestandteile nicht gestartet:
* `scheduler`
* `dokploy-network`
* Strato-SSH
* produktive Scheduler-Secrets
Die lokale Compose-Datei startet ausschließlich:
Die `docker-compose.local.yml` bildet die Anwendungsdienste der produktiven `docker-compose.yml` lokal ab und ergänzt die Datenbank. Lokal werden damit gestartet:
* `web`
* `scheduler`
* `db` (PostgreSQL 18 mit pgvector)
Sie verwendet denselben `Dockerfile` wie Produktion.
Das externe `dokploy-network` wird lokal nicht benötigt. Alle drei Container verwenden stattdessen das lokale Compose-Netzwerk `app`. `web` und `scheduler` greifen über `DB_HOST=db` direkt auf den lokalen PostgreSQL-Container zu.
Der Web-Container ist lokal unter `127.0.0.1:8080` erreichbar. PostgreSQL wird für pgAdmin unter `127.0.0.1:5432` freigegeben.
Der Web-Container ist unter `127.0.0.1:8080` erreichbar. PostgreSQL wird für pgAdmin unter `127.0.0.1:5432` freigegeben.
Für die Datenbank wird das Image `pgvector/pgvector:pg18` verwendet, weil der Produktiv-Dump die PostgreSQL-Erweiterung `vector` benötigt.
PostgreSQL 18 verwendet für persistente Daten den Mount-Punkt:
Für die Datenbank wird das Image `pgvector/pgvector:pg18` verwendet, weil der Produktiv-Dump die PostgreSQL-Erweiterung `vector` benötigt. PostgreSQL 18 verwendet für persistente Daten den Mount-Punkt:
```text
/var/lib/postgresql
@@ -301,17 +295,18 @@ Durch den Bind-Mount
./web → /var/www/html
```
werden Änderungen an PHP, CSS und JavaScript ohne erneuten Image-Build sichtbar. Laufzeitdaten wie Profilbilder und Aushänge liegen weiterhin in lokalen Docker-Volumes.
werden Änderungen an PHP, CSS und JavaScript ohne erneuten Image-Build sichtbar. Laufzeitdaten wie Profilbilder, Aushänge, Scheduler-Zustand und generierte Kalenderdateien liegen weiterhin in lokalen Docker-Volumes.
---
## 4. Environment-Variablen anlegen
Im Projektroot eine `.env` anlegen:
Im Projektroot eine `.env` anlegen. Werte, die lokal nicht benötigt oder noch nicht bekannt sind, bleiben leer.
```dotenv
# PostgreSQL
POSTGRES_VERSION=18
DB_HOST=
DB_PORT=5432
DB_NAME=intranet
DB_USER=intranet
DB_PASSWORD=local-dev-password
@@ -319,24 +314,39 @@ DB_PASSWORD=local-dev-password
# Intranet
INTRANET_FQDN=localhost:8080
# Lokale Dummy-Werte für externe Dienste
SMTP_HOST=127.0.0.1
SMTP_PORT=1025
SMTP_USER=local
SMTP_PASSWORD=local
ADMIN_EMAIL=local@example.invalid
# SMTP / Benachrichtigungen
SMTP_HOST=
SMTP_PORT=
SMTP_USER=
SMTP_PASSWORD=
ADMIN_EMAIL=
SMS_GATEWAY_URL=
SMS_GATEWAY_URL=http://127.0.0.1:9
HA_BASE_URL=http://127.0.0.1:9
HA_TOKEN=local
OPENWEATHER_API_KEY=local
# Dashboard / externe APIs
HA_BASE_URL=
HA_TOKEN=
OPENWEATHER_API_KEY=
# CKalender / Scheduler
CKAL_USERNAME=
CKAL_PASSWORD=
CKAL_CALENDAR_URL=
CALENDAR_INTERVAL_SECONDS=60
# Strato-Synchronisation
STRATO_SYNC_ENABLED=false
STRATO_SSH_HOST=
STRATO_SSH_PORT=
STRATO_SSH_USER=
STRATO_REMOTE_PATH=
STRATO_SSH_PRIVATE_KEY=
STRATO_KNOWN_HOSTS=
# Brandschutz
BRANDSCHUTZ_MAIL_ENABLED=false
```
Die `.env` darf keine produktiven Secrets enthalten und sollte nicht ins Repository committed werden.
Funktionen, die einen externen Dienst benötigen, funktionieren erst, wenn die zugehörigen Werte gesetzt sind.
> Lokal sollte möglichst dieselbe PostgreSQL-Major-Version wie in Produktion verwendet werden. Wir verwenden **PostgreSQL 18**.
@@ -379,12 +389,6 @@ docker compose -f docker-compose.local.yml ps
Der Datenbank-Container sollte nach einigen Sekunden den Status `healthy` anzeigen.
Optional kann geprüft werden, ob pgvector verfügbar ist:
```bash
docker exec -it intranet-local-db-1 psql -U intranet -d intranet -c "CREATE EXTENSION IF NOT EXISTS vector;"
```
---
## 7. Dump mit pgAdmin importieren
@@ -399,8 +403,6 @@ Falls pgAdmin 4 noch nicht installiert ist, kann es lokal als Desktop-Anwendung
Die Installationspakete und Anleitungen sind unter https://www.pgadmin.org/download/ verfügbar.
Unter Windows mit WSL 2 kann pgAdmin direkt unter Windows installiert werden. Die PostgreSQL-Datenbank aus Docker ist anschließend über `localhost:5432` erreichbar.
In pgAdmin einen neuen Server registrieren:
```text
@@ -427,14 +429,8 @@ Danach:
7. **Clean before restore: No** beim ersten Import.
8. **Restore** starten.
Soll die lokale Datenbank später vollständig durch einen neuen Dump ersetzt werden, kann das lokale Setup zurückgesetzt werden:
```bash
docker compose -f docker-compose.local.yml down -v
docker compose -f docker-compose.local.yml up -d db
```
Danach den Dump erneut importieren.
> **Hinweis:** Soll die lokale Datenbank später vollständig durch einen neuen Dump ersetzt werden, kann das lokale Setup zurückgesetzt werden: `docker compose -f docker-compose.local.yml down -v`,
`docker compose -f docker-compose.local.yml up -d db`. Danach den Dump erneut importieren.
> **Achtung:** `down -v` löscht nicht nur PostgreSQL, sondern auch alle übrigen lokalen Intranet-Volumes, z. B. Profilbilder, Aushänge und andere Laufzeitdaten. Nur verwenden, wenn diese Daten bewusst verworfen werden sollen.
@@ -504,9 +500,7 @@ docker compose -f docker-compose.local.yml logs -f db
### Änderungen an PHP, CSS und JavaScript
Änderungen unter `web/` werden durch den Bind-Mount direkt in den laufenden Container übernommen. Ein Rebuild ist normalerweise nicht notwendig.
Nach dem Speichern reicht in der Regel ein Reload im Browser.
Änderungen unter `web/` werden durch den Bind-Mount direkt in den laufenden Container übernommen. Ein Rebuild ist normalerweise nicht notwendig. Nach dem Speichern reicht in der Regel ein Reload im Browser.
### Änderungen am Dockerfile