Verwenden Sie Dev Proxy in Dev-Containern und GitHub Codespaces

Auf einen Blick
Ziel: Installieren von Dev Proxy in einem Entwicklercontainer oder GitHub Codespaces
Zeit: 10 Minuten
Voraussetzungen: Ein Projekt mit einer devcontainer.json Datei, Docker oder GitHub Codespaces

Wenn Sie in einem Dev Container oder in GitHub Codespaces entwickeln, können Sie Dev Proxy mithilfe des Dev Proxy Dev Container Feature installieren. Das Feature installiert Dev Proxy im Container und generiert nach dem Erstellen des Containers ein für den Container eindeutiges Dev Proxy-Stammzertifikat und stuft es als vertrauenswürdig ein. Sie müssen die Schritte beim ersten Start nicht ausführen, um dem Zertifikat selbst zu vertrauen.

Hinzufügen des Dev-Proxyfeatures zu Ihrem Dev-Container

Um Dev Proxy in Ihrem Dev-Container zu installieren, fügen Sie das Dev Proxy-Feature dem .devcontainer/devcontainer.json Abschnitt Ihrer features Datei hinzu:

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/dotnet/dev-proxy/dev-proxy:1": {}
  }
}

Erstellen Sie den Container neu, oder erstellen Sie einen neuen Codespace, um die Änderung anzuwenden. Überprüfen Sie nach dem Start des Containers, ob Dev Proxy installiert ist:

devproxy --version

Hinweis

Das Feature wird separat vom Dev-Proxy versioniert. ghcr.io/dotnet/dev-proxy/dev-proxy:1 bezieht sich auf Version 1 des Features. Um auszuwählen, welche Version von Dev Proxy installiert werden soll, verwenden Sie die version Option.

Funktion konfigurieren

Das Feature unterstützt die folgenden Optionen:

Option Description Typ Standard
version Zu installierende Dev Proxy-Version: latest, beta oder eine bestimmte Version wie 4.0.0 oder v4.0.0. string latest
trustCertificate Nachdem der Container erstellt wurde, generieren Sie ein dev Proxy-Stammzertifikat, das für den Container eindeutig ist, und vertrauen Sie diesem systemweit und für allgemeine Laufzeiten. boolean true

Um beispielsweise eine bestimmte Version von Dev Proxy zu installieren, verwenden Sie die folgende Konfiguration:

{
  "features": {
    "ghcr.io/dotnet/dev-proxy/dev-proxy:1": {
      "version": "4.0.0"
    }
  }
}

Um die neuesten Vorschaufunktionen auszuprobieren, setzen Sie version auf beta. Wenn Sie eine Betaversion installieren, fügt das Feature auch den devproxy-beta Befehl hinzu.

Wenn Sie Dev Proxy in einer Konfiguration für gemeinsam genutzte Entwicklercontainer verwenden, sollten Sie Dev Proxy stattdessen an eine bestimmte Version anheften, anstelle von latest oder beta. Auf diese Weise stellen Sie sicher, dass jeder, der am Projekt arbeitet, dieselbe Version von Dev Proxy verwendet.

So verarbeitet die Funktion das Stammzertifikat

Dev Proxy verwendet ein Stammzertifikat zum Entschlüsseln von HTTPS-Datenverkehr. Das Feature generiert das Zertifikat nicht, wenn es das Image erstellt. Wenn dies der Fall wäre, würde das Zertifikat und sein privater Schlüssel in einer Imageebene enden, und jeder, der dasselbe Image oder Codespaces Prebuild verwendet, würde dieselbe vertrauenswürdige Zertifizierungsstelle gemeinsam nutzen.

Stattdessen bietet die Funktion, nachdem der Container erstellt wurde (postCreateCommand):

  1. Wird als Remotebenutzer ausgeführt devproxy cert ensure , um ein für den Container eindeutiges Stammzertifikat zu generieren.
  2. Fügt das Zertifikat dem Systemzertifikatspeicher (/usr/local/share/ca-certificates) hinzu, sodass curl, .NET und andere Tools, die den Systemspeicher verwenden, dem Zertifikat vertrauen.

Einige Laufzeiten verwenden nicht den Systemzertifikatspeicher, daher legt das Feature die folgenden Umgebungsvariablen fest, damit sie auf das System-CA-Bundle verweisen (/etc/ssl/certs/ca-certificates.crt):

Variable Verwendet von
NODE_EXTRA_CA_CERTS Node.js
REQUESTS_CA_BUNDLE Python requests
SSL_CERT_FILE Python und andere OpenSSL-basierte Tools

Um dem Zertifikat zu vertrauen, installiert das Feature ein Hilfsskript mit Eigentümer root und ermöglicht es dem Remotebenutzer, es sudo ohne Kennwort auszuführen. Wenn Sie nicht möchten, dass das Feature das Zertifikat generiert und dem Zertifikat vertraut, legen Sie trustCertificate auf false fest:

{
  "features": {
    "ghcr.io/dotnet/dev-proxy/dev-proxy:1": {
      "trustCertificate": false
    }
  }
}

Important

Das Feature konfiguriert nicht Java Keystores. Daher vertrauen Java Apps dem Dev Proxy-Stammzertifikat nicht.

Python 3.13 und höher aktivieren die strenge Zertifikatsüberprüfung, wodurch die Zertifikate abgelehnt werden, die Dev Proxy v3 und frühere Versionen für abgefangene Hosts erzeugen. Um APIs aus Python 3.13 oder neuer über Dev Proxy aufzurufen, verwenden Sie Dev Proxy v4 oder neuer.

Dev Proxy im Dev-Container verwenden

Das Feature startet keinen Dev-Proxy und legt die Umgebungsvariablen HTTP_PROXY oder HTTPS_PROXY für den gesamten Container nicht fest. Containerweite Proxyvariablen würden Paketmanager, Git und den Datenverkehr von VS Code selbst über Dev Proxy weiterleiten, wodurch sie nicht mehr funktionieren, wenn Dev Proxy nicht ausgeführt wird.

Um Dev Proxy zu verwenden, starten Sie ihn in einem Terminal im Entwicklercontainer mit Ihrer Konfigurationsdatei:

devproxy --config-file .devproxy/devproxyrc.json

Konfigurieren Sie dann die App, die Sie testen, um Dev Proxy zu verwenden. Um z. B. Anfragen von einer Node.js-App über Dev Proxy weiterzuleiten, starten Sie die App mit der HTTPS_PROXY Umgebungsvariable:

HTTPS_PROXY=http://127.0.0.1:8000 npm start

Weitere Informationen zum Konfigurieren Ihrer App für die Verwendung von Dev Proxy finden Sie im Leitfaden für Ihre Technologie, z. B. Verwenden von Dev Proxy mit Node.js Anwendungen oder Verwenden von Dev Proxy mit .NET Anwendungen.

Dev Proxy Toolkit

Das Feature fügt die Dev Proxy Toolkit-Erweiterung zu VS Code im Entwicklercontainer hinzu. Wenn Sie die Erweiterung nicht installieren möchten, schließen Sie sie in Ihrer devcontainer.json Datei aus:

{
  "features": {
    "ghcr.io/dotnet/dev-proxy/dev-proxy:1": {}
  },
  "customizations": {
    "vscode": {
      "extensions": ["-garrytrinder.dev-proxy-toolkit"]
    }
  }
}

Unterstützte Bilder

Das Feature unterstützt Debian- und Ubuntu-basierte Bilder auf x64 und arm64. Alpine und andere musl-basierte Images werden nicht unterstützt.

Siehe auch

  • Zuletzt aktualisiert um