Update Dockerfile settings

README.md

@@ -6,33 +6,75 @@ beim Essensportal-Projekt. Postgres-Datenbank.
 
 ## Start
 
+Es gibt bewusst **keine `.env`-Datei** – alle Einstellungen (DB-Zugangsdaten,
+Port, `SECRET_KEY`, `MASCHINEN_PASSWORT`) stehen direkt in `docker-compose.yml`.
+Vor dem ersten Start dort alle `BITTE-AENDERN-...`-Platzhalter durch echte
+Werte ersetzen (Datenbank-Passwort bei `ens-db` und `ens-app` muss identisch
+sein), dann:
+
 ```bash
-cp .env.example .env
-# .env anpassen (Passwort etc.)
 docker compose up -d --build
 ```
 
-Die Anwendung ist danach unter `http://<server>:8090/` erreichbar (Port über
-`APP_PORT` in `.env` änderbar).
+Die Anwendung ist danach unter `http://<server>:8081/` erreichbar (Port
+direkt im `ports:`-Abschnitt von `docker-compose.yml` änderbar).
 
 **Wichtig zur DB-Initialisierung:** `build/db/init.sql` (= dein hochgeladenes Schema,
 ergänzt um ein paar Beispiel-Abweichungsgründe) wird **nur beim allerersten
 Start** ausgeführt, wenn das Datenvolume noch leer ist. Hast du bereits eine
 bestehende Postgres-Datenbank mit Daten, dann:
 
-- entweder das `db`-Volume vor dem ersten Start leer lassen und `init.sql`
-  anpassen/ersetzen, **oder**
-- den `db`-Service in `docker-compose.yml` entfernen und stattdessen über
-  `DB_HOST` / `DB_PORT` / `DB_NAME` / `DB_USER` / `DB_PASSWORD` in der `.env`
+- entweder das Datenverzeichnis vor dem ersten Start leer lassen und
+  `init.sql` anpassen/ersetzen, **oder**
+- den `ens-db`-Service in `docker-compose.yml` entfernen und stattdessen über
+  `DB_HOST` / `DB_PORT` / `DB_NAME` / `DB_USER` / `DB_PASSWORD` bei `ens-app`
   auf deine bestehende Datenbank zeigen.
 
+> **Achtung, bitte prüfen:** `ens-db` bindet aktuell als Volume das Verzeichnis
+> `/var/lib/docker/volumes/postgresql_ens_data` ein. Laut eurer eigenen
+> System-Doku ist genau das der Datenbankpfad des *bestehenden* Budibase-
+> Systems. Läuft Budibase parallel mit seiner eigenen Postgres-Instanz auf
+> demselben Host, würden zwei unabhängige Postgres-Prozesse gleichzeitig auf
+> dasselbe Datenverzeichnis schreiben – das kann das Datenverzeichnis
+> beschädigen. Bitte kurz gegenprüfen, ob das so beabsichtigt ist (z.B. weil
+> Budibase dort inzwischen abgelöst ist) oder ob hier versehentlich der
+> falsche Pfad übernommen wurde; im Zweifel einen eigenen, neuen Pfad/Volume
+> für `ens-db` verwenden.
+
+## Bauen und Verteilen als Container
+
+Bei jedem Push nach `main` bzw. auf einen `v*`-Tag baut die Gitea-Actions-
+Pipeline (`.gitea/workflows/build.yml`) automatisch ein Image und pusht es in
+die Gitea-Registry (getaggt als `:latest` und mit dem Commit-Hash).
+
+Für einen **anderen Server**, der nur das fertige Image ziehen und selbst
+nichts bauen soll, gibt es `docker-compose.deploy.yml`: sie referenziert das
+Image direkt aus der Registry (`image: git.thiede-brauer.de/bryan.hoffmann/wdm:latest`,
+kein `build:`). Auf diesem Server reicht allein diese eine Datei – der Rest
+des Repos wird dort nicht benötigt:
+
+```bash
+docker login git.thiede-brauer.de -u <benutzername>   # falls die Registry nicht öffentlich lesbar ist
+docker compose -f docker-compose.deploy.yml up -d
+```
+
+Update auf eine neue Version:
+
+```bash
+docker compose -f docker-compose.deploy.yml pull
+docker compose -f docker-compose.deploy.yml up -d
+```
+
+Auch hier gilt: keine `.env`, alle Werte direkt in `docker-compose.deploy.yml`
+eintragen (dieselben Werte wie beim Bauen, insbesondere das DB-Passwort).
+
 ## Aufruf der einzelnen Seiten
 
-- Maschine N (1–40): `http://<server>:8090/m<N>`
-  z.B. `http://<server>:8090/m1`
-- Produktionsleiter: `http://<server>:8090/start`
+- Maschine N (1–40): `http://<server>:8081/m<N>`
+  z.B. `http://<server>:8081/m1`
+- Produktionsleiter: `http://<server>:8081/start`
 
-**Alte/lange URL-Form:** `http://<server>:8090/m<N>_m_view_main` (z.B.
+**Alte/lange URL-Form:** `http://<server>:8081/m<N>_m_view_main` (z.B.
 `.../m1_m_view_main`) funktioniert unverändert weiter und zeigt auf
 dieselbe Seite. Sie bleibt bewusst zusätzlich zur kurzen Form erhalten,
 damit bereits auf Tablets als Kiosk-Startseite/Lesezeichen hinterlegte
@@ -122,9 +164,10 @@ location /app/wdm-performance/ {
 - **Maschinenverwaltung** (`/start_maschinen_verwaltung`, passwortgeschützt):
   Maschinen anlegen, umbenennen/Standort ändern, löschen (nur möglich wenn
   keine Aufträge mehr an der Maschine hängen). Passwort über die
-  Umgebungsvariable `MASCHINEN_PASSWORT` in der `.env` konfigurierbar
-  (Standard `admin` – bitte unbedingt ändern!). Für die Login-Session wird
-  zusätzlich ein `SECRET_KEY` benötigt (ebenfalls in der `.env` setzen).
+  Umgebungsvariable `MASCHINEN_PASSWORT` in `docker-compose.yml` konfigurierbar
+  (unbedingt vom Platzhalter auf einen echten Wert ändern!). Für die
+  Login-Session wird zusätzlich ein `SECRET_KEY` benötigt (ebenfalls dort
+  gesetzt).
 
 ### Aufträge importieren (`/start_import`)
 Excel- (.xlsx) oder CSV-Datei mit (mindestens) diesen Spalten hochladen
@@ -160,10 +203,12 @@ Prioritätsliste und (sofern gerade ein Auftrag aktiv ist) auch in der
 Maschinenübersicht ("Zu Maschine springen") mit angezeigt.
 
 ### Logo / Icon
-`build/static/logo.svg` wird als Favicon und (in doppelter Standardgröße,
-104×104px) über dem Seitentitel angezeigt. Einfach durch eine eigene Datei
-mit demselben Namen (`logo.svg`, idealerweise quadratisch) ersetzen, um das
-Firmenlogo einzubinden – kein Code muss dafür angepasst werden.
+`build/static/logo.svg` wird als Favicon und über dem Seitentitel angezeigt.
+Die Darstellung ist proportional (feste Höhe 130px, Breite skaliert automatisch
+im echten Seitenverhältnis mit) – funktioniert also auch mit einem breiten,
+nicht-quadratischen Logo. Einfach durch eine eigene Datei mit demselben Namen
+(`logo.svg`) ersetzen, um das Firmenlogo einzubinden – kein Code muss dafür
+angepasst werden.
 
 ### JavaScript-Einsatz (Ausnahmen vom "kein Client-JS"-Grundsatz)
 Zwei bewusste, punktuelle Ausnahmen von der sonst reinen Server-Side-
@@ -189,11 +234,12 @@ Rendering-Philosophie:
 ## Struktur
 
 ```
-wdm-performance/
+wdm/
 ├── Dockerfile              Build-Anweisungen (Kontext = Projektwurzel)
-├── docker-compose.yml
+├── docker-compose.yml          lokal bauen/testen (build: .)
+├── docker-compose.deploy.yml   nur Image ziehen (für andere Server)
+├── .gitea/workflows/build.yml  CI: baut Image und pusht in die Gitea-Registry
 ├── README.md
-├── .env.example
 └── build/
     ├── app.py               Flask-Anwendung (alle Routen, Server-Side-Rendering)
     ├── db.py                 DB-Pool mit Retry-Logik