Aplikaciji dodate network_mode: service:vpn, znova zaženete sklad in aplikacija umre, ker se db ne razrešuje več. V datoteki compose ni bilo nič preimenovano, zato sta očitna osumljenca DNS in zbirka podatkov. Dejanska sprememba je manjša in čudnejša: aplikacija ni več član omrežja Compose, kjer to ime obstaja. Dokler se ne odločite, iz katerega imenskega prostora mora zbirka podatkov odgovarjati, je vsak popravek imena gostitelja ugibanje.

Zakaj se ime gostitelja db ni več razreševalo

Storitev, ki uporablja network_mode, nima lastnega naslova v omrežju Compose; izposodi si imenski prostor imenovane storitve. Ta prostor prinese svoje vmesnike, poti, prostor vrat in razreševalnik ter nadomesti priključitev aplikacije na omrežje backend. Ime db nikoli ni bilo abstraktno: živelo je v tem omrežju in se razreševalo prek njegovega vgrajenega DNS. Odstranite priključitev in ime nima kje razrešiti.

To potrdite znotraj vsebnikov in ne z gostitelja. Iskanje, ki v aplikaciji spodleti, v vsebniku zbirke podatkov pa uspe, pomeni, da je ime v redu, članstvo pa ne. Ta izid tudi umesti popravek v topologijo compose in ne v nastavitve razreševalnika aplikacije.

Tri vprašanja pred urejanjem datoteke

Odgovorite po vrsti, ker vsako zoži topologijo. Na čem mora zbirka podatkov odgovarjati: na imenu gostitelja, ki ga uporabljajo drugi vsebniki, ali samo na aplikaciji na loopbacku? Mora aplikacija objaviti vrata na gostitelja, in katera storitev bi jih imela v lasti? Mora biti zbirka podatkov dosegljiva z gostitelja ali z drugega stroja, ali samo znotraj tunela?

Če zbirka podatkov potrebuje svoje ime in aplikacija ničesar ne objavi, ju imejte na ločenih priključitvah. Če mora aplikacija objaviti vrata in vse poteka skozi tunel, postavite zbirko podatkov v imenski prostor VPN in uporabite loopback. Mešanje obojega ustvari sklad, ki se čisto zažene in spodleti pri povezovanju.

Pustite zbirko podatkov tam, kjer je

Manjša sprememba priključi lastnika imenskega prostora na omrežje, ki že vsebuje zbirko podatkov. Aplikacija to priključitev podeduje, ker si deli sklad vpn, in db se razreši natanko kot prej.

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

Ne dodajte networks tudi aplikaciji. Compose to lastnost zavrne skupaj z network_mode v isti storitvi, napaka pa kaže na datoteko in ne na par. Če odjemalec VPN filtrira cilj backend znotraj svojega imenskega prostora, prilagodite tudi njegovo podprto politiko lokalnega omrežja; skupna priključitev ponuja pot, a tega filtra ne razveljavi.

Premaknite zbirko podatkov v imenski prostor

Večja sprememba postavi zbirko podatkov v isti imenski prostor in usmeri aplikacijo na 127.0.0.1 z resničnimi vrati. Dva procesa ne moreta oba vezati istega naslova in istih vrat samo zato, ker sta se zagnala v različnih vsebnikih, zato bo zbirka podatkov, ki posluša tudi na naslovu wildcard, trčila v vse drugo, kar to počne. Pred premikom preverite poslušalca.

Objavljena vrata pripadajo storitvi, ki ima v lasti imenski prostor. Dodajanje ports aplikaciji se zavrne skupaj z network_mode, izmišljanje ločenega naslova aplikacije pa opisuje vmesnik, ki ne obstaja.

Pripravljenost, blokiranje in razreševalnik

depends_on ureja zagon vsebnikov; to ni dokaz, da je tunel aktiven, in ne ustavi prometa, ko tunel pade. Obravnavajte dosegljivost, pripravljenost tunela in blokiranje napak kot tri ločene zahteve. Sklad, ki izpolni samo prvo, na dober dan prestane ročni preizkus, na slab dan pa pušča. Tri odgovore zapišite ob datoteko compose, tja, kamor bo pogledala naslednja oseba.

Deljenje imenskega prostora pomeni tudi, da aplikacija podeduje razreševalnik vsebnika VPN, kar pomaga, ko tunel vsiljuje strežnike DNS, in zmede, ko tega ne počne. Preverite, kaj imenski prostor dejansko vsebuje, namesto da predpostavljate, da velja razreševalnik gostitelja. Referenca storitev Compose dokumentira network_mode, ports in vedenje odvisnosti na enem mestu, vključno s tem, zakaj storitev network_mode nima lastnega naslova.

Sorodni članki