Il bello dei container è che si possono cancellare e ricreare in pochi secondi. Il rovescio della medaglia è che tutto ciò che non è stato salvato fuori dal container sparisce con lui. Quando un servizio di casa perde la configurazione dopo un aggiornamento, quasi sempre la causa è una sola: i dati non erano dove si pensava. Organizzare bene cartelle, volumi e permessi fin dal primo giorno rende ogni servizio facile da aggiornare, spostare e salvare.
Il principio: il container è usa e getta, i dati no
Un container dovrebbe poter essere distrutto in qualunque momento senza perdere nulla. Per riuscirci bisogna separare tre cose:
- L'immagine: il programma, scaricato dal registro e sempre ricostruibile.
- La configurazione: il file di composizione, le variabili d'ambiente, eventuali file di impostazioni.
- I dati: database, file caricati dagli utenti, cache importanti, chiavi generate al primo avvio.
Solo le ultime due vanno salvate e conservate. Se per ricostruire un servizio da zero bastano il file di composizione e la cartella dei dati, l'organizzazione è corretta.
Bind mount o volumi gestiti
Ci sono due modi principali per dare a un container uno spazio persistente.
| Caratteristica | Bind mount | Volume gestito |
|---|---|---|
| Dove stanno i dati | In una cartella scelta da te | In un'area gestita dal motore dei container |
| Visibilità | Si navigano come file normali | Serve un comando o il percorso interno |
| Backup | Basta includere la cartella | Va gestito con attenzione |
| Permessi | Da sistemare a mano | Gestiti in automatico |
Per un server di casa preferisco quasi sempre i bind mount: tutto ciò che conta sta in un albero di cartelle che posso vedere, copiare e includere in un backup con una sola riga. I volumi gestiti restano utili per dati davvero temporanei.
Una struttura di cartelle prevedibile
Una convenzione semplice, applicata a tutti i servizi, evita di dover ricordare dove si trova ogni cosa:
/srv/servizi/
immich/
compose.yaml
.env
data/
db/
freshrss/
compose.yaml
data/
Ogni servizio ha la sua cartella con dentro il file di composizione, il file delle variabili e le sottocartelle dei dati. Spostare un servizio su un'altra macchina diventa un'operazione meccanica: si ferma, si copia la cartella, si avvia dall'altra parte. Se i file multimediali sono grandi (foto, film) è normale tenerli su un disco diverso, ma il riferimento deve essere scritto in chiaro nel file di composizione.
Utenti e permessi
Il problema più frequente con i bind mount sono i permessi. Il processo dentro il container gira con un certo identificativo utente (UID) e di gruppo (GID); se la cartella sull'host appartiene a un altro utente, il servizio non riesce a scrivere e spesso fallisce con errori poco chiari.
Alcune soluzioni pratiche:
- Leggere la documentazione dell'immagine: molte immagini accettano variabili come
PUIDePGIDper scegliere l'utente con cui girare. - Creare un utente dedicato sull'host per i servizi e assegnargli le cartelle dei dati.
- Evitare di far girare tutto come root: funziona, ma un errore o una vulnerabilità nel servizio avrebbe accesso completo ai file montati.
- Montare in sola lettura ciò che il servizio deve solo leggere, aggiungendo
:roal percorso. Un media server, per esempio, non ha bisogno di modificare i film.
Database: sempre su disco locale
Molti servizi usano SQLite o PostgreSQL. I database sono sensibili al modo in cui il file system gestisce i blocchi e la scrittura su disco. Mettere la cartella del database su una condivisione di rete (NFS o SMB) è una fonte classica di corruzioni difficili da diagnosticare, soprattutto con SQLite.
La regola che seguo è semplice: database su un disco locale, preferibilmente SSD; file grandi e poco critici anche su un NAS. Se il servizio lo consente, è utile separare le due cose in cartelle distinte proprio per poterle collocare in posti diversi.
Pensare al backup fin dall'inizio
Una buona struttura rende il backup quasi automatico. Con tutto sotto /srv/servizi, basta un solo percorso da includere. Restano due accortezze:
- I database non vanno copiati mentre scrivono: conviene fermare il servizio durante la copia oppure esportare un dump prima del backup.
- Il file
.envcontiene spesso password e chiavi: va salvato, ma in un backup cifrato, e non va mai pubblicato in un repository.
Una prova da fare subito
Per verificare che tutto sia a posto, si può simulare un disastro su un servizio poco importante: si ferma, si rimuovono container e immagine, poi si ricrea solo a partire dalla sua cartella. Se riparte con utenti, impostazioni e dati intatti, la struttura funziona. Se qualcosa manca, meglio scoprirlo ora che durante un guasto vero.
In sintesi
- Il container si può buttare; configurazione e dati devono stare fuori.
- I bind mount in una struttura di cartelle prevedibile semplificano backup e migrazioni.
- UID, GID e montaggi in sola lettura risolvono la maggior parte dei problemi di permessi.
- I database vanno su disco locale, non su condivisioni di rete.
- Ricreare un servizio da zero è il test migliore per capire se i dati sono al sicuro.
