Hur fungerar datapersistens med Docker-volymer?

Question

Accepted Answer

Som standard är data i en behållare **tillfällig** — förlorad när behållaren tas bort. **Volymer** (och bind mounts) ger **persistent lagring** som överlever behållare, väsentligt för databaser och all data som måste överleva omstart/borttagning av behållare.

## Problemet: behållare är tillfälliga

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

## Volymer — hanterad 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
```

**Volymer** är Docker-hanterad persistent lagring (lagrad på värden, hanterad av Docker) — det föredragna sättet att bevara data. Data i den monterade sökvägen överlever även om behållaren tas bort.

## Bind mounts — mappa en värdkatalog

```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** mappar en värdkatalog in i behållaren — användbar för utveckling (redigera kod på värden, se ändringar live i behållaren).

## Volymer 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
```

## Varför det spelar roll

Att förstå datapersistens med volymer är väsentligt för att använda Docker korrekt med alla applikationer som har data, så det är viktig praktisk kunskap.

Det grundläggande problemet — **behållare är tillfälliga**, med deras skrivbara lager borttaget vid borttagning, vilket betyder att **data skriven inuti en behållare går förlorad** — är ett kritiskt koncept: behållare är utformade för att vara förbrukbara, så lagring av viktig data inuti dem (som en databass filer) orsakar dataförlust när behållaren ersätts. **Volymer** löser detta genom att tillhandahålla **Docker-hanterad persistent lagring** som finns utanför behållarens livscykel, så data (databaser, överföringar, vilken stat som helst) överlever borttagning och ersättning av behållare — väsentligt för tillståndsbaserade applikationer.

Att förstå **bind mounts** (mappning av en värdkatalog in i behållaren) är viktigt för **utveckling** (redigera kod på värden och se ändringar live i behållaren, ett mycket vanligt dev-arbetsflöde) och för delning av värdfiler.

Att känna till **skillnaden** — volymer (Docker-hanterad, bärbar, det föredragna valet för persistent applikationsdata som databaser) kontra bind mounts (värdvägsspecifik, bra för utveckling) — vägleder valet av rätt tillvägagångssätt.

Eftersom behållare är tillfälliga enligt design och de flesta riktiga applikationer har data som måste bestå (särskilt databaser), och eftersom volymer är den väsentliga mekanismen för persistent lagring (med bind mounts viktiga för utveckling), är förståelse för Docker-datapersistens — problemet med tillfälliga behållare, volymer för beständig data, bind mounts för utveckling, och när man ska använda var — väsentlig, praktiskt relevant Docker-kunskap, nödvändig för att köra tillståndsbaserade applikationer korrekt och undvika det allvarliga misstaget att förlora data som lagras inuti förbrukbara behållare.