Docker-basisbeelde aftrek: bouer-proxy teenoor bou-argumente
Proxy-argumente wat aan boustappe verskaf word, konfigureer nie elke registerversoek wat die bouer maak nie. Vind die bouer wat die basisbeeld oplos.
'n Bou kan misluk terwyl FROM opgelos word voordat enige Dockerfile-pakketlaaistap uitgevoer word. Die bouer se registerkliënt het sy eie roete nodig om daardie basisbeeld te verkry.
| Bewerking | Komponent wat die roete nodig het |
|---|---|
| Los die basisbeeld op en haal dit | Die bouer se registerkliënt |
| Aflaai tydens RUN | Die proses wat die boustap uitvoer |
| Roep 'n API tydens looptyd | Die toepassing wat loop |
Vind die bouer
Die standaard Docker-drywer sentreer op die daemon. Ander Buildx-drywers kan 'n toegewyde BuildKit-houer, Kubernetes of 'n afgeleë diens gebruik. Konfigureer die gekose drywer se ondersteunde proxy-meganisme waar daardie werker loop.
'n Skootrekenaar se loopback-proxy is nie outomaties bereikbaar vanaf 'n afgeleë werker nie, en om die plaaslike daemon te wysig herkonfigureer nie daardie afgeleë bouer nie.
'n ARG voor FROM kan help om die beeldverwysing te kies. Dit konfigureer egter nie daardeur die registerkliënt se netwerkroete nie. Latere RUN-opdragte wat pakketinstellings skryf of sertifikate installeer, kan nie hierdie vroeëre versoek herstel nie.
Vertroue, rekeninge en gekasde data
Goedgekeurde CA-materiaal moet beskikbaar wees vir die komponent wat die aanvanklike registerverbinding valideer. Registergeloofsbriewe en proxygeloofsbriewe magtig verskillende partye; 'n registeraanmelding kan nie 'n proxy 407 beantwoord nie.
'n Werker wat gekasde beelddata hergebruik, herhaal dalk nie dieselfde netwerkversoek as 'n nuwe werker nie. Vergelyk die werklik gelogde bewerking. Sodra toegang tot die basisbeeld deur die beoogde roete werk, ondersoek enige latere aflaai in die boustap by daardie volgende grens.