Progress Watch über Umgebungsvariablen konfigurieren

Alles ist eine Umgebungsvariable. Es gibt keine Konfigurationsdateien zu bearbeiten und keine verschlüsselten Zugangsdaten im Image, derselbe Container läuft also auf einem NAS zu Hause und in der Cloud.

Allgemein

Variable	Voreinstellung	Wofür sie da ist
`SECRET_KEY_BASE`	`/data/progresswatch/progresswatch.env`	Wird beim ersten Start erzeugt und auf dem Volume aufbewahrt, lassen Sie sie also ungesetzt. Setzen Sie sie selbst, wo es kein Volume gibt oder mehrere Container sie teilen müssen.
`DATABASE_URL`	`sqlite3:/data/progresswatch/db.sqlite3`	Wo Bereiche und Aufgabenstruktur liegen. Die voreingestellte Datei ist das, was das Docker-Volume hält; zeigen Sie für eine Cloud-Installation auf `postgresql://…`. Der Fortschritt selbst wird hier nie geschrieben.
`FORCE_SSL`	`false`	Auf `true` setzen, wenn etwas davor TLS terminiert. Es steuert auch `assume_ssl`, es auszulassen hält die App also über einfaches HTTP benutzbar, statt auf ein Zertifikat umzuleiten, das Sie nicht haben.
`PORT`	`3000`	Der Port, an den Puma im Container bindet. `docker-compose.yml` veröffentlicht ihn auf 7979, weil ein Dienst, den Sie wochenlang laufen lassen, nicht den Port belegen sollte, den Ihre eigenen Dev-Server wollen.
`RAILS_LOG_LEVEL`	`info`	Logs gehen nach stdout und sonst nirgendwohin. Das hier ist, wie viel davon.
`RATE_LIMIT_PER_HOUR`	—	Wie viele Bereiche und Aufgaben eine Adresse pro Stunde anlegen darf. Ungesetzt heißt kein Limit, was die richtige Antwort für einen Server ist, den nur Sie erreichen. Fortschritt zu berichten wird nie begrenzt.

Hinter einem Proxy ist RATE_LIMIT_PER_HOUR nur so gut wie die Adresse, die die App sieht. Rails liest X-Forwarded-For und vertraut dem Header aus privaten Bereichen, was ein Reverse Proxy auf demselben Host sendet — kommt der Header aber nicht an, sieht jede Anfrage wie ein einziger Client aus, und das Limit sperrt alle auf einmal aus statt niemanden.

Redis

Redis hält zwei voneinander unabhängige Dinge: den aktuellen Fortschritt jeder Aufgabe und die Sidekiq-Warteschlange. Das sind standardmäßig zwei logische Datenbanken eines Servers, und beide lassen sich auf eine eigene Instanz verschieben.

Variable	Voreinstellung	Wofür sie da ist
`REDIS_URL`	—	Der Server für beide Rollen, aufgeteilt in db 0 für Fortschritt und db 1 für die Warteschlange. Ungesetzt startet das Image ein eigenes Redis im Container und schreibt Snapshots davon auf das Volume.
`PROGRESS_REDIS_URL`	`REDIS_URL`, db 0	Überschreibt allein den Fortschrittsspeicher.
`SIDEKIQ_REDIS_URL`	`REDIS_URL`, db 1	Überschreibt allein die Warteschlange.
`PROGRESS_TTL_SECONDS`	`86400`	Wie lange eine Aufgabe ihren Fortschritt behält, ohne beschrieben zu werden. Jeder Bericht frischt das auf, das hier ist also eigentlich, wie lange eine aufgegebene Aufgabe auf dem Schirm bleibt.
`PROGRESS_KEY_PREFIX`	`pw:progress`	Schlüsselpräfix für den Fortschrittsspeicher, damit er sich eine Datenbank mit etwas anderem teilen kann.

Grenzen

Text über einer Grenze wird darauf gekürzt, das letzte Zeichen ist dann eine Ellipse. Ein values-Objekt mit mehr Schlüsseln oder einem längeren Schlüssel wird stattdessen mit 400 abgelehnt. Diese Vorgaben gelten für einen eigenen Server; progress.watch hält jede davon niedriger.

Variable	Voreinstellung	Wofür sie da ist
`MAX_TASK_TITLE_LENGTH`	`500`	Längster gespeicherter Aufgabentitel, in Zeichen
`MAX_TASK_SOURCE_LENGTH`	`200`	Längste gespeicherte Quelle einer Aufgabe
`MAX_SPACE_TITLE_LENGTH`	`200`	Längster gespeicherter Bereichsname
`MAX_VALUES_KEY_COUNT`	`50`	Meiste Schlüssel in den values eines Berichts
`MAX_VALUES_KEY_LENGTH`	`100`	Längster Schlüssel in values
`MAX_VALUES_STRING_LENGTH`	`10000`	Längster String in values, eine log-Zeile eingeschlossen

Benachrichtigungen

Beide Schlüssel ungesetzt heißt, die Funktion existiert nicht: kein Knopf auf einem Bereich, und nichts über irgendwen gespeichert. Es gibt nichts bei Apple oder Google zu registrieren — wer den Browser gebaut hat, betreibt den Push-Dienst. Erzeugen Sie einmal ein Paar und rotieren Sie es nicht; bestehende Anmeldungen sind daran gebunden, und Browser werden nicht informiert.

Variable	Voreinstellung	Wofür sie da ist
`VAPID_PUBLIC_KEY`	—	Die öffentliche Hälfte des Paars, das jeden Push signiert. Wird dem Browser bei der Anmeldung übergeben.
`VAPID_PRIVATE_KEY`	—	Die private Hälfte. Verlässt den Server nie.
`VAPID_SUBJECT`	`https://github.com/progress-watch/progresswatch`	Eine Kontaktadresse, unter der die Push-Dienste Sie erreichen können, wenn etwas schiefgeht. Niemand prüft sie.
`PUSH_CONTENT`	`full`	`full` setzt den Aufgabentitel in die Benachrichtigung, `minimal` sendet „Task completed“ und nichts Identifizierendes.
`PUSH_RELAY`	`https://progress.watch`	Wohin eine Benachrichtigung für die iOS-App geschickt wird, um signiert und an Apple übergeben zu werden: Nur der Herausgeber der App besitzt den Schlüssel, den Apple verlangt, ein selbst gehosteter Server kann sie also nicht selbst zustellen. Das Relay sieht das Gerät und den Text der Benachrichtigung, nie eine Bereichs-UUID, und es wird nichts gesendet, bevor jemand in der App Benachrichtigungen einschaltet. `PUSH_CONTENT=minimal` hält Aufgabentitel heraus. `false` schaltet es ab, und die App bietet auf diesem Server dann keine Benachrichtigungen an.

Prozessgrößen

Variable	Voreinstellung	Wofür sie da ist
`RAILS_MAX_THREADS`	`5`	Puma-Threads pro Prozess, und die Größe sowohl des Datenbank- als auch des Redis-Verbindungspools.
`WEB_CONCURRENCY`	`0`	Puma-Worker-Prozesse. Null lässt einen einzelnen Prozess laufen, was auf einer kleinen Maschine die richtige Antwort ist.
`SIDEKIQ_CONCURRENCY`	`5`	Threads im Sidekiq-Prozess. Benachrichtigungen zu senden ist der einzige Job, den es gibt.