Ինչու Docker-ի կոնտեյներները անտեսում են VPN-ի DNS լուծիչը

VPN-ը միացված է, զննարկիչը հասնում է ներքին կայքերին, իսկ կոնտեյները դեռ չի կարողանում լուծել նույն անունները։ Փաթեթի տեղադրումը մահանում է անվան լուծման սխալով, օրինակ EAI_AGAIN, կամ հավելվածը չի գտնում տվյալների բազայի հոսթ, որը հոսթ մեքենան լուծում է առանց որևէ բողոք։ Կոնտեյները չի օգտագործում այն լուծիչը, որը տեղադրել է VPN-ը։ Docker-ը պատճենել է հոսթի լուծիչի կոնֆիգուրացիան կոնտեյների ստեղծման պահին, և դրանից հետո ոչինչ այն նորից չի պատճենել։

Լուծիչի երկու տեսք մեկ մեքենայի վրա

Linux-ում Docker-ը ստեղծման պահին յուրաքանչյուր կոնտեյների տալիս է հոսթի լուծիչի կոնֆիգուրացիայի պատճեն, զտում է loopback հասցեները և 127.0.0.11 հասցեում գործարկում է ներկառուցված DNS սերվեր, որը հարցումները փոխանցում է դուրս։ VPN հաճախորդը, որը վերագրում է /etc/resolv.conf-ը կոնտեյների գործարկումից հետո, դրա ներսում ոչինչ չի փոխում։ Կոնտեյների վերագործարկումը օգնում է միայն այն դեպքում, երբ այդ պահին հոսթի լուծիչը պատահաբար ճիշտ է։

Docker Desktop-ը macOS-ում կամ Windows-ում ավելացնում է շերտ, որովհետև դեմոնն ապրում է վիրտուալ մեքենայում։ Հոսթի VPN լուծիչը կարող է երբեք տեսանելի չլինել այդ VM-ին, ուստի վերագործարկումը բոլորովին ոչինչ չի փոխում։ Համեմատեք երկու տեսքը լուծում ընտրելուց առաջ՝ docker exec mycontainer cat /etc/resolv.conf հոսթի լուծիչների ցանկի կողքին։

Կոնտեյները, որը թվարկում է հանրային լուծիչ, մինչ հոսթը թվարկում է ներքին, կլուծի հանրային անունները և կձախողվի ներքիններում։ Այդ բաժանումը այս խնդրի ստորագրությունն է։

Տարբերակ A՝ թունելի լուծիչը փոխանցել յուրաքանչյուր կոնտեյներին

Docker-ը ընդունում է DNS կարգավորումներ յուրաքանչյուր կոնտեյների համար, և դա ամենափոքր աշխատող փոփոխությունն է։ Սկզբում կարդացեք VPN-ի լուծիչի հասցեները՝ scutil --dns macOS-ում, resolvectl status կամ հաճախորդի սեփական կարգավիճակի ելքը Linux-ում։ Այնուհետև գործարկեք կոնտեյները դրանցով, օրինակ docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage։ Compose-ում նույն կարգավորումը ծառայության տակ գտնվող ցանկ է, որտեղ այն ապրում է տարբերակների կառավարման մեջ, ոչ թե ինչ-որ մեկի shell-ի պատմության մեջ։

/etc/docker/daemon.json-ում dns զանգվածը կիրառվում է յուրաքանչյուր նոր կոնտեյների վրա, ինչը ավելի կոկիկ է հնչում, քան կա։ Այն կիրառվում է նաև, երբ թունելը կանգնած է, և այդ ժամանակ միայն VPN-ով հասանելի լուծիչը կոտրում է սովորական պատկերների ներբեռնումները։ Կոնտեյներով պարամետրերը ավելի հեշտ են հիմնավորել և ավելի հեշտ՝ հետարկել։

Տարբերակ B՝ թույլ տալ կոնտեյներին կիսել հոսթի ցանցը

Հոսթի ցանցը ամբողջությամբ շրջանցում է պատճենը, որովհետև կոնտեյնը օգտագործում է հոսթի լուծիչը և հոսթի թունելը։ Այն նաև հեռացնում է ցանցային մեկուսացումը, որը հավանաբար ուզում էիք, և Docker Desktop-ի տակ նույն կերպ չի վարվում։ Linux-ում սա պրագմատիկ ընտրություն է միանվագ գործիքի համար, որը պետք է լուծի ներքին անուններ։

Կառուցումների համար երկու տարբերակներից ոչ մեկը չի կիրառվում, քանի որ կառուցման քայլերը չեն ժառանգում գործարկման դրոշները։ Կառուցեք հոսթի ցանցով այնտեղ, որտեղ հարթակը թույլ է տալիս, կամ կախվածությունների տեղադրումը պահեք այն փուլում, որը թունելի կարիք չունի։

Ինչ ոչ մի տարբերակ չի ուղղում

DNS հասցեն անօգուտ է, եթե կոնտեյները դրան երթուղի չունի։ VPN լուծիչը սովորաբար նստում է թունելի հասցեային տարածության ներսում, ուստի կոնտեյնին պետք է ուղի դեպի այդ նախադասությունը։ Docker-ի լռելյայն կամուրջը սովորաբար երթուղավորում է դուրս հոսթի միջով, և դա բավարար է, երբ հոսթն ունի թունելի երթուղին, և փոխանցումը միացված է։ Սեփական հասցեային լողավազաններով հատուկ կամրջային ցանցերը կարող են բախվել VPN ենթացանցի հետ, և այդ ժամանակ հարցումները գնում են բոլորովին այլ տեղ։

Նախքան լուծիչն ինքնին վրիպազերծելը, ստուգեք Docker ցանցի ենթացանցը VPN ենթացանցի դեմ։ Համընկնումն առաջացնում է ձախողում, որը ճիշտ կոտրված DNS սերվերի տեսք ունի։

Ստուգեք կոնտեյների ներսում

Փորձարկեք getent hosts db.internal-ով կոնտեյների ներսում, ոչ թե զննարկիչով կամ լեզվի գործարկման միջավայրով, որովհետև դրանք կիրառում են իրենց DNS քաղաքականությունը և իրենց քեշը։ Եթե getent-ը լուծում է անունը, իսկ հավելվածը դեռ ձախողվում է, լուծիչն այժմ ճիշտ է, և մնացած խնդիրը հավելվածի մակարդակում է։ Եթե այն չի լուծում, DNS քայլն ավարտված չէ։

DNS կարգավորումները փոխելուց հետո վերստեղծեք կոնտեյները։ Գործող կոնտեյների ներսում /etc/resolv.conf-ի խմբագրումը անհետանում է դրա հետ և թաքցնում կոնֆիգուրացիայի խնդիրը ճիշտ այնքան ժամանակ, որքան պահանջվում է ինչ-որ մեկին այն վերագործարկելու համար։