Ihre Entwicklungsumgebung
Sie können wählen, ob Sie einen Container-basierten Dienst in der lokalen Umgebung oder in einer Remote-Umgebung entwickeln möchten. Die lokale Umgebung ist das Betriebssystem Ihrer Entwickler-Workstation; die Verwendung der lokalen Umgebung bedeutet, dass Sie Ihre Dienst-Container mit Docker, das auf Ihrer Workstation installiert ist, erstellen und ausführen. Docker wird unter Windows, macOS und verschiedenen Linux-Distributionen unterstützt. System- und Hardwareanforderungen finden Sie auf der Docker-Installationsseite.
Eine Remote-Entwicklungsumgebung unterscheidet sich von Ihrer Entwickler-Workstation. Es kann sich um eine Remote-Maschine handeln, die über SSH erreichbar ist, eine virtuelle Maschine, die auf Ihrer Entwickler-Workstation läuft, oder ein Entwicklungcontainer. Eine Remote-Umgebung kann Vorteile gegenüber der lokalen Umgebung haben, der wichtigste ist die Möglichkeit, dasselbe Betriebssystem während der Entwicklung zu verwenden, und wenn Ihr Dienst in der Produktion läuft. Um eine Remote-Umgebung zu nutzen, müssen Sie sicherstellen, dass der Befehl docker (Docker CLI) in dieser Umgebung verfügbar und funktionsfähig ist.
Die zweite wichtige Wahl ist, ob Sie Ihren Dienst, der als normaler Prozess läuft, debuggen oder Ihren Dienst, der in einem Container läuft, debuggen möchten.
Richtlinien zur Auswahl einer Entwicklungsumgebung
-
Verwenden Sie die lokale Umgebung, wenn Sie sich nicht um Folgendes kümmern
- Verwendung desselben Betriebssystems für die Entwicklung und innerhalb des Dienst-Containers.
- Installation notwendiger Werkzeuge und Abhängigkeiten auf Ihrer lokalen Umgebung.
-
Erwägen Sie zuerst die Verwendung eines Entwicklungscontainers, wenn Sie eine Remote-Umgebung benötigen.
- Unter Windows ist die Verwendung von Windows Subsystem for Linux (WSL) eine gute Option.
-
Das Debugging Ihres Dienstes in einem Container ist möglich, bringt aber zusätzliche Komplexität mit sich. Verwenden Sie standardmäßig das normale Debugging und das Debugging im Container, wenn Sie es benötigen.
Die Container Tools-Erweiterung unterstützt nativ das Container-Debugging für .NET-, Node.js- und Python-basierte Dienste.
Docker CLI in einer Remote-Entwicklungsumgebung aktivieren
Die Art und Weise, wie Sie Docker CLI in einer Remote-Entwicklungsumgebung aktivieren, hängt von der Art der gewählten Remote-Umgebung ab.
Entwicklungscontainer
Für einen Entwicklungscontainer sollten Sie die Docker CLI im Container an den Docker-Daemon auf dem lokalen Rechner umleiten.
Stellen Sie zunächst sicher, dass die Docker CLI in Ihren Entwicklungscontainer installiert ist. Die genauen Schritte hängen von der Linux-Distribution ab, die der Container verwendet.
Hier ist ein Beispiel für Ubuntu-basierte Distributionen (aus einer .devcontainer/Dockerfile)
...
&& apt-get -y install software-properties-common \
&& curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - 2>/dev/null \
&& add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu bionic stable" \
&& apt-get update -y \
&& apt-get install -y docker-ce-cli \
&& apt-get install -y python python-pip \
&& pip install docker-compose \
...
Stellen Sie als Nächstes sicher, dass der Docker-Socket in den Entwicklungscontainer gemappt wird (in .devcontainer/devcontainer.json)
...
"runArgs": [ "-v", "/var/run/docker.sock:/var/run/docker.sock"]
...
Windows-Subsystem für Linux
Das Windows Subsystem for Linux ist eine großartige Wahl für die Entwicklung von Container-basierten Diensten unter Windows. Windows Subsystem for Linux Version 2 (WSL 2) wird dringend empfohlen. Docker Desktop für Windows wurde aktualisiert, um mit WSL 2 zu funktionieren, und verfügt über eine grafische Einstellung, um die Docker CLI in WSL 2-Distributionen zu aktivieren.
Um WSL 2 für die Docker-Entwicklung zu verwenden, benötigen Sie Windows 10 Version 2004 oder neuer und Docker Desktop für Windows Version 2.2.0.5 oder neuer.
Die alte Version von WSL (WSL 1) bietet keine einfache Möglichkeit, sich mit dem Docker-Daemon auf dem Host zu verbinden.
Remote-Maschine
Der empfohlene Weg, die Containerentwicklung mit einer Remote-Maschine zu ermöglichen, ist eine vollständige Docker-Installation auf der Maschine, einschließlich des Docker-Daemons.
Hinweis: Das Produkt Docker Desktop wird nur auf physischen Windows- und macOS-Maschinen unterstützt, nicht auf virtuellen Maschinen. Wenn Sie eine virtuelle Maschine als Remote-Entwicklungsumgebung verwenden möchten, empfehlen wir die Verwendung einer Linux-VM mit Docker Engine.
Nachdem Docker auf der Remote-Maschine installiert und funktionsfähig ist, können Sie die Remote - SSH-Erweiterung von VS Code aus dem Remote Development-Erweiterungspaket verwenden, um sich mit Ihrer Remote-Maschine zu verbinden und dort zu arbeiten.
-
Öffnen Sie die VS Code Command Palette (⇧⌘P (Windows, Linux Ctrl+Shift+P)) und führen Sie den Befehl Remote-SSH: Add new SSH host... aus. Folgen Sie den Anweisungen, um eine Verbindung zum Zielhost einzurichten.
-
Führen Sie den Befehl Remote-SSH: Connect to host... aus und verbinden Sie sich mit dem Host.
-
Ein neues VS Code-Fenster wird geöffnet, das im Kontext der Zielmaschine ausgeführt wird. Wenn Sie die Passwortauthentifizierung verwenden, wird hier nach dem Passwort gefragt. Wir empfehlen dringend, die SSH-Schlüsselauthentifizierung einzurichten, um die Bedienung zu erleichtern.
-
Installieren Sie in der Ansicht "Erweiterungen" die Container Tools-Erweiterung (auf dem Remote-Host) (nach diesem Schritt ist möglicherweise ein Neuladen erforderlich).
Hinweis: Wenn Sie die Container Tools-Erweiterung zum Erstellen von Container-Images und Quellcode verwenden, bedeutet der oben beschriebene Ansatz wahrscheinlich, dass sich Ihre Quellcodeverwaltung auf dem Remote-Host und nicht auf Ihrer Entwickler-Workstation befindet. Wenn Sie die Container Tools-Erweiterung nur für die Container Explorer-Funktionen verwenden, können Sie dies ignorieren.
Lokale Linux-VM
Um eine Linux-VM, die auf Ihrer Entwickler-Workstation läuft, zu verwenden, sollten Sie Docker auf der VM auf dieselbe Weise installieren, wie Sie es auf einer Remote-Maschine installieren würden, und die VS Code Remote-SSH-Erweiterung verwenden, um sich mit der VM zu verbinden.
Alternativ können Sie nur die Docker CLI in Ihrer Entwicklungsumgebung installieren und die CLI mithilfe des Docker-Kontextmechanismus auf den Docker-Host (Engine) verweisen, der auf der Entwickler-Workstation läuft. Die Hauptsorge bei diesem Ansatz ist die Sicherstellung der Netzwerkverbindung von der VM zum Docker-Daemon auf dem Host und dies auf sichere Weise zu tun. Eine Möglichkeit ist die Verwendung von SSH-Tunneling oder Remote - Tunnels zur Entwickler-Workstation. Eine andere Möglichkeit ist, den Docker-Daemon auf einem HTTPS-Port lauschen zu lassen. Sie müssen mit SSH und Public-Key-Infrastruktur (PKI) vertraut sein, um den Host-Docker-Daemon von der Docker CLI innerhalb der VM aus zu verwenden. Für die meisten Benutzer empfehlen wir eine vollständige Docker-Installation innerhalb der virtuellen Maschine.
Debugging in einem Container
Die Container Tools-Erweiterung unterstützt das Debugging von .NET- und Node.js-basierten Diensten, die in einem Container laufen. Andere Programmiersprachen werden derzeit nicht unterstützt.
Das Debugging in einem Container kann schwieriger einzurichten sein als das normale Debugging, da ein Container ein stärkerer Isolationsmechanismus als ein Prozess ist. Insbesondere
- Die Debugging-Engine, die innerhalb des VS Code-Prozesses läuft, muss mit dem zu debuggenden Dienstprozess kommunizieren. Im Fall eines Dienstes, der in einem Container läuft, bedeutet dies Netzwerkkommunikation über ein gemeinsames Netzwerk (typischerweise das Docker-Host-Netzwerk). Der Container muss über das Docker-Host-Netzwerk geeignete Ports für die Debugging-Engine bereitstellen, um eine Verbindung zum Dienstprozess (Node.js) oder zum Debugger-Proxy innerhalb des Containers (.NET) herzustellen.
- Die während der Erstellungszeit generierten Quellcodedateiinformationen sind im Kontext der Erstellungsumgebung (wo VS Code ausgeführt wird) gültig. Das Dateisystem des Containers unterscheidet sich vom Dateisystem der Erstellungsumgebung, und Pfade zu Quellcodedateien müssen neu zugeordnet werden, damit der Debugger die korrekte Quellcodedatei anzeigt, wenn ein Breakpoint getroffen wird.
Aufgrund der oben genannten Bedenken wird generell empfohlen, das normale Debugging zu verwenden und das Debugging im Container bei Bedarf einzusetzen.
Weitere Informationen zum Einrichten des Debuggings in einem Container finden Sie im ASP.NET Core Quickstart, im Node.js Quickstart und in den Container Tools extension task properties (docker-build- und docker-run-Aufgaben).
Nächste Schritte
Lesen Sie weiter, um mehr über Folgendes zu erfahren: