Docker-ի pool-ի համընկնման սխալը VPN երթուղու խնդիր չէ

Docker-ը հրաժարվում է ցանց ստեղծել այն հաղորդագրությամբ, որ pool-ը համընկնում է մյուսի հետ այս հասցեային տարածքում, և ինչ-որ մեկը որոշում է, որ VPN երթուղին պետք է լինի պատճառը։ Դա չի կարող լինել։ Այդ սխալն առաջանում է, երբ pool-ը բաշխվում է, նախքան թեկուզ մեկ փաթեթի գոյությունը, և ձեռքով արված միջուկի երթուղին ոչ մի ազդեցություն չունի դրա վրա։ VPN-ը կարևորվում է մեկ քայլ անց, երբ արդեն հասցե ունեցող կոնտեյները դադարում է հասանելի լինել երթուղու հայտնվելուց հետո։ Երկու խնդիր, ապացույցների երկու հավաքածու, և դրանք խառնելը տալիս է փոփոխություն, որը ոչ մեկը չի շտկում։

Երկու նմանատիպ սխալ

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

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

Երկուսն էլ հասցեային պլանի խնդիրներ են։ Միայն մեկն է Docker-ի խնդիր։

Սկզբում կարդացեք բաշխված pool-երը

Թվարկեք ցանցերը և ստուգեք նրանք, որոնք կարող են հատվել։ Ենթացանցը գտնվում է IPAM կարգավորումներում, իսկ միացված կոնտեյներները թվարկվում են առանձին։

docker network ls
docker network inspect EXISTING_NETWORK

Համեմատեք այդ ենթացանցը նոր ցանցի պահանջած pool-ի հետ և հիշեք, որ Compose-ը յուրաքանչյուր նախագծի համար ստեղծում է իր սեփական լռելյայն ցանցը։ Մոռացված նախագծի հետ կոնֆլիկտը ճիշտ նույն տեսքն ունի, ինչ դեմոնի հետ կոնֆլիկտը։

Ծառայության վրա ստատիկ ipv4_address-ը մեկ կոնտեյների հասցե է, ոչ թե pool-ի սահմանումը։ Այն փոխելը չի վերացնում համընկնումը, քանի որ համընկնումը ցանցերի ենթացանցերի միջև է, ոչ թե կոնտեյներների միջև։ Docker-ի network-create տեղեկատու սովորական կամրջային բաշխման համար պահանջում է չհամընկնող ենթացանցեր և փաստաթղթավորում է, թե ինչպես բացահայտ ընտրել մեկը։

Ընտրեք նախածանց, որը դիմանում է VPN-ին

Ակնթարթային կոնֆլիկտը և ապագա երթուղին որոշվում են նույն ընտրությամբ, ուստի արեք այն մեկ անգամ։ Համեմատեք թեկնածու տիրույթը LAN-ի, հյուրընկալողի հասանելի յուրաքանչյուր VPN նպատակակետի և օգտագործվող ցանկացած այլ overlay-ի հետ։

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

Գրեք ընտրված տիրույթները մի տեղ, որտեղից հաջորդ նախագիծը կկարողանա կարդալ դրանք։ Բաշխված նախածանցների մեկտողանոց գրանցամատյանն ավելի էժան է, քան չբացատրված ժամկետանցումների մեկ շաբաթը։

Ցանցը դիտավորյալ դուրս բերեք կամ փոխեք

Նոր Compose ցանցի համար սահմանեք չօգտագործված նախածանցը ցանցի IPAM կարգավորումներում։ Գոյություն ունեցող նախագծի համար պլանավորեք վերահամարակալումը. հաստատուն հասցեները, կախյալ ծառայությունները և ցանցի վերստեղծման քայլը բոլորը պետք է հաշվի առնվեն, քանի որ YAML-ը խմբագրելը չի վերահամարակալում աշխատող ցանցը։

Եթե հնացած ցանցն է տիրում կոնֆլիկտային բաշխմանը, նախքան այն հեռացնելը ստուգեք, թե ով է միացված։ docker network rm-ը հրաժարվում է, քանի դեռ կան ակտիվ endpoint-ներ, իսկ docker stop-ը վերցնում է կոնտեյների անուններ կամ ID-ներ, ոչ թե ցանցի անուն։ Կոնտեյների կանգնեցումը նույնպես չի հեռացնում pool-ը պահող ցանցի սահմանումը։

Լայն prune-ը ախտորոշիչ գործիք չէ։ Այն հասնում է անկապ նախագծերին և ոչնչացնում է այն ապացույցները, որոնք դուք պատրաստվում էիք հավաքել։

Լռելյայն pool-երը օգնում են միայն հաջորդ բաշխմանը

Դեմոնի լռելյայն հասցեային pool-ի կարգավորումը բարելավում է ապագա ավտոմատ բաշխումները՝ դրանք պահելով ձեր վերապահած տիրույթներից դուրս։ Այն հետադարձ ուժով չի վերահասցեավորում արդեն գոյություն ունեցող ցանցերը, և չի լուծում բացահայտ ենթացանց, որը համընկնում է մեկ այլ բացահայտ ենթացանցի հետ։

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

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

Աշխատանքի հերթականությունը. կարդացեք բաշխված pool-երը, ընտրեք նախածանց, որը շրջանցում է և՛ Docker-ը, և՛ VPN նպատակակետերը, դիտավորյալ վերստեղծեք ցանցը, ապա փորձարկեք մեկ հարցում թունելը բարձրացված վիճակում։