Add separate production, testserver, and demo deployments

README.md

@@ -384,27 +384,43 @@ verwenden. Beiträge im Namen eines Unternehmens müssen vorab abgestimmt werden
 
 Der `Dockerfile` kann Images für API und Web erzeugen. Unter `remote/production`
 liegen außerdem Beispielkonfigurationen für systemd. Die
-`production/*`-Ziele im `Makefile` sind auf die vorhandene Gardomatic-Infrastruktur
-zugeschnitten, enthalten einen fest konfigurierten Zielhost und führen Migrationen
-sowie Dienstneustarts aus. Sie sind keine allgemeine Deployment-Anleitung und
-sollten vor jeder Verwendung geprüft werden.
+Präfixe `production/*`, `testserver/*` und `demo/*` verwenden denselben
+Deployment-Ablauf, aber getrennte Zielhosts und Laufzeitkonfigurationen. Sie sind
+auf die vorhandene Gardomatic-Infrastruktur zugeschnitten, führen Migrationen
+sowie Dienstneustarts aus und sollten vor jeder Verwendung geprüft werden.
 
-Die lokale Produktionsverbindung wird in `config.mk` konfiguriert. Eine kommentierte
-Vorlage mit Zielhost, SSH-Admin, Port, optionalem privaten Schlüssel und
-Zielarchitektur steht in `config.mk.example`. Der SSH-Admin ist der vom Hoster oder
-bei der LXC-Erstellung bereitgestellte Benutzer (`root`, `ubuntu` oder ähnlich)
-und benötigt Root-Rechte oder passwortloses `sudo`. Private SSH-Schlüssel bleiben
-ausschließlich auf dem lokalen Rechner; auf dem Server muss vorab nur der
-zugehörige öffentliche Schlüssel für diesen Admin hinterlegt sein.
+Die drei SSH-Verbindungen werden gemeinsam in `config.mk` konfiguriert. Eine
+kommentierte Vorlage mit Zielhost, SSH-Admin, Port, optionalem privaten Schlüssel
+und Zielarchitektur steht in `config.mk.example`. Die Präfixe der Variablen sind
+`PRODUCTION_`, `TESTSERVER_` und `DEMO_`. Der SSH-Admin ist der vom Hoster oder bei
+der LXC-Erstellung bereitgestellte Benutzer (`root`, `ubuntu` oder ähnlich) und
+benötigt Root-Rechte oder passwortloses `sudo`.
 
 Das Server-Setup unter `remote/setup/provision-server.sh` liest seine Konfiguration
-aus `remote/setup/.env`. Als Ausgangspunkt dient `remote/setup/.env.example`; die
-echte Datei muss auf Modus `0600` gesetzt werden und bleibt von Git ausgeschlossen.
-`make production/provision` überträgt das Skript und streamt die Konfiguration über
-SSH, ohne die Quelldatei dauerhaft auf dem Server abzulegen. Das Provisioning legt
-den gesperrten Servicebenutzer `gardomatic` ohne Login, SSH-Schlüssel oder
-sudo-Rechte an und installiert die Laufzeitwerte als
-`/etc/gardomatic/gardomatic.env`.
+aus einer zum Ziel gehörenden Datei. Alle drei Dateien werden von `make config/init`
+mit Modus `0600` angelegt und bleiben von Git ausgeschlossen:
+
+| Make-Präfix | SSH-Einstellungen | Laufzeitkonfiguration |
+| --- | --- | --- |
+| `production/` | `PRODUCTION_*` in `config.mk` | `remote/setup/.env` |
+| `testserver/` | `TESTSERVER_*` in `config.mk` | `remote/setup/.env.testserver` |
+| `demo/` | `DEMO_*` in `config.mk` | `remote/setup/.env.demo` |
+
+Jede Laufzeitdatei benötigt eine eigene Datenbank-DSN, eigene Passwörter und die
+URL des jeweiligen Servers. Für Produktion wird `GARDOMATIC_ENV=production`
+verwendet. Der Testserver kann `GARDOMATIC_ENV=test` und dateibasierten
+Mailversand nutzen. Die öffentliche Demo läuft gehärtet mit
+`GARDOMATIC_ENV=production`, aber mit `GARDOMATIC_DEMO_RESET_ENABLED=true`,
+`GARDOMATIC_DEMO_ACCOUNT_EMAIL=demo@example.com` und
+`GARDOMATIC_SMTP_MODE=file`. Ein gemeinsames Runtime-Environment wird absichtlich
+nicht verwendet, damit ein Demo-Deployment keine Produktionsdatenbank erreichen
+kann.
+
+`*/provision` überträgt das Setup und streamt ausschließlich die zugehörige
+Konfiguration über SSH, ohne die Quelldatei dauerhaft auf dem Server abzulegen.
+Das Provisioning legt den gesperrten Servicebenutzer `gardomatic` ohne Login,
+SSH-Schlüssel oder sudo-Rechte an und installiert die Laufzeitwerte auf dem
+jeweiligen Server als `/etc/gardomatic/gardomatic.env`.
 
 Ein vollständiger Erstbetrieb besteht aus:
 
@@ -414,13 +430,21 @@ make config/init
 make production/provision
 make production/deploy
 make production/create-admin
+
+# Entsprechend für die anderen Instanzen:
+make testserver/provision
+make testserver/deploy
+make testserver/create-admin
+
+make demo/provision
+make demo/deploy
 ```
 
-`production/deploy` überträgt Binärdateien, Migrationen, systemd-Units und die
-Admin-Hilfe über denselben SSH-Admin, wendet Migrationen an und startet die Dienste.
-`production/create-admin` fragt interaktiv nach Name und E-Mail und erstellt den
-Benutzer aktiviert und mit der Rolle `application:admin`; das sichere generierte
-Passwort wird einmalig ausgegeben.
+Jedes Präfix bietet `connect`, `provision`, `deploy` und `create-admin`.
+`*/deploy` überträgt Binärdateien, Migrationen, systemd-Units und die Admin-Hilfe,
+wendet Migrationen an und startet die Dienste. `*/create-admin` erstellt
+interaktiv einen aktivierten Anwendungsadministrator und gibt das generierte
+Passwort einmalig aus.
 
 Für Produktion gelten mindestens folgende Anforderungen:
 
@@ -432,6 +456,59 @@ Für Produktion gelten mindestens folgende Anforderungen:
 - korrekte öffentliche Web-URL und vertrauenswürdige CORS-Origins
 - SMTP statt dateibasiertem Mailversand, sofern E-Mails zugestellt werden sollen
 
+### Öffentliche Demo-Instanz
+
+Für eine öffentliche Demo empfiehlt sich eine eigene Gardomatic-Installation mit
+eigener PostgreSQL-Datenbank und eigener Domain, nicht ein Demo-Garten in einer
+Produktivdatenbank. Die Anwendung sollte weiterhin mit
+`GARDOMATIC_ENV=production`, HTTPS und sicheren Cookies laufen. Ausschließlich auf
+dieser wegwerfbaren Instanz wird `GARDOMATIC_DEMO_RESET_ENABLED=true` gesetzt.
+`GARDOMATIC_DEMO_ACCOUNT_EMAIL=demo@example.com` schützt das gemeinsame Konto
+serverseitig: Profil, E-Mail-Adresse, Passwort, Passwort-Zurücksetzen und die
+globale Sitzungsverwaltung können von Besuchern nicht verändert werden. Die
+Garteninhalte bleiben vollständig bedienbar.
+
+Der Befehl `gardomatic-cli --yes demo reset --password-stdin` ersetzt alle
+Benutzer- und Gartendaten atomar durch einen zeitlich aktuellen Beispieldatensatz.
+Er erstellt den Garten `Sonnengarten` mit drei Mitgliedern, Einladung und eigener
+Gartenrolle, acht detaillierten Orten, zwölf Arten, Pflegehinweisen,
+Aufgabenvorlagen, sechzehn Pflanzen in unterschiedlichen Zuständen, fälligen,
+wiederkehrenden und erledigten Aufgaben, Tags, längeren Tagebuch- und
+Pinnwandeinträgen sowie einer bebilderten Medienbibliothek. Das gewünschte Login
+lautet standardmäßig
+`demo@example.com`; das Passwort wird nicht im Repository gespeichert.
+
+Die mitgelieferte systemd-Konfiguration setzt die Demo jede Nacht um 04:00 Uhr
+zurück. Für einen frisch aufgesetzten Demo-Server:
+
+1. In `remote/setup/.env.demo` `GARDOMATIC_DEMO_RESET_ENABLED='true'`,
+   `GARDOMATIC_DEMO_ACCOUNT_EMAIL='demo@example.com'` und
+   `GARDOMATIC_SMTP_MODE='file'` setzen.
+2. Den Server mit `make demo/provision` provisionieren.
+3. Auf dem Demo-Server das Passwort verdeckt einlesen und mit `Enter` bestätigen:
+
+   ```sh
+   make demo/connect
+   sudo install -d -m 0750 -o root -g gardomatic /etc/gardomatic
+   systemd-ask-password 'Demo-Passwort:' | \
+       sudo tee /etc/gardomatic/demo-password >/dev/null
+   sudo chown root:gardomatic /etc/gardomatic/demo-password
+   sudo chmod 0640 /etc/gardomatic/demo-password
+   exit
+   ```
+
+4. `make demo/deploy` ausführen. Das Deployment befüllt die Demo sofort
+   und aktiviert `gardomatic-demo-reset.timer`.
+
+Mit `systemctl list-timers gardomatic-demo-reset.timer` lässt sich der nächste
+Lauf prüfen; `journalctl -u gardomatic-demo-reset.service` zeigt die Reset-Läufe.
+Ein Reverse Proxy sollte zusätzlich Request-Größen begrenzen und die vorhandene
+Rate-Limitierung aktiviert lassen. Für die Demo sollte der Mailversand im
+`file`-Modus bleiben, damit Besucher keine E-Mails an Dritte auslösen können. Da
+Besucher Schreibrechte besitzen, dürfen
+auf diesem Host keine anderen schützenswerten Anwendungen oder Datenbanken mit
+denselben Zugangsdaten betrieben werden.
+
 ## Weiterführende Dokumentation
 
 - [`doc/planung.md`](doc/planung.md) – Produktbeschreibung, Leitplanken und Fahrplan