Hvordan fungerer datapersistens med Docker-volumer?

Question

Accepted Answer

Som standard er data i en container **kortlevet** — forsvinner når containeren fjernes. **Volumer** (og bind mounts) gir **persistent lagring** som overlever containere, essensielt for databaser og data som må overleve containeromstarter/fjerninger.

## Problemet: containere er kortlevede

```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.
```

## Volumer — administrert 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
```

**Volumer** er Docker-administrert persistent lagring (lagret på verten, administrert av Docker) — den foretrukne måten å persistere data på. Data i den monterte banen overlever selv om containeren fjernes.

## Bind mounts — kartlegg en vertmappe

```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** kartlegger en vertmappe inn i containeren — nyttig for utvikling (redigere kode på verten, se endringer live i containeren).

## Volumer 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 er viktig

Å forstå datapersistens med volumer er essensielt for å bruke Docker korrekt med enhver applikasjon som har data, så det er viktig praktisk kunnskap.

Grunproblemet — **containere er kortlevede**, med deres skrivbart lag slettet ved fjerning, noe som betyr at **data skrevet inne i en container går tapt** — er et kritisk konsept: containere er ment å være disposable, så lagring av viktig data inne i dem (som en databases filer) forårsaker datatap når containeren erstattes. **Volumer** løser dette ved å gi **Docker-administrert persistent lagring** som lever utenfor containerens livssyklus, så data (databaser, opplastinger, enhver tilstand) overlever containerfjernelse og erstatning — essensielt for stateful-applikasjoner.

Å forstå **bind mounts** (kartlegging av en vertmappe inn i containeren) er viktig for **utvikling** (redigere kode på verten og se endringer live i containeren, en veldig vanlig dev-arbeidsflyt) og for deling av vertfiler.

Å kjenne **skillet** — volumer (Docker-administrert, bærbar, det foretrukne valget for persistent applikasjonsdata som databaser) versus bind mounts (vertsti-spesifikk, utmerket for utvikling) — veileder valg av riktig tilnærming.

Siden containere er kortlevede etter utforming og de fleste virkelige applikasjoner har data som må persistes (spesielt databaser), og siden volumer er mekanismen som er essensielt for persistent lagring (med bind mounts viktige for utvikling), er forståelse av Docker-datapersistens — det kortlevede containerproblemet, volumer for persistent data, bind mounts for utvikling, og når man skal bruke hver av dem — essensielt, praktisk relevant Docker-kunnskap, nødvendig for å kjøre stateful-applikasjoner korrekt og unngå den alvorlige feilen med å miste data lagret inne i disposable containere.