Proksi-agordoj por la S3-petoj de Distribution-registro
Metu proksi-agordojn en la Distribution-registra procezo kiu aliras S3, kaj kalkulu aparte la klientojn plusenditajn al objekta konservejo.
Por ujigita Distribution-registro uzanta medikonscian HTTP-transporton, pasigu la S3-vojon en la registran ujon:
services:
registry:
environment:
HTTP_PROXY: http://proxy.example.internal:8080
HTTPS_PROXY: http://proxy.example.internal:8080
NO_PROXY: localhost,127.0.0.1Kunfandu tion kun la ekzistanta image, konservejo, aŭtentigo kaj volumes. La fragmento ne estas kompleta registro. La proksa nomo devas esti atingebla el tiu ujo, kaj la skemo devas kongrui kun la proksa aŭskultanto.
Konfirmu la efektivigitan S3-stirilon kaj transporton. La citita fonto de Distribution 2.8.3 uzas AWS SDK-sesion; propra stirilo aŭ transporto eble bezonas alian subtenatan agordon.
| Konekto | Kiu agordas aŭ esploras |
|---|---|
| Kliento → registro | La envena HTTP-aŭskultanto de la registro kaj la klienta vojo |
| Demono → image-fonto | Proksi-agordoj de la Docker-demono |
| Registro → S3 | La konserveja HTTP-transporto de la registra procezo |
Sukcesa klienta ensaluto pruvas nur la unuan vojon. La konserveja stirilo sendas proprajn petojn al S3; la demono kiu antaŭe eltiris la registran image ne faras tiujn alvokojn.
Inspektu ankaŭ plusendojn dum blob-elŝutoj. Distribution povas plusendi konsumanton al objekta konservejo, donante al tiu kliento postulon pri rekta S3-atingeblo. Agordi la prokson de la registro ne agordas la konsumanton. Ŝanĝi la plusendan konduton ŝanĝas kien fluas la blobtrafiko, do nomu la malsukcesantan sendanton kaj operacion antaŭ ol ŝanĝi tiun agordon.