Entwicklung in einem Container

Die Erweiterung Visual Studio Code Dev Containers ermöglicht die Verwendung eines Containers als vollwertige Entwicklungsumgebung. Sie können jeden beliebigen Ordner innerhalb eines Containers (oder in einen Container eingebunden) öffnen und die volle Funktionalität von Visual Studio Code nutzen. Eine devcontainer.json-Datei in Ihrem Projekt teilt VS Code mit, wie auf einen Entwicklungscontainer mit einem klar definierten Tool- und Runtime-Stack zugegriffen (oder wie dieser erstellt) werden kann. Dieser Container kann zum Ausführen einer Anwendung oder zur Trennung von Tools, Bibliotheken oder Runtimes, die für die Arbeit mit einer Codebasis benötigt werden, verwendet werden.

Arbeitsbereichsdateien werden vom lokalen Dateisystem eingebunden oder in den Container kopiert bzw. geklont. Erweiterungen werden im Container installiert und ausgeführt, wo sie vollen Zugriff auf die Tools, die Plattform und das Dateisystem haben. Das bedeutet, dass Sie Ihre gesamte Entwicklungsumgebung nahtlos wechseln können, indem Sie sich einfach mit einem anderen Container verbinden.

Dies ermöglicht es VS Code, eine lokalwertige Entwicklungserfahrung bereitzustellen, einschließlich vollständiger IntelliSense (Vervollständigungen), Code-Navigation und Debugging, unabhängig davon, wo sich Ihre Tools (oder Ihr Code) befinden.

Die Dev Containers-Erweiterung unterstützt zwei primäre Betriebsmodelle

• Sie können einen Container als Ihre Vollzeit-Entwicklungsumgebung nutzen
• Sie können eine Verbindung zu einem laufenden Container herstellen, um ihn zu inspizieren.

Hinweis: Die Dev Containers-Erweiterung unterstützt die offene Dev Containers-Spezifikation, die es jedem Benutzer in jedem Tool ermöglicht, eine konsistente Entwicklungsumgebung zu konfigurieren. Weitere Informationen finden Sie in unseren Dev Container FAQ und auf der Website der Spezifikation containers.dev.

Erste Schritte

Hinweis: Im einführenden Dev Containers Tutorial erfahren Sie, wie Sie schnell mit Dev Containern loslegen können.

Systemanforderungen

Lokaler / Remote-Host

Sie können Docker auf verschiedene Arten mit der Dev Containers-Erweiterung verwenden, darunter

• Lokal installiertes Docker.
• Docker, das in einer Remote-Umgebung installiert ist.
• Andere Docker-konforme CLIs, die lokal oder remote installiert sind.
  • Obwohl andere CLIs funktionieren mögen, werden sie nicht offiziell unterstützt. Beachten Sie, dass für das Herstellen einer Verbindung zu einem Kubernetes-Cluster lediglich eine korrekt konfigurierte kubectl CLI erforderlich ist.

Weitere Informationen finden Sie im Dokument zu alternativen Docker-Optionen.

Nachfolgend finden Sie einige spezifische Möglichkeiten, wie Sie Docker auf einem lokalen oder Remote-Host konfigurieren können

• Windows: Docker Desktop 2.0+ unter Windows 10 Pro/Enterprise. Windows 10 Home (2004+) erfordert Docker Desktop 2.3+ und das WSL 2-Backend. (Docker Toolbox wird nicht unterstützt. Windows-Container-Images werden nicht unterstützt.)
• macOS: Docker Desktop 2.0+.
• Linux: Docker CE/EE 18.06+ und Docker Compose 1.21+. (Das Ubuntu-Snap-Paket wird nicht unterstützt.)
• Remote-Hosts: 1 GB RAM wird benötigt, aber mindestens 2 GB RAM und eine 2-Kern-CPU werden empfohlen.

Container:

• x86_64 / ARMv7l (AArch32) / ARMv8l (AArch64) Debian 9+, Ubuntu 16.04+, CentOS / RHEL 7+
• x86_64 Alpine Linux 3.9+

Andere glibc-basierte Linux-Container funktionieren möglicherweise, wenn sie die erforderlichen Linux-Voraussetzungen haben.

Installation

Um loszulegen, folgen Sie diesen Schritten

1. Installieren und konfigurieren Sie Docker für Ihr Betriebssystem, indem Sie einen der unten aufgeführten Wege oder eine alternative Docker-Option verwenden, wie z. B. Docker auf einem Remote-Host oder eine Docker-konforme CLI.

   Windows / macOS:

   1. Installieren Sie Docker Desktop für Windows/Mac.

   2. Wenn Sie WSL 2 unter Windows verwenden, stellen Sie sicher, dass das WSL 2-Backend aktiviert ist: Klicken Sie mit der rechten Maustaste auf das Docker-Taskleistensymbol und wählen Sie Einstellungen. Aktivieren Sie Das WSL 2-basierte Engine verwenden und vergewissern Sie sich, dass Ihre Distribution unter Ressourcen > WSL-Integration aktiviert ist.

   3. Wenn Sie nicht das WSL 2-Backend verwenden, klicken Sie mit der rechten Maustaste auf das Docker-Taskleistensymbol, wählen Sie Einstellungen und aktualisieren Sie Ressourcen > Dateifreigabe mit allen Speicherorten, an denen Ihr Quellcode gespeichert ist. Weitere Informationen zur Fehlerbehebung finden Sie unter Tipps und Tricks.

   Linux:

   1. Folgen Sie den offiziellen Installationsanweisungen für Docker CE/EE für Ihre Distribution. Wenn Sie Docker Compose verwenden, folgen Sie auch den Docker Compose-Anweisungen.

   2. Fügen Sie Ihren Benutzer zur docker-Gruppe hinzu, indem Sie ein Terminal verwenden, um Folgendes auszuführen: sudo usermod -aG docker $USER

   3. Melden Sie sich ab und wieder an, damit Ihre Änderungen wirksam werden.

2. Installieren Sie Visual Studio Code oder Visual Studio Code Insiders.

3. Installieren Sie die Dev Containers-Erweiterung. Wenn Sie mit anderen Remote-Erweiterungen in VS Code arbeiten möchten, können Sie das Remote Development-Erweiterungspaket installieren.

Arbeiten mit Git?

Hier sind zwei Tipps, die Sie beachten sollten

• Wenn Sie dasselbe Repository sowohl lokal unter Windows als auch innerhalb eines Containers bearbeiten, stellen Sie sicher, dass Sie konsistente Zeilenenden einrichten. Einzelheiten finden Sie unter Tipps und Tricks.
• Wenn Sie mit einem Git-Credential-Manager klonen, sollte Ihr Container bereits Zugriff auf Ihre Anmeldeinformationen haben! Wenn Sie SSH-Schlüssel verwenden, können Sie diese ebenfalls teilen. Weitere Einzelheiten finden Sie unter Freigabe von Git-Anmeldeinformationen mit Ihrem Container.

Wählen Sie Ihren Schnellstart

Dieses Dokument enthält 3 Schnellstarts – wir empfehlen, mit demjenigen zu beginnen, der am besten zu Ihrem Workflow und Ihren Interessen passt

1. Möchten Sie einen Dev Container in einem schnellen Beispiel-Repository ausprobieren? Sehen Sie sich Schnellstart 1: Entwicklung mit einem Container ausprobieren an.
2. Möchten Sie einem Ihrer vorhandenen, lokal geklonten Projekte einen Dev Container hinzufügen? Sehen Sie sich Schnellstart 2: Einen vorhandenen Ordner in einem Container öffnen an.
3. Möchten Sie mit einer isolierten Kopie eines Repositorys arbeiten, z. B. um einen PR zu überprüfen oder einen Branch zu untersuchen, ohne Ihre lokalen Arbeiten zu beeinträchtigen? Sehen Sie sich Schnellstart 3: Ein Git-Repository oder einen GitHub PR in einem isolierten Container-Volume öffnen an.

Schnellstart: Entwicklung mit einem Container ausprobieren

Der einfachste Weg, um loszulegen, ist, einen der Beispiel-Entwicklungscenter auszuprobieren. Das Container-Tutorial führt Sie durch die Einrichtung von Docker und der Dev Containers-Erweiterung und ermöglicht Ihnen die Auswahl eines Beispiels

Hinweis: Wenn Sie bereits VS Code und Docker installiert haben, können Sie im Dev Container öffnen. Weitere Informationen hierzu und wie Sie dies zu Ihren Repos hinzufügen können, finden Sie im Leitfaden zum Erstellen eines Dev Containers.

Schnellstart: Einen vorhandenen Ordner in einem Container öffnen

Dieser Schnellstart beschreibt, wie Sie einen Dev Container für ein bestehendes Projekt einrichten, das Sie als Vollzeit-Entwicklungsumgebung mit vorhandenem Quellcode auf Ihrem Dateisystem verwenden möchten. Befolgen Sie diese Schritte

1. Starten Sie VS Code, führen Sie den Befehl Dev Containers: Ordner im Container öffnen... aus der Befehlspalette (F1) oder über die Schnellaktionen auf der Statusleiste aus und wählen Sie den Projektordner aus, für den Sie den Container einrichten möchten.

   Tipp: Wenn Sie den Inhalt oder die Einstellungen des Containers vor dem Öffnen des Ordners bearbeiten möchten, können Sie stattdessen Dev Containers: Konfigurationsdateien für Dev Container hinzufügen... ausführen.

   

2. Wählen Sie nun einen Ausgangspunkt für Ihren Dev Container. Sie können entweder eine vordefinierte Dev Container-Vorlage aus einer filterbaren Liste auswählen oder eine vorhandene Dockerfile oder Docker Compose-Datei verwenden, falls eine im ausgewählten Ordner vorhanden ist.

   Hinweis: Bei der Verwendung von Alpine Linux-Containern funktionieren einige Erweiterungen aufgrund von glibc-Abhängigkeiten im nativen Code der Erweiterung möglicherweise nicht.

   

   Die Liste wird automatisch basierend auf dem Inhalt des von Ihnen geöffneten Ordners sortiert.

   Sie können Ihren Dev Container möglicherweise mit zusätzlichen Features anpassen, über die Sie weiter unten mehr erfahren.

   Die angezeigten Dev Container-Vorlagen stammen aus unserem Index von First-Party- und Community-Vorlagen, der Teil der Dev Container-Spezifikation ist. Wir hosten eine Reihe von Vorlagen als Teil der Spezifikation im devcontainers/templates-Repository. Sie können den src-Ordner dieses Repositorys durchsuchen, um den Inhalt jeder Vorlage zu sehen.

   Sie können Ihre eigenen Dev Container-Vorlagen auch über die Dev Container CLI veröffentlichen und verteilen.

3. Nachdem Sie den Ausgangspunkt für Ihren Container ausgewählt haben, fügt VS Code die Dev Container-Konfigurationsdateien zu Ihrem Projekt hinzu (.devcontainer/devcontainer.json).

4. Das VS Code-Fenster wird neu geladen und beginnt mit dem Erstellen des Dev Containers. Eine Benachrichtigung über den Fortschritt liefert Statusaktualisierungen. Sie müssen einen Dev Container nur einmal beim ersten Öffnen erstellen. Das Öffnen des Ordners nach dem ersten erfolgreichen Erstellen erfolgt viel schneller.

   

5. Nach Abschluss des Erstellvorgangs stellt VS Code automatisch eine Verbindung zum Container her.

Sie können nun mit Ihrem Projekt in VS Code interagieren, genau wie Sie es beim lokalen Öffnen des Projekts tun würden. Von nun an wird VS Code bei jedem Öffnen des Projektordners automatisch Ihre Dev Container-Konfiguration erkennen und wiederverwenden.

Tipp: Möchten Sie einen Remote-Docker-Host verwenden? Informationen hierzu finden Sie im Abschnitt Ordner auf einem Remote-SSH-Host in einem Container öffnen.

Während die Verwendung dieses Ansatzes zum Bind-Mount des lokalen Dateisystems in einen Container bequem ist, hat er unter Windows und macOS einige Leistungseinbußen. Es gibt einige Techniken, die Sie anwenden können, um die Festplattenleistung zu verbessern, oder Sie können stattdessen ein Repository in einem Container mit einem isolierten Container-Volume öffnen.

Einen WSL 2-Ordner unter Windows in einem Container öffnen

Wenn Sie das Windows Subsystem for Linux v2 (WSL 2) verwenden und das WSL 2-Backend von Docker Desktop aktiviert haben, können Sie mit Quellcode arbeiten, der innerhalb von WSL gespeichert ist!

Sobald die WSL 2-Engine aktiviert ist, können Sie entweder

• Verwenden Sie den Befehl Dev Containers: Im Container neu öffnen aus einem Ordner, der bereits mit der WSL-Erweiterung geöffnet wurde.
• Wählen Sie Dev Containers: Ordner im Container öffnen... aus der Befehlspalette (F1) und wählen Sie einen WSL-Ordner über die lokale \\wsl$-Freigabe (von der Windows-Seite) aus.

Der Rest des Schnellstarts gilt unverändert! Weitere Informationen zur WSL-Erweiterung finden Sie in deren Dokumentation.

Einen Ordner auf einem Remote-SSH-Host in einem Container öffnen

Wenn Sie einen Linux- oder macOS-SSH-Host verwenden, können Sie die Erweiterungen Remote - SSH und Dev Containers zusammen verwenden. Sie benötigen nicht einmal einen Docker-Client lokal installiert.

Um dies zu tun

1. Befolgen Sie die Installationsschritte und die Host-Einrichtungsschritte für die Remote - SSH-Erweiterung.
2. Optional: Richten Sie eine SSH- schlüsselbasierte Authentifizierung zum Server ein, damit Sie Ihr Passwort nicht mehrmals eingeben müssen.
3. Installieren Sie Docker auf Ihrem SSH-Host. Sie müssen Docker nicht lokal installieren.
4. Befolgen Sie den Schnellstart für die Remote - SSH-Erweiterung, um eine Verbindung zu einem Host herzustellen und dort einen Ordner zu öffnen.
5. Verwenden Sie den Befehl Dev Containers: In Container neu öffnen aus der Befehlspalette (F1, ⇧⌘P (Windows, Linux Ctrl+Shift+P)).

Der Rest des Dev Containers-Schnellstarts gilt unverändert. Weitere Informationen zur Remote - SSH-Erweiterung finden Sie in deren Dokumentation. Sie können auch den Artikel Entwicklung auf einem Remote-Docker-Host lesen, wenn dieses Modell nicht Ihren Anforderungen entspricht.

Einen Ordner auf einem Remote-Tunnel-Host in einem Container öffnen

Sie können die Erweiterungen Remote - Tunnels und Dev Containers zusammen verwenden, um einen Ordner auf Ihrem Remote-Host in einem Container zu öffnen. Sie benötigen nicht einmal einen Docker-Client lokal installiert. Dies ähnelt dem Szenario mit dem SSH-Host, verwendet aber stattdessen Remote - Tunnels.

Um dies zu tun

1. Befolgen Sie die Anweisungen unter Erste Schritte für die Remote - Tunnels-Erweiterung.
2. Installieren Sie Docker auf Ihrem Tunnel-Host. Sie müssen Docker nicht lokal installieren.
3. Befolgen Sie die Schritte für die Remote - Tunnels-Erweiterung, um eine Verbindung zu einem Tunnel-Host herzustellen und dort einen Ordner zu öffnen.
4. Verwenden Sie den Befehl Dev Containers: In Container neu öffnen aus der Befehlspalette (F1, ⇧⌘P (Windows, Linux Ctrl+Shift+P)).

Der Rest des Dev Containers-Schnellstarts gilt unverändert. Weitere Informationen zur Remote - Tunnels-Erweiterung finden Sie in deren Dokumentation. Sie können auch den Artikel Entwicklung auf einem Remote-Docker-Host lesen, wenn dieses Modell nicht Ihren Anforderungen entspricht.

Einen vorhandenen Arbeitsbereich in einem Container öffnen

Sie können auch einen ähnlichen Prozess verwenden, um einen VS Code Multi-Root-Arbeitsbereich in einem einzelnen Container zu öffnen, wenn der Arbeitsbereich nur relative Pfade zu Unterordnern des Ordners verweist, in dem sich die .code-workspace-Datei befindet (oder des Ordners selbst).

Sie können entweder

• Verwenden Sie den Befehl Dev Containers: Arbeitsbereich im Container öffnen....
• Verwenden Sie Datei > Arbeitsbereich öffnen..., sobald Sie einen Ordner geöffnet haben, der eine .code-workspace-Datei in einem Container enthält.

Nach der Verbindung möchten Sie möglicherweise den .devcontainer-Ordner zum Arbeitsbereich hinzufügen, damit Sie dessen Inhalt leicht bearbeiten können, falls er noch nicht sichtbar ist.

Beachten Sie auch, dass Sie zwar nicht mehrere Container für denselben Arbeitsbereich im selben VS Code-Fenster verwenden können, aber Sie können mehrere Docker Compose-verwaltete Container gleichzeitig aus separaten Fenstern verwenden.

Schnellstart: Ein Git-Repository oder einen GitHub PR in einem isolierten Container-Volume öffnen

Obwohl Sie ein lokal geklontes Repository in einem Container öffnen können, möchten Sie möglicherweise mit einer isolierten Kopie eines Repositorys für eine PR-Überprüfung arbeiten oder einen anderen Branch untersuchen, ohne Ihre Arbeit zu beeinträchtigen.

Repository-Container verwenden isolierte, lokale Docker-Volumes anstelle von Bind-Mounts des lokalen Dateisystems. Zusätzlich zur Vermeidung von Verunreinigungen Ihres Dateibaums bieten lokale Volumes den Vorteil einer verbesserten Leistung unter Windows und macOS. (Weitere Informationen zur Verwendung dieser Arten von Volumes in anderen Szenarien finden Sie im Artikel zur fortgeschrittenen Konfiguration Festplattenleistung verbessern.)

Befolgen Sie beispielsweise diese Schritte, um eines der "try"-Repositories in einem Repository-Container zu öffnen

1. Starten Sie VS Code und führen Sie Dev Containers: Repository im Container-Volume klonen... aus der Befehlspalette (F1) aus.

2. Geben Sie microsoft/vscode-remote-try-node (oder eines der anderen "try"-Repositories), eine Git-URI, eine GitHub-Branch-URL oder eine GitHub-PR-URL in das erscheinende Eingabefeld ein und drücken Sie Enter.

   

   Tipp: Wenn Sie ein privates Repository auswählen, sollten Sie möglicherweise einen Anmeldeinformations-Manager einrichten oder Ihre SSH-Schlüssel zu Ihrem SSH-Agenten hinzufügen. Weitere Informationen finden Sie unter Freigabe von Git-Anmeldeinformationen mit Ihrem Container.

3. Wenn Ihr Repository keine .devcontainer/devcontainer.json-Datei enthält, werden Sie aufgefordert, einen Ausgangspunkt aus einer filterbaren Liste oder einer vorhandenen Dockerfile oder Docker Compose-Datei (falls vorhanden) auszuwählen.

   Hinweis: Bei der Verwendung von Alpine Linux-Containern funktionieren einige Erweiterungen aufgrund von glibc-Abhängigkeiten im nativen Code der Erweiterung möglicherweise nicht.

   

   Die Liste wird automatisch basierend auf dem Inhalt des von Ihnen geöffneten Ordners sortiert. Die angezeigten Dev Container-Vorlagen stammen aus unserem Index von First-Party- und Community-Vorlagen, der Teil der Dev Container-Spezifikation ist. Wir hosten eine Reihe von Vorlagen als Teil der Spezifikation im devcontainers/templates-Repository. Sie können den src-Ordner dieses Repositorys durchsuchen, um den Inhalt jeder Vorlage zu sehen.

4. Das VS Code-Fenster (Instanz) wird neu geladen, der Quellcode geklont und mit dem Erstellen des Dev Containers begonnen. Eine Benachrichtigung über den Fortschritt liefert Statusaktualisierungen.

   

   Wenn Sie in Schritt 2 eine GitHub-Pull-Request-URL eingefügt haben, wird der PR automatisch ausgecheckt und die GitHub Pull Requests-Erweiterung im Container installiert. Die Erweiterung bietet zusätzliche PR-bezogene Funktionen wie einen PR-Explorer, die Interaktion mit PR-Kommentaren inline und die Sichtbarkeit in der Statusleiste.

   

5. Nach Abschluss des Erstellvorgangs stellt VS Code automatisch eine Verbindung zum Container her. Sie können nun mit dem Quellcode des Repositorys in dieser unabhängigen Umgebung arbeiten, so wie Sie es tun würden, wenn Sie den Code lokal geklont hätten.

Beachten Sie, dass, wenn der Container aufgrund eines Docker-Build-Fehlers oder Ähnlichem nicht gestartet werden kann, Sie in dem erscheinenden Dialog Im Wiederherstellungscontainer neu öffnen auswählen können, um in einen "Wiederherstellungscontainer" zu gelangen, der es Ihnen ermöglicht, Ihre Dockerfile oder andere Inhalte zu bearbeiten. Dies öffnet das Docker-Volume mit dem geklonten Repository in einem minimalen Container und zeigt Ihnen das Erstellungsprotokoll an. Sobald Sie die Korrekturen vorgenommen haben, verwenden Sie Im Container neu öffnen, um es erneut zu versuchen.

Tipp: Möchten Sie einen Remote-Docker-Host verwenden? Informationen hierzu finden Sie im Abschnitt Ordner auf einem Remote-SSH-Host in einem Container öffnen.

Vertrauen Sie Ihrem Arbeitsbereich

Visual Studio Code nimmt Sicherheit ernst und möchte Ihnen helfen, Code sicher zu durchsuchen und zu bearbeiten, unabhängig von Quelle oder ursprünglichen Autoren. Die Workspace Trust-Funktion ermöglicht es Ihnen zu entscheiden, ob Ihre Projektordner die automatische Codeausführung zulassen oder einschränken sollen.

Die Dev Containers-Erweiterung hat Workspace Trust übernommen. Je nachdem, wie Sie auf Ihren Quellcode zugreifen und damit interagieren, werden Sie zu verschiedenen Zeitpunkten aufgefordert zu entscheiden, ob Sie dem Code, den Sie bearbeiten oder ausführen, vertrauen.

Ordner im Container neu öffnen

Das Einrichten eines Dev Containers für ein bestehendes Projekt erfordert, dass Sie dem lokalen (oder WSL) Ordner vertrauen. Sie werden aufgefordert, dem lokalen (oder WSL) Ordner zu vertrauen, bevor das Fenster neu geladen wird.

Es gibt ein paar Ausnahmen von diesem Ablauf

1. Beim Klicken auf einen kürzlichen Eintrag.
2. Die Verwendung des Befehls Ordner im Container öffnen fordert zur Vertrauensüberprüfung nach dem Neuladen des Fensters auf, wenn das Vertrauen noch nicht erteilt wurde.

An vorhandenen Container anhängen

Beim Anhängen an einen vorhandenen Container werden Sie aufgefordert zu bestätigen, dass das Anhängen bedeutet, dass Sie dem Container vertrauen. Dies wird nur einmal bestätigt.

Repository in einem Volume klonen

Beim Klonen eines Repositorys in einem Container-Volume werden Sie aufgefordert zu bestätigen, dass das Klonen eines Repositorys bedeutet, dass Sie dem Repository vertrauen. Dies wird nur einmal bestätigt.

Volume inspizieren

Das Inspizieren eines Volumes beginnt im eingeschränkten Modus, und Sie können dem Ordner innerhalb des Containers vertrauen.

Docker-Daemon läuft remote

Dies impliziert, dass Sie der Maschine, auf der der Docker-Daemon läuft, vertrauen. Es gibt keine zusätzlichen Bestätigungsaufforderungen (nur die für den lokalen/WSL-Fall oben aufgeführten).

Erstellen einer devcontainer.json-Datei

Die Container-Konfiguration von VS Code wird in einer Datei devcontainer.json gespeichert. Diese Datei ähnelt der launch.json-Datei für Debugging-Konfigurationen, wird aber stattdessen zum Starten (oder Anhängen an) Ihres Entwicklungscenters verwendet. Sie können auch beliebige Erweiterungen angeben, die installiert werden sollen, sobald der Container läuft, oder Befehle nach der Erstellung, um die Umgebung vorzubereiten. Die Dev-Container-Konfiguration befindet sich entweder unter .devcontainer/devcontainer.json oder ist als .devcontainer.json-Datei (beachten Sie den Punkt am Anfang) im Stammverzeichnis Ihres Projekts gespeichert.

Wenn Sie den Befehl Dev Containers: Konfigurationsdateien für Dev Container hinzufügen... aus der Befehlspalette (F1) auswählen, werden die benötigten Dateien als Ausgangspunkt zu Ihrem Projekt hinzugefügt, die Sie dann weiter an Ihre Bedürfnisse anpassen können. Der Befehl ermöglicht es Ihnen, eine vordefinierte Container-Konfiguration aus einer Liste basierend auf den Inhalten Ihres Ordners auszuwählen, eine vorhandene Dockerfile oder eine vorhandene Docker Compose-Datei wiederzuverwenden.

Sie können auch manuell eine devcontainer.json-Datei erstellen und jedes beliebige Image, Dockerfile oder eine beliebige Sammlung von Docker Compose-Dateien als Ausgangspunkt verwenden. Hier ist ein einfaches Beispiel, das eines der vorkompilierten Development Container-Images verwendet

{
  "image": "mcr.microsoft.com/devcontainers/typescript-node",
  "forwardPorts": [3000],
  "customizations": {
    // Configure properties specific to VS Code.
    "vscode": {
      // Add the IDs of extensions you want installed when the container is created.
      "extensions": ["streetsidesoftware.code-spell-checker"]
    }
  }
}

Hinweis: Zusätzliche Konfigurationen werden bereits auf Basis des Inhalts des Basis-Images in den Container übernommen. Beispielsweise fügen wir die Erweiterung streetsidesoftware.code-spell-checker oben hinzu, und der Container enthält auch "dbaeumer.vscode-eslint", da dies Teil von mcr.microsoft.com/devcontainers/typescript-node ist. Dies geschieht automatisch beim Vorkompilieren mit devcontainer.json, worüber Sie im Abschnitt Vorkompilierung mehr erfahren können.

Um mehr über die Erstellung von devcontainer.json-Dateien zu erfahren, siehe Entwicklungscenter erstellen.

Dev Container-Features

Entwicklungscenter-"Features" sind eigenständige, teilbare Einheiten von Installationscode und Dev-Container-Konfiguration. Der Name leitet sich von der Idee ab, dass die Referenzierung einer dieser Einheiten es Ihnen ermöglicht, schnell und einfach weitere Tooling-, Runtime- oder Bibliotheks-"Features" in Ihren Entwicklungscenter zu integrieren, die von Ihnen oder Ihren Kollaborateuren genutzt werden können.

Wenn Sie Dev Containers: Konfigurationsdateien für Dev Container hinzufügen verwenden, wird Ihnen eine Liste von Skripten angezeigt, um die vorhandenen Dev-Container-Konfigurationen anzupassen, z. B. die Installation von Git oder der Azure CLI.

Wenn Sie Ihren Container neu erstellen und erneut öffnen, sind die von Ihnen ausgewählten Features in Ihrer devcontainer.json verfügbar.

"features": {
    "ghcr.io/devcontainers/features/github-cli:1": {
        "version": "latest"
    }
}

Sie erhalten IntelliSense beim Bearbeiten der "features"-Eigenschaft in der devcontainer.json direkt.

Der Befehl Dev Containers: Container-Features konfigurieren ermöglicht es Ihnen, eine vorhandene Konfiguration zu aktualisieren.

Die in der VS Code-UI bezogenen Features stammen jetzt aus einem zentralen Index, zu dem Sie ebenfalls beitragen können. Sehen Sie sich die Dev Containers-Spezifikationsseite für die aktuelle Liste an und erfahren Sie, wie Sie Features veröffentlichen und verteilen.

Immer installierte Features

Ähnlich wie Sie Erweiterungen so einstellen können, dass sie immer installiert werden, können Sie die Benutzereinstellung dev.containers.defaultFeatures verwenden, um Features festzulegen, die Sie immer installiert haben möchten.

"dev.containers.defaultFeatures": {
    "ghcr.io/devcontainers/features/github-cli:1": {}
},

Erstellen eines eigenen Features

Es ist auch einfach, eigene Dev Container-Features zu erstellen und zu veröffentlichen. Veröffentlichte Features können als OCI-Artefakte von jedem unterstützenden öffentlichen oder privaten Container-Registry gespeichert und geteilt werden. Die Liste der derzeit veröffentlichten Features finden Sie auf containers.dev.

Ein Feature ist eine eigenständige Entität in einem Ordner mit mindestens einer devcontainer-feature.json und einem install.sh-Einstiegsskript.

+-- feature
|    +-- devcontainer-feature.json
|    +-- install.sh
|    +-- (other files)

Schauen Sie sich das feature/starter-Repository an, um Anleitungen zur Verwendung der Dev Container CLI für die Veröffentlichung Ihrer eigenen öffentlichen oder privaten Features zu erhalten.

Feature-Spezifikation und -Verteilung

Features sind ein wichtiger Bestandteil der Open-Source- Development Containers-Spezifikation. Sie können weitere Informationen darüber, wie Features funktionieren und deren Verteilung einsehen.

Vorkompilieren von Dev-Container-Images

Wir empfehlen, Images mit den benötigten Tools vorkompiliert zu haben, anstatt jedes Mal, wenn Sie Ihr Projekt in einem Dev Container öffnen, ein Container-Image zu erstellen und zu bauen. Die Verwendung vorkompilierter Images führt zu einem schnelleren Containerstart, einer einfacheren Konfiguration und ermöglicht es Ihnen, eine bestimmte Version von Tools anzuheften, um die Sicherheit der Lieferkette zu verbessern und potenzielle Fehler zu vermeiden. Sie können das Vorkompilieren Ihres Images automatisieren, indem Sie den Build über einen DevOps- oder CI-Dienst wie GitHub Actions planen.

Noch besser: Vorkompilierte Images können Dev Container-Metadaten enthalten, sodass beim Referenzieren eines Images Einstellungen automatisch übernommen werden.

Wir empfehlen die Verwendung der Dev Container CLI (oder anderer spezifikationskonformer Utilities wie der GitHub Action), um Ihre Images vorkompiliert zu erstellen, da diese mit den neuesten Funktionen der Dev Containers-Erweiterung synchronisiert bleibt, einschließlich Dev Container Features. Nach dem Erstellen Ihres Images können Sie es in einer Container-Registry (wie der Azure Container Registry, der GitHub Container Registry oder Docker Hub) pushen und direkt referenzieren.

Sie können die GitHub Action im Repository devcontainers/ci verwenden, um Ihre Dev Container in Ihren Workflows wiederzuverwenden.

Weitere Informationen zum Vorkompilieren von Images finden Sie im Artikel zur Dev Container CLI über das Vorkompilieren.

Metadaten erben

Sie können Dev Container-Konfigurations- und Feature-Metadaten über Image-Labels in vorkompilierte Images aufnehmen. Dies macht das Image eigenständig, da diese Einstellungen automatisch übernommen werden, wenn das Image referenziert wird – sei es direkt, in einem FROM in einem referenzierten Dockerfile oder in einer Docker Compose-Datei. Dies hilft, eine Inkonsistenz zwischen Ihrer Dev Container-Konfiguration und dem Image-Inhalt zu vermeiden und ermöglicht es Ihnen, Updates derselben Konfiguration auf mehrere Repositories über eine einfache Image-Referenz zu pushen.

Dieses Metadaten-Label wird automatisch hinzugefügt, wenn Sie mit der Dev Container CLI (oder anderen spezifikationskonformen Utilities wie der GitHub Action oder der Azure DevOps Task) vorkompilieren und enthält Einstellungen aus devcontainer.json und allen referenzierten Dev Container Features.

Dies ermöglicht es Ihnen, eine separate, komplexere devcontainer.json zu haben, die Sie zum Vorkompilieren Ihres Images verwenden, und dann eine drastisch vereinfachte in einem oder mehreren Repositories. Der Inhalt des Images wird zum Zeitpunkt der Containererstellung mit dem Inhalt dieser vereinfachten devcontainer.json zusammengeführt (weitere Informationen zur Zusammenführungslogik finden Sie in der Spezifikation). Aber im einfachsten Fall können Sie das Image direkt in devcontainer.json referenzieren, damit die Einstellungen wirksam werden.

{
  "image": "mcr.microsoft.com/devcontainers/go:1"
}

Beachten Sie, dass Sie sich auch dafür entscheiden können, Metadaten manuell zu einem Image-Label hinzuzufügen. Diese Eigenschaften werden auch dann übernommen, wenn Sie die Dev Container CLI nicht zum Erstellen verwendet haben (und können von der CLI aktualisiert werden, auch wenn Sie dies tun). Betrachten Sie beispielsweise diesen Dockerfile-Snippet

LABEL devcontainer.metadata='[{ \
  "capAdd": [ "SYS_PTRACE" ], \
  "remoteUser": "devcontainer", \
  "postCreateCommand": "yarn install" \
}]'

Volumes inspizieren

Gelegentlich kann es vorkommen, dass Sie mit einem benannten Docker-Volume arbeiten, das Sie inspizieren oder ändern möchten. Sie können VS Code verwenden, um mit diesen Inhalten zu arbeiten, ohne eine devcontainer.json-Datei zu erstellen oder zu ändern, indem Sie den Befehl Dev Containers: Volume in einem Dev Container erkunden... aus der Befehlspalette (F1) auswählen.

Sie können Ihre Volumes auch im Remote Explorer inspizieren. Stellen Sie sicher, dass Sie Container im Dropdown-Menü ausgewählt haben, dann bemerken Sie einen Abschnitt Entwicklungs-Volumes. Sie können mit der rechten Maustaste auf ein Volume klicken, um seine Erstellungsinformationen zu inspizieren, z. B. wann das Volume erstellt wurde, welches Repository darin geklont wurde und den Mountpoint. Sie können es auch in einem Entwicklungscontainer erkunden.

Wenn Sie die Container Tools-Erweiterung installiert haben, können Sie mit der rechten Maustaste auf ein Volume im Abschnitt Volumes des Container Explorers klicken und In einem Entwicklungscontainer erkunden auswählen.

Verwalten von Erweiterungen

VS Code führt Erweiterungen an einem von zwei Orten aus: lokal auf der UI / Client-Seite oder im Container. Während Erweiterungen, die die VS Code-Benutzeroberfläche beeinflussen, wie Themes und Snippets, lokal installiert werden, befinden sich die meisten Erweiterungen in einem bestimmten Container. Dies ermöglicht es Ihnen, nur die Erweiterungen zu installieren, die Sie für eine bestimmte Aufgabe in einem Container benötigen, und Ihre gesamte Toolchain nahtlos zu wechseln, indem Sie sich einfach mit einem neuen Container verbinden.

Wenn Sie eine Erweiterung aus der Erweiterungsansicht installieren, wird sie automatisch an der richtigen Stelle installiert. Sie können anhand der Kategorien gruppierung erkennen, wo eine Erweiterung installiert ist. Es gibt eine Kategorie Lokal – Installiert und auch eine für Ihren Container.

Hinweis: Wenn Sie ein Erweiterungsautor sind und Ihre Erweiterung nicht richtig funktioniert oder an der falschen Stelle installiert wird, finden Sie weitere Informationen unter Unterstützung für die Remote-Entwicklung.

Lokale Erweiterungen, die tatsächlich remote ausgeführt werden müssen, werden in der Kategorie Lokal – Installiert als Deaktiviert angezeigt. Wählen Sie Installieren, um eine Erweiterung auf Ihrem Remote-Host zu installieren.

Sie können auch alle lokal installierten Erweiterungen innerhalb des Entwicklungscontainers installieren, indem Sie zur Erweiterungsansicht wechseln und Lokale Erweiterungen in Entwicklungscontainer installieren: {Name} über die Cloud-Schaltfläche rechts von der Titelleiste Lokal – Installiert auswählen. Dies zeigt ein Dropdown-Menü an, in dem Sie auswählen können, welche lokal installierten Erweiterungen in Ihrem Container installiert werden sollen.

Einige Erweiterungen erfordern jedoch möglicherweise, dass Sie zusätzliche Software im Container installieren. Konsultieren Sie die Erweiterungsdokumentation, wenn Probleme auftreten.

Hinzufügen einer Erweiterung zu devcontainer.json

Während Sie Ihre devcontainer.json-Datei manuell bearbeiten können, um eine Liste von Erweiterungs-IDs hinzuzufügen, können Sie auch mit der rechten Maustaste auf eine beliebige Erweiterung in der Erweiterungsansicht klicken und Zu devcontainer.json hinzufügen auswählen.

Erweiterungen abwählen

Wenn ein Basisimage oder ein Feature eine Erweiterung konfiguriert, die Sie nicht in Ihrem Entwicklungscontainer installiert haben möchten, können Sie sie abwählen, indem Sie die Erweiterung mit einem Minuszeichen auflisten. Zum Beispiel

{
  "image": "mcr.microsoft.com/devcontainers/typescript-node:1-20-bookworm",
  "customizations": {
    "vscode": {
      "extensions": ["-dbaeumer.vscode-eslint"]
    }
  }
}

"Immer installierte" Erweiterungen

Wenn es Erweiterungen gibt, die Sie immer in jedem Container installiert haben möchten, können Sie die Benutzereinstellung dev.containers.defaultExtensions aktualisieren. Wenn Sie beispielsweise die Erweiterungen GitLens und Resource Monitor installieren möchten, würden Sie deren Erweiterungs-IDs wie folgt angeben

"dev.containers.defaultExtensions": [
    "eamodio.gitlens",
    "mutantdino.resourcemonitor"
]

Erweitert: Erzwingen der Ausführung einer Erweiterung lokal oder remote

Erweiterungen werden normalerweise so entwickelt und getestet, dass sie entweder lokal oder remote ausgeführt werden, nicht beides. Wenn eine Erweiterung dies jedoch unterstützt, können Sie sie in Ihrer settings.json-Datei erzwingen, an einem bestimmten Speicherort auszuführen.

Zum Beispiel erzwingt die folgende Einstellung die lokale Ausführung der Erweiterung Container Tools und die remote Ausführung der Erweiterung Remote - SSH: Konfigurationsdateien bearbeiten anstelle ihrer Standardwerte

"remote.extensionKind": {
    "ms-azuretools.vscode-containers": [ "ui" ],
    "ms-vscode-remote.remote-ssh-edit": [ "workspace" ]
}

Ein Wert von "ui" anstelle von "workspace" erzwingt, dass die Erweiterung auf der lokalen UI-/Client-Seite ausgeführt wird. Dies sollte normalerweise nur zum Testen verwendet werden, es sei denn, es ist anders in der Dokumentation der Erweiterung angegeben, da es Erweiterungen brechen kann. Weitere Informationen finden Sie im Abschnitt zur bevorzugten Erweiterungs-Position.

Einen Port weiterleiten oder veröffentlichen

Container sind separate Umgebungen. Wenn Sie auf einen Server, Dienst oder eine andere Ressource in Ihrem Container zugreifen möchten, müssen Sie den Port entweder "weiterleiten" oder "veröffentlichen". Sie können entweder Ihren Container so konfigurieren, dass diese Ports immer verfügbar sind, oder sie nur vorübergehend weiterleiten.

Port immer weiterleiten

Sie können eine Liste von Ports angeben, die Sie immer weiterleiten möchten, wenn Sie einen Ordner im Container anhängen oder öffnen, indem Sie die Eigenschaft forwardPorts in devcontainer.json verwenden.

"forwardPorts": [3000, 3001]

Laden Sie einfach das Fenster neu / öffnen Sie es erneut, und die Einstellung wird angewendet, wenn VS Code eine Verbindung zum Container herstellt.

Port vorübergehend weiterleiten

Wenn Sie auf einen Port zugreifen müssen, den Sie nicht zu devcontainer.json hinzugefügt oder in Ihrer Docker Compose-Datei veröffentlicht haben, können Sie einen neuen Port für die Dauer der Sitzung vorübergehend weiterleiten, indem Sie den Befehl Port weiterleiten aus der Befehlspalette (F1) ausführen.

Nachdem Sie einen Port ausgewählt haben, wird eine Benachrichtigung Ihnen den Localhost-Port mitteilen, den Sie zum Zugriff auf den Port im Container verwenden sollten. Wenn Sie beispielsweise einen HTTP-Server weitergeleitet haben, der auf Port 3000 hört, kann die Benachrichtigung Ihnen mitteilen, dass er Port 4123 auf localhost zugeordnet wurde. Sie können sich dann mit diesem Remote-HTTP-Server über https://:4123 verbinden.

Diese gleichen Informationen sind im Abschnitt Weitergeleitete Ports des Remote Explorers verfügbar, falls Sie später darauf zugreifen müssen.

Wenn VS Code sich an weitergeleitete Ports erinnern soll, aktivieren Sie Remote: Weitergeleitete Ports wiederherstellen im Einstellungseditor (⌘, (Windows, Linux Ctrl+,)) oder setzen Sie "remote.restoreForwardedPorts": true in settings.json.

Port veröffentlichen

Docker hat das Konzept des "Veröffentlichens" von Ports beim Erstellen des Containers. Veröffentlichte Ports verhalten sich sehr ähnlich wie Ports, die wir unserem lokalen Netzwerk zur Verfügung stellen. Wenn Ihre Anwendung nur Aufrufe von localhost akzeptiert, lehnt sie Verbindungen von veröffentlichten Ports ab, genau wie Ihr lokaler Computer Netzwerkaufrufe ablehnen würde. Weitergeleitete Ports hingegen sehen für die Anwendung tatsächlich wie localhost aus. Beide können in verschiedenen Situationen nützlich sein.

Um einen Port zu veröffentlichen, können Sie

1. Verwenden Sie die Eigenschaft appPort: Wenn Sie in devcontainer.json auf ein Image oder eine Dockerfile verweisen, können Sie die Eigenschaft appPort verwenden, um Ports auf dem Host zu veröffentlichen.

   "appPort": [ 3000, "8921:5000" ]
   

2. Verwenden Sie die Docker Compose-Portzuordnung: Die Portzuordnung kann einfach zu Ihrer docker-compose.yml-Datei hinzugefügt werden, um zusätzliche Ports zu veröffentlichen.

   ports:
   - "3000"
   - "8921:5000"
   

In jedem Fall müssen Sie Ihren Container neu erstellen, damit die Einstellung wirksam wird. Sie können dies tun, indem Sie den Befehl Dev Containers: Container neu erstellen in der Befehlspalette (F1) ausführen, wenn Sie mit dem Container verbunden sind.

Ein Terminal öffnen

Das Öffnen eines Terminals in einem Container von VS Code aus ist einfach. Sobald Sie einen Ordner in einem Container geöffnet haben, wird jedes Terminalfenster, das Sie in VS Code öffnen (Terminal > Neues Terminal), automatisch im Container und nicht lokal ausgeführt.

Sie können auch den code-Befehl aus diesem selben Terminalfenster verwenden, um eine Reihe von Operationen auszuführen, wie z. B. das Öffnen einer neuen Datei oder eines neuen Ordners im Container. Geben Sie code --help ein, um zu erfahren, welche Optionen von der Befehlszeile aus verfügbar sind.

Debuggen in einem Container

Sobald Sie einen Ordner in einem Container geöffnet haben, können Sie den VS Code-Debugger auf die gleiche Weise verwenden, wie Sie es bei der lokalen Ausführung der Anwendung tun würden. Wenn Sie beispielsweise eine Startkonfiguration in launch.json auswählen und das Debugging starten (F5), wird die Anwendung auf dem Remote-Host gestartet und der Debugger daran angehängt.

Details zur Konfiguration der Debugging-Funktionen von VS Code in .vscode/launch.json finden Sie in der Debugging-Dokumentation.

Container-spezifische Einstellungen

Die lokalen Benutzereinstellungen von VS Code werden auch wiederverwendet, wenn Sie mit einem Entwicklungscontainer verbunden sind. Dies hält Ihre Benutzererfahrung konsistent, aber Sie möchten möglicherweise einige dieser Einstellungen zwischen Ihrem lokalen Computer und jedem Container variieren. Glücklicherweise können Sie, sobald Sie mit einem Container verbunden sind, auch Container-spezifische Einstellungen festlegen, indem Sie den Befehl Einstellungen: Remote-Einstellungen öffnen aus der Befehlspalette (F1) ausführen oder den Tab Remote im Einstellungseditor auswählen. Diese überschreiben alle lokalen Einstellungen, die Sie haben, wenn Sie sich mit dem Container verbinden.

Standardmäßige Container-spezifische Einstellungen

Sie können Standardwerte für Container-spezifische Einstellungen in devcontainer.json über die Eigenschaft settings aufnehmen. Diese Werte werden automatisch in die Container-spezifische Einstellungsdatei innerhalb des Containers eingefügt, sobald er erstellt ist.

Wenn Sie beispielsweise Folgendes zu .devcontainer/devcontainer.json hinzufügen, wird der Java-Home-Pfad festgelegt

// Configure tool-specific properties.
"customizations": {
    // Configure properties specific to VS Code.
    "vscode": {
        "settings": {
            "java.home": "/docker-java-home"
        }
    }
}

Da dies nur den Standard festlegt, können Sie die Einstellungen nach der Erstellung des Containers immer noch nach Bedarf ändern.

Container verwalten

Standardmäßig startet die Dev Containers-Erweiterung die in devcontainer.json erwähnten Container automatisch, wenn Sie den Ordner öffnen. Wenn Sie VS Code schließen, beendet die Erweiterung automatisch die Container, mit denen Sie verbunden waren. Sie können dieses Verhalten ändern, indem Sie "shutdownAction": "none" zu devcontainer.json hinzufügen.

Während Sie die Befehlszeile zur Verwaltung Ihrer Container verwenden können, können Sie auch den Remote Explorer verwenden. Um einen Container zu stoppen, wählen Sie Container aus dem Dropdown-Menü (falls vorhanden), klicken Sie mit der rechten Maustaste auf einen laufenden Container und wählen Sie Container stoppen. Sie können auch beendete Container starten, Container entfernen und kürzlich verwendete Ordner entfernen. In der Detailansicht können Sie Ports weiterleiten und bereits weitergeleitete Ports im Browser öffnen.

Wenn Sie Images bereinigen oder Container massenhaft löschen möchten, lesen Sie Bereinigen von ungenutzten Containern und Images für verschiedene Optionen.

Personalisierung mit Dotfile-Repositories

Dotfiles sind Dateien, deren Dateiname mit einem Punkt (.) beginnt und die typischerweise Konfigurationsinformationen für verschiedene Anwendungen enthalten. Da Entwicklungscontainer eine breite Palette von Anwendungstypen abdecken können, kann es nützlich sein, diese Dateien irgendwo zu speichern, damit Sie sie leicht in einen Container kopieren können, sobald er gestartet ist.

Eine gängige Methode hierfür ist, diese Dotfiles in einem GitHub-Repository zu speichern und dann ein Dienstprogramm zu verwenden, um sie zu klonen und anzuwenden. Die Dev Containers-Erweiterung hat integrierte Unterstützung für die Verwendung dieser mit Ihren eigenen Containern. Wenn Sie neu in dieser Idee sind, schauen Sie sich die verschiedenen Dotfiles-Bootstrap-Repositories an, die es gibt.

Um es zu verwenden, fügen Sie Ihr Dotfiles-GitHub-Repository zu den Benutzereinstellungen von VS Code hinzu (⌘, (Windows, Linux Ctrl+,)) wie folgt:

Oder in settings.json

{
  "dotfiles.repository": "your-github-id/your-dotfiles-repo",
  "dotfiles.targetPath": "~/dotfiles",
  "dotfiles.installCommand": "install.sh"
}

Von diesem Zeitpunkt an wird das Dotfiles-Repository verwendet, wenn ein Container erstellt wird.

Bekannte Einschränkungen

Einschränkungen von Dev Containers

• Windows-Container-Images werden nicht unterstützt.
• Alle Roots/Ordner in einem Multi-Root-Workspace werden im selben Container geöffnet, unabhängig davon, ob auf niedrigeren Ebenen Konfigurationsdateien vorhanden sind.
• Das inoffizielle Ubuntu Docker snap-Paket für Linux wird nicht unterstützt. Befolgen Sie die offiziellen Docker-Installationsanweisungen für Ihre Distribution.
• Docker Toolbox unter Windows wird nicht unterstützt.
• Wenn Sie ein Git-Repository über SSH klonen und Ihr SSH-Schlüssel eine Passphrase hat, können die Pull- und Synchronisierungsfunktionen von VS Code beim Remote-Betrieb hängen bleiben. Verwenden Sie entweder einen SSH-Schlüssel ohne Passphrase, klonen Sie über HTTPS oder führen Sie git push von der Befehlszeile aus, um das Problem zu umgehen.
• Lokale Proxy-Einstellungen werden im Container nicht wiederverwendet, was dazu führen kann, dass Erweiterungen nicht funktionieren, es sei denn, die entsprechenden Proxy-Informationen werden konfiguriert (z. B. globale Umgebungsvariablen HTTP_PROXY oder HTTPS_PROXY mit den entsprechenden Proxy-Informationen).
• Es gibt eine Inkompatibilität zwischen OpenSSH-Versionen unter Windows, wenn der ssh-Agent mit Version <= 8.8 ausgeführt wird und der SSH-Client (auf jeder Plattform) Version >= 8.9 ausführt. Die Problemumgehung besteht darin, OpenSSH unter Windows auf 8.9 oder höher zu aktualisieren, entweder über winget oder ein Installationsprogramm von Win32-OpenSSH/releases. (Beachten Sie, dass ssh-add -l korrekt funktioniert, aber ssh <ssh-server> mit <ssh-server>: Permission denied (publickey) fehlschlägt. Dies betrifft auch Git bei der Verwendung von SSH zur Verbindung mit dem Repository.)

Siehe hier für eine Liste aktiver Probleme im Zusammenhang mit Containern.

Docker-Einschränkungen

Weitere Informationen finden Sie im Docker-Fehlerbehebungsleitfaden für Windows oder Mac.

Einschränkungen der Container Tools-Erweiterung

Wenn Sie die Container Tools- oder Kubernetes-Erweiterung von einem WSL-, Remote-Tunnels- oder Remote-SSH-Fenster aus verwenden, wird die Kontextmenüaktion Visual Studio Code anhängen im Container Explorer oder in der Kubernetes-Ansicht ein zweites Mal aufgefordert, aus den verfügbaren Containern auszuwählen.

Einschränkungen bei Erweiterungen

Zu diesem Zeitpunkt werden die meisten Erweiterungen innerhalb von Dev Containers ohne Änderungen funktionieren. In einigen Fällen können jedoch bestimmte Funktionen Änderungen erfordern. Wenn Sie auf ein Erweiterungsproblem stoßen, finden Sie hier eine Zusammenfassung häufiger Probleme und Lösungen, die Sie dem Erweiterungsautor bei der Meldung des Problems erwähnen können.

Darüber hinaus ist zwar Alpine-Unterstützung verfügbar, aber einige im Container installierte Erweiterungen funktionieren möglicherweise aufgrund von glibc-Abhängigkeiten im nativen Code der Erweiterung nicht. Weitere Informationen finden Sie im Artikel Remote-Entwicklung unter Linux.

Erweiterte Container-Konfiguration

Siehe die Artikel Erweiterte Containerkonfiguration für Informationen zu folgenden Themen

• Hinzufügen von Umgebungsvariablen
• Hinzufügen einer weiteren lokalen Dateimountung
• Ändern oder Entfernen des Standard-Quellcode-Mounts
• Verbesserung der Container-Festplattenleistung
• Hinzufügen eines Nicht-Root-Benutzers zu Ihrem Entwicklungscontainer
• Festlegen des Projektnamens für Docker Compose
• Verwenden von Docker oder Kubernetes aus einem Container heraus
• Verbinden mit mehreren Containern gleichzeitig
• Entwickeln in einem Container auf einem Remote Docker Machine oder SSH-Host
• Reduzieren von Dockerfile-Build-Warnungen
• Freigeben von Git-Anmeldedaten mit Ihrem Container

Referenz zu devcontainer.json

Es gibt eine vollständige devcontainer.json-Referenz, in der Sie das Dateischema überprüfen können, um Ihre Entwicklungscontainer anzupassen und zu steuern, wie Sie sich mit laufenden Containern verbinden.

Fragen oder Feedback

• Siehe Tipps und Tricks oder die FAQ.
• Auf Stack Overflow suchen.
• Eine Funktionsanforderung hinzufügen oder ein Problem melden.
• Erstellen Sie eine Dev Container-Vorlage oder ein Feature für andere zur Verwendung.
• Überprüfen und geben Sie Feedback zur Development Containers Specification.
• Zu unserer Dokumentation oder VS Code selbst beitragen.
• Details finden Sie in unserem CONTRIBUTING-Leitfaden.

Fehlerbehebung

Datei kann nicht geschrieben werden (Keine Berechtigungen (FileSystemError))

Dieses Problem kann auftreten, wenn Sie Entwicklungscontainer in der folgenden Konfiguration ausführen

• Docker Desktop mit WSL-Backend (Windows Subsystem for Linux)
• Verbesserte Containerisolierung (ECI) aktiviert

Überprüfen Sie Issue #8278 für eine mögliche Problemumgehung.

Nächste Schritte

• An einen laufenden Container anhängen - Hängt sich an einen bereits laufenden Docker-Container an.
• Einen Entwicklungscontainer erstellen - Erstellt einen benutzerdefinierten Container für Ihre Arbeitsumgebung.
• Fortgeschrittene Container – Finden Sie Lösungen für fortgeschrittene Container-Szenarien.
• devcontainer.json-Referenz – Überprüfen Sie das devcontainer.json-Schema.