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 volume, 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, e avvialo:

Questa è tutta la configurazione: l'app su http://localhost:7979, con Redis e SQLite nello stesso container e tutto ciò che conservano sul 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: sotto il servizio, che il file omette finché non te ne serve uno:

environment:
- 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, tutto in un container. L'app risponde alle richieste ed esegue il worker al proprio interno, perché Sidekiq è incorporato in Puma, e avvia Redis accanto a sé e lo ferma all'uscita. Redis tiene il progresso corrente di ogni attività e la coda dei job, e ne salva snapshot sul volume; SQLite tiene gli spazi e la forma di ogni attività. Imposta REDIS_URL e l'app usa quel Redis al suo posto senza avviarne uno proprio.

Aggiornarlo

Scarica la nuova immagine e riavvialo:

docker compose pull
docker compose up -d

Ogni attività in corso resta dov'era. Fermare il container fa scrivere a Redis uno snapshot sul volume, e il nuovo container lo ricarica all'avvio. Solo un crash o un'interruzione di corrente salta quella scrittura, e allora torna l'ultimo snapshot periodico, vecchio di minuti se i report sono frequenti e fino a un'ora se non lo sono: un'attività mostra «In attesa di dati…» o un numero più vecchio fino al report successivo.

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, la struttura delle attività, uno snapshot di Redis e la chiave segreta. Se sparisce, crei un nuovo spazio e i tuoi processi ripopolano tutto alla richiesta successiva, e una nuova chiave segreta non costa nulla, perché non ci sono account da cui disconnettere nessuno. 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.