Docker bazinių atvaizdų traukimas: kūrėjo proxy ir kūrimo argumentai
Kūrimo žingsniams perduoti proxy argumentai nesukonfigūruoja kiekvienos registro užklausos, kurią atlieka kūrėjas. Raskite kūrėją, kuris išsprendžia bazinį atvaizdą.
Kūrimas gali nepavykti sprendžiant FROM prieš paleidžiant bet kurį Dockerfile paketų atsisiuntimo žingsnį. Kūrėjo registro klientui reikia savo maršruto, kad gautų tą bazinį atvaizdą.
| Operacija | Komponentas, kuriam reikia maršruto |
|---|---|
| Išspręsti ir gauti bazinį atvaizdą | Kūrėjo registro klientas |
| Atsisiuntimas per RUN | Procesas, vykdantis kūrimo žingsnį |
| API iškvietimas vykdymo metu | Veikianti programa |
Raskite kūrėją
Numatytoji Docker tvarkyklė sutelkta į demoną. Kitos Buildx tvarkyklės gali naudoti atskirą BuildKit konteinerį, Kubernetes arba nuotolinę paslaugą. Sukonfigūruokite pasirinktos tvarkyklės palaikomą proxy mechanizmą ten, kur dirba tas worker.
Nešiojamojo kompiuterio loopback proxy nėra automatiškai pasiekiamas iš nuotolinio worker, o vietinio demono redagavimas neperkonfigūruoja to nuotolinio kūrėjo.
ARG prieš FROM gali padėti pasirinkti atvaizdo nuorodą. Tačiau taip nesukonfigūruojamas registro kliento tinklo maršrutas. Vėlesnės RUN komandos, rašančios paketų nustatymus arba diegiančios sertifikatus, negali pataisyti šios ankstesnės užklausos.
Pasitikėjimas, paskyros ir podėlyje saugomi duomenys
Patvirtinta CA medžiaga turi būti prieinama komponentui, kuris tikrina pradinį registro ryšį. Registro ir proxy prisijungimo duomenys suteikia teises skirtingoms šalims; prisijungimas prie registro negali atsakyti į proxy 407.
Worker, kuris pakartotinai naudoja podėlyje saugomus atvaizdo duomenis, gali nekartoti tos pačios tinklo užklausos kaip naujas worker. Palyginkite faktiškai užregistruotą operaciją. Kai prieiga prie bazinio atvaizdo veikia numatytu maršrutu, diagnozuokite bet kokį vėlesnį kūrimo žingsnio atsisiuntimą toje kitoje riboje.