Proxy-Einstellungen für die S3-Anfragen einer Distribution-Registry
Setzen Sie die Proxy-Einstellungen am Distribution-Registry-Prozess, der auf S3 zugreift, und berücksichtigen Sie Clients, die auf Objektspeicher umgeleitet werden, getrennt.
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.1Fü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.
| Verbindung | Wer konfiguriert oder untersucht |
|---|---|
| Client → Registry | Der eingehende HTTP-Listener der Registry und die Client-Route |
| Daemon → Image-Quelle | Proxy-Einstellungen des Docker-Daemons |
| Registry → S3 | Der 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.