Docker-alapképek letöltése: a builder proxy vagy a build argumentumok
A build-lépéseknek adott proxy argumentumok nem konfigurálják a builder minden regisztrációs kérését. Keresse meg azt a buildert, amely feloldja az alapképet.
A build meghiúsulhat FROM feloldásakor, mielőtt bármely Dockerfile-csomagletöltő lépés lefutna. A builder regisztrációs kliensének saját útvonalra van szüksége az alapkép megszerzéséhez.
| Művelet | Az útvonalat igénylő összetevő |
|---|---|
| Az alapkép feloldása és letöltése | A builder regisztrációs kliense |
| Letöltés RUN közben | A build-lépést végrehajtó folyamat |
| API hívása futásidőben | A futó alkalmazás |
Keresse meg a buildert
Az alapértelmezett Docker-illesztő a daemonra összpontosít. Más Buildx-illesztők használhatnak dedikált BuildKit-konténert, Kubernetes-t vagy távoli szolgáltatást. Konfigurálja a kiválasztott illesztő által támogatott proxy-mechanizmust ott, ahol az a worker fut.
A laptopon futó loopback proxy nem érhető el automatikusan egy távoli workerből, és a helyi daemon szerkesztése nem konfigurálja át azt a távoli buildert.
A FROM előtti ARG segíthet a képhivatkozás kiválasztásában. Ez azonban nem konfigurálja ezáltal a regisztrációs kliens hálózati útvonalát. A későbbi RUN-parancsok, amelyek csomagbeállításokat írnak vagy tanúsítványokat telepítenek, nem tudják kijavítani ezt a korábbi kérést.
Bizalom, fiókok és gyorsítótárazott adatok
A jóváhagyott CA-anyagnak elérhetőnek kell lennie annak az összetevőnek, amely a kezdeti regisztrációs kapcsolatot ellenőrzi. A regisztrációs és a proxy-hitelesítő adatok különböző feleket jogosítanak fel; a regisztrációs bejelentkezés nem tud válaszolni egy proxy 407-re.
Előfordulhat, hogy a gyorsítótárazott képadatokat újrahasználó worker nem ismétli meg ugyanazt a hálózati kérést, mint egy friss worker. Hasonlítsa össze a ténylegesen naplózott műveletet. Miután az alapkép elérése a szánt útvonalon működik, diagnosztizálja a későbbi build-lépés bármely letöltését ezen a következő határon.