Docker: ուղղորդեք մեկ կոնտեյներ VPN-ով և մյուսը թողեք ուղիղ
Տվեք թունելին իր սեփական կոնտեյները, թույլ տվեք միայն այն ծառայություններին, որոնք դրա կարիքն ունեն, կիսել այդ անվանատարածքը, ապա հաշվի առեք այն, ինչ հաջորդում է սեփականատիրոջը՝ պորտեր, localhost, DNS:
Մեկ հոսթ, երկու աշխատանքային բեռ և մեկ պահանջ, որը բաժանում է նրանց՝ ներբեռնման հաճախորդ, որը պետք է դուրս գա առևտրային VPN-ից, և կառավարման ինտերֆեյս, որը պետք է շարունակի օգտագործել հոսթի կապը։ VPN հաճախորդը հոսթի վրա տեղադրելը անմիջապես խախտում է պահանջը, քանի որ այդ դեպքում երկու բեռներն էլ կիսում են մեկ ելք։ Կաղապարը, որն իրականում աշխատում է, թունելը սեփական կոնտեյների մեջ տեղափոխելն է և թույլ տալ միայն այն բեռներին, որոնք դրա կարիքն ունեն, միանալ այդ կոնտեյների ցանցային անվանատարածքին։ Մնացած ամեն ինչ պահում է Docker-ի սովորական ուղին, և հետագա մանրամասները հետևանք են այն բանի, թե ով է տիրապետում անվանատարածքին։
Ինչու է համատեղ անվանատարածքը փոխում կանոնները
Կոնտեյները, որը միանում է մեկ այլի անվանատարածքին, չի ստանում իր սեփական ցանցային կույտը։ Այն տեսնում է նույն ինտերֆեյսները, նույն երթուղային աղյուսակը և նույն loopback-ը, ինչ այն կոնտեյները, որին միացել է, և հենց դրա համար է կաղապարը օգտակար. բեռը սովորական ձևով լուծում և միանում է, իսկ ներքևի թունելը որսում է երթևեկությունը՝ առանց հավելվածի իմացության։ Գինը այն է, որ յուրաքանչյուր ցանցային կարգավորում այժմ ունի մեկ սեփականատեր, և միացող կոնտեյները նա չէ։
Սեփականության այս կանոնը պատասխանում է կարգավորման հարցերի մեծ մասին դեռ տրվելուց առաջ։ Եթե կարգավորումը ապրում է ցանցային կույտում, այն պատկանում է կողային կոնտեյներին։ Եթե այն նկարագրում է գործընթացը, այն մնում է բեռի հետ։
loopback-ը այն մասն է, որ զարմացնում է մարդկանց։ Միացող կոնտեյների ներսում localhost լուծվում է դեպի կողային կոնտեյների loopback-ը, ոչ թե իր սեփական մասնավորին, ուստի 127.0.0.1-ին կապվող և մեկուսացում ակնկալող ծառայությունը այժմ կիսում է այդ հասցեն թունելի կոնտեյների հետ։
Հրապարակեք պորտերը այն կոնտեյնի վրա, որը տիրապետում է անվանատարածքին
Պորտերի քարտեզագրումը պատկանում է անվանատարածքի սեփականատիրոջը, նույնիսկ երբ լսող գործընթացը աշխատում է մյուս կոնտեյներում։ Հայտարարեք քարտեզագրումը կողային կոնտեյնի վրա, և թող բեռը պահի իր գործընթացի կազմաձևումը անձեռնմխելի։ Միացող ծառայության վրա քարտեզագրումը չի կարող ուժի մեջ մտնել՝ անկախ նրանից, թե շարժիչը մերժում է այն, թե կախված նրանից, թե ինչպես է կոնտեյները գործարկվում, լուռ անտեսում է այն, և դրա համար էլ մի պահ առաջ հասանելի ինտերֆեյսը անհետանում է հենց կաղապարը կիրառվում է։
services:
gluetun:
image: qmcgaw/gluetun
cap_add: [NET_ADMIN]
ports: ["8080:8080"]
client-vpn:
image: example/client
network_mode: "service:gluetun"
client-direct:
image: example/client
ports: ["8081:8080"]Կարդացեք այդ բլոկը որպես երեք որոշում, ոչ թե երեք ծառայություն։ Կողային կոնտեյները տիրապետում է թունելին և հրապարակված պորտին. միացող հաճախորդը ընդհանրապես ցանց չի հայտարարում. ուղիղ հաճախորդը պահում է իր սեփական քարտեզագրումը լռելյայն ցանցում։ Կարողությունը NET_ADMIN այն է, ինչ թույլ է տալիս կողային կոնտեյներին ստեղծել ինտերֆեյսներ և փոխել երթուղիներ, և հենց դա է պատճառը, որ այս կոնտեյնին ավելի շատ արտոնություններ են պետք, քան այն բեռներին, որոնց ծառայում է։
Ուղիղ մնացող ծառայությունը պահում է իր սեփական ցանցը
Այն բեռը, որը չպետք է անցնի թունելով, պահում է լռելյայն կամուրջը կամ իր սեփական օգտատիրոջ կողմից սահմանված ցանցը՝ իր հրապարակված պորտով և իր ելքով։ Գրավիչ է այն միացնել կողային կոնտեյների ցանցին, որպեսզի երկու կոնտեյներները կարողանան խոսել անունով, բայց այդ մեկ քայլը լուռ տեղափոխում է նրա երթևեկությունը թունել։ Եթե նրանք պետք է հասնեն միմյանց, կառուցեք առանձին օգտատիրոջ կողմից սահմանված ցանց, միացրեք երկուսին էլ դրան, և թողեք կողային կոնտեյնը որպես դուրս գալու միակ ուղի։
Առանձին պահեք երկու հարցերը՝ որ կոնտեյներները կարող են հասնել միմյանց, և որը որտեղից է դուրս գալիս։ Դրանց միավորումը ամենատարածված ձևն է, որով այս ձևավորումը նորից դառնում է ամբողջ հոսթն ընդգրկող VPN։
Ձախողումների մատրիցա առաջին ժամվա համար
Առաջին փորձերի մեծ մասը ձախողվում է չորս եղանակներից մեկով, և յուրաքանչյուրն ունի տարբեր պատճառ։ Ստուգեք դրանք այս հերթականությամբ, քանի որ առաջին երկուսը բացատրում են գրեթե բոլոր հաշվետվությունները։
| Symptom | Likely cause |
|---|---|
| Web UI unreachable after the change | Port mapping declared on the joining container instead of the sidecar |
| Both containers show the provider's exit address | The direct service was attached to the sidecar network |
| Internal names stop resolving | Resolver settings live on the host, not in the shared namespace |
| Health check fails but the app works | The check probes localhost, which now means the sidecar |
Չորրորդ տողն այն է, ինչը մարդիկ սխալմամբ ախտորոշում են որպես հավելվածի սխալ։ Բեռի սեփական loopback-ի դեմ գրված ստուգումն այժմ փորձարկում է թունելի կոնտեյները, ուստի այն կամ ձախողվում է, կամ հաղորդում է բոլորովին սխալ ծառայության մասին։
Երբ մեկ հոսթի անուն է թունելի կարիքն ունենում
Երբեմն ամբողջական թունելը չափից շատ է. մեկ ներքին անուն պետք է անցնի կորպորատիվ VPN-ով, մինչ տեղական սոքեթը կամ ցուցադրման կապը շարունակում է աշխատել։ Կոնտեյների ներսում ամբողջական թունելը կոտրում է այդ ուղին և այն ամենը, ինչ հասցեագրված է հոսթին, ուստի երթուղավորեք միայն այն նախածանցը, որն ունի դրա կարիքը։ Հաճախորդի շուրջ բաժանված երթուղավորման փաթաթան դա անում է՝ նշված հոսթն ուղարկելով թունելով և նախորդ երթուղին անձեռնմխելի թողնելով մնացած ամեն ինչի համար։
Ընտրեք սա, երբ պետք է հասնեք միայն մեկ ծառայության և չեք փորձում տեղափոխել կոնտեյների ամբողջ երթևեկությունը։ Սա այլ գործիք է, քան կողային կոնտեյները, և պատասխանում է այլ հարցի։
Ստուգեք, ապա դարձրեք այն վերագործարկման դիմացկուն
Հարցրեք յուրաքանչյուր կոնտեյնի, թե որ հասցեից է այն կարծես գալիս։ Թունելի մեջ գտնվողը պետք է տպի մատակարարի հասցեն, իսկ ուղիղը՝ հոսթի ելքը։ Նույնական պատասխանները նշանակում են, որ ուղիղ ծառայությունը ժառանգել է սխալ անվանատարածքը, կամ հոսթի մակարդակի VPN-ը դեռ որսում է ամեն ինչ, և այդ երկու ուղղումները տարբեր են։ Գործարկեք ստուգումը նորից յուրաքանչյուր compose խմբագրումից հետո, քանի որ մեկ պատճենված ծառայության բլոկը բավական է խնդիրը վերադարձնելու համար։
Երեք բան հակված է ավելի ուշ կոտրվելու։ DNS-ը հետևում է անվանատարածքի սեփականատիրոջը, ուստի լուծիչի և որոնման դոմենի կարգավորումները պատկանում են կողային կոնտեյնին, ոչ թե հոսթին։ Պորտերի փոխանցմամբ VPN-ը վերամիացման ժամանակ փոխում է իր լսող պորտը, ուստի մատակարարի փոխանցված պորտը և կոնտեյնի կողմի լսող պորտը պետք է հետ գրվեն հաճախորդի կազմաձևման կամ պորտերի քարտեզագրման մեջ, սովորաբար փոքր թարմացնողի միջոցով, որը կարդում է մատակարարի API-ն։ Եվ ցանկացած ստուգում, որը գրված է localhost դեմ, այժմ հարցնում է թունելի կոնտեյնին, ոչ թե բեռին։
Գրեք կաղապարը՝ ներառյալ, թե որ կոնտեյնն է տիրապետում անվանատարածքին և որ պորտերն են դրան պատկանում։ Հաջորդ մարդը կավելացնի ծառայություն, կպատճենի սխալ բլոկը և կվերարտադրի այս հոդվածի առաջին ձախողումը։