Avvia un database in un contenitore, aggiungi alcuni dati, rimuovi il contenitore e ne avvii uno nuovo. I dati sono spariti. Quasi tutti imparano questa lezione nel modo più duro. I volumi Docker e i montaggi di bind esistono per mantenere i dati in vita oltre la vita di qualsiasi contenitore.

Questa guida spiega come funziona ciascuno e come scegliere. I comandi e i file qui sono esempi standard, basati sul comportamento documentato di Docker e non li abbiamo eseguiti per questo articolo, quindi provali prima su dati usa e getta. I dettagli possono differire tra le versioni di Docker e su Docker Desktop. Se non conosci i container, inizia con il nostro tutorial su Docker per principianti.

Perché i dati contenitore scompaiono

Un’immagine Docker è composta da livelli di sola lettura. Quando si avvia un contenitore, Docker aggiunge un sottile livello scrivibile sopra e tutte le modifiche vengono inserite lì. Tale livello sopravvive all’arresto e al riavvio, ma viene rimosso quando il contenitore viene eliminato.

docker run -d --name db -e POSTGRES_PASSWORD=devonly postgres:17
# ... create tables and add data ...
docker rm -f db
docker run -d --name db -e POSTGRES_PASSWORD=devonly postgres:17
# The data you added is not there

Questo è previsto dalla progettazione, poiché consente di sostituire liberamente i contenitori. Significa che tutto ciò che devi conservare deve vivere fuori dal contenitore. Ci sono tre modi per farlo:

Volumi Docker e montaggi di collegamento affiancati

Volumi con nome

Un volume è uno spazio di archiviazione creato e gestito da Docker. Ti riferisci ad esso per nome e non devi preoccuparti di dove vive fisicamente.

docker volume create pgdata

docker run -d --name db \
  -e POSTGRES_PASSWORD=devonly \
  -v pgdata:/var/lib/postgresql/data \
  postgres:17

Ora i file del database risiedono in pgdata. Elimina il contenitore e avviane uno nuovo con lo stesso volume e i tuoi dati saranno ancora lì. Su Linux, i volumi di solito si trovano sotto /var/lib/docker/volumes/, ma non dovresti modificare direttamente quei file. Su Docker Desktop risiedono all’interno di una macchina virtuale, non in una normale cartella.

Il percorso all’interno del contenitore dipende dall’immagine, quindi controlla la documentazione dell’immagine. Montare sul percorso sbagliato è un classico errore: tutto sembra funzionare, ma i dati vengono ancora scritti nel livello contenitore. Anche le versioni principali più recenti di un’immagine possono modificare questo percorso, quindi leggere le note sulla versione prima dell’aggiornamento.

Docker creerà automaticamente un volume denominato se non esiste. Funziona anche un volume anonimo, creato senza nome, ma ottiene un ID casuale lungo ed è facile perderne traccia. Assegna sempre nomi ai tuoi volumi.

Legare i supporti

Un montaggio di associazione mappa un percorso host specifico direttamente nel contenitore. Entrambe le parti vedono immediatamente gli stessi file. Ciò lo rende perfetto per lo sviluppo, poiché le modifiche nel tuo editor hanno effetto nel contenitore in esecuzione senza una ricostruzione:

docker run -d --name web \
  -p 8080:80 \
  -v "$(pwd)/site:/usr/share/nginx/html:ro" \
  nginx:1.27

Modifica un file in site/, aggiorna il browser e vedrai la modifica. Il :ro rende il montaggio di sola lettura all’interno del contenitore, il che è una buona abitudine quando il contenitore non ha bisogno di scrivere lì.

I supporti di rilegatura presentano alcuni compromessi:

• Ti legano all’host. Il percorso deve esistere su ogni macchina, quindi le configurazioni sono meno portabili.
• Nascondono il contenuto dell’immagine. Se monti sopra /app, qualunque cosa contenesse l’immagine diventa invisibile. Un esempio comune è la scomparsa di node_modules.
• Espongono l’host. Un contenitore con un montaggio scrivibile può modificare o eliminare file host reali. Non montare mai percorsi sensibili come / o il socket Docker a meno che non si comprenda appieno il rischio.
• Le prestazioni possono variare. Su Docker Desktop per macOS e Windows, la condivisione dei file supera i limiti della virtualizzazione e può essere più lenta rispetto a Linux.

tmpfs si monta

Un montaggio tmpfs risiede nella memoria dell’host e non viene mai scritto nel livello contenitore. Svanisce quando il contenitore si ferma, quindi è adatto a file temporanei, cache e dati sensibili di breve durata:

docker run -d --tmpfs /app/cache:size=64m myapp:1.0

tmpfs è disponibile sugli host Linux. Può anche velocizzare i database in ambienti di test usa e getta, dove non ti interessa conservare i dati.

-v o –mount?

Entrambi i flag funzionano. --mount è più lungo, ma è più esplicito e molte persone lo preferiscono negli script:

# Short form
docker run -v pgdata:/var/lib/postgresql/data postgres:17

# Explicit form
docker run --mount type=volume,source=pgdata,target=/var/lib/postgresql/data postgres:17

# Bind mount, read-only
docker run --mount type=bind,source="$(pwd)"/site,target=/usr/share/nginx/html,readonly nginx:1.27

C’è una differenza significativa. Con -v, viene creato un percorso host mancante come cartella vuota, che può nascondere un errore di battitura. Con --mount e un tipo di associazione, Docker segnala invece un errore. Inoltre, con -v, il lato sinistro decide il tipo: un nome significa un volume e un percorso significa un mount di collegamento. Quindi -v data:/x e -v ./data:/x fanno cose molto diverse.

Volumi in Docker Compose

La maggior parte dei progetti reali dichiara l’archiviazione in un file Compose. Questo utilizza entrambi i tipi, ciascuno per il proprio lavoro:

services:
  web:
    build: .
    ports:
      - "3000:3000"
    volumes:
      - ./src:/app/src      # bind mount: live code
    depends_on:
      - db

  db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: devonly
    volumes:
      - pgdata:/var/lib/postgresql/data   # named volume: data

volumes:
  pgdata:

I volumi denominati devono essere dichiarati nella sezione di livello superiore volumes. Compose antepone il nome effettivo al nome del progetto. Consulta il nostro tutorial su Docker Compose per una procedura dettagliata completa.

Comandi utili per il volume

Controlla cosa prune rimuoverà prima di confermarlo, poiché questa operazione non può essere annullata. I volumi che nessun contenitore attualmente utilizza potrebbero comunque contenere dati importanti.

Eseguire il backup e ripristinare un volume

È possibile eseguire il backup di un volume eseguendo un contenitore di breve durata che monta sia il volume che una cartella host:

# Back up
docker run --rm \
  -v pgdata:/data:ro \
  -v "$(pwd)":/backup \
  alpine tar czf /backup/pgdata.tar.gz -C /data .

# Restore into a new volume
docker volume create pgdata_restored
docker run --rm \
  -v pgdata_restored:/data \
  -v "$(pwd)":/backup \
  alpine tar xzf /backup/pgdata.tar.gz -C /data

Per un database attivo, la copia di file come questo può acquisire uno stato incoerente. Arrestare prima il contenitore o, meglio, utilizzare lo strumento del database, come pg_dump per PostgreSQL. E un backup che non hai mai ripristinato è in realtà solo una speranza, quindi prova il ripristino.

Autorizzazioni sui file

“Permesso negato” è il problema più comune con i mount. I file mantengono gli ID utente e gruppo numerici su Linux, quindi se un contenitore viene eseguito come utente 1000 e la cartella host appartiene a un altro utente, le scritture falliranno. Alcuni modi per risolvere questo problema:

• Esegui il contenitore con un utente corrispondente: docker run --user "$(id -u):$(id -g)" ...
• Imposta la proprietà corretta della tua immagine, come descritto nelle nostre best practice per Dockerfile.
• Preferire i volumi denominati per i dati, poiché un nuovo volume assume la proprietà della cartella dell’immagine quando viene utilizzato per la prima volta.
• Sui sistemi che utilizzano SELinux, i montaggi di collegamento potrebbero richiedere un’etichetta :z o :Z.

Evita la tentazione di chmod 777, come spiega la nostra guida ai comandi Linux.

Quale dovresti usare?

L’ultima riga è importante. In produzione, il codice appartiene all’immagine, in modo che ciò che hai testato sia ciò che esegui. Nei cluster, l’archiviazione dei dati funziona ancora in modo diverso, attraverso volumi persistenti, che sono trattati nella documentazione più ampia di Kubernetes. La nostra guida Docker vs Kubernetes spiega come i due si relazionano.

Errori comuni

• Montaggio sul percorso sbagliato. I dati risiedono ancora nel livello contenitore e scompaiono in seguito.
• Esecuzione down -v casualmente. Questa operazione elimina i volumi con nome.
• Utilizzo di percorsi relativi con -v. Moduli come -v data:/x creano un volume anziché una mappatura di cartelle.
• Inserire i segreti in supporti di associazione scrivibili. Montarli in sola lettura o utilizzare una funzionalità dei segreti.
• Puntare due contenitori di database su un volume. Ciò può danneggiare i dati.
• Non sono presenti backup. Un volume non è un backup. Vive sullo stesso disco.

Considerazioni finali

La regola pratica è breve: volumi denominati per i dati, montaggi di associazione per il codice che stai modificando e tmpfs per cose che non dovrebbero durare. Provalo su un database usa e getta. Crea un volume denominato, aggiungi una riga, elimina il contenitore, iniziane uno nuovo e conferma che la riga è sopravvissuta. Quindi esercitati con un backup e un ripristino prima di averne bisogno.

Domande frequenti

Continua a imparare