Far girare il proprio Progress Watch

Il server è open source sotto licenza AGPL, e il servizio ospitato usa la stessa immagine che useresti tu. Ospitarlo per conto proprio costa un container e un Redis, e il database resta piccolo per sempre perché l'avanzamento non ci viene mai scritto.

Un solo file

docker-compose.yml è tutta l'installazione. Avvia l'immagine pubblicata, quindi non c'è niente da clonare e niente da compilare: copialo dalla la pagina Docker, che stampa il file corrente, sostituisci il segreto segnaposto con openssl rand -hex 64 e avvialo:

Questa è tutta la configurazione: l'app su http://localhost:7979, un Redis e un file SQLite su un volume con nome. Aprila, crea uno spazio, e il menu Connetti di quello spazio ti dà i comandi con l'UUID già inserito.

Configurarlo

Il file è tuo dal momento in cui lo salvi, ed è l'unico posto in cui si configura qualcosa: ogni impostazione è una riga in un blocco environment:, quindi aggiungerne una significa aggiungere una riga:

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

Variabili d'ambiente è l'elenco completo, e tutto ciò che vi compare funziona qui. Per pubblicare su una porta diversa dalla 7979, cambia la parte sinistra di 7979:3000: l'app dentro il container è sempre sulla 3000.

curl http://localhost:7979/up

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

Cosa sta girando

Due processi e un file. L'app risponde alle richieste ed esegue il worker al proprio interno — Sidekiq è incorporato in Puma, quindi a una notifica non può mancare un servizio dedicato. Redis tiene il progresso corrente di ogni attività e la coda dei job; SQLite tiene gli spazi e la forma di ogni attività.

Aggiornarlo

Indica il servizio. Un docker compose pull da solo scarica anche Redis, e se è stato pubblicato un redis:8-alpine più recente, up -d sostituisce anche quel container — buttando via il progresso di tutto ciò che sta girando.

docker compose pull progresswatch
docker compose up -d progresswatch

Sostituire solo il container dell'app lascia ogni attività in corso esattamente dov'era, perché il progresso sta in Redis e Redis non è stato toccato. Titoli e struttura sono sul volume e sopravvivono comunque. Nulla sopravvive a docker compose down o a un riavvio dell'host: Redis non tiene nulla su disco, di proposito.

Perché la 7979

Non la 3000. Questo è un servizio che lasci acceso per settimane mentre lavori, e la 3000 è dove atterrano i tuoi server di sviluppo: Rails, Vite, Next, Grafana e metà delle righe docker run delle altre guide. Un servizio in background non dovrebbe occupare la porta più contesa della macchina, tanto meno una il cui URL incolli in un segreto di CI e poi dimentichi.

Dentro il container è ancora la 3000; si è spostata solo la porta pubblicata, ed è la riga 7979:3000.

Perdere il volume è recuperabile

Ci sono sopra gli spazi e la struttura delle attività, e nient'altro. Se sparisce, crei un nuovo spazio e i tuoi processi ripopolano tutto alla richiesta successiva. Fanne un backup se preferisci non ridistribuire un nuovo UUID di spazio a tutto ciò che ci riporta dentro, ma non c'è niente sopra che non possa essere ricostruito rieseguendo i job.

SQLite o PostgreSQL

Entrambi, dalla stessa immagine e dalle stesse migrazioni, scelti con DATABASE_URL. SQLite è il predefinito ed è la risposta giusta per una sola macchina: due tabelle, letture per chiave primaria, quasi mai scritture. Punta a postgresql://… quando fai girare più container dell'app, perché non possono condividere un file.

Dietro un proxy

Imposta FORCE_SSL=true non appena qualcosa davanti all'app termina il TLS. È spento per impostazione predefinita perché un'installazione raggiunta via HTTP semplice non ti reindirizzi verso un certificato che non hai.

Notifiche

Imposta una coppia di chiavi VAPID e su ogni spazio compare un pulsante «Avvisami»; lascia le chiavi vuote e la funzione non esiste. Non c'è niente da registrare con Apple o Google. Vedi notifiche per la storia completa, compreso cosa deve accadere su un telefono.

Ripulire gli spazi vuoti

Aprire il sito crea uno spazio per te, quindi se ne creano parecchi che non vengono mai usati, compresi quelli di qualunque cosa faccia scansione della pagina. Uno spazio che ha mai contenuto un'attività viene conservato per sempre, per quanto a lungo nessuno lo guardi. Vengono ripuliti solo quelli che non hanno mai contenuto nemmeno un'attività, e solo quando hanno più di 30 giorni.

Niente lo esegue al posto tuo. Pianificalo come già pianifichi le cose:

# crontab, ogni giorno alle 04:17
17 4 * * * cd /path/to/progresswatch && docker compose exec -T progresswatch bin/rails sweep_empty_spaces

Poiché niente gira su un timer, 30 giorni sono un minimo e non un calendario: eseguilo ogni giorno e gli spazi vuoti se ne vanno il giorno in cui ne hanno i requisiti, eseguilo una volta l'anno e restano fino ad allora. Saltarlo è sicuro per i tuoi dati — la pulizia prende solo righe che non sono mai state usate — significa soltanto che la tabella cresce con spazi che nessuno ha mai aperto.

La tua istanza non è indicizzabile

Ogni pagina di un'installazione autogestita è noindex, robots.txt vieta tutto, e /sitemap.xml risponde 404. Dalla macchina di qualcuno non c'è pubblico da raggiungere e non c'è nulla lì dentro che voglia essere trovato in una ricerca, e non c'è niente da configurare perché sia così: è quello che ottieni.