Hvordan fungerer datapersistering med Docker-volumener?

Question

Accepted Answer

Som standard er data i en container **flygtig** — tabt når containeren fjernes. **Volumener** (og bind mounts) giver **persistent lagring** som overlever containers, væsentlig for databaser og enhver data, der skal overleve container-genstarter/fjernelser.

## Problemet: containere er flygtige

```text
A container's writable layer is DELETED when the container is removed:
  → data written inside the container (e.g. a database's files) is LOST
  → containers are meant to be disposable/replaceable → don't store important data in them
→ For persistent data, you need storage OUTSIDE the container's lifecycle.
```

## Volumener — administreret persistent lagring

```bash
# create and use a named volume (managed by Docker)
docker volume create mydata
docker run -v mydata:/var/lib/mysql mysql      # mount the volume into the container
# → data in /var/lib/mysql persists in the volume, surviving container removal

docker volume ls                 # list volumes
docker volume inspect mydata     # details
```

**Volumener** er Docker-administreret persistent lagring (lagret på værten, administreret af Docker) — den foretrukne måde at bevare data på. Data i den monterede sti overlever selv hvis containeren fjernes.

## Bind mounts — kortlæg en værtsmappe

```bash
# bind mount: map a specific HOST directory into the container
docker run -v /host/path:/app -p 3000:3000 myapp
docker run -v $(pwd):/app myapp   # mount the current directory (great for development)
# → changes on the host are reflected in the container (and vice versa)
```

**Bind mounts** kortlægger en værtsmappe ind i containeren — nyttig til udvikling (redigering af kode på værten, ser ændringer live i containeren).

## Volumener vs bind mounts

```text
VOLUMES      → Docker-managed, portable, the preferred choice for PERSISTENT DATA
               (databases, uploads) — decoupled from the host's filesystem layout
BIND MOUNTS  → map a specific host path; great for DEVELOPMENT (live code reload)
               and sharing host files; tied to the host's filesystem
tmpfs        → in-memory (non-persistent), for sensitive/temporary data
```

## Hvorfor det betyder noget

Forståelse af datapersistering med volumener er væsentlig for at bruge Docker korrekt med enhver applikation, der har data, så det er vigtig praktisk viden.

Det grundlæggende problem — **containere er flygtige**, med deres skrivbar lag slettet ved fjernelse, hvilket betyder, at **data skrevet inde i en container går tabt** — er et kritisk koncept: containere er beregnet til at være kassérbare, så lagring af vigtige data inde i dem (som en databases filer) forårsager datatab når containeren erstattes. **Volumener** løser dette ved at give **Docker-administreret persistent lagring** som lever uden for containerens livscyklus, så data (databaser, uploads, enhver tilstand) overlever containerfjerning og erstatning — væsentlig for tilstandsfulde applikationer.

Forståelse af **bind mounts** (kortlægning af en værtsmappe ind i containeren) er vigtig for **udvikling** (redigering af kode på værten og se ændringer live i containeren, en meget almindelig dev-arbejdsgang) og til deling af værtsfiler.

Viden om **sondringen** — volumener (Docker-administreret, bærbar, det foretrukne valg for persistent applikationsdata som databaser) versus bind mounts (værtssti-specifik, fantastisk til udvikling) — vejleder valget af den rigtige tilgang.

Fordi containere er flygtige efter design, og fordi de fleste rigtige applikationer har data, der skal bevares (databaser især), og fordi volumener er den væsentlige mekanisme for persistent lagring (med bind mounts vigtige til udvikling), er forståelse af Docker-datapersistering — det flygtige-container-problem, volumener for persistent data, bind mounts til udvikling, og hvornår man bruger hver — væsentlig, praktisk relevant Docker-viden, nødvendig for at køre tilstandsfulde applikationer korrekt og undgå den alvorlige fejl at miste data lagret inde i kassérbare containere.