network_mode: service:vpn kaj la mankanta db-gastnomo

Vi aldonas network_mode: service:vpn al la apo, restarigas la stakon, kaj la apo mortas ĉar db ne plu solviĝas. Nenio estis renomita en la compose-dosiero, do la evidentaj suspektatoj estas DNS kaj la datumbazo. La reala ŝanĝo estas pli malgranda kaj pli stranga: la apo ĉesis esti membro de la Compose-reto, kie tiu nomo ekzistas. Ĝis vi decidos, el kiu nomspaco la datumbazo devas respondi, ĉiu gastnoma riparo estas konjekto.

Kial la gastnomo db ĉesis solviĝi

Servo uzanta network_mode havas neniun propran adreson sur Compose-reto; ĝi pruntas la nomspacon de la nomita servo. Tiu nomspaco alportas siajn proprajn interfacojn, itinerojn, pordan spacon kaj solvilon, kaj ĝi anstataŭigas la alligon de la apo al la backend-reto. La nomo db neniam estis abstrakta: ĝi vivis sur tiu reto kaj solviĝis per ĝia enkonstruita DNS. Forigu la alligon kaj la nomo havas nenie por solviĝi.

Konfirmu tion el la interno de la ujoj anstataŭ de la gastiganto. Serĉo, kiu malsukcesas en la apo sed sukcesas en la datumbaza ujo, signifas ke la nomo estas bona kaj la membreco ne. Tiu rezulto ankaŭ metas la riparon en la compose-topologion anstataŭ en la solvilajn agordojn de la apo.

Tri demandoj antaŭ ol redakti la dosieron

Respondu ilin laŭorde, ĉar ĉiu mallarĝigas la topologion. Sur kio la datumbazo devas respondi: nomo de gastiganto, kiun uzas aliaj ujoj, aŭ nur la apo sur loopback? Ĉu la apo devas publikigi pordon al la gastiganto, kaj kiu servo posedus ĝin? Ĉu la datumbazo devas esti atingebla de la gastiganto aŭ de alia maŝino, aŭ nur el la interno de la tunelo?

Se la datumbazo bezonas sian propran nomon kaj la apo publikigas nenion, tenu ilin sur apartaj alligoj. Se la apo devas publikigi pordon kaj ĉio pasas tra la tunelo, metu la datumbazon en la VPN-nomspacon kaj uzu loopback. Miksi la du produktas stakon, kiu startas pure kaj malsukcesas ĉe konekto.

Lasu la datumbazon tie, kie ĝi estas

La pli malgranda ŝanĝo alligas la posedanton de la nomspaco al la reto, kiu jam enhavas la datumbazon. La apo heredas tiun alligon ĉar ĝi kunhavigas la vpn-stakon, kaj db solviĝas ĝuste kiel antaŭe.

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

Ne aldonu networks ankaŭ al la apo. Compose malakceptas tiun econ kune kun network_mode en la sama servo, kaj la eraro montras al la dosiero anstataŭ al la paro. Se la VPN-kliento filtros la backend-celon ene de sia nomspaco, ĝustigu ankaŭ ĝian subtenatan lokretan politikon; kunhavigita alligo proponas vojon sed ne superas tiun filtron.

Movu la datumbazon en la nomspacon

La pli granda ŝanĝo metas la datumbazon en la saman nomspacon kaj direktas la apon al 127.0.0.1 kun la reala pordo. Du procezoj ne povas ambaŭ bindumi la saman adreson kaj pordon nur ĉar ili startis en malsamaj ujoj, do datumbazo, kiu ankaŭ aŭskultas sur la wildcard-adreso, kolizios kun kio ajn alia tion faras. Kontrolu la aŭskultanton antaŭ ol movi ĝin.

Publikigitaj pordoj apartenas al la servo, kiu posedas la nomspacon. Aldoni ports al la apo estas malakceptata kune kun network_mode, kaj elpensi apartan apoadreson priskribas interfacon, kiu ne ekzistas.

Preteco, blokado kaj la solvilo

depends_on ordigas la ujostarton; ĝi ne estas pruvo, ke la tunelo funkcias, kaj ĝi ne haltigas trafikon, kiam la tunelo falas. Traktu atingeblon, tunelpretecon kaj fiaskoblokadon kiel tri apartajn postulojn. Stako, kiu plenumas nur la unuan, trapasas manan teston en bona tago kaj likas en malbona. Skribu la tri respondojn apud la compose-dosiero, kie la sekva persono rigardos.

Kunhavigi nomspacon ankaŭ signifas, ke la apo heredas la solvilon de la VPN-ujo, kio helpas, kiam la tunelo puŝas DNS-servilojn, kaj konfuzas, kiam ĝi ne faras tion. Kontrolu, kion la nomspaco efektive enhavas, anstataŭ supozi, ke la solvilo de la gastiganto validas. La Compose-serva referenco dokumentas network_mode, ports kaj la konduton de dependecoj en unu loko, inkluzive de kial servo kun network_mode havas neniun propran adreson.