Data-Only-Container-Pattern: heute noch sinnvoll?

1. Woher das Data-Only-Container-Pattern kommt

In den fruehen Versionen von Docker, lange bevor Named Volumes als eigenstaendiges, benanntes Konstrukt existierten, gab es nur anonyme Volumes und Bind Mounts. Wer Daten zwischen mehreren Containern teilen wollte, ohne sich auf einen festen Host-Pfad festzulegen, musste einen Umweg gehen: das Data-Only-Container-Pattern. Dabei wurde ein Container ausschliesslich zu dem Zweck erstellt, ein oder mehrere Volumes zu deklarieren, ohne selbst einen Prozess auszufuehren, der laenger als den initialen Start lief.

Andere Container konnten sich dann ueber den Parameter --volumes-from an diesen Data-Container haengen und dessen Volumes mitbenutzen, selbst nachdem der Data-Container selbst laengst beendet war. Das Data-Only-Container-Pattern war zu seiner Zeit die einzig praktikable Loesung, um Daten unabhaengig vom Lebenszyklus eines Anwendungscontainers zu halten und zwischen mehreren Containern zu teilen, wurde aber mit der Einfuehrung von Named Volumes in Docker 1.9 im Jahr 2015 weitgehend obsolet.

2. Wie das Pattern konkret funktioniert hat

Ein klassischer Data-Only-Container wurde typischerweise mit einem minimalen Image wie busybox erstellt und deklarierte ein oder mehrere Volumes ueber den VOLUME-Befehl im Dockerfile oder den -v-Parameter bei docker create. Der Container selbst fuehrte oft keinen sinnvollen Prozess aus und wurde nach der Erstellung nie wieder gestartet, sondern diente ausschliesslich als Referenzpunkt fuer die deklarierten Volumes.

Andere Container griffen dann mit docker run --volumes-from data-container auf genau dieselben Volume-Mounts zu, ohne den Volume-Pfad selbst erneut angeben zu muessen. Dieses Data-Only-Container-Pattern loeste damit zwei Probleme gleichzeitig: Es machte Volumes zwischen Containern teilbar, ohne einen festen Host-Pfad zu benoetigen, und es entkoppelte den Lebenszyklus der Daten vollstaendig vom Lebenszyklus jedes einzelnen Anwendungscontainers, der die Daten nutzte.

#!/usr/bin/env bash
# legacy-data-only-container.sh — historical pattern, shown for reference
set -euo pipefail

# Create a data-only container (never actually runs a real process)
docker create -v /var/lib/mysql --name mysql-data busybox

# Application containers reference the data container's volumes
docker run -d --volumes-from mysql-data --name mysql-app1 mysql:5.7
docker run -d --volumes-from mysql-data --name mysql-app2 mysql:5.7

# Data survives even if the data-only container is removed
# (as long as another container still references its volumes)
docker inspect mysql-data --format '{{ .Mounts }}'

3. Warum Named Volumes das Pattern fast ueberfluessig gemacht haben

Mit Docker 1.9 fuehrte das Docker-Team benannte Volumes ein, die genau die Probleme direkt loesen, fuer die zuvor das Data-Only-Container-Pattern als Workaround diente. Ein docker volume create myvolume erstellt ein eigenstaendiges, benanntes Volume, das unabhaengig von jedem Container existiert und ueber seinen Namen direkt referenziert werden kann, ohne einen Umweg ueber einen zusaetzlichen, nie laufenden Container zu benoetigen.

Der entscheidende Vorteil von Named Volumes gegenueber dem Data-Only-Container-Pattern liegt in der direkten Verwaltbarkeit: Volumes lassen sich mit docker volume ls, docker volume inspect und docker volume rm unabhaengig verwalten, waehrend ein Data-Container immer einen zusaetzlichen, semantisch verwirrenden Eintrag in der Container-Liste erzeugte, obwohl er nie wirklich lief. Diese Klarheit in der Docker-API war der Hauptgrund, warum sich Named Volumes innerhalb weniger Jahre als Standardloesung durchsetzten und das aeltere Pattern in den allermeisten Setups verdraengten.

4. Die Nachteile des alten Patterns im Rueckblick

Im Rueckblick zeigt sich, dass das Data-Only-Container-Pattern mehrere strukturelle Schwaechen hatte, die zu seiner Zeit als notwendiges Uebel akzeptiert wurden. Der Data-Container selbst erschien in docker ps -a als gestoppter Container, was bei automatisierten Cleanup-Skripten haeufig zu versehentlichem Loeschen fuehrte, wenn diese Skripte pauschal alle gestoppten Container entfernten, ohne zwischen echten Anwendungscontainern und reinen Daten-Referenzen zu unterscheiden.

Ein zweites strukturelles Problem war die fehlende Klarheit darueber, welche Container tatsaechlich von einem Data-Only-Container abhingen. Da die Abhaengigkeit ueber --volumes-from zur Laufzeit hergestellt wurde und nicht in einer zentralen, deklarativen Konfiguration sichtbar war, mussten Teams oft manuell nachvollziehen, welche Anwendungscontainer beim Entfernen eines Data-Containers betroffen waeren. Named Volumes loesen dieses Problem durch explizite Referenzierung in der Compose-Datei oder im docker run-Befehl, was die Abhaengigkeiten sofort sichtbar macht.

5. Bestehende Data-Only-Container migrieren

Wer heute noch auf ein historisch gewachsenes Data-Only-Container-Pattern in einer produktiven Umgebung stoesst, sollte die Migration zu Named Volumes as Standardaufgabe einplanen, nicht als optionales Aufraeumen. Der erste Schritt ist, die tatsaechlichen Daten aus dem anonymen Volume des Data-Containers in ein neues, benanntes Volume zu kopieren, waehrend alle abhaengigen Anwendungscontainer kurz gestoppt sind, um Konsistenz zu gewaehrleisten.

Nach erfolgreicher Kopie werden die Anwendungscontainer neu erstellt, diesmal mit direkter Referenz auf das neue Named Volume statt auf --volumes-from. Erst wenn alle Anwendungscontainer erfolgreich auf das neue Volume umgestellt sind und die Funktionalitaet verifiziert wurde, sollte der alte Data-Only-Container zusammen mit seinem anonymen Volume entfernt werden. Dieser schrittweise Ansatz vermeidet, dass eine unvollstaendige Migration zu Datenverlust fuehrt.

#!/usr/bin/env bash
# migrate-data-container-to-named-volume.sh
set -euo pipefail

OLD_DATA_CONTAINER="mysql-data"
NEW_VOLUME="mysql-data-named"

# 1. Create the new named volume
docker volume create "$NEW_VOLUME"

# 2. Stop dependent application containers for a consistent copy
docker stop mysql-app1 mysql-app2

# 3. Copy data from the anonymous volume into the new named volume
docker run --rm \
  --volumes-from "$OLD_DATA_CONTAINER" \
  -v "${NEW_VOLUME}:/target" \
  alpine sh -c "cp -a /var/lib/mysql/. /target/"

# 4. Recreate application containers referencing the named volume directly
docker rm mysql-app1 mysql-app2
docker run -d --name mysql-app1 -v "${NEW_VOLUME}:/var/lib/mysql" mysql:5.7
docker run -d --name mysql-app2 -v "${NEW_VOLUME}:/var/lib/mysql" mysql:5.7

# 5. Once verified, remove the legacy data-only container
docker rm "$OLD_DATA_CONTAINER"
echo "[OK] Migration to named volume complete"

6. Verbliebene Nischen: wo das Pattern noch vorkommt

Trotz der weitgehenden Ablösung durch Named Volumes taucht das Data-Only-Container-Pattern gelegentlich noch in zwei Kontexten auf. Der erste ist historisch gewachsener Legacy-Code, der seit Jahren unveraendert in Produktion laeuft und bei dem niemand die Migration priorisiert hat, weil das System funktioniert und ein Umbau als Risiko ohne unmittelbaren Nutzen wahrgenommen wird. Solche Systeme finden sich vor allem in Unternehmen, die frueh mit Docker begonnen haben und seither wenig an der Storage-Schicht geaendert haben.

Der zweite verbliebene Anwendungsfall ist konzeptionell verwandt, aber nicht identisch: das Muster eines dedizierten Init-Containers, der beim Start einmalig Daten in ein Volume schreibt, etwa initiale Konfigurationsdateien oder Seed-Daten, bevor der eigentliche Anwendungscontainer startet. Dieser moderne Nachfahre des Data-Only-Container-Patterns nutzt jedoch immer ein Named Volume als Ziel, nicht mehr ein anonymes Volume eines nie laufenden Containers, und unterscheidet sich damit strukturell vom historischen Original.

7. Der Vergleich zu Kubernetes Init-Containern

Interessant ist, dass die Grundidee hinter dem Data-Only-Container-Pattern, naemlich ein Container, der Daten fuer andere Container vorbereitet, in Kubernetes als offizielles, erstklassiges Konzept wiederkehrt: der Init-Container. Ein Kubernetes Init-Container laeuft vor den eigentlichen Anwendungscontainern eines Pods, kann Volumes vorbefuellen und beendet sich danach regulaer, waehrend das befuellte Volume dem Hauptcontainer zur Verfuegung steht.

Der Unterschied zum urspruenglichen Data-Only-Container-Pattern liegt darin, dass Kubernetes Init-Container als explizites, dokumentiertes API-Konzept mit klarer Ausfuehrungsreihenfolge existieren, waehrend das Docker-Pattern ein informeller Community-Workaround ohne native Unterstuetzung war. Wer heute Init-Logik fuer Volumes braucht, etwa das Vorbefuellen mit Seed-Daten, sollte in Docker Compose auf einen expliziten Init-Service mit depends_on und einer Erfolgsbedingung setzen, statt das alte Data-Only-Container-Pattern nachzubauen.

8. Alte Compose-Dateien erkennen und bereinigen

Ein zuverlaessiges Erkennungsmerkmal fuer ein noch aktives Data-Only-Container-Pattern in einer bestehenden Compose-Datei ist die Verwendung von volumes_from als Schluesselwort, das seit Compose-Datei-Version 3 offiziell entfernt wurde und in modernen Setups nicht mehr auftauchen sollte. Findet sich dieser Schluessel in einer Legacy-Compose-Datei, ist das ein klares Signal, dass eine Migration zu Named Volumes noch aussteht.

Ein einfaches Grep ueber alle Compose-Dateien eines Projekts deckt solche Altlasten zuverlaessig auf, bevor sie bei einem Upgrade auf eine neuere Compose-Version zu einem harten Fehler fuehren, weil die Syntax schlicht nicht mehr unterstuetzt wird. Wer regelmaessig Compose-Dateien auf veraltete Syntax prueft, vermeidet boese Ueberraschungen beim naechsten grossen Docker- oder Compose-Upgrade und stellt sicher, dass kein Data-Only-Container-Pattern unbemerkt in Produktion weiterlebt.

#!/usr/bin/env bash
# find-legacy-pattern.sh — scan for deprecated volumes_from usage
set -euo pipefail

echo "[INFO] Scanning for legacy volumes_from directive..."
if grep -rn "volumes_from" --include="docker-compose*.yml" .; then
  echo "[WARN] Legacy Data-Only-Container pattern detected — migrate to named volumes"
  exit 1
else
  echo "[OK] No legacy volumes_from usage found"
fi

9. Data-Only-Container vs. Named Volumes im Vergleich

Die folgende Tabelle stellt das historische Data-Only-Container-Pattern dem modernen Named-Volume-Ansatz direkt gegenueber.

Die Tabelle macht deutlich, dass es praktisch keinen Grund mehr gibt, das Data-Only-Container-Pattern in neuen Projekten einzusetzen. Named Volumes bieten dieselbe Kernfunktionalitaet, naemlich vom Container-Lebenszyklus entkoppelte, teilbare Datenverwaltung, ohne die strukturellen Nachteile des alten Ansatzes.

10. Zusammenfassung

Das Data-Only-Container-Pattern war eine clevere Notloesung aus einer Zeit, in der Docker noch keine benannten Volumes kannte, und loeste damals ein echtes Problem: Daten unabhaengig vom Container-Lebenszyklus teilbar zu machen. Seit der Einfuehrung von Named Volumes in Docker 1.9 ist dieses Muster in fast allen Faellen ueberfluessig geworden, weil Named Volumes dieselbe Funktionalitaet direkter, sichtbarer und ohne die Cleanup-Risiken des alten Ansatzes bieten.

Wer heute noch auf ein Data-Only-Container-Pattern in einer produktiven Umgebung stoesst, sollte die Migration zu Named Volumes als Pflichtaufgabe behandeln, nicht als optionales Aufraeumen. Die wenigen verbliebenen Nischen, etwa historisch gewachsene Legacy-Systeme oder init-aehnliche Vorbefuellungslogik, rechtfertigen keine bewusste Neuverwendung des alten Musters in neuen Projekten.

11. FAQ: Data-Only-Container-Pattern