Docker on kenji.blog

Aufbau einer reproduzierbaren lokalen Entwicklungsumgebung mit Docker

Sun, 13 Sep 2026 01:00:00 +0900

1. Einführung: Weg von “Auf meiner Maschine funktioniert es”

In der Softwareentwicklung ist das Problem “Auf meiner Maschine funktioniert es” (It works on my machine), das auf unterschiedliche Umgebungen zwischen Entwicklern zurückzuführen ist, seit langem ein Faktor, der in vielen Projekten Zeit verschwendet. Aufgrund von Unterschieden im Betriebssystem, Versionen installierter Sprachen, Bibliotheksabhängigkeiten und Konflikten zwischen global installierten Tools ist die lokale Umgebung ständig einer “Zustandsunsicherheit” ausgesetzt.

Was diese Probleme von Grund auf löst, sind Container-Technologien wie Docker und das Paradigma von Infrastructure as Code (IaC). Durch die Containerisierung der lokalen Entwicklungsumgebung wird eine Isolierung auf Betriebssystemebene erreicht, was es ermöglicht, die Umgebung selbst zusammen mit der Codebasis zu versionieren.

In diesem Artikel erklären wir ausführlich die Schritte zum Aufbau einer “reproduzierbaren lokalen Entwicklungsumgebung, die immer in exakt demselben Zustand startet, unabhängig davon, wer sie wann und auf welcher Maschine startet”, unter Verwendung von Docker, Docker Compose und VSCode DevContainers. Wir beleuchten auch die tiefgreifenden technischen Mechanismen dahinter, einschließlich einer mathematischen Perspektive.

2. Die Affinität zwischen Infrastructure as Code (IaC) und Container-Technologie

Prinzipien von IaC und deren Anwendung auf lokale Umgebungen

Infrastructure as Code (IaC) ist ein Ansatz zur Verwaltung der Konfiguration und Bereitstellung von Infrastruktur durch maschinenlesbare Definitionsdateien anstelle von manuellen Prozessen. Zu den Kernprinzipien von IaC gehören folgende Elemente:

Deklarativer Ansatz (Declarative Approach): Definiert “wie der Endzustand sein soll”, anstatt “wie der Zustand geändert werden soll”.
Idempotenz (Idempotency): Egal wie oft das Skript ausgeführt wird, es wird immer dasselbe Ergebnis (Zustand) garantiert.
Versionskontrolle (Version Control): Der Zustand der Infrastruktur wird als Code in einem VCS wie Git gespeichert, was die Verfolgung des Änderungsverlaufs und Peer-Reviews ermöglicht.

Die Umsetzung von IaC in einer lokalen Entwicklungsumgebung bedeutet, den “idealen Zustand” der Entwicklungsumgebung mit Dockerfile, docker-compose.yml und devcontainer.json in Code zu fassen. Dadurch wird ein Onboarding-Erlebnis geschaffen, bei dem neue Teammitglieder einfach das Repository klonen und einen einzigen Befehl ausführen können, um sofort mit der Entwicklung zu beginnen.

Kernel-Funktionen, die die Container-Technologie unterstützen

Im Gegensatz zur Hypervisor-basierten Virtualisierung wie bei virtuellen Maschinen (VMs) ist die Container-Technologie eine leichtgewichtige Virtualisierungstechnik, die Prozesse isoliert, während sie den Kernel des Host-Betriebssystems teilt. Um dies zu erreichen, werden hauptsächlich die folgenden Funktionen des Linux-Kernels verwendet:

Namespaces: Bieten eine isolierte Sicht auf Systemressourcen (PID, Netzwerk, Mount-Punkte, Benutzer usw.) für jeden Prozess.
Cgroups (Control Groups): Begrenzen und weisen physische Ressourcen (CPU, Speicher, Festplatten-I/O usw.) zu, die von Prozessen verwendet werden können.
UnionFS (Union File System): Eine Technologie, die mehrere Verzeichnisbäume (Ebenen) transparent überlagert, sodass sie als ein einziges Dateisystem erscheinen. Die Image-Ebenen von Docker basieren auf dieser Technologie.

Betrachten wir ein mathematisches Modell der Ressourcenbegrenzung. Sei $M_{\text{total}}$ die Gesamtspeicherkapazität der Host-Maschine und $m_i$ die Speicherbegrenzung von $n$ Containern, die auf dem Host laufen. Unter Berücksichtigung des Basisspeichers $M_{\text{os}}$, der vom Host-Betriebssystem und anderen Prozessen verbraucht wird, kann die notwendige Bedingung für den stabilen Betrieb des Systems durch folgende Ungleichung ausgedrückt werden:

$$ \sum_{i=1}^{n} m_i \le M_{\text{total}} - M_{\text{os}} $$

Indem $m_i$ für jeden Container mithilfe von Cgroups strikt definiert wird, kann verhindert werden, dass der OOM (Out Of Memory) Killer andere Container oder das gesamte Host-System zum Absturz bringt, selbst wenn ein bestimmter Container ein Speicherleck verursacht.

3. Effizientes Dockerfile-Design: Multi-Stage-Builds meistern

Der erste Schritt zu einer reproduzierbaren Umgebung ist das Design des Dockerfile, das die Ausführungsumgebung der Anwendung definiert. Hier erklären wir am Beispiel von Python (FastAPI) die Best Practices für ein sicheres und leichtgewichtiges Dockerfile unter Verwendung von Multi-Stage-Builds.

Ein Multi-Stage-Build ist eine Technik, die mehrere FROM-Anweisungen in einem einzigen Dockerfile verwendet, um die Build-Umgebung (eine schwere Umgebung, die Compiler und Entwicklungstools enthält) von der Laufzeitumgebung (einer leichtgewichtigen Umgebung, die nur die notwendigen Artefakte enthält) zu trennen.

Praktisches Dockerfile für Python FastAPI

Der folgende Code ist ein Beispiel für ein fortgeschrittenes Dockerfile, das Abhängigkeitsmanagement mit Poetry und Multi-Stage-Builds kombiniert.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52


# ---------------------------------------------------------
# Stage 1: Builder (Build-Umgebung)
# ---------------------------------------------------------
FROM python:3.11-slim AS builder

# Festlegen erforderlicher Umgebungsvariablen
ENV PYTHONUNBUFFERED=1 \
 PYTHONDONTWRITEBYTECODE=1 \
 POETRY_VERSION=1.6.1 \
 POETRY_HOME="/opt/poetry" \
 POETRY_VIRTUALENVS_IN_PROJECT=true \
 POETRY_NO_INTERACTION=1

# Installation von Abhängigkeiten
RUN apt-get update && apt-get install -y --no-install-recommends \
 curl build-essential && \
 curl -sSL https://install.python-poetry.org | python3 - && \
 apt-get clean && rm -rf /var/lib/apt/lists/*

ENV PATH="$POETRY_HOME/bin:$PATH"

WORKDIR /app

# Kopieren und Installieren der Abhängigkeitsdateien
COPY pyproject.toml poetry.lock ./
RUN poetry install --no-root --only main

# ---------------------------------------------------------
# Stage 2: Runtime (Laufzeitumgebung)
# ---------------------------------------------------------
FROM python:3.11-slim AS runtime

ENV PYTHONUNBUFFERED=1 \
 PYTHONDONTWRITEBYTECODE=1 \
 PATH="/app/.venv/bin:$PATH"

# Erstellen eines minimalen, nicht privilegierten Benutzers
RUN groupadd -r appuser && useradd -r -g appuser appuser

WORKDIR /app

# Kopieren nur der virtuellen Umgebung (Abhängigkeiten) vom Builder
COPY --from=builder --chown=appuser:appuser /app/.venv /app/.venv

# Kopieren des Anwendungscodes
COPY --chown=appuser:appuser ./src /app/src

# Wechseln zum nicht privilegierten Benutzer
USER appuser

# Standardbefehl beim Starten des Containers
ENTRYPOINT ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8000"]

Mathematische Bewertung der Image-Größe durch Multi-Stage-Builds

Sei $S_{\text{single}}$ die Image-Größe bei einem Single-Stage-Build und $S_{\text{multi}}$ die Image-Größe bei Anwendung eines Multi-Stage-Builds. Die Reduktionsrate der Größe $R$ wird wie folgt berechnet:

$$ R = \left( 1 - \frac{S_{\text{multi}}}{S_{\text{single}}} \right) \times 100 \ (\%) $$

Angenommen, $S_{\text{single}}$ enthält das Basis-Image des Betriebssystems (ca. 110 MB), Entwicklungspakete (z. B. gcc, ca. 150 MB), Poetry selbst (ca. 40 MB), die Abhängigkeitsbibliotheken des Projekts (ca. 80 MB) und den Quellcode (ca. 5 MB), was insgesamt 385 MB ergibt. Andererseits werden in $S_{\text{multi}}$ nur die Abhängigkeitsbibliotheken (80 MB) und der Quellcode (5 MB) in das Basis-Image (110 MB) kopiert, was insgesamt 195 MB ergibt.

$$ R = \left( 1 - \frac{195}{385} \right) \times 100 \approx 49.35\% $$

Wie gezeigt, kann durch die Einführung von Multi-Stage-Builds die Image-Größe um etwa die Hälfte reduziert werden. Die Reduzierung der Image-Größe führt direkt zu kürzeren Pull-Zeiten aus der Registry, Einsparungen beim Festplattenspeicher und einer Erhöhung der Sicherheit durch Verkleinerung der Angriffsfläche (Attack Surface).

4. Orchestrierung mehrerer Container mit Docker Compose

In der modernen Entwicklung von Webanwendungen ist eine Microservices-Architektur üblich, in der mehrere Komponenten wie Webserver, Datenbanken und Cache-Server zusammenarbeiten. Um diese in einer lokalen Umgebung zentral zu verwalten, wird docker-compose.yml verwendet.

In diesem Fall werden wir ein 3-Schicht-System bestehend aus “Web (FastAPI)”, “Database (PostgreSQL)” und “Cache (Redis)” lokal aufbauen.

Architekturdiagramm (Mermaid)

Das folgende Diagramm ist ein Blockdiagramm, das die Beziehungen zwischen den einzelnen Containern, dem Netzwerk und den Volumes auf dem lokalen Rechner darstellt.

graph TD
User["Host-Maschine (Browser/curl)"] -->|Localhost:8000| Web["FastAPI Web-Container"]
subgraph "Docker Bridge Netzwerk (app-network)"
Web -->|Port 5432| DB["PostgreSQL-Container"]
Web -->|Port 6379| Redis["Redis-Container"]
end
DB --> Volume1["Benanntes Volume (postgres_data)"]
Redis --> Volume2["Benanntes Volume (redis_data)"]
HostDir["Host-Quellcode (./src)"] -.->|Bind Mount| Web

Implementierung und detaillierte Erklärung der docker-compose.yml

Im Folgenden zeigen wir ein Beispiel für eine robuste docker-compose.yml, die für den Aufbau einer praktischen Umgebung geeignet ist.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63


version: '3.8'

services:
 web:
 build:
 context: .
 target: runtime
 container_name: dev_web
 ports:
 - "8000:8000"
 volumes:
 - ./src:/app/src:ro  # Host-Code im schreibgeschützten Modus einhängen (für Hot Reloading)
 environment:
 - DATABASE_URL=postgresql://postgres:${POSTGRES_PASSWORD}@db:5432/${POSTGRES_DB}
 - REDIS_URL=redis://redis:6379/0
 env_file:
 - .env
 depends_on:
 db:
 condition: service_healthy
 redis:
 condition: service_started
 networks:
 - app-network
 command: ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8000", "--reload"]

 db:
 image: postgres:15-alpine
 container_name: dev_db
 ports:
 - "5432:5432"
 environment:
 POSTGRES_USER: postgres
 POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
 POSTGRES_DB: ${POSTGRES_DB}
 volumes:
 - postgres_data:/var/lib/postgresql/data
 networks:
 - app-network
 healthcheck:
 test: ["CMD-SHELL", "pg_isready -U postgres -d ${POSTGRES_DB}"]
 interval: 5s
 timeout: 5s
 retries: 5

 redis:
 image: redis:7-alpine
 container_name: dev_redis
 ports:
 - "6379:6379"
 volumes:
 - redis_data:/data
 networks:
 - app-network
 command: ["redis-server", "--appendonly", "yes"]

volumes:
 postgres_data:
 redis_data:

networks:
 app-network:
 driver: bridge

Volumes und Datenpersistenz

Container sind grundsätzlich “zustandslos (stateless)” und “kurzlebig (ephemeral)”. Wenn ein Container zerstört wird, gehen auch die internen Daten verloren. Um Datenbankdaten oder Caches beizubehalten, muss ein Bereich des Dateisystems der Host-Maschine im Container gemountet werden.

Bind Mount: Das ./src:/app/src:ro im obigen web-Service ist ein Beispiel dafür. Ein bestimmtes Verzeichnis auf dem Host wird direkt in den Container gemappt. Dies wird verwendet, um lokale Code-Änderungen sofort im Container widerzuspiegeln (Hot Reloading). Aus Sicherheitsgründen ist es eine Best Practice, die Option :ro (Read-Only) hinzuzufügen, um zu verhindern, dass der Host-Quellcode vom Container aus geändert wird.
Benanntes Volume (Named Volume): Hierunter fallen postgres_data und redis_data. Es handelt sich um Bereiche, die Docker intern verwaltet (z.B. /var/lib/docker/volumes/). Sie bieten eine bessere I/O-Leistung als Bind Mounts und verbergen die Unterschiede zwischen den Dateisystemen verschiedener Betriebssysteme. Für die Persistenz von Datenbanken sollte immer diese Methode verwendet werden.

Netzwerk (Networking) und Service Discovery

Docker Compose erstellt standardmäßig für jedes Projekt ein eigenes Bridge-Netzwerk, wie das obige app-network. Container, die zum selben Netzwerk gehören, können einander über den “Service-Namen (z. B. db, redis)” als Hostnamen auflösen (DNS-Auflösung) anstatt über IP-Adressen. Zum Beispiel kann der Web-Container über die URL postgresql://postgres:password@db:5432/mydb auf die Datenbank zugreifen. Dies ermöglicht es, das Verbindungsziel transparent über Umgebungsvariablen umzuschalten, sowohl in lokalen Umgebungen als auch in Produktionsumgebungen.

Health Checks und Steuerung der Startreihenfolge

Die Direktive depends_on steuert die Startreihenfolge von Containern, aber wenn Sie nur depends_on angeben, wird der Web-Container gestartet, sobald “der DB-Container gestartet ist”. In der Realität dauert es jedoch einige Sekunden, bis der Initialisierungsprozess der Datenbank (Start des PostgreSQL-Prozesses und Vorbereitung der Tabellen) abgeschlossen ist, was dazu führen kann, dass die DB-Verbindung vom Web-Container aus fehlschlägt. Um dies zu verhindern, kann man einen healthcheck definieren und condition: service_healthy festlegen. Dadurch wird sichergestellt, dass der Web-Container erst gestartet wird, nachdem verifiziert wurde, dass “die Datenbank bereit ist, Verbindungsanfragen anzunehmen”.

5. Verwaltung von Umgebungsvariablen und Sicherheit (.env)

Das Festcodieren sensibler Informationen wie Datenbankpasswörter oder API-Schlüssel in der docker-compose.yml ist ein Anti-Pattern, das unbedingt vermieden werden sollte. Stattdessen verwenden wir eine Umgebungsvariablendatei .env, um diese Werte zu injizieren.

Erstellen Sie eine .env-Datei im Projektstammverzeichnis.

1
2
3
4


# .env Datei (Zur .gitignore hinzufügen, um sie von der Git-Verwaltung auszuschließen)
POSTGRES_PASSWORD=supersecretpassword
POSTGRES_DB=devdb
API_SECRET_KEY=dev_secret_key_12345

Docker Compose liest standardmäßig die .env-Datei im Ausführungsverzeichnis und erweitert die Platzhalter ${VAR_NAME} in der YAML-Datei. Diese Methode ermöglicht es, unterschiedliche Konfigurationswerte für Umgebungen wie lokal, Staging und Produktion sicher zu verwalten, ohne den Infrastrukturcode zu ändern.

6. Das ultimative Entwicklungserlebnis mit VSCode DevContainers

Bis hierhin haben wir eine robuste Backend-Umgebung mit Docker aufgebaut. Wir können jedoch noch einen Schritt weiter gehen. Durch die Nutzung der Funktion VSCode DevContainers (Remote - Containers) ist es möglich, das Backend des Editors (VSCode) selbst innerhalb des Containers auszuführen.

Dadurch müssen weder Python noch Node.js auf der lokalen Maschine installiert werden. Alles, von Lintern (flake8/eslint) und Formattern (black/prettier) bis hin zu IDE-Erweiterungen, kann innerhalb der Codebasis definiert und mit dem gesamten Team geteilt werden.

Konfiguration von devcontainer.json

Erstellen Sie im Projektstammverzeichnis ein .devcontainer-Verzeichnis und platzieren Sie die Konfigurationsdatei darin.

.devcontainer/devcontainer.json:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


{
 "name": "Python FastAPI Dev Environment",
 "dockerComposeFile": ["../docker-compose.yml"],
 "service": "web",
 "workspaceFolder": "/app",
 "customizations": {
 "vscode": {
 "settings": {
 "python.defaultInterpreterPath": "/app/.venv/bin/python",
 "python.formatting.provider": "black",
 "editor.formatOnSave": true
 },
 "extensions": [
 "ms-python.python",
 "ms-python.vscode-pylance",
 "ms-python.black-formatter",
 "tamasfe.even-better-toml"
 ]
 }
 },
 "forwardPorts": [8000, 5432, 6379],
 "remoteUser": "appuser",
 "postCreateCommand": "poetry install"
}

Indem Sie diese Datei in das Repository aufnehmen, wird sofort nach dem Öffnen des Projekts in VSCode die Aufforderung “Reopen in Container” angezeigt. Mit nur einem Klick werden alle notwendigen Container gestartet, Erweiterungen installiert und Sie sind sofort bereit, mit dem Coden zu beginnen. Es ist wahrlich ein magisches Erlebnis.

7. Sequenz der Anforderungsverarbeitung und Leistungsmodellierung

Wir betrachten den Lebenszyklus der Anforderungsverarbeitung der Webanwendung in der aufgebauten lokalen Entwicklungsumgebung anhand eines Sequenzdiagramms und diskutieren ein mathematisches Modell für deren Leistung.

Sequenzdiagramm (Anforderungsfluss)

sequenceDiagram
participant Client as "Browser / VSCode"
participant Web as "FastAPI (Web)"
participant Redis as "Redis Cache"
participant DB as "PostgreSQL"
Client->>Web: "GET /api/users/123"
activate Web
Web->>Redis: "Check Cache for user:123"
activate Redis
alt "Cache Hit (Daten vorhanden)"
Redis-->>Web: "Return Cached User Data"
Web-->>Client: "200 OK (Fast Response)"
else "Cache Miss (Keine Daten)"
Redis-->>Web: "Null (Not Found)"
deactivate Redis
Web->>DB: "SELECT * FROM users WHERE id = 123"
activate DB
DB-->>Web: "Return Database Row"
deactivate DB
Web->>Redis: "SET user:123 Data (TTL: 60s)"
activate Redis
Redis-->>Web: "OK"
deactivate Redis
Web-->>Client: "200 OK (Standard Response)"
end
deactivate Web

Mathematisches Modell der Verarbeitungsverzögerung (Latenz)

Wir modellieren mathematisch die durchschnittliche Anforderungsverarbeitungszeit $T_{\text{total}}$ im obigen System. Wir definieren die Latenz jeder Verarbeitung wie folgt:

$T_{\text{net}}$: Netzwerklatenz zwischen Client und Web-Container
$T_{\text{app}}$: Reine Verarbeitungszeit auf Anwendungsseite (Serialisierung usw.)
$T_{\text{cache}}$: Lese-/Schreibzeit von/nach Redis
$T_{\text{db}}$: Ausführungszeit für Abfragen an PostgreSQL
$p_{\text{miss}}$: Cache-Miss-Rate ($0 \le p_{\text{miss}} \le 1$)

Dann wird die durchschnittliche Antwortzeit durch die folgende Erwartungswertformel dargestellt:

$$ T_{\text{total}} = T_{\text{net}} + T_{\text{app}} + T_{\text{cache}} + p_{\text{miss}} \times (T_{\text{db}} + T_{\text{cache\_write}}) $$

In einer lokalen Entwicklungsumgebung (innerhalb von Docker) liegt $T_{\text{net}}$ nahe bei 0. Beachtenswert ist jedoch die I/O-Leistung bei Bind Mounts. Insbesondere bei der Verwendung von Docker Desktop auf Windows/macOS tendiert $T_{\text{app}}$ (wie z. B. die Zeit zum Laden von Code) dazu, aufgrund des Overhead bei der Dateifreigabe zwischen dem Host-Betriebssystem und der VM (Container) anzusteigen. Um diesen Engpass zu beheben, wird dringend eine Architektur empfohlen, bei der entweder die gesamten Quellcodes in einem benannten Volume mit den zuvor erwähnten DevContainers abgelegt werden oder die Docker-Engine nativ in einer WSL2-Umgebung (Windows Subsystem for Linux 2) ausgeführt wird.

8. Leistungsoptimierung für Docker-Builds: Layer-Cache-Strategie

Beim Schreiben eines Dockerfile ändert sich die Build-Zeit drastisch, je nachdem, ob Sie den Mechanismus des “Layer Caches” verstehen oder nicht. Docker erstellt Dateisystemdifferenzen (Ebenen) für jede Anweisung im Dockerfile (wie FROM, RUN, COPY) und hält sie als Cache bereit. Bei einem erneuten Build wird der Cache der unveränderten Ebenen wiederverwendet.

Ein wichtiges Prinzip lautet: “Schreiben Sie in der Reihenfolge von der geringsten zur höchsten Änderungshäufigkeit.”

Betrachten wir die Modellierung der Auswirkungen von Quellcodeänderungen auf die Build-Zeit. Sei $T_{\text{build}}$ die Gesamt-Build-Zeit, $T_{\text{layer}_i}$ die Ausführungszeit jedes Schritts und das Vorhandensein eines Cache-Treffers der boolesche Wert $c_i \in \{0, 1\}$ (1 bei Cache-Treffer).

$$ T_{\text{build}} = T_{\text{init}} + \sum_{i=1}^{n} (1 - c_i) \times T_{\text{layer}_i} $$

Sobald ein Cache-Miss ($c_k = 0$) in Ebene $k$ auftritt, wird der Cache für alle nachfolgenden Ebenen $j > k$ ungültig ($c_j = 0$).

1
2
3
4


# Schlechtes Beispiel (Quellcode wird zuerst kopiert)
COPY ./src /app/src
COPY pyproject.toml poetry.lock ./
RUN poetry install

In obigem Fall führt das Ändern nur einer Codezeile zu einem Cache-Miss beim ersten COPY, und das zeitaufwändige RUN poetry install wird jedes Mal ausgeführt.

1
2
3
4


# Gutes Beispiel (Abhängigkeiten werden zuerst aufgelöst)
COPY pyproject.toml poetry.lock ./
RUN poetry install
COPY ./src /app/src

Durch diese Schreibweise bleibt der Layer-Cache von poetry install ($c_i = 1$) auch bei Änderung des Quellcodes wirksam, wodurch die Build-Zeit drastisch von einigen Minuten auf wenige Sekunden reduziert wird.

9. Fehlerbehebung (Troubleshooting) und Tipps

Hier sind einige häufige Probleme und Lösungen beim Betrieb einer lokalen Umgebung:

Fehler durch Portkonflikt Wenn ein Fehler wie Bind for 0.0.0.0:8000 failed: port is already allocated auftritt, verwendet ein anderer Prozess auf dem lokalen Rechner diesen Port. Sie können dies vermeiden, indem Sie die hostseitige Portnummer ändern, z. B. auf ports: - "8080:8000".
Erschöpfung des Festplattenspeichers Wenn Sie Docker über einen längeren Zeitraum verwenden, können sich ungenutzte Images und Volumes (Dangling Images / Volumes) ansammeln und zig Gigabyte Festplattenspeicherplatz belegen. Es wird empfohlen, das System regelmäßig mit dem folgenden Befehl zu bereinigen:
1

docker system prune -a --volumes
Probleme mit Dateiberechtigungen Wenn Sie Bind Mounts in einer Linux-Umgebung verwenden, kann der Eigentümer der innerhalb des Containers erstellten Dateien zu root werden, was die Bearbeitung auf der Host-Seite unmöglich macht. Dieses Problem kann gelöst werden, indem ein nicht privilegierter Benutzer im Dockerfile erstellt wird, dessen UID/GID mit der Ihres eigenen Host-Betriebssystems (z. B. 1000:1000) übereinstimmt.

10. Fazit: Steigerung der Entwicklungsgeschwindigkeit durch Reproduzierbarkeit

Durch die Kombination von Docker, Docker Compose und VSCode DevContainers wird eine robuste lokale Entwicklungsumgebung realisiert, bei der “unabhängig davon, wer die Umgebung startet, immer exakt derselbe Zustand erreicht wird”.

Das Einbringen des IaC-Paradigmas in die lokale Umgebung verkürzt nicht nur die anfängliche Einrichtungszeit. Es steigert die Geschwindigkeit und Qualität des gesamten Entwicklungszyklus dramatisch, indem es die Angst vor Änderungen an der Infrastrukturkonfiguration nimmt, das Experimentieren mit neuen Technologie-Stacks erleichtert und einen reibungslosen Übergang zu CI/CD-Pipelines ermöglicht.

Bitte nutzen Sie die in diesem Artikel erläuterten Best Practices, wie z. B. die Optimierung der Image-Größe durch Multi-Stage-Builds, die Steuerung von Abhängigkeiten mithilfe von Health Checks und das Schreiben eines Dockerfiles unter Berücksichtigung des Layer-Caches, und führen Sie unbedingt das beste Entwicklungserlebnis (DX: Developer Experience) in Ihren eigenen Projekten ein.

Der ultimative Leitfaden zur Einrichtung der Entwicklungsumgebung in WSL2 (Windows Subsystem for Linux)

Sat, 12 Sep 2026 23:00:00 +0900

„WSL2 (Windows Subsystem for Linux 2)“, das eine native Linux-Entwicklungsumgebung unter Windows bietet, ist zu einem unverzichtbaren Werkzeug in der modernen Softwareentwicklung geworden. Es gibt jedoch einen himmelweiten Unterschied in Leistung und Entwicklungserfahrung zwischen der weiteren Nutzung im Standardzustand und dem Verständnis der Architektur zur entsprechenden Optimierung.

Dieser Artikel beginnt mit einer Erklärung der Architektur, die das Fundament von WSL2 bildet. Er behandelt ausführlich alle Schritte zum Aufbau der „ultimativen Entwicklungsumgebung“, die professionelle Ingenieure verlangen, einschließlich Konfigurationen zur Maximierung der Leistung, Aufbau einer komfortablen Terminalumgebung, nahtlose Integration mit Docker und VS Code sowie erweiterte Netzwerkeinstellungen, mit einem Umfang von über 10.000 Zeichen.

1. WSL2-Architektur und die Evolution von WSL1

Um das Potenzial von WSL2 voll auszuschöpfen, ist es wichtig, zuerst seine interne Struktur zu verstehen. Das erste WSL (WSL1) und WSL2 unterscheiden sich grundlegend in ihrem Ansatz, Linux-Binärdateien unter Windows auszuführen.

WSL1: Systemcall-Übersetzungsebene

WSL1 verwendete einen Mechanismus zur Übersetzung von Linux-Systemaufrufen in Windows-NT-APIs in Echtzeit. Dies hatte den Vorteil eines sehr geringen Ressourcen-Overheads, da keine virtuelle Maschine (VM) verwendet wurde. Es war jedoch schwierig, komplexe Systemaufrufe wie Dateisystem-I/O-Operationen vollständig zu emulieren. Dies führte zu einer katastrophalen Leistungseinbuße, insbesondere bei der Verarbeitung einer großen Anzahl kleiner Dateien, wie z.B. npm install von Node.js oder Git-Repository-Operationen.

WSL2: Lightweight Utility VM und vollständiger Linux-Kernel

Bei WSL2 wurde die Architektur erneuert, und ein von Microsoft erstellter echter Linux-Kernel läuft jetzt direkt auf einer „Lightweight Utility VM“, die eine Teilmenge der Hyper-V-Architektur nutzt. Dies garantiert 100%ige Kompatibilität von Systemaufrufen, und durch die Verwendung einer virtuellen Festplatte (VHDX) mit dem nativen Linux-Dateisystem ext4 hat sich die Datei-I/O-Leistung im Vergleich zu WSL1 dramatisch verbessert.

Das folgende Mermaid-Diagramm zeigt die strukturellen Unterschiede zwischen WSL1 und WSL2.

flowchart TD
subgraph "Windows OS-Umgebung"
A["Windows NT-Kernel"]
A --> F["NTFS-Dateisystem (C:-Laufwerk)"]
end
subgraph "WSL2-Architektur"
B["Hyper-V-Hypervisor"]
B --> C["Lightweight Utility VM"]
C --> D["Linux-Kernel (Microsoft)"]
D --> E["Ubuntu User Space (glibc, bash usw.)"]
D --> G["Virtuelle ext4-Festplatte (.vhdx)"]
end
A -.->|"Plan 9 (9P) Protocol Network File Share"| D
style B fill:#f9f,stroke:#333,stroke-width:2px
style D fill:#bbf,stroke:#333,stroke-width:2px

Die wichtigste Lektion aus dieser Struktur ist: „Der Zugriff auf Dateien auf der Linux-Seite (innerhalb von VHDX) ist extrem schnell, aber der Zugriff auf Dateien auf der Windows-Seite (/mnt/c/) ist sehr langsam, da er über das 9P-Protokoll erfolgt.“ Der Quellcode für Ihre Projekte muss unter dem Home-Verzeichnis (~) auf der WSL-Seite abgelegt werden.

2. Mathematische Leistungsanalyse: Warum ist WSL2 schnell?

Lassen Sie uns die Leistungssteigerung von WSL2 mithilfe eines mathematischen Modells quantitativ bewerten. Eine der zeitaufwändigsten Operationen in der Softwareentwicklung ist die Verarbeitung, die mit einer großen Menge an Datei-I/O einhergeht (z.B. Bibliotheksinstallation und Build).

Die Gesamtausführungszeit $T_{total}$ eines bestimmten Prozesses wird durch die Summe der CPU-Berechnungszeit $T_{compute}$ und der Festplatten-I/O-Zeit $T_{io}$ ausgedrückt.

$$ T_{total} = T_{compute} + T_{io} $$

Im Fall von WSL1, da ein Overhead für die Konvertierung von Operationen auf der Linux-Seite in NTFS-Operationen entsteht, wird die I/O-Zeit wie folgt modelliert. Hierbei ist $n$ die Anzahl der Dateioperationen, $t_{ntfs\_syscall}$ die Ausführungszeit des Systemaufrufs auf der Windows-Seite und $t_{trans}$ der Overhead der Übersetzungsebene.

$$ T_{wsl1\_io} = \sum_{i=1}^{n} (t_{ntfs\_syscall_i} + t_{trans_i}) $$

Im Fall von WSL2, da der Kernel direkt I/O an das ext4-Dateisystem ausgibt, besteht der Overhead nur aus der sehr geringen Verzögerung $t_{virt}$ durch die Virtualisierung.

$$ T_{wsl2\_io} = \sum_{i=1}^{n} (t_{ext4_i} + t_{virt_i}) $$

In allgemeinen Dateisystemen ist $t_{ext4} \ll t_{ntfs\_syscall} + t_{trans}$. Wenn also $n$ sehr groß ist (Zehntausende bis Hunderttausende von Dateioperationen durchführen), vergrößert sich der Unterschied in der I/O-Zeit zwischen WSL1 und WSL2 exponentiell.

Wenn wir außerdem das Overhead-Verhältnis der CPU-Berechnung in einer virtualisierten Umgebung mit $\rho$ ansetzen, bleibt es bei der neuesten hardwareunterstützten Virtualisierung (Intel VT-x / AMD-V) bei etwa $\rho \approx 0.01 \sim 0.03$ (1-3%). Daher wird selbst bei reinen Rechenaufgaben eine Leistung von $97\% \sim 99\%$ erreicht, was der einer nativen Linux-Umgebung in nichts nachsteht.

3. Installation und Aufbau der Grundlagen

Unter Windows 10/11 ist die Installation von WSL2 sehr einfach geworden. Öffnen Sie einfach PowerShell mit Administratorrechten und führen Sie den folgenden Befehl aus.

1
2
3
4
5
6


# WSL2 und Ubuntu werden standardmäßig installiert
wsl --install

# Wenn Sie eine bestimmte Distribution angeben
# Kann mit wsl --list --online überprüft werden
wsl --install -d Ubuntu-24.04

Nach der Installation und einem Neustart werden Sie beim ersten Start aufgefordert, einen UNIX-Benutzernamen und ein Passwort festzulegen. Dieser Benutzer ist unabhängig von Ihrem Windows-Benutzer und nur innerhalb von WSL gültig.

Wenn Sie bereits WSL1 verwenden, können Sie es mit den folgenden Befehlen in WSL2 konvertieren.

1
2
3
4
5


# Konvertieren Sie die vorhandene Distribution in WSL2
wsl --set-version Ubuntu 2

# Machen Sie WSL2 zur Standardversion für zukünftige Distributionen
wsl --set-default-version 2

4. Das Geheimnis der Ressourcenkontrolle: .wslconfig und wsl.conf

Eine der größten Fallen von WSL2 ist der „unbegrenzte Speicherverbrauch (Aufblähen des Vmmem-Prozesses)“. Da WSL2 den Page Cache des Linux-Kernels verwendet, verbraucht es bei jedem I/O unendlich viel Host-Speicher (Windows). Um dies zu verhindern, ist es zwingend erforderlich, Ressourcen über Konfigurationsdateien zu begrenzen.

Es gibt zwei WSL2-Konfigurationsdateien: .wslconfig, die das gesamte Windows betrifft, und wsl.conf, die das Innere jeder Distribution betrifft.

4.1. .wslconfig (Windows-Seite)

Erstellen Sie eine Datei im Windows-Benutzerprofilverzeichnis (C:\Users\<Benutzername>\.wslconfig), um die Ressourcenzuweisung an die VM zu steuern.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# C:\Users\<Benutzername>\.wslconfig
[wsl2]
# Maximale Speichermenge, die der VM zugewiesen werden soll. Es werden etwa 50% bis 75% des gesamten Host-Speichers empfohlen
memory=16GB

# Anzahl der zu verwendenden CPU-Kerne (alle Kerne werden verwendet, wenn weggelassen)
processors=8

# Größe der Auslagerungsdatei
swap=8GB

# Speicherort der Auslagerungsdatei (wenn Sie Speicherplatz auf dem Laufwerk C sparen möchten)
# swapfile=D:\\wsl\\swap.vhdx

# Aktivieren Sie das Localhost-Forwarding (um auf WSL von der Windows-Seite über localhost zuzugreifen)
localhostForwarding=true

# Speicher automatisch freigeben (nur Windows 11)
# Gibt den Page Cache dynamisch frei und verhindert ein Aufblähen von Vmmem
autoMemoryReclaim=dropcache

[experimental]
# Erweiterte Netzwerkfunktionen für Windows 11 22H2 und neuer
# Dies ermöglicht IPv6-Unterstützung und die gemeinsame Nutzung derselben IP-Adresse zwischen WSL und Windows
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

4.2. wsl.conf (Linux-Seite)

Bearbeiten Sie /etc/wsl.conf in WSL, um das distributionsspezifische Verhalten zu steuern.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# /etc/wsl.conf (In WSL bearbeitet)
[network]
# Deaktivieren Sie die Generierung von /etc/resolv.conf, das beim Start von WSL automatisch generiert wird
# Nützlich, wenn Sie ein eigenes DNS einrichten möchten (z. B. 8.8.8.8)
generateResolvConf=false

# Festlegen eines eigenen Hostnamens
hostname=WSL-DevNode

[automount]
# Einstellungen beim Mounten von Windows-Laufwerken
enabled=true
options="metadata,uid=1000,gid=1000,umask=022"
# Ändern Sie den Mount-Punkt des Laufwerks C von /mnt/c auf /c (verkürzt den Pfad)
root=/

[boot]
# systemd aktivieren (WSL 0.67.6 und neuer)
# Dadurch können snap und verschiedene Daemons (wie Docker) nativ ausgeführt werden
systemd=true

[user]
# Standardmäßig angemeldeter Benutzer
default=kenji

Um diese Einstellungen anzuwenden, müssen Sie wsl --shutdown in PowerShell ausführen, um die WSL-VM vollständig zu stoppen, und sie dann neu starten.

5. Die ultimative Terminal-Umgebung: Zsh + Powerlevel10k

Mit der Standard-Bash allein steigt Ihre Produktivität nicht. Durch die Kombination von Zsh, das sich durch leistungsstarke Vervollständigung und Sichtbarkeit auszeichnet, mit dem ultraschnellen Thema „Powerlevel10k“, bauen wir die stärkste Eingabeaufforderung.

5.1. Installation und Konfiguration von Windows Terminal

Installieren Sie „Windows Terminal“ aus dem Microsoft Store. Öffnen Sie die JSON-Einstellungen (settings.json), legen Sie das Standardprofil auf WSL (Ubuntu) fest und ändern Sie die Schriftart in einen Nerd Font für die Entwicklung (z.B. HackGen Console NF oder MesloLGS NF).

5.2. Zsh und Oh My Zsh installieren

Führen Sie die folgenden Befehle im WSL-Terminal aus.

1
2
3
4
5
6


# Pakete aktualisieren und Zsh installieren
sudo apt update && sudo apt upgrade -y
sudo apt install -y zsh git curl

# Führen Sie das Installationsskript für Oh My Zsh aus
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

5.3. Einführung von Powerlevel10k und Plugins

Wir werden Plugins (Syntax-Hervorhebung und Eingabevervollständigung) und das Powerlevel10k-Thema einführen, um Zsh weiter zu verbessern.

1
2
3
4
5
6
7
8


# Powerlevel10k
git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k

# zsh-autosuggestions
git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

# zsh-syntax-highlighting
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

Bearbeiten Sie ~/.zshrc, um das Thema und die Plugins zu aktivieren.

1
2
3
4
5


# Änderungen an ~/.zshrc
ZSH_THEME="powerlevel10k/powerlevel10k"

# Zum Plugin-Array hinzufügen
plugins=(git zsh-autosuggestions zsh-syntax-highlighting)

Wenn Sie es speichern und source ~/.zshrc ausführen, wird der Powerlevel10k-Konfigurationsassistent (p10k configure) gestartet. Folgen Sie den Anweisungen auf dem Bildschirm, um Ihre bevorzugte Eingabeaufforderung (Eingabeaufforderungsstil, ob Symbole vorhanden sind, anzuzeigende Informationen usw.) anzupassen. Der Git-Zweigname und -Status, die Node.js-Version, die Ausführungszeit von Befehlen usw. werden in Echtzeit angezeigt, wodurch die Entwicklungseffizienz drastisch verbessert wird.

6. VS Code Remote - Nahtlose Integration mit WSL

Für die Entwicklung auf WSL2 gibt es eine „Remote - WSL“-Erweiterung, die Ihnen den nahtlosen Zugriff auf Dateien innerhalb von WSL von der auf der Windows-Seite installierten IDE (Visual Studio Code) ermöglicht.

Erklärung der Architektur

Das folgende Sequenzdiagramm zeigt, wie VS Code mit WSL2 kommuniziert.

sequenceDiagram
autonumber
participant U as "Entwickler"
participant V as "VS Code UI (Windows)"
participant S as "VS Code Server (WSL2)"
participant F as "ext4-Dateisystem (WSL2)"
U->>V: "Geben Sie `code .` in WSL Terminal ein"
V->>S: "Aufbau einer RPC-Verbindung über Vsock"
Note over V,S: Kommunikation über Hyper-V-Sockets ohne TCP/IP
S->>F: "Quelldateien lesen / Linter ausführen"
F-->>S: "Daten & Analyse zurückgeben"
S-->>V: "Language Server-Ergebnisse an UI streamen"
V-->>U: "Syntax-Highlighting & Fehler anzeigen"

Der VS Code auf der Windows-Seite fungiert als reiner „Thin Client (UI)“, und rechenintensive Aufgaben wie der Language Server, der Debugger und die Terminal-Ausführung werden alle vom „VS Code Server“ auf der WSL-Seite erledigt. Auf diese Weise können Sie die Umgebung auf der WSL-Seite sauber halten, ohne Node.js oder Python auf der Windows-Seite zu installieren.

Wesentliche VS Code-Einstellungen

Installieren Sie “WSL” (ms-vscode-remote.remote-wsl) aus den “Erweiterungen” von VS Code. Navigieren Sie dann im WSL-Terminal zum Projektverzeichnis und führen Sie einfach code . aus, um den VS Code auf der Windows-Seite mit dem geöffneten Verzeichnis zu starten.

Wichtiger Hinweis (Problem mit dem Zeilenumbruchcode): Windows und Linux haben unterschiedliche Zeilenumbruchcodes (Windows verwendet CRLF, Linux verwendet LF). Bei der Entwicklung in WSL stellen Sie bitte sicher, dass die Git-Einstellung core.autocrlf und die Standarddateieinstellungen von VS Code auf LF vereinheitlicht werden. Wenn Sie dies versäumen, werden Sie von mysteriösen Fehlern bei der Ausführung von Shell-Skripten oder Docker-Containern geplagt.

1
2


# Git-Zeilenumbruchcode-Einstellung auf der WSL-Seite
git config --global core.autocrlf input

Fügen Sie der settings.json (Remote-Einstellung) von VS Code auch Folgendes hinzu:

1
2
3
4


{
 "files.eol": "\n",
 "terminal.integrated.defaultProfile.linux": "zsh"
}

7. Optimierung von Docker Desktop und WSL2 Integration

Es gibt hauptsächlich zwei Ansätze zur Verwendung von Docker in einer WSL2-Umgebung.

Installieren Sie Docker Desktop für Windows und aktivieren Sie die WSL2-Integrationsfunktion
Installieren Sie die native Docker Engine direkt innerhalb von WSL2 (z. B. Ubuntu)

Ansatz 1: Docker Desktop (Empfohlen)

Dies wird in den meisten Fällen empfohlen, da es ein einfaches Management mit einer GUI und einen transparenten Zugriff auf Container zwischen Windows und WSL ermöglicht. Überprüfen Sie Folgendes in den Einstellungen von Docker Desktop (Settings).

Aktivieren Sie General -> Use the WSL 2 based engine.
Aktivieren Sie Resources -> WSL Integration -> Enable integration with my default WSL distro und aktivieren Sie die zu verwendende Distribution (Ubuntu) mit der Umschaltfläche.

Dies ermöglicht es Ihnen, den docker-Befehl direkt aus dem WSL2-Terminal auszuführen, und die Kommunikation mit dem Docker-Daemon erfolgt über dedizierte Lightweight-VMs (docker-desktop und docker-desktop-data), die von Docker Desktop verwaltet werden.

Ansatz 2: Direkte Installation der nativen Docker Engine

Wenn Sie Unternehmensnetzwerkeinschränkungen haben (z. B. um die Kosten für Docker Desktop zu vermeiden) oder den Leistungs-Overhead so weit wie möglich reduzieren möchten, aktivieren Sie systemd in /etc/wsl.conf und installieren Sie Docker als reinen Ubuntu-Server.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# Auszug aus dem offiziellen Docker-Installationsverfahren auf WSL2 Ubuntu mit aktiviertem systemd
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Repository hinzufügen
echo \
 "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
 "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
 sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Fügen Sie den aktuellen Benutzer zur docker-Gruppe hinzu (um ohne sudo auszuführen)
sudo usermod -aG docker $USER

Nach dem Neustart funktioniert systemctl start docker genau wie in einer nativen Linux-Umgebung und bietet hohe Leistung.

8. Integration von SSH-Schlüsseln: Nahtlose Authentifizierung in Windows und WSL

Bei der Durchführung von SSH-Klonen in Git oder Verbindungen zu Remote-Servern über SSH ist es sehr mühsam, separate SSH-Schlüssel auf der Windows- und der WSL-Seite zu verwalten. Um Sicherheit und Komfort in Einklang zu bringen, richten wir eine Brücke vom auf der Windows-Seite laufenden SSH-Agenten (oder einem Passwort-Manager wie 1Password) zur WSL-Seite ein.

Hier erklären wir die sicherste und modernste Methode, den SSH-Agenten von 1Password oder den OpenSSH Authentication Agent von Windows zu verwenden und ihn mithilfe von npiperelay oder socat an den UNIX-Domain-Socket von WSL2 weiterzuleiten.

ssh-agent Socket-Weiterleitung

Normalerweise muss der als Named Pipe (benannte Pipe) in Windows bereitgestellte SSH-Agent in eine Socket-Datei auf der WSL-Seite konvertiert werden. Dies lässt sich mithilfe von wsl-ssh-agent oder Funktionen von 1Password leicht erreichen.

Aktivieren Sie im Einstellungsbildschirm von 1Password “Entwickler” -> “SSH-Agenten verwenden”. Fügen Sie als Nächstes die folgenden Einstellungen zur ~/.zshrc oder ~/.bashrc auf der WSL-Seite hinzu, um den Socket bei der Anmeldung automatisch zu binden.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Zu ~/.zshrc hinzufügen (Beispiel für die Verwendung des 1Password SSH Agent)
export SSH_AUTH_SOCK=$HOME/.ssh/agent.sock
# Wenn der Socket beim Start von WSL nicht existiert oder der Prozess nicht gebunden ist, mit socat und npiperelay weiterleiten
ALREADY_RUNNING=$(ps -aux | grep "[n]piperelay.exe -ei -s //./pipe/openssh-ssh-agent" | wc -l)
if [ $ALREADY_RUNNING -eq 0 ]; then
 if [ -S $SSH_AUTH_SOCK ]; then
 rm $SSH_AUTH_SOCK
 fi
 # Starten Sie socat im Hintergrund und verbinden Sie die Named Pipe auf der Windows-Seite mit dem UNIX-Socket auf der WSL-Seite
 (setsid socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork EXEC:"npiperelay.exe -ei -s //./pipe/openssh-ssh-agent",nofork &) >/dev/null 2>&1
fi

*Vorab müssen Sie npiperelay.exe auf der Windows-Seite installieren und den Pfad konfigurieren.

Nach Abschluss dieser Konfiguration wird bei Ausführung von ssh-add -l aus dem WSL-Terminal eine Liste der öffentlichen Schlüssel von SSH-Schlüsseln angezeigt, die in 1Password oder auf der Windows-Seite registriert sind. Auf diese Weise können Sie sich sicher authentifizieren, ohne die private Schlüsseldatei nach WSL kopieren zu müssen.

9. Wartung: Optimierung (Komprimierung) von aufgeblähten VHDX

Einer der größten Nachteile von WSL2 ist die Tatsache, dass die Dateigröße der virtuellen Festplatte (.vhdx) auf der Windows-Seite nicht automatisch reduziert wird, selbst wenn Sie Docker-Images oder Dateien löschen. Wenn Sie lange Zeit weiterentwickeln, bläht sich die Datei ext4.vhdx auf Dutzende bis Hunderte von GB auf.

Um Speicherplatz freizugeben, müssen Sie VHDX regelmäßig von der Windows-Seite aus optimieren (komprimieren).

Schalten Sie zunächst WSL vollständig aus.
1

wsl --shutdown
Öffnen Sie PowerShell mit Administratorrechten und führen Sie den folgenden Befehl diskpart oder den Befehl Optimize-VHD des Hyper-V-Moduls aus (letzteres kann nur verwendet werden, wenn Hyper-V aktiviert ist).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Wenn das Hyper-V-Modul verfügbar ist
Optimize-VHD -Path "$env:LOCALAPPDATA\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx" -Mode Full

# Wenn Sie diskpart verwenden
diskpart
# Geben Sie interaktiv innerhalb des folgenden Prompts ein
DISKPART> select vdisk file="C:\Users\<Benutzername>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx"
DISKPART> attach vdisk readonly
DISKPART> compact vdisk
DISKPART> detach vdisk
DISKPART> exit

Wenn Sie diesen Vorgang regelmäßig durchführen, können Sie die auf Laufwerk C verschwendete Kapazität zurückgewinnen.

10. Fazit

WSL2 hat den Rahmen eines bloßen „Zusatz-Linux, das unter Windows läuft“ komplett überschritten und sich zu einer leistungsstarken Entwicklungsplattform entwickelt, die einer MacOS- oder nativen Linux-Maschine in nichts nachsteht oder diese sogar übertrifft.

Durch die Anwendung aller hier erläuterten Einstellungen (Ressourcenoptimierung durch .wslconfig, Terminalerweiterung durch Zsh + Powerlevel10k, transparenter Zugriff durch VS Code Remote sowie SSH-Integration und VHDX-Wartung) wird eine stressfreie, schnelle und sichere „ultimative Entwicklungsumgebung“ vervollständigt.

Der Aufbau der Umgebung erfordert zwar etwas Aufwand, aber wenn Sie die Einstellungen einmal festgelegt haben, wird sich Ihre zukünftige Engineering-Produktivität zweifellos dramatisch verbessern. Erkunden Sie gerne weitere Anpassungen basierend auf diesem Leitfaden, um sie an Ihre eigenen Projekte und Vorlieben anzupassen.