Docker Volume: containerdata persistent maken

Een docker volume is een persistente opslageenheid die je data in leven houdt, zelfs wanneer een container wordt verwijderd, opnieuw aangemaakt of zijn image wordt bijgewerkt. Containers in Docker zijn van nature vluchtig: wanneer je er een verwijdert met docker rm, verdwijnt alles in zijn schrijfbare laag mee. Als databasebestanden, geüploade afbeeldingen of applicatielogs in die laag staan, kan één enkele docker compose down urenlang opgebouwde data wissen. Volumes bestaan precies om dit probleem op te lossen.

Waarom data binnen een container schrijven riskant is

Een Docker-image is opgebouwd uit gestapelde alleen-lezen lagen. Wanneer een container draait, wordt er bovenop een dunne schrijfbare laag toegevoegd waarin elke wijziging wordt weggeschreven. Die laag is gebonden aan de levensduur van de container; als de container weg is, is de laag dat ook. Het gevolg:

• De container opnieuw aanmaken (image-update, configuratiewijziging) verwijdert de data.
• Schijftoegang via de schrijfbare laag is trager dan rechtstreeks naar de schijf schrijven.
• Data van buiten de container back-uppen, of delen met een andere container, wordt lastig.

Alles wat moet blijven bestaan, hoort buiten het bestandssysteem van de container te leven, in een ruimte die door Docker wordt beheerd. Die ruimte is een volume.

Volume, bind mount en tmpfs

Docker biedt drie soorten mounts, en weten welke je kiest is belangrijk:

• Volume: beheerd door Docker op de host onder /var/lib/docker/volumes/. Het is draagbaar, eenvoudig te back-uppen en de aanbevolen optie voor productie.
• Bind mount: koppelt een specifieke hostmap (zoals /home/user/project) rechtstreeks in de container. Ideaal om code live te bewerken tijdens ontwikkeling, maar sterk gekoppeld aan de hoststructuur.
• tmpfs: houdt data alleen in RAM; ze verdwijnt zodra de container stopt. Gebruikt voor tijdelijke of gevoelige data.

Een simpele regel: gebruik een volume wanneer je wilt dat de data van Docker is, en een bind mount wanneer je ze wilt koppelen aan een echte map op de host.

Een volume aanmaken en gebruiken

Het meest voorkomende scenario is een benoemd volume aanmaken en aan een container koppelen:

docker volume create db_data

docker run -d \
  --name postgres \
  -v db_data:/var/lib/postgresql/data \
  -e POSTGRES_PASSWORD=geheim \
  postgres:16

Het deel -v db_data:/var/lib/postgresql/data zegt: koppel het volume met de naam db_data aan de datamap van PostgreSQL binnen de container. Verwijder de container en start hem opnieuw met hetzelfde volume, en de database staat er nog. Om bestaande volumes te bekijken:

docker volume ls
docker volume inspect db_data

Persistente data met Compose

In echte projecten definieer je volumes meestal in docker-compose.yml. Het onderstaande voorbeeld draait een database met een persistent volume:

services:
  db:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: geheim
    volumes:
      - mysql_data:/var/lib/mysql

volumes:
  mysql_data:

Het volumes:-blok op het hoogste niveau declareert het benoemde volume, en de regel binnen de service koppelt het. docker compose down verwijdert de containers maar behoudt het volume mysql_data; docker compose up brengt de data terug. Wil je het volume ook verwijderen, dan voer je bewust docker compose down -v uit.

Een volume back-uppen en herstellen

Omdat volumes ingebed in het hostbestandssysteem leven, is de nette manier om er een te back-uppen het archiveren van de inhoud met een wegwerp-hulpcontainer:

# Back-up: db_data volume opslaan als tar.gz
docker run --rm \
  -v db_data:/data \
  -v $(pwd):/backup \
  alpine tar czf /backup/db_data.tar.gz -C /data .

# Herstel: het archief uitpakken in een leeg volume
docker run --rm \
  -v db_data:/data \
  -v $(pwd):/backup \
  alpine tar xzf /backup/db_data.tar.gz -C /data

Deze aanpak koppelt een kleine alpine-container aan het volume en de huidige map, en comprimeert het vervolgens met tar. Voor databases voegt het maken van logische back-ups zoals mysqldump of pg_dump een tweede laag toe die veiliger is tegen corruptie.

Veelgemaakte fouten

• Het verkeerde pad koppelen: als je het volume niet koppelt aan de map waar de app werkelijk naar schrijft (bv. /var/lib/postgresql/data voor PostgreSQL), blijft er niets bewaard.
• Rechtenproblemen: wanneer de gebruikers-ID in de container niet overeenkomt met de bestandseigenaar in het volume, krijg je "permission denied"-fouten.
• Anonieme volumes opstapelen: volumes die zonder naam worden aangemaakt, stapelen zich op en vullen na verloop van tijd de schijf; ruim ze op met docker volume prune (voorzichtig).

Veelgestelde vragen

Moet ik een volume of een bind mount kiezen?

Kies in productie een volume wanneer je wilt dat de data draagbaar en door Docker beheerd is. Tijdens ontwikkeling is een bind mount praktischer als je hostcode live wilt bewerken.

Als ik de container verwijder, wordt het volume dan ook verwijderd?

Nee. Benoemde volumes staan los van de container en worden niet verwijderd door docker rm. Alleen een expliciet commando zoals docker volume rm of docker compose down -v verwijdert het volume.

Kunnen meerdere containers hetzelfde volume delen?

Ja, je kunt hetzelfde volume aan meerdere containers koppelen. Maar voor diensten die één schrijver verwachten, zoals databases, kan parallel naar hetzelfde volume schrijven corruptie veroorzaken; plan dit zorgvuldig.

Laat je data niet over aan de genade van een container. Heb je hulp nodig bij een docker volume-strategie, back-ups of het opzetten van containerinfrastructuur, neem dan contact met me op.