network_mode: service:vpn un pazudušais db resursdatora nosaukums

Jūs pievienojat network_mode: service:vpn lietotnei, restartējat steku, un lietotne mirst, jo db vairs netiek atrisināts. Compose failā nekas netika pārdēvēts, tāpēc acīmredzamie aizdomās turamie ir DNS un datubāze. Faktiskās izmaiņas ir mazākas un dīvainākas: lietotne pārstāja būt tā Compose tīkla dalībniece, kurā šis nosaukums pastāv. Kamēr neizlemsiet, no kuras nosaukumtelpas datubāzei jāatbild, katrs resursdatora nosaukuma labojums ir minējums.

Kāpēc db resursdatora nosaukums pārstāja atrisināties

Pakalpojumam, kas izmanto network_mode, nav savas adreses Compose tīklā; tas aizņemas nosauktā pakalpojuma nosaukumtelpu. Šī telpa līdzi nes savus interfeisus, maršrutus, portu telpu un atrisinātāju, un tā aizstāj lietotnes piesaisti backend tīklam. Nosaukums db nekad nav bijis abstrakts: tas dzīvoja šajā tīklā un tika atrisināts ar tā iebūvēto DNS. Noņemiet piesaisti, un nosaukumam nav kur atrisināties.

Apstipriniet to konteineru iekšienē, nevis no resursdatora. Meklējums, kas lietotnē neizdodas, bet datubāzes konteinerā izdodas, nozīmē, ka nosaukums ir kārtībā un dalība nav. Šis rezultāts arī novieto labojumu compose topoloģijā, nevis lietotnes atrisinātāja iestatījumos.

Trīs jautājumi pirms faila rediģēšanas

Atbildiet uz tiem pēc kārtas, jo katrs sašaurina topoloģiju. Uz ko datubāzei jāatbild: uz resursdatora nosaukumu, ko izmanto citi konteineri, vai tikai uz lietotni uz loopback? Vai lietotnei jāpublicē ports uz resursdatoru, un kurš pakalpojums to piederētu? Vai datubāzei jābūt sasniedzamai no resursdatora vai citas mašīnas, vai tikai no tuneļa iekšienes?

Ja datubāzei vajag savu nosaukumu un lietotne neko nepublicē, turiet tos atsevišķos savienojumos. Ja lietotnei jāpublicē ports un viss iet caur tuneli, ievietojiet datubāzi VPN nosaukumtelpā un izmantojiet loopback. Abu sajaukšana rada steku, kas sākas tīri un neizdodas savienošanas brīdī.

Atstājiet datubāzi tur, kur tā ir

Mazākās izmaiņas pievieno nosaukumtelpas īpašnieku tīklam, kurā jau ir datubāze. Lietotne manto šo piesaisti, jo kopīgo vpn steku, un db tiek atrisināts tieši tāpat kā iepriekš.

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

Nepievienojiet networks arī lietotnei. Compose noraida šo īpašību kopā ar network_mode tajā pašā pakalpojumā, un kļūda norāda uz failu, nevis uz pāri. Ja VPN klients filtrē backend galamērķi savā nosaukumtelpā, pielāgojiet arī tā atbalstīto vietējā tīkla politiku; kopīga piesaiste piedāvā ceļu, bet neatsauc šo filtru.

Pārvietojiet datubāzi nosaukumtelpā

Lielākās izmaiņas ievieto datubāzi tajā pašā nosaukumtelpā un vērš lietotni uz 127.0.0.1 ar īsto portu. Divi procesi nevar abi saistīt vienu un to pašu adresi un portu tikai tāpēc, ka tie sākti dažādos konteineros, tāpēc datubāze, kas klausās arī uz wildcard adreses, sadursies ar visu citu, kas to dara. Pārbaudiet klausītāju pirms pārvietošanas.

Publicētie porti pieder pakalpojumam, kuram pieder nosaukumtelpa. ports pievienošana lietotnei tiek noraidīta kopā ar network_mode, un atsevišķas lietotnes adreses izgudrošana apraksta interfeisu, kas neeksistē.

Gatavība, bloķēšana un atrisinātājs

depends_on sakārto konteineru palaišanu; tas nav pierādījums, ka tunelis darbojas, un tas neaptur datu plūsmu, kad tunelis krīt. Uztveriet sasniedzamību, tuneļa gatavību un kļūmju bloķēšanu kā trīs atsevišķas prasības. Steks, kas apmierina tikai pirmo, iztur manuālu testu labā dienā un noplūst sliktā. Uzrakstiet trīs atbildes blakus compose failam, tur, kur skatīsies nākamais cilvēks.

Nosaukumtelpas kopīgošana nozīmē arī to, ka lietotne manto VPN konteinera atrisinātāju, kas palīdz, kad tunelis uzspiež DNS serverus, un mulsina, kad tas to nedara. Pārbaudiet, ko nosaukumtelpa faktiski satur, nevis pieņemiet, ka ir spēkā resursdatora atrisinātājs. Compose pakalpojumu uzziņa vienuviet dokumentē network_mode, ports un atkarību uzvedību, tostarp to, kāpēc network_mode pakalpojumam nav savas adreses.