Ein eigenes Progress Watch betreiben

Der Server ist quelloffen unter der AGPL, und der gehostete Dienst läuft mit demselben Image, das auch Sie nehmen würden. Selbst betreiben kostet einen Container und ein Redis, und die Datenbank bleibt für immer klein, weil Fortschritt nie in sie geschrieben wird.

Eine Datei

docker-compose.yml ist die ganze Installation. Sie startet das veröffentlichte Image, es gibt also nichts zu klonen und nichts zu bauen — kopieren Sie sie von der Docker-Seite, die die aktuelle Datei ausgibt, ersetzen Sie den Platzhalter für das Secret durch openssl rand -hex 64 und starten Sie:

Das ist die gesamte Einrichtung: die App auf http://localhost:7979, ein Redis und eine SQLite-Datei auf einem benannten Volume. Öffnen Sie sie, legen Sie einen Bereich an, und das Verbinden-Menü dieses Bereichs gibt Ihnen Befehle mit bereits eingesetzter UUID.

Konfigurieren

Die Datei gehört Ihnen ab dem Moment, in dem Sie sie speichern, und sie ist der einzige Ort, an dem irgendetwas konfiguriert wird — jede Einstellung ist eine Zeile in einem environment:-Block, eine hinzuzufügen heißt also, eine Zeile hinzuzufügen:

    environment:
      - SECRET_KEY_BASE=8f3c…
      - DATABASE_URL=postgresql://progresswatch:secret@db.internal/progresswatch
      - VAPID_PUBLIC_KEY=BJ1w…
      - VAPID_PRIVATE_KEY=xK2p…

Umgebungsvariablen ist die vollständige Liste, und alles darauf funktioniert hier. Um auf einem anderen Port als 7979 zu veröffentlichen, ändern Sie die linke Seite von 7979:3000 — die App im Container läuft immer auf 3000.

curl http://localhost:7979/up

{"status":"ok","database":true,"redis":true,"worker":true}

Was da läuft

Zwei Prozesse und eine Datei. Die App beantwortet Anfragen und führt den Worker in sich selbst aus — Sidekiq ist in Puma eingebettet, sodass einer Benachrichtigung kein eigener Dienst fehlen kann. Redis hält den aktuellen Fortschritt jeder Aufgabe und die Job-Queue; SQLite hält Spaces und die Form jeder Aufgabe.

Aktualisieren

Nennen Sie den Dienst. Ein blosses docker compose pull holt auch Redis, und wenn ein neueres redis:8-alpine veröffentlicht wurde, ersetzt up -d auch diesen Container — und wirft damit den Fortschritt von allem weg, was gerade läuft.

docker compose pull progresswatch
docker compose up -d progresswatch

Wird nur der App-Container ersetzt, bleibt jede laufende Aufgabe genau dort, wo sie war, denn der Fortschritt liegt in Redis, und Redis wurde nicht angefasst. Titel und Struktur liegen auf dem Volume und überleben ohnehin. Nichts überlebt docker compose down oder einen Neustart des Hosts: Redis hält bewusst nichts auf der Festplatte.

Warum 7979

Nicht 3000. Das ist ein Dienst, den Sie wochenlang laufen lassen, während Sie arbeiten, und 3000 ist der Ort, an dem Ihre eigenen Dev-Server landen — Rails, Vite, Next, Grafana und die Hälfte der docker run-Zeilen in anderen Anleitungen. Ein Hintergrunddienst sollte nicht den umkämpftesten Port der Maschine belegen, am allerwenigsten einer, dessen URL Sie in ein CI-Secret einsetzen und dann vergessen.

Im Container ist es weiterhin 3000; nur der veröffentlichte Port ist umgezogen, und das ist die Zeile 7979:3000.

Das Volume zu verlieren ist verkraftbar

Bereiche und Aufgabenstruktur liegen darauf, sonst nichts. Geht es verloren, legen Sie einen neuen Bereich an, und Ihre berichtenden Prozesse füllen bei der nächsten Anfrage alles wieder auf. Sichern Sie es, wenn Sie nicht eine neue Bereichs-UUID an alles verteilen möchten, was hineinberichtet — aber es liegt nichts darauf, was sich nicht durch erneutes Laufenlassen der Jobs wiederherstellen ließe.

SQLite oder PostgreSQL

Beides, aus demselben Image und denselben Migrationen, gewählt über DATABASE_URL. SQLite ist die Voreinstellung und die richtige Antwort für eine Maschine: zwei Tabellen, Zugriffe über den Primärschlüssel, fast nie geschrieben. Zeigen Sie auf postgresql://…, wenn Sie mehrere App-Container betreiben, denn die können sich keine Datei teilen.

Hinter einem Proxy

Setzen Sie FORCE_SSL=true, sobald etwas vor der App TLS terminiert. Es ist standardmäßig aus, damit eine über einfaches HTTP erreichte Installation Sie nicht auf ein Zertifikat umleitet, das Sie nicht haben.

Benachrichtigungen

Setzen Sie ein VAPID-Schlüsselpaar, und auf jedem Bereich erscheint ein „Benachrichtigen“-Knopf; lassen Sie die Schlüssel ungesetzt, und die Funktion existiert nicht. Es gibt nichts bei Apple oder Google zu registrieren. Siehe Benachrichtigungen für die ganze Geschichte, einschließlich dessen, was auf einem Telefon passieren muss.

Leere Bereiche aufräumen

Die Seite zu öffnen legt einen Bereich für Sie an, es entstehen also viele, die nie benutzt werden — auch durch alles, was die Seite crawlt. Ein Bereich, der jemals eine Aufgabe enthalten hat, bleibt für immer erhalten, so lange niemand hinsieht. Nur solche, die nie eine einzige Aufgabe enthielten, werden aufgeräumt, und erst wenn sie älter als 30 Tage sind.

Nichts führt das für Sie aus. Planen Sie es so ein, wie Sie ohnehin Dinge einplanen:

# crontab, täglich um 04:17
17 4 * * * cd /path/to/progresswatch && docker compose exec -T progresswatch bin/rails sweep_empty_spaces

Weil nichts auf einem Timer läuft, sind 30 Tage eine Untergrenze und kein Zeitplan: Führen Sie es täglich aus, verschwinden leere Bereiche an dem Tag, an dem sie infrage kommen; einmal im Jahr, dann bleiben sie bis dahin. Es auszulassen ist für Ihre Daten ungefährlich — der Sweep nimmt nur Zeilen, die nie benutzt wurden — es bedeutet lediglich, dass die Tabelle mit Bereichen wächst, die nie jemand geöffnet hat.

Ihre Instanz ist nicht indexierbar

Jede Seite einer selbst betriebenen Installation ist noindex, robots.txt verbietet alles, und /sitemap.xml antwortet mit 404. Von der eigenen Maschine aus gibt es kein Publikum zu erreichen und nichts dort, was in einer Suche gefunden werden möchte, und dafür muss nichts konfiguriert werden — so bekommen Sie es.