Docker-ի բազային պատկերների ներբեռնում. կառուցողի պրոքսին ընդդեմ build-արգումենտների
Build-քայլերին տրված պրոքսի արգումենտները չեն կարգավորում կառուցողի բոլոր ռեեստրի հարցումները։ Գտեք այն կառուցողին, որը լուծում է բազային պատկերը։
Կառուցումը կարող է ձախողվել FROM-ը լուծելիս՝ նախքան Dockerfile-ի փաթեթների ներբեռնման որևէ քայլի մեկնարկը։ Կառուցողի ռեեստրի հաճախորդին անհրաժեշտ է իր սեփական ուղին այդ բազային պատկերը ստանալու համար։
| Գործողություն | Ուղին պահանջող բաղադրիչը |
|---|---|
| Լուծել և ստանալ բազային պատկերը | Կառուցողի ռեեստրի հաճախորդը |
| Ներբեռնում RUN-ի ընթացքում | Build-քայլը կատարող գործընթացը |
| API-ի կանչ գործարկման ժամանակ | Աշխատող հավելվածը |
Գտեք կառուցողին
Docker-ի լռելյայն դրայվերը կենտրոնանում է դեմոնի վրա։ Այլ Buildx դրայվերներ կարող են օգտագործել առանձին BuildKit կոնտեյներ, Kubernetes կամ հեռավոր ծառայություն։ Կարգավորեք ընտրված դրայվերի աջակցվող պրոքսի մեխանիզմը այնտեղ, որտեղ աշխատում է այդ worker-ը։
Նոութբուքի loopback պրոքսին ինքնաբերաբար հասանելի չէ հեռավոր worker-ից, և տեղական դեմոնի խմբագրումը չի վերակարգավորում այդ հեռավոր կառուցողին։
FROM-ից առաջ ARG-ը կարող է օգնել ընտրել պատկերի հղումը։ Սակայն դրանով այն չի կարգավորում ռեեստրի հաճախորդի ցանցային ուղին։ Ավելի ուշ RUN հրամանները, որոնք գրում են փաթեթի կարգավորումներ կամ տեղադրում վկայագրեր, չեն կարող վերանորոգել այս ավելի վաղ հարցումը։
Վստահություն, հաշիվներ և պահված տվյալներ
Հաստատված CA նյութը պետք է հասանելի լինի ռեեստրի սկզբնական կապը ստուգող բաղադրիչին։ Ռեեստրի և պրոքսի հավատարմագրերը լիազորում են տարբեր կողմերի. ռեեստր մուտքը չի կարող պատասխանել պրոքսի 407-ին։
Պահված պատկերի տվյալները վերաօգտագործող worker-ը կարող է չկրկնել նույն ցանցային հարցումը, ինչ նոր worker-ը։ Համեմատեք փաստացի գրանցված գործողությունը։ Երբ բազային պատկերի հասանելիությունը աշխատի նախատեսված ուղով, ախտորոշեք ցանկացած հետագա build-քայլի ներբեռնում այդ հաջորդ սահմանին։