network_mode: service:vpn og hið horfna db-hýsilsheiti

Þú bætir network_mode: service:vpn við forritið, endurræsir staflann, og forritið deyr því db leysist ekki lengur. Ekkert var endurnefnt í compose-skránni, svo augljósir grunaðir eru DNS og gagnagrunnurinn. Raunverulega breytingin er minni og undarlegri: forritið hætti að vera meðlimur í Compose-netinu þar sem þetta heiti er til. Þangað til þú ákveður úr hvaða nafnrými gagnagrunnurinn á að svara er önnur hver hýsilsheitisleiðrétting ágiskun.

Hvers vegna db-hýsilsheitið hætti að leysast

Þjónusta sem notar network_mode hefur ekkert eigið vistfang á Compose-neti; hún fær nafnrými hinnar nefndu þjónustu að láni. Það nafnrými kemur með sín eigin viðmót, leiðir, portrými og leysir, og það kemur í stað tengingar forritsins við backend-netið. Heitið db var aldrei óhlutbundið: það bjó á því neti og leystist í gegnum innbyggða DNS þess. Fjarlægðu tenginguna og heitið hefur hvergi að leysast.

Staðfestu þetta innan úr gámum frekar en frá hýsilnum. Uppfletting sem mistekst í forritinu en tekst í gámi gagnagrunnsins þýðir að heitið er í lagi og meðlimurinn ekki. Þessi niðurstaða setur líka lagfæringuna í netlögun compose frekar en í leysirastillingar forritsins.

Þrjár spurningar áður en þú breytir skránni

Svaraðu þeim í röð, því hver og ein þrengir netlögunina. Við hvað á gagnagrunnurinn að svara: hýsilsheiti sem aðrir gámir nota, eða aðeins forritinu á loopback? Á forritið að birta port til hýsilsins, og hvaða þjónusta myndi eiga það? Á gagnagrunnurinn að vera aðgengilegur frá hýsilnum eða annarri vél, eða aðeins innan úr göngunum?

Ef gagnagrunnurinn þarf eigið heiti og forritið birtir ekkert, haltu þeim á aðskildum tengingum. Ef forritið verður að birta port og allt fer í gegnum göngin, settu gagnagrunninn í nafnrými VPN og notaðu loopback. Að blanda þessu tvennu framleiðir stafla sem byrjar hreint og mistekst við tengingu.

Láttu gagnagrunninn vera þar sem hann er

Minni breytingin tengir eiganda nafnrýmisins við netið sem inniheldur nú þegar gagnagrunninn. Forritið erfir þá tengingu því það deilir vpn-staflanum, og db leysist nákvæmlega eins og áður.

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

Bættu networks ekki við forritið líka. Compose hafnar þeim eiginleika við hlið network_mode í sömu þjónustu, og villan bendir á skrána frekar en parið. Ef VPN-viðskiptavinurinn síar backend-áfangastaðinn innan nafnrýmis síns skaltu einnig stilla studda staðarnetstefnu hans; sameiginleg tenging býður leið en hnekkir ekki þeirri síu.

Færðu gagnagrunninn inn í nafnrýmið

Stærri breytingin setur gagnagrunninn í sama nafnrými og beinir forritinu að 127.0.0.1 með raunverulega portinu. Tvö ferli geta ekki bæði bundið sama vistfang og port bara af því að þau byrjuðu í mismunandi gámum, svo gagnagrunnur sem hlustar líka á wildcard-vistfangið mun rekast á hvað sem annað gerir það. Athugaðu hlustandann áður en þú færir hann.

Birt port tilheyra þjónustunni sem á nafnrýmið. Að bæta ports við forritið er hafnað við hlið network_mode, og að finna upp aðskilið forritsvistfang lýsir viðmóti sem er ekki til.

Viðbúnaður, blokkun og leysirinn

depends_on raðar ræsingu gáma; það er ekki sönnun þess að göngin séu uppi og stöðvar ekki umferð þegar göngin falla. Meðhöndlaðu aðgengi, viðbúnað ganganna og blokkun bilana sem þrjár aðskildar kröfur. Stafli sem uppfyllir aðeins þá fyrstu stenst handvirkt próf á góðum degi og lekur á slæmum. Skrifaðu þrjú svör við hlið compose-skrárinnar, þar sem næsta manneskja mun líta.

Að deila nafnrými þýðir líka að forritið erfir leysi VPN-gámsins, sem hjálpar þegar göngin ýta að DNS-þjónum og ruglar þegar þau gera það ekki. Athugaðu hvað nafnrýmið inniheldur í raun í stað þess að gera ráð fyrir að leysir hýsilsins eigi við. Compose-þjónustuviðmiðunin skjalfestir network_mode, ports og hegðun háðra atriða á einum stað, þar á meðal hvers vegna network_mode-þjónusta hefur ekkert eigið vistfang.