Uso disco

Capacita

Consumo per area

Immagini Docker staging

Repo piu' grandi

Backup

Un backup giornaliero completo pesa ~3.7 GiB. La retention locale mantiene 1 snapshot completo; la cronologia vive su DigitalOcean Spaces Cold Storage.

Componenti di un backup:

Raccomandazioni

1. Pulire history git di tulpa-studio per ridurre .git da 969 MB se il repo restera' sul droplet.
2. Ridurre asset pesanti app-specific solo dopo verifica funzionale della singola app.
3. Mantenere retention locale a 1 snapshot e verificare ogni giorno manifest offsite.
4. Non usare docker system prune --volumes su questa VPS senza piano di rollback.
5. Monitorare uso disco con alert sotto 20 GB liberi.
6. Gestire build cache Docker con policy, non a impulso: dopo rebuild completi la cache accelera i deploy successivi ma puo' occupare decine di GB.

Stato dopo deploy centralizzato 2026-06-24

Dopo obelica deploy all su tutti i 14 target:

Images:      9.699 GB, 2.614 GB reclaimable
Containers:  111.8 MB
Build cache: 29.4 GB, 28.42 GB reclaimable
Disco root:  51 GB usati / 26 GB liberi / 67%

Interpretazione:

• i container live sono sani e usano immagini correnti;
• l'aumento disco e' quasi tutto build cache Docker prodotta dal rebuild massivo;
• non e' un problema immediato, ma deve essere governato prima della migrazione produzione completa;
• pulire tutta la cache rende i prossimi deploy piu' lenti, ma libera molto spazio.

Policy consigliata:

• dopo deploy normali: lasciare cache se il disco resta sotto ~70%;
• se il disco supera 75% o scende sotto 20 GB liberi: eseguire prune controllato della build cache;
• non toccare volumi;
• verificare sempre docker ps, obelica health e smoke test dopo la pulizia.

Comando conservativo:

docker builder prune -f --filter until=24h
docker image prune -f

Comando aggressivo, solo dopo conferma container/smoke:

docker builder prune -af
docker image prune -f

Pulizia Docker controllata

Eseguita il 2026-06-22 dopo rebuild e recreate completo delle app staging:

docker builder prune -f
docker image prune -f

Risultato:

Questa pulizia non rimuove volumi e non ferma container. Evitare docker system prune --volumes salvo piano di rollback esplicito.

Cleanup globale 2026-06-24

Eseguita pulizia conservativa dopo restore test backup:

docker builder prune -af --filter until=24h
docker image prune -f
docker image rm rust:1.86-bookworm amazon/aws-cli:latest
docker builder prune -af

Rimossi inoltre:

• file temporanei di build/test in /tmp;
• SQL/password temporanee residue in /tmp;
• log temporanei di rebuild in /tmp;
• cache di compilazione Rust root-owned sotto /opt/obelica/infra/tools/*/target/release;
• artefatti temporanei del restore test.

Non rimossi:

• database;
• /opt/obelica/data;
• repository app;
• bucket Spaces;
• ultimo snapshot locale;
• immagini Docker usate dai container live;
• rust:1.91-bookworm, postgres:18-alpine e alpine:latest, perche' usati da build/backup;
• script legacy in /opt/obelica/infra/scripts e /opt/obelica/infra/cron, perche' ancora referenziati da runner docs, cron staging o documentazione.

Risultato:

Check post-cleanup:

• obelica health: OK;
• obelica backup status: OK, 1 snapshot locale;
• obelica backup verify-offsite: OK;
• docs: HTTP 200;
• tutti i container applicativi e infrastrutturali running.

Log container

Dal 2026-06-22 i servizi pubblici e infrastrutturali principali usano rotazione Docker:

logging:
  driver: "json-file"
  options:
    max-size: "10m"
    max-file: "3"

Questo evita crescita indefinita dei file json.log, ma non sostituisce l'ottimizzazione immagini/cache.

Build context Docker

Dal 2026-06-22 tutti i repo app staging hanno .dockerignore standard e cache mount BuildKit nei Dockerfile dove applicabile.

Regole operative:

• non includere .git, node_modules, .next, cache locali, log, .env o cartelle editor nel build context;
• usare cache mount per install npm/pnpm;
• dopo rebuild massivi verificare docker system df;
• se la build cache cresce molto, usare docker builder prune -f dopo avere confermato che i container sono running e lo smoke test e' verde.

Nota: .dockerignore riduce file locali e cache inutili. Non riduce asset realmente necessari al runtime o alla build. tulpa-studio rimane il caso principale da rivedere a livello app/asset.

Cleanup automatico Docker

Dopo ripetute pulizie manuali della build cache, dal 2026-06-28 e' attivo un cleanup notturno automatico.

Script

/opt/obelica/infra/cron/docker-cleanup.sh

Operazioni eseguite:

1. docker builder prune -f --filter until=48h --reserved-space 5GB
   rimuove la build cache non usata da piu' di 48 ore, lasciando almeno 5 GB di cache recente per non rallentare i deploy.
2. docker image prune -f
   rimuove le immagini dangling (layer orfani senza tag).

Scheduling

Aggiunto al crontab di bona:

# Docker cleanup every night at 02:00
0 2 * * * /opt/obelica/infra/cron/docker-cleanup.sh

L'orario e' prima del backup (04:00) e prima dei cron applicativi, per evitare conflitti con build o dump.

Log

/opt/obelica/logs/docker-cleanup.log

Risultato prima esecuzione (2026-06-28)

Tutti i container sono rimasti running; smoke test e health check OK.

Note operative

• Lo script non rimuove volumi, container o immagini in uso.
• Il parametro --reserved-space 5GB sostituisce il vecchio --keep-storage deprecato.
• Se in futuro il disco dovesse crescere troppo anche con questo cron, valutare l'aggiunta di docker image prune -a -f --filter "until=168h" nello script, tenendo presente che rimuove anche immagini base non attualmente usate da container live.