network_mode: service:vpn և անհետացած db հոսթանունը

Դուք ավելացնում եք network_mode: service:vpn հավելվածին, վերագործարկում եք փաթեթը, և հավելվածը մահանում է, որովհետև db այլևս չի լուծվում։ Compose ֆայլում ոչինչ չի վերանվանվել, ուստի ակնհայտ կասկածյալներն են DNS-ը և տվյալների բազան։ Իրական փոփոխությունն ավելի փոքր և տարօրինակ է. հավելվածը դադարել է լինել այն Compose ցանցի անդամը, որտեղ գոյություն ունի այդ անունը։ Քանի դեռ չեք որոշել, թե որ անունների տարածությունից պետք է պատասխանի տվյալների բազան, հոսթանվան յուրաքանչյուր ուղղում ենթադրություն է։

Ինչու db հոսթանունը դադարեց լուծվել

network_mode օգտագործող ծառայությունը Compose ցանցում սեփական հասցե չունի. այն փոխառում է անվանված ծառայության անունների տարածությունը։ Այդ տարածությունը բերում է իր ինտերֆեյսները, երթուղիները, պորտային տարածությունը և լուծիչը, և այն փոխարինում է հավելվածի կապը backend ցանցի հետ։ db անունը երբեք վերացական չի եղել. այն ապրում էր այդ ցանցում և լուծվում էր ներկառուցված DNS-ի միջոցով։ Հեռացրեք կապը, և անունը տեղ չունի լուծվելու։

Հաստատեք դա կոնտեյներների ներսից, ոչ թե հոսթից։ Դիտարկումը, որը ձախողվում է հավելվածում, բայց հաջողվում է տվյալների բազայի կոնտեյներում, նշանակում է, որ անունը կարգին է, իսկ անդամությունը՝ ոչ։ Այդ արդյունքը ուղղումը դնում է compose տոպոլոգիայի մեջ, ոչ թե հավելվածի լուծիչի կարգավորումների։

Երեք հարց ֆայլը խմբագրելուց առաջ

Պատասխանեք դրանց հերթով, որովհետև ամեն մեկը նեղացնում է տոպոլոգիան։ Ինչի՞ վրա պետք է պատասխանի տվյալների բազան. հոսթանվան, որն օգտագործում են այլ կոնտեյներներ, թե՞ միայն հավելվածին loopback-ում։ Արդյո՞ք հավելվածը պետք է պորտ հրապարակի հոսթի համար, և ո՞ր ծառայությունը կտիրեր այն։ Արդյո՞ք տվյալների բազան պետք է հասանելի լինի հոսթից կամ այլ մեքենայից, թե՞ միայն թունելի ներսից։

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

Թողեք տվյալների բազան իր տեղում

Ավելի փոքր փոփոխությունը կապում է անունների տարածության տիրոջը այն ցանցին, որն արդեն պարունակում է տվյալների բազան։ Հավելվածը ժառանգում է այդ կապը, որովհետև կիսում է vpn փաթեթը, և db լուծվում է ճիշտ ինչպես առաջ։

services:
  vpn:
    networks:
      - backend
  app:
    network_mode: service:vpn
  db:
    networks:
      - backend
networks:
  backend:

Չավելացնեք networks նաև հավելվածին։ Compose-ը մերժում է այդ հատկությունը network_mode-ի կողքին նույն ծառայության մեջ, և սխալը ցույց է տալիս ֆայլը, ոչ թե զույգը։ Եթե VPN հաճախորդը զտում է backend նպատակակետը իր անունների տարածության ներսում, կարգավորեք նաև նրա աջակցվող լոկալ ցանցի քաղաքականությունը. համատեղ կապը ուղի է առաջարկում, բայց չի վերացնում այդ զտիչը։

Տեղափոխեք տվյալների բազան անունների տարածություն

Ավելի մեծ փոփոխությունը տեղադրում է տվյալների բազան նույն անունների տարածության մեջ և հավելվածը ուղղում է 127.0.0.1 հասցեին իրական պորտով։ Երկու պրոցես չեն կարող երկուսն էլ կապել նույն հասցեն և պորտը միայն այն պատճառով, որ սկսվել են տարբեր կոնտեյներներում, ուստի wildcard հասցեում նույնպես լսող տվյալների բազան բախվելու է այդ անող ցանկացած այլ բանի հետ։ Ստուգեք լսողին տեղափոխելուց առաջ։

Հրապարակված պորտերը պատկանում են անունների տարածությանը տիրող ծառայությանը։ ports հավելվածին ավելացնելը մերժվում է network_mode-ի կողքին, և հավելվածի առանձին հասցե հորինելը նկարագրում է ինտերֆեյս, որը գոյություն չունի։

Պատրաստվածություն, արգելափակում և լուծիչ

depends_on-ը կարգավորում է կոնտեյներների մեկնարկը. դա ապացույց չէ, որ թունելը աշխատում է, և այն չի կանգնեցնում երթևեկությունը, երբ թունելը ընկնում է։ Վերաբերվեք հասանելիությանը, թունելի պատրաստվածությանը և խափանումների արգելափակմանը որպես երեք առանձին պահանջ։ Փաթեթը, որը բավարարում է միայն առաջինը, լավ օրը անցնում է ձեռքով փորձարկումը և վատ օրը արտահոսում է։ Գրեք երեք պատասխանները compose ֆայլի կողքին, որտեղ կնայի հաջորդ մարդը։

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