Docker Mount: volumi, bind mount e tmpfs spiegati

Hai appena arrestato il container Docker per aggiornare un file di configurazione, ma al riavvio tutti i dati erano spariti. Ci sono passato anch’io.

Succede perché i container sono effimeri per impostazione predefinita – quando vengono rimossi, qualunque dato salvato nel loro layer scrivibile scompare. Le applicazioni reali non possono funzionare così. Ti servono database persistenti, file di configurazione che sopravvivano ai riavvii e log a cui tu possa davvero accedere.

I mount di Docker risolvono il problema collegando lo storage del container a posizioni esterne. Esistono tre tipi: volumi per i dati di produzione, bind mount per i flussi di lavoro di sviluppo e tmpfs per file temporanei salvati in memoria.

In questo articolo ti spiego come scegliere il tipo di mount giusto per il tuo caso d’uso e come implementarlo correttamente. Per seguire tutto, ti serve una buona base su Docker e la containerizzazione. Segui il nostro corso Intermediate Docker per metterti rapidamente in pari.

Come Docker gestisce lo storage

I container Docker usano un filesystem a livelli che tratta tutto come temporaneo per impostazione predefinita.

Quando crei un’immagine Docker, ogni istruzione del Dockerfile genera un nuovo layer in sola lettura. Questi layer si impilano come un mazzo di carte. Se scarichi un’immagine Ubuntu con Python installato, avrai un layer per l’OS base e un altro per Python.

Il punto è che tutti questi layer sono in sola lettura. Non puoi modificarli.

Il filesystem del container e il layer scrivibile

Quando avvii un container, Docker aggiunge un altro layer in cima - il layer scrivibile del container.

Qui avvengono tutte le modifiche. Ogni file che crei, configurazione che modifichi e record che aggiungi vive qui.

Sembra fantastico, ma il problema è che questo layer è legato al ciclo di vita del container.

Quando arresti e rimuovi il container con docker rm, il layer scrivibile sparisce. Tutto quello su cui hai lavorato se ne va. Docker non chiede conferma. Semplicemente elimina tutto.

Questo approccio ha senso per app stateless che non devono ricordare nulla tra un’esecuzione e l’altra. Ma le applicazioni reali non sono stateless.

Perché i mount sono necessari

Il layer scrivibile ha due grossi problemi in produzione.

Primo, perdi i dati quando i container si fermano. A cosa serve un container di database che si dimentica tutte le righe dopo un riavvio? L’unico caso che mi viene in mente è per eseguire test di integrazione della tua app.

Secondo, non puoi condividere dati tra container. Metti che esegui una web app e un worker in background che devono accedere agli stessi file. Se quei file vivono nel layer scrivibile di un container, l’altro container non li vede.

I mount di Docker risolvono entrambi i problemi collegando i container a uno storage che esiste al di fuori del ciclo di vita del container. Puoi montare una directory della tua macchina host o un volume gestito da Docker. I dati persistono anche quando i container vengono rimossi. Più container possono montare la stessa posizione e condividere file in tempo reale.

Ecco perché devi usare i mount. Vediamo i tipi di mount e poi ti mostro come funzionano.

Panoramica dei tipi di mount in Docker

Docker ti offre tre modi per gestire i dati persistenti, e ognuno risolve problemi diversi. Ecco cosa fa ogni tipo e quando usarlo.

Volumi

I volumi sono la risposta predefinita di Docker allo storage persistente.

Docker crea e gestisce i volumi per te in una directory dedicata sulla macchina host. Non devi sapere dove si trova, pensa a tutto Docker. Questo rende i volumi portabili tra sistemi diversi e sicuri per la produzione.

Quando rimuovi un container, il volume resta intatto. Se avvii un nuovo container e alleghi lo stesso volume, tutti i tuoi dati saranno lì dove li avevi lasciati.

I volumi sono ideali per database di produzione, stato applicativo e qualunque dato che non puoi perdere.

Bind mount

I bind mount collegano direttamente una directory specifica della macchina host a un container.

Scegli il percorso esatto sull’host - ad esempio /home/user/project - e Docker lo mappa nel container. Quando cambi un file sull’host, il container vede subito la modifica. Se cambi un file nel container, la modifica appare sull’host.

Questa sincronizzazione in tempo reale rende i bind mount perfetti per lo sviluppo.

Ma i bind mount comportano dei rischi. Espongono percorsi dell’host ai container e dipendono da strutture di directory specifiche che potrebbero non esistere su altre macchine.

Mount tmpfs

I mount tmpfs salvano i dati nella memoria dell’host invece che su disco.

Nulla viene scritto sul filesystem. Quando il container si ferma, i dati scompaiono completamente. Questo rende i tmpfs utili per dati temporanei che non vuoi persistere - ad esempio token di autenticazione, dati di sessione o file di cache che ricostruirai comunque.

Detto ciò, i tmpfs sono limitati dalla RAM disponibile e funzionano solo su host Linux.

Volumi Docker per dati persistenti

I volumi sono la soluzione di storage pronta per la produzione di Docker, e dovresti usarli di default a meno che non ci sia un motivo specifico per non farlo.

Sono interamente gestiti da Docker, funzionano in modo coerente su piattaforme diverse e sopravvivono alla rimozione dei container per progettazione. Se esegui database, salvi stato applicativo o gestisci dati che devono sopravvivere a un singolo container, i volumi sono la scelta giusta.

Come funzionano i volumi Docker

Docker salva i volumi in una directory dedicata sulla macchina host:

• Linux: /var/lib/docker/volumes/
• macOS: ~/Library/Containers/com.docker.docker/Data/vms/0/data/
• Windows: \\wsl$\docker-desktop-data\data\docker\volumes\, assumendo backend WSL2

Non gestisci direttamente questa directory. Docker si occupa di creazione, permessi e cleanup tramite la sua API. Questa separazione significa che i volumi funzionano allo stesso modo su Linux, Mac e Windows, rendendo la tua configurazione portabile tra ambienti di sviluppo e produzione.

Ricorda che i volumi esistono indipendentemente da qualsiasi container. Quando crei un volume, lo alleghi a un container, esegui l’app, poi arresti ed elimini quel container, il volume resta dov’è con tutti i tuoi dati intatti.

Se avvii un nuovo container e alleghi lo stesso volume, i dati saranno ancora lì.

Creare e riutilizzare i volumi

Puoi creare un volume con nome prima di avviare qualsiasi container:

docker volume create mydata

Poi allegalo quando avvii un container usando il flag --mount:

docker run -d \
  --name postgres-db \
  --mount source=mydata,target=/var/lib/postgresql/data \
  postgres:18

Questo monta il volume mydata in /var/lib/postgresql/data all’interno del container, dove Postgres salva i file del database.

Ora puoi arrestare e rimuovere questo container, quindi avviarne uno nuovo con lo stesso volume:

docker rm -f postgres-db

docker run -d \
  --name postgres-db-new \
  --mount source=mydata,target=/var/lib/postgresql/data \
  postgres:18

Il tuo database torna con tutte le tabelle e le righe intatte.

È questo il senso dei volumi: persistenza dei dati attraverso i cicli di vita dei container.

Gestione e manutenzione dei dati nei volumi

Puoi eseguire questo comando per vedere quali volumi esistono sul tuo sistema:

docker volume ls

Poi puoi ispezionare un volume specifico per vedere dove è salvato e quali container lo usano:

docker volume inspect mydata

Questo mostra il punto di mount sull’host e metadati utili. Ma raramente hai bisogno di accedere direttamente a questa directory: se ne occupa Docker.

Se hai finito con il volume e vuoi rimuoverlo, esegui semplicemente questo comando:

docker volume rm mydata

Docker non ti permette di eliminare un volume collegato a un container in esecuzione. Prima arresta il container, poi rimuovi il volume.

Infine, se vuoi fare pulizia e recuperare spazio su disco, puoi eseguire questo comando per rimuovere in una volta tutti i volumi inutilizzati:

docker volume prune

Per ambienti di produzione, Docker supporta driver di volume che si collegano a sistemi di storage esterni come NFS, AWS EFS o storage a blocchi cloud. Specifichi il driver quando crei il volume e Docker gestisce il resto. Così puoi salvare i dati interamente al di fuori dell’host, cosa importante per configurazioni ad alta disponibilità in cui i container si spostano tra server.

Ora passiamo ai bind mount.

Bind mount per lo sviluppo locale

I bind mount ti danno accesso diretto al filesystem dell’host dall’interno di un container, ed è proprio per questo che gli sviluppatori li amano.

Sono perfetti per lo sviluppo locale ma hanno compromessi che li rendono rischiosi in produzione. Ottieni sincronizzazione in tempo reale e zero step di build, ma perdi portabilità e puoi aprire falle di sicurezza.

Come funzionano i bind mount

Un bind mount mappa direttamente una directory specifica della tua macchina host in un container.

Specifichi il percorso esatto - ad esempio /home/user/myapp - e Docker lo rende disponibile a un percorso all’interno del container. Niente copie, niente storage gestito da Docker, nessun layer di astrazione. Il container vede i tuoi veri file dell’host.

Se cambi un file sull’host, il container vede la modifica all’istante. Allo stesso modo, se modifichi un file nel container, si aggiorna sull’host. Entrambi lavorano sugli stessi file in tempo reale.

Ecco un bind mount in azione:

docker run -d \
  --name dev-app \
  --mount type=bind,source=/Users/dradecic/Desktop/app,target=/app \
  python:3.14

Questo monta /Users/dradecic/Desktop/app dal mio host in /app dentro il container. Quando modifico un file Python in /Users/dradecic/Desktop/app con il tuo editor di testo, l’app containerizzata vede subito la modifica.

Puoi anche usare la sintassi più corta:

Flussi di lavoro di sviluppo comuni

Il caso d’uso più comune è montare il codice sorgente durante lo sviluppo.

Metti che stai sviluppando un’applicazione FastAPI. Puoi montare la directory del progetto nel container, abilitare l’hot reload e ottenere un ambiente di sviluppo completo:

docker run -d \
  --name fastapi-dev \
  --mount type=bind,source=/Users/dradecic/Desktop/app,target=/app \
  -w /app \
  -p 8000:8000 \
  python:3.14 \
  sh -c "pip install fastapi uvicorn && uvicorn main:app --reload --host 0.0.0.0"

Per riferimento, ecco il mio file main.py:

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI(
    title="FastAPI Docker Demo",
    description="A minimal FastAPI app running inside Docker",
    version="1.0.0",
)

class Item(BaseModel):
    name: str
    price: float
    in_stock: bool = True

@app.get("/")
def read_root():
    return {
        "message": "FastAPI is running",
        "docs": "/docs",
        "redoc": "/redoc",
    }

@app.get("/health")
def health_check():
    return {"status": "ok"}

@app.post("/items")
def create_item(item: Item):
    return {
        "message": "Item received",
        "item": item,
    }

Dopo aver eseguito il comando Docker, l’app è disponibile dalla mia macchina host sulla porta 8000:

Se modifichi main.py nel tuo editor e salvi il file, FastAPI ricarica automaticamente. Niente rebuild delle immagini, niente riavvio dei container. Scrivi codice come faresti in locale, ma l’app gira in un ambiente container coerente.

Rischi e limitazioni

I bind mount espongono il filesystem dell’host ai container, e questo può creare problemi di sicurezza.

Un container con un bind mount può leggere e scrivere file sull’host. Eseguire un container come root - impostazione predefinita - gli dà accesso root a quei file montati. Codice malevolo o un container compromesso potrebbe modificare o eliminare qualsiasi cosa nella directory montata.

La portabilità è un altro problema.

I bind mount dipendono dall’esistenza di percorsi specifici sull’host. Il percorso /Users/dradecic/Desktop/app potrebbe non esistere sulla tua macchina o su un server di produzione. Questo rompe la promessa del "funziona ovunque" dei container.

Anche le differenze di piattaforma contano. Windows e Mac usano una VM per eseguire Docker, quindi i bind mount passano per un layer di traduzione extra. Questo rallenta le operazioni sui file e può causare bug sottili con file watcher e symlink.

Gli ambienti di produzione non dovrebbero mai usare i bind mount.

Sono troppo dipendenti dai percorsi specifici dell’host, troppo rischiosi dal punto di vista della sicurezza e impossibili da versionare. I volumi risolvono tutti questi problemi, motivo per cui sono lo standard in produzione.

Considera i bind mount uno strumento di sviluppo: veloce, comodo e potente, ma non qualcosa da usare in produzione.

Mount tmpfs per dati temporanei

I mount tmpfs salvano i dati nella RAM dell’host invece che su disco. Sono perfetti per i dati che non vuoi persistere.

Comportamento dello storage in memoria

Un mount tmpfs esiste interamente in memoria.

Docker alloca RAM sull’host e la rende disponibile come filesystem all’interno del container. Un file scritto su un tmpfs non tocca mai il disco. I dati restano in memoria finché il container non si ferma.

Quando arresti il container, tutto ciò che è nel mount tmpfs viene eliminato. Niente cleanup richiesto, nessun file residuo, nessuna traccia. Ogni riavvio parte con un tmpfs vuoto.

In sintesi, i tmpfs sono per dati che esplicitamente non vuoi conservare: calcoli temporanei, token di sessione o informazioni sensibili che non devono persistere dopo l’uso.

Casi d’uso tipici

Il caso d’uso più comune è archiviare segreti o dati sensibili.

Metti che esegui un container che necessita di una chiave API o una password del database. Salvala in un mount tmpfs e il segreto non verrà mai memorizzato su disco. Quando il container si ferma, il segreto scompare dalla memoria. Non c’è un file da committare per errore o lasciare esposto sul filesystem.

Anche le cache sono un buon candidato. Artefatti di build, codice compilato o dipendenze scaricate che rigenererai comunque non devono persistere. Mettili su tmpfs per un accesso più rapido durante la vita del container e lasciali sparire quando hai finito.

Anche i file temporanei funzionano bene qui: dati di sessione, file di lock o risultati intermedi che contano solo mentre il container è in esecuzione.

Configurazione di base

Esegui questo comando per creare un mount tmpfs usando il flag --tmpfs:

docker run -d \
  --name temp-app \
  --tmpfs /tmp:rw,size=100m \
  python:3.14

Questo crea un mount tmpfs da 100 MB in /tmp dentro il container. L’opzione size limita quanta RAM può usare il mount.

Puoi anche usare la sintassi --mount:

docker run -d \
  --name temp-app \
  --mount type=tmpfs,destination=/tmp,tmpfs-size=104857600 \
  python:3.14

Il valore di tmpfs-size è in byte: 104857600 byte equivalgono a 100 MB.

Se non specifichi un limite di dimensione, tmpfs usa fino a metà della RAM di sistema. È pericoloso, per ovvi motivi. Imposta sempre limiti espliciti.

L’unico grosso limite è che i mount tmpfs funzionano solo su Linux.

Docker Desktop per Mac e Windows non li supporta perché esegue Docker in una VM Linux e tmpfs richiede supporto diretto del kernel.

Sintassi e configurazione dei mount in Docker

Docker offre due modi per definire i mount, e scegliere la sintassi giusta rende i comandi più leggibili e facili da fare debug.

Entrambi funzionano, ma uno scala meglio quando ti servono opzioni avanzate o più mount in un singolo container.

-mount vs --volume

Il flag --mount usa coppie chiave-valore esplicite, mentre -v o --volume usa una stringa separata da due punti.

Ecco lo stesso mount di un volume con entrambe le sintassi:

# Using --mount
docker run -d \
  --mount type=volume,source=mydata,target=/app/data \
  python:3.14

# Using -v
docker run -d \
  -v mydata:/app/data \
  python:3.14

Entrambi creano un volume chiamato mydata e lo montano in /app/data nel container.

Usa --mount per tutto ciò che va oltre le configurazioni di base. È più prolisso, ma le chiavi esplicite chiariscono cosa fa ogni parte. Quando aggiungi opzioni come accesso in sola lettura o driver di volume personalizzati, resta leggibile mentre -v può sembrare una stringa criptica.

La sintassi -v va bene per flussi di lavoro semplici di sviluppo dove scrivi i comandi a mano.

Opzioni di mount comuni

L’opzione readonly impedisce ai container di modificare i dati montati:

docker run -d \
  --mount type=volume,source=mydata,target=/app/data,readonly \
  python:3.14

È utile per file di configurazione o dati di riferimento che i container devono leggere ma non modificare. Un container che prova a scrivere su un mount readonly riceve un errore di permessi.

Per i volumi, l’opzione volume-nocopy evita la copia dei dati esistenti dall’immagine del container nel volume:

docker run -d \
  --mount type=volume,source=mydata,target=/app/data,volume-nocopy \
  python:3.14

Per impostazione predefinita, Docker copia ciò che esiste nel punto di mount dell’immagine in un nuovo volume. Con volume-nocopy ottieni un volume vuoto a prescindere da cosa c’è nell’immagine.

Per i mount tmpfs, l’opzione tmpfs-size imposta un limite di memoria:

docker run -d \
  --mount type=tmpfs,target=/tmp,tmpfs-size=104857600 \
  python:3.14

Questo limita il mount tmpfs a 100 MB. Senza limite, un tmpfs può consumare tutta la RAM disponibile.

Montare sopra dati esistenti

Quando monti in una directory che esiste già nell’immagine del container, il mount nasconde completamente ciò che c’era.

Metti che l’immagine abbia una directory /app/data con file di configurazione inclusi. Quando monti un volume in /app/data, quei file scompaiono. Il container vede solo ciò che c’è nel volume.

Succede con tutti i tipi di mount - volumi, bind mount e tmpfs. Il contenuto montato ha la precedenza e la directory originale diventa inaccessibile finché il mount è attivo.

Usare i mount con Docker Compose

Docker Compose semplifica la definizione e la condivisione dei mount tra più container nel tuo stack applicativo.

Invece di digitare lunghi comandi docker run con flag di mount, dichiari tutto in un file docker-compose.yml. Ti mostro come.

Definire volumi e bind mount in Compose

Ecco un file Compose con esempi di volume e bind mount:

services:
  service-1:
    image: ubuntu:latest
    command: sleep infinity
    volumes:
      - ./code:/app          # Bind mount per lo sviluppo
      - shared:/data         # Volume con nome condiviso con worker

  service-2:
    image: ubuntu:latest
    command: sleep infinity
    volumes:
      - shared:/data         # Stesso volume di service-1

volumes:
  shared:

La chiave volumes sotto ogni servizio definisce cosa viene montato. Percorsi relativi come ./code creano bind mount, mentre nomi come shared fanno riferimento a volumi con nome.

La sezione volumes a livello superiore dichiara i volumi con nome che Compose crea e gestisce. Sia service-1 che service-2 montano lo stesso volume shared, quindi vedono gli stessi file. Scrivi un file da un container e l’altro può leggerlo subito.

Il comando sleep infinity mantiene i container in esecuzione per poterci entrare con exec - solo a scopo dimostrativo.

Persistenza e verifica dei dati

Avvia lo stack con docker compose up -d, poi verifica che i mount funzionino:

# Scrivi dati nel volume condiviso dall'app
docker compose exec service-1 sh -c "echo 'test' > /data/file.txt"

# Leggili dal worker
docker compose exec service-2 cat /data/file.txt

Se entrambi i comandi funzionano, i volumi sono configurati correttamente.

Ora puoi eseguire questo comando per arrestare e rimuovere tutto:

docker compose down

I tuoi volumi con nome saranno ancora presenti. Se riavvii lo stack con docker compose up -d, i dati scritti in precedenza saranno ancora lì. È così che i database persistono tra i deploy: il volume sopravvive al container.

Per eliminare i volumi quando arresti lo stack, aggiungi il flag -v:

docker compose down -v

Questo rimuove tutti i volumi definiti nel file Compose. Usalo quando vuoi ripartire da zero.

Popolare i volumi con dati iniziali

Il pattern più comune è usare un container di init separato per popolare il volume condiviso:

services:
  init:
    image: ubuntu:latest
    command: sh -c "mkdir -p /source && echo 'initial data' > /source/seed.txt && cp /source/* /dest/"
    volumes:
      - shared:/dest

  service-1:
    image: ubuntu:latest
    command: sleep infinity
    depends_on:
      - init
    volumes:
      - shared:/data

  service-2:
    image: ubuntu:latest
    command: sleep infinity
    depends_on:
      - init
    volumes:
      - shared:/data

volumes:
  shared:

Il container init crea dati di seed e li copia nel volume shared, poi termina. Sia service-1 che service-2 partono dopo e trovano i dati pronti all’uso.

Compose gestisce la complessità di coordinare più container e lo storage condiviso in un unico file versionato.

Prestazioni e sicurezza dei mount in Docker

Scegliere il tipo di mount sbagliato può rallentare i container o creare falle di sicurezza di cui non eri consapevole. Leggi questa sezione se non vuoi che accada.

Compromessi di prestazioni tra i tipi di mount

I volumi offrono le migliori prestazioni su Linux perché sono salvati direttamente sul filesystem dell’host senza layer di traduzione.

Su Mac e Windows, Docker gira in una VM Linux. I volumi comunque vanno bene perché restano dentro la VM. I bind mount invece devono sincronizzare i file tra l’OS host e la VM Linux, aggiungendo overhead. Le operazioni sui file in bind mount possono essere significativamente più lente su Mac e Windows rispetto a Linux nativo.

tmpfs è l’opzione più veloce per lettura e scrittura perché tutto avviene in RAM. Niente I/O su disco, niente overhead del filesystem. Ma sei limitato dalla memoria disponibile e i dati scompaiono quando il container si ferma.

Se sei su Linux e ti servono prestazioni massime, usa i volumi. Se sei su Mac o Windows e noti lentezza nelle operazioni su file durante lo sviluppo, probabilmente è l’overhead dei bind mount. Passa ai volumi per i carichi di lavoro in produzione.

Implicazioni di sicurezza dei mount

Ogni mount dà ai container accesso a qualcosa al di fuori del loro filesystem isolato, e questo crea rischio.

I bind mount sono la preoccupazione maggiore. Se monti /home/user in un container, un container compromesso può leggere le tue chiavi SSH, modificare la configurazione della shell o eliminare file in tutta la home. Se lo esegui come root - impostazione predefinita - ha accesso di root a quei file.

I volumi riducono questo rischio perché sono isolati nella directory di storage di Docker. Un container non può montare percorsi host arbitrari tramite volumi. Ma i volumi possono comunque far trapelare dati tra container se li condividi senza attenzione.

I mount tmpfs minimizzano il rischio di persistenza: i segreti in memoria scompaiono quando i container si fermano. Ma non proteggono da attacchi in runtime in cui un container compromesso legge i segreti dalla memoria.

La regola generale è che i mount rompono l’isolamento del container, quindi usali con cautela.

Best practice per mount sicuri

Monta solo ciò di cui i container hanno bisogno e niente di più.

Invece di montare l’intera directory del progetto, monta solo la sottodirectory usata dal container. Invece di montare /var/log in scrittura, montala in sola lettura se il container deve solo leggere i log.

Usa l’opzione readonly quando possibile:

docker run -d \
  --mount type=bind,source=/app/config,target=/config,readonly \
  ubuntu:latest

Questo impedisce ai container di modificare i dati montati, limitando i danni in caso di compromissione.

Esegui i container come utenti non root per ridurre l’impatto delle vulnerabilità dei bind mount. Crea un utente nel Dockerfile e passaci prima che il container parta:

RUN useradd -m appuser
USER appuser

Pulisci regolarmente i volumi inutilizzati con docker volume prune. Col tempo i volumi vecchi si accumulano, consumano spazio su disco e possono contenere dati sensibili di container eliminati.

Non montare mai directory host sensibili come /, /etc o /var a meno che tu non abbia un motivo specifico e comprenda i rischi. Ogni mount dovrebbe avere uno scopo chiaro e un ambito minimo.

Risoluzione dei problemi con i mount Docker

I problemi di mount di solito si manifestano come errori di permessi, file mancanti o container che non si avviano - e quasi sempre sono causati dallo stesso set di problemi.

Ecco come diagnosticare e risolvere i problemi più comuni.

Errori di permessi e ownership

Gli errori di permessi accadono quando l’utente nel container non ha accesso ai file montati.

I container Docker girano come root per impostazione predefinita. Quando root crea un file in un bind mount, quel file è di proprietà di root sull’host. Se provi a modificarlo con il tuo utente normale, otterrai un errore di permesso negato.

Succede anche il contrario. Monta una directory di cui sei proprietario in un container che gira come utente non root, e il container potrebbe non riuscire a scriverci.

Puoi controllare proprietà e permessi con ls -la sulla directory montata:

ls -la /path/to/mounted/directory

Se i file sono di proprietà di root ma il tuo container gira come un altro utente, c’è un mismatch. Risolvilo eseguendo il container come lo stesso utente proprietario dei file:

docker run -d \
  --user $(id -u):$(id -g) \
  -v ./data:/app/data \
  ubuntu:latest

Questo esegue il container con il tuo utente corrente invece che root, allineando l’ownership dei file nel bind mount.

Per i volumi, Docker gestisce i permessi automaticamente quando i container creano file. Ma se vedi errori, controlla con quale utente gira l’app nel container e se ha accesso in scrittura al punto di mount.

Errori di percorso e configurazione

L’errore più comune è montare un percorso che non esiste sull’host.

Se provi a montare /home/user/project quando quella directory non esiste, Docker crea una directory vuota di proprietà di root. Il container parte, ma sta montando la cosa sbagliata: una directory vuota invece del tuo progetto.

Verifica sempre che i percorsi esistano prima di montarli:

ls /home/user/project

Se la directory non esiste, creala prima o correggi il percorso nel comando di mount.

In Docker Compose, i percorsi relativi sono risolti a partire dalla directory che contiene il file docker-compose.yml. Se il file è in /home/user/app/ e usi ./data, Docker cercherà /home/user/app/data.

Sposta il file Compose e il mount si rompe.

Un altro errore comune è montare nel percorso sbagliato dentro il container. Se monti in /app/data quando l’app si aspetta /data, l’app non troverà i suoi file. Controlla la documentazione dell’app o il Dockerfile per sapere dove si aspetta i dati.

Stranezze specifiche di piattaforma

Su Linux, i bind mount lavorano direttamente con il filesystem dell’host.

Su Mac e Windows, Docker gira in una VM Linux. I bind mount sincronizzano i file tra l’OS host e la VM, creando problemi di timing. I file watcher - strumenti che ricaricano l’app quando i file cambiano - a volte perdono aggiornamenti a causa dei ritardi di sincronizzazione.

Mac e Windows gestiscono anche i permessi in modo diverso. La VM traduce i permessi tra host e Linux, e questo può far apparire i file con ownership errata nei container.

I symlink non funzionano sempre in modo affidabile nei bind mount su Mac e Windows. La VM non sempre risolve symlink che puntano fuori dalla directory montata, quindi i file possono apparire mancanti o rotti nel container.

I mount tmpfs non funzionano affatto su Mac e Windows perché la VM non espone tmpfs all’host. Se provi a usarli, Docker li ignora silenziosamente o lancia un errore a seconda della versione.

Se sviluppi su Mac o Windows e riscontri strani problemi di sincronizzazione file, passa ai volumi con nome per migliori prestazioni e affidabilità. Tieni i bind mount per flussi di sviluppo dove la sincronizzazione in tempo reale conta più della coerenza perfetta.

Conclusione

In sintesi: usa i volumi per i dati di produzione che devono persistere, come database, file caricati, stato applicativo - tutto ciò che non puoi permetterti di perdere. Sono gestiti da Docker, portabili tra piattaforme e la scelta più sicura per i dati importanti.

I bind mount appartengono ai flussi di lavoro di sviluppo in cui ti serve sincronizzazione in tempo reale tra host e container. Quando modifichi il codice nel tuo editor, vedi subito i cambiamenti nell’app containerizzata. Ma tienili fuori dalla produzione: dipendono troppo dai percorsi specifici dell’host e creano rischi di sicurezza inutili.

Quando sei pronto per approfondire containerizzazione e virtualizzazione, dai un’occhiata al nostro corso: Containerization and Virtualization with Docker and Kubernetes.