docker pull VPN-ի միջոցով՝ daemon-ն ունի իր ցանցը

Ձեր նոութբուքը կորպորատիվ VPN-ում է, curl հասնում է ներքին registry-ին, և այնուամենայնիվ docker pull դեռ ընկնում է EOF-ով։ Այս համակցությունը հակասություն չէ։ Ձեր մուտքագրած հրամանը կատարվում է ձեր shell-ում, բայց փոխանցումը կատարվում է այն daemon-ում, որն ընտրել է Docker CLI-ն, և այդ daemon-ը կարող է լինել բոլորովին այլ հոսթի վրա։ Հենց նրա ցանցային ուղին պետք է աշխատի, և հենց նրա proxy-ի կարգավորումներն են գործում։

Սկսեք շարժիչի նույնականացումից, ոչ թե երթուղուց

Գործարկեք docker context show և docker version։ Տարբերակի ելքը տպում է հաճախորդի բաժին և սերվերի բաժին, և սերվերի բլոկը ձեզ ասում է, թե ով է պատասխանել՝ տեղական բնիկ շարժիչ, Docker Desktop-ի վիրտուալ մեքենան, թե հեռավոր մեքենայի daemon։ docker context inspect ցույց կտա ընտրված կոնտեքստի վերջնական կետը, եթե ուզում եք համոզված լինել, և այս հրամաններից ոչ մեկը ոչինչ չի փոխում։

Այնպիսի միջավայրի փոփոխական, ինչպիսին DOCKER_HOST-ն է, կարող է լուռ ուղղել CLI-ն ձեր ենթադրածից տարբեր շարժիչի, և սա է այն սովորական բացատրությունը, երբ նոութբուքը կարծես VPN-ում է, մինչ pull-ը գնում է այլ տեղ։

Daemon-ն ունի իր ցանցային ինքնությունը

Հեռավոր շարժիչին անհրաժեշտ է իր հաստատված ուղին դեպի մասնավոր registry։ Ձեր նոութբուքի VPN հաճախորդը միացնելը տալիս է այդ նոութբուքին երթուղի, բայց լաբորատորիայում կամ ամպային ենթացանցում նստած daemon-ին չի տալիս նույն մասնավոր հասցեն։ Եթե շարժիչը Docker Desktop-ն է, pull-ը տեղի է ունենում նրա վիրտուալ մեքենայի ներսում, որն ունի իր ցանցային և proxy կարգավորումները՝ առանձին ձեր shell-ի միջավայրից։

Այդ պատճառով հոսթի վրա հաջող curl-ը ապացույց է հոսթի մասին և ոչ ավելին։

Պարզեք, թե registry-ի հետ որ փոխանակումն ավարտվեց

Պատկերի pull-ը հաջորդականություն է՝ նույնականացում, manifest-ի ստացում, ապա blob փոխանցումներ, որոնք հաճախ վերահղվում են օբյեկտային պահոց կամ CDN վերջնակետ։ Հաջող docker login-ը ապացուցում է միայն առաջին քայլը, և token-ը կարող է լիովին վավեր լինել, մինչ վերահղված blob հոսթն անհասանելի է daemon-ի ցանցից։ Նախքան որևէ բան փոխելը գրանցեք ճշգրիտ ժամը, պատկերի հղումը և daemon-ի կամ հաճախորդի մատյանի առաջին օգտակար իրադարձությունը։

EOF-ը ինքնին ոչ մի պատճառ չի նշում։ Դա կարող է լինել կտրված կապ, հոսքը գցած proxy, ժամկետի սպառում կամ MTU խնդիր, և առանց ժամանշված իրադարձության նրանց միջև գուշակելը հենց այն ճանապարհն է, որով մարդիկ վերակառուցում են առողջ շարժիչ։ Վերաբերվեք հաճախորդի ելքի բայթային շեղմանը որպես տվյալ, որովհետև ամեն անգամ նույն չափով կանգնող փոխանցումը բոլորովին այլ կենդանի է, քան այն, որը երբեք չի սկսվում։ Գրանցեք երկու արդյունքներն էլ և համեմատեք դրանք փորձերի միջև։

Կարգավորեք այն բաղադրիչը, որը փոխանցում է

Բնիկ Linux շարժիչի համար proxy-ն պատկանում է ծառայության միջավայրին, ոչ թե ձեր shell-ին։ /etc/systemd/system/docker.service.d/-ի տակ գտնվող drop-in ֆայլը HTTP_PROXY, HTTPS_PROXY և NO_PROXY գրառումներով, որին հաջորդում են systemctl daemon-reload-ը և վերագործարկումը, փաստաթղթավորված լուծումն է։ Docker Desktop-ը նույն արժեքները տրամադրում է իր կարգավորումների միջոցով, և shell-ի պրոֆիլը խմբագրելը չի դիպչում դրանցից ոչ մեկին։

Եթե registry-ին պետք է հասնել անմիջապես VPN-ով, daemon-ին անհրաժեշտ են resolver, երթուղի և դիտավորյալ proxy բացառում, ոչ միայն բացառում։ NO_PROXY-ի համապատասխանեցումը յուրաքանչյուր բաղադրիչի համար տողերի համեմատում է, և ենթակա երթուղի չունեցող բացառությունը ստեղծում է ձախողում, որը նման է proxy-ի խնդրի։

Երբ կորպորատիվ TLS ստուգումը գտնվում է հաստատված ուղու վրա, տեղադրեք նրա ստուգված արմատը շարժիչի կամ Desktop-ի աշխատահոսքի միջոցով։ Registry-ն insecure-registries-ին ավելացնելը այլ փոփոխություն է, որը անջատում է վավերացումը, և դա վստահության պահոցի կարգավորում չէ։

Կրկնեք մեկ վերահսկվող pull և ստուգեք, թե ինչ փոխվեց

Փոխեք մեկ սահման, վերագործարկեք այն բաղադրիչը, որին այն պատկանում է, և կրկնեք նույն pull-ը նույն կոնտեքստից։ Ստուգեք ստացված պատկերի հղումը և digest-ը, ոչ թե սխալի բացակայությունը, որովհետև քեշավորված շերտը կարող է երկրորդ փորձին ստիպել անցնել ուղու շատ ավելի փոքր մասով, քան առաջինը։ Պահեք տոմսում այն փոխանցումները, որոնք իրականում տեղի ունեցան, քանի որ դրանք միակ գրառումն են այն մասին, թե ինչ փորձարկեց կրկնությունը իրոք։

Build-ի քայլերն ու աշխատող կոնտեյներներն ունեն իրենց ցանցային կոնտեքստերը, ուստի դրանց վերաբերվեք որպես առանձին հարցեր, երբ ինքնին pull-ն աշխատի։