Hold proxy-legitimasjon fra byggetid utenfor Docker-images

For pakkenedlasting under et bygg bør du bruke Dockers forhåndsdefinerte proxy-inndata for bygg i stedet for å lagre en midlertidig rute i Dockerfile ENV. Et POSIX-kall kan gi:

HTTP_PROXY=http://203.0.113.10:8080 \
HTTPS_PROXY=http://203.0.113.10:8080 \
docker build --build-arg HTTP_PROXY --build-arg HTTPS_PROXY .

Erstatt dokumentasjonsendepunktet. Hvis du utelater verdier etter --build-arg-navnene, hentes de fra miljøet i dette kallet. Matchende ARG-deklarasjoner kreves ikke for disse forhåndsdefinerte inndataene.

Docker utelater disse proxy-argumentene fra behandling av byggcache og docker history som standard. Hvis du refererer til dem eksplisitt i Dockerfile, endres denne atferden, så ikke legg til deklarasjoner bare fordi et annet eksempel på byggargument gjør det.

Prosessen mottar fortsatt verdiene. En autentisert URL kan lekke gjennom skrevet miljø, logger, kopiert konfigurasjon eller senere image-operasjoner selv om én historikkvisning utelater den. Dockerfile ENV gjør en rute til en del av det endelige image-miljøet og kan gjøre en proxy som bare brukes ved bygg til en avhengighet for hver container.

Når en kommando trenger sensitivt materiale, gir BuildKit-hemmelighetsmounts et grensesnitt for hemmeligheter ved byggetid. Begrens legitimasjonen til den operasjonen; ikke skriv ut mountet eller kopier innholdet til et image-lag.

Disse byggeinndataene konfigurerer verken daemonens tidligere registerhenting eller en utilgjengelig ekstern byggemaskins vertsrute. Etterpå bør du inspisere det tiltenkte sluttbildet og applikasjonskonfigurasjonen for varige proxy-verdier i stedet for å anta at håndtering av midlertidige inndata fjernet hver kopi.