Für eine containerisierte Distribution-Registry mit umgebungsbewusstem HTTP-Transport übergeben Sie die S3-Route an den Registry-Container:

services:
  registry:
    environment:
      HTTP_PROXY: http://proxy.example.internal:8080
      HTTPS_PROXY: http://proxy.example.internal:8080
      NO_PROXY: localhost,127.0.0.1

Fügen Sie dies mit dem vorhandenen Image, Storage, der Authentifizierung und den Volumes zusammen. Das Fragment ist keine vollständige Registry. Der Proxy-Name muss aus diesem Container erreichbar sein, und das Schema muss zum Proxy-Listener passen.

Bestätigen Sie den eingesetzten S3-Treiber und Transport. Die zitierte Quelle von Distribution 2.8.3 verwendet eine AWS-SDK-Session; ein eigener Treiber oder Transport kann eine andere unterstützte Konfiguration erfordern.

VerbindungWer konfiguriert oder untersucht
Client → RegistryDer eingehende HTTP-Listener der Registry und die Client-Route
Daemon → Image-QuelleProxy-Einstellungen des Docker-Daemons
Registry → S3Der Speicher-HTTP-Transport des Registry-Prozesses

Ein erfolgreicher Client-Login beweist nur die erste Route. Der Storage-Treiber stellt seine eigenen Anfragen an S3; der Daemon, der zuvor das Registry-Image gezogen hat, tätigt diese Aufrufe nicht.

Prüfen Sie auch Weiterleitungen bei Blob-Downloads. Distribution kann einen Konsumenten auf Objektspeicher umleiten, wodurch dieser Client S3 direkt erreichen muss. Das Konfigurieren des Registry-Proxys konfiguriert den Konsumenten nicht. Eine Änderung des Weiterleitungsverhaltens ändert den Weg des Blob-Verkehrs; benennen Sie daher den fehlschlagenden Absender und die Operation, bevor Sie diese Einstellung anpassen.

Ähnliche Artikel