Begriff

Bind Mount

Containerization Docker S2

2 Quellen 1 Lernpfad 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Container sind standardmäßig isoliert. Sie sehen deine Festplatte nicht. Manchmal willst du aber eine Datei von deinem PC in den Container spiegeln. Zum Beispiel: Du entwickelst eine Webseite. Der Webserver läuft im Container. Der Code liegt auf deinem Desktop. Ein Bind Mount bohrt ein Loch in den Container und "bindet" einen Ordner von deinem Host-PC an einen Ordner im Container. Wenn du auf dem PC die Datei änderst, sieht der Container sofort die Änderung. Es ist wie ein magisches Fenster zwischen zwei Welten.

Merksatz: Eine Methode in Docker, um eine Datei oder ein Verzeichnis vom Host-System direkt in einen Container einzublenden (zu mounten), wobei Änderungen auf beiden Seiten sofort wirksam sind.

Beim Starten des Containers: docker run -v /home/user/projekt:/app nginx

/home/user/projekt: Pfad auf deinem PC (Host).
/app: Pfad im Container. Der Inhalt von /app wird überdeckt durch den Inhalt deines Projekts.

In Docker Compose (Standard für Entwicklung):

services:
  web:
    image: nginx
    volumes:
      - ./html:/usr/share/nginx/html

Sobald du index.html speicherst, reloadet der Browser (Live Reload).

Praxisroutine

In der Praxis lernst du Bind Mount, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Performance & Filesystem Events

Bind Mounts sind langsam, besonders auf Mac/Windows. Docker läuft dort in einer VM (Linux). Jede Dateiänderung muss über die Grenze (Hypervisor) synchronisiert werden (VirtioFS, gRPC FUSE). Bei 10.000 Dateien (z. B. node_modules) wird npm install extrem langsam. Lösung: Named Volumes für node_modules nutzen (Hack: "Volume Trick"), damit diese nicht synchronisiert werden.

2. Permissions (Die Hölle)

Auf Linux haben Dateien User-IDs (UID 1000). Im Container läuft der Prozess oft als Root (UID 0). Wenn der Container eine Datei schreibt, gehört sie plötzlich root auf deinem Host-PC. Du kannst sie nicht mehr löschen (Permission Denied). Lösung: User-Remapping (user: "${UID}:${GID}" in Compose) oder Podman (Rootless Containers).

3. Security Implication

Bind Mounts erlauben dem Container Zugriff auf den Host. Wenn du -v /:/host mountest, kann der Container dein ganzes Betriebssystem löschen. In Production sind Bind Mounts daher oft verboten (Security Risk). Man nutzt dort Docker Volumes (verwaltet von Docker, liegen sicher in /var/lib/docker).

VirtioFS und gRPC FUSE (Mac & Windows)

Unter Linux ist ein Bind Mount trivial: Cgroups und Namespaces mappen den Inode auf dem Host direkt in den Container. Fast null Overhead. Auf macOS und Windows läuft Docker aber in einer leichtgewichtigen Linux-VM. Ein Bind Mount muss also die Grenze von macOS-Dateisystem (APFS) zu Linux (ext4) überwinden. Früher nutzte Docker dafür osxfs, was bei vielen kleinen Dateien (node_modules) extrem langsam war. Heute nutzt es gRPC FUSE oder (noch neuer) VirtioFS. VirtioFS teilt den Host-Speicher auf Page-Ebene (Shared Memory) mit der VM, anstatt ihn über ein Netzwerkprotokoll zu synchronisieren. Das beschleunigt I/O-Heavy Server-Setups (wie PHP Symfony oder Ruby on Rails) dramatisch.

Das UID/GID Mapping Problem

Das größte Frustpotenzial auf Linux. Wenn du einen Host-Ordner ~/projekt bind-mountest und der Container läuft intern als User root (UID 0), dann haben alle von ihm erstellten Logs und Dateien auf deinem Host-PC plötzlich root-Rechte. Mit sudo chown ... reparierst du das ständig. Die Profi-Lösung: User Namespaces. Docker mappt den internen root User (UID 0) auf eine ungefährliche, ungenutzte High-Number-UID auf dem Host (z.B. User 100000). Das bedeutet, der Container glaubt, er sei Root (darf also Pakete installieren), hat aber auf dem Host-System absolut keine Rechte. Dieses Feature ist essenziell für echte Multi-Tenant-Sicherheit, muss in der Docker-Daemon-Konfiguration aber hart aktiviert werden (userns-remap).

SELinux Contexts (`:Z` und `:z`)

Auf Systemen wie RHEL oder Fedora ist SELinux standardmäßig aktiv. Wenn du $ docker run -v /var/data:/data postgres ausführst, wird PostgreSQL crashen. SELinux verbietet dem Container den Zugriff auf den container_file_t Kontext. Der Trick: Du musst das Suffix :Z (großes Z) anhängen. docker run -v /var/data:/data:Z postgres. Docker weist SELinux an, den Security-Kontext des Ordners /var/data umzuschreiben, sodass ihn genau dieser Container (Private, unshared) nutzen darf. Ein kleines :z würde es als "shared" deklarieren, sodass mehrere Container ihn gleichzeitig nutzen können.

Quick-Check

Unterschied zu Volume?
Volume: Docker verwaltet den Speicherort (Blackbox). Bind Mount: Du bestimmst den Pfad (C:\Users\...). Volumes sind performanter und portabler. Bind Mounts sind bequemer für Entwicklung (Live-Edit).
Was passiert, wenn der Host-Pfad nicht existiert?
Docker erstellt ihn automatisch als leeren Ordner (und zwar als Root). Das führt oft zu Verwirrung ("Warum ist mein Config-File ein Ordner?").
Read-Only Mount?
Ja, -v ./config:/etc/config:ro. Der Container kann lesen, aber nicht schreiben. Gute Praxis für Konfigurationsdateien.