Jy voeg network_mode: service:vpn by die app, herbegin die stapel, en die app sterf omdat db nie meer oplos nie. Niks is in die compose-lêer hernoem nie, so die ooglopende verdagtes is DNS en die databasis. Die werklike verandering is kleiner en vreemder: die app het opgehou om ’n lid van die Compose-netwerk te wees waar daardie naam bestaan. Tot jy besluit uit watter naamruimte die databasis moet antwoord, is elke hostnaam-regstelling raaiwerk.

Waarom die db-hostnaam ophou oplos het

’n Diens wat network_mode gebruik, het geen eie adres op ’n Compose-netwerk nie; dit leen die genoemde diens se naamruimte. Daardie naamruimte bring sy eie koppelvlakke, roetes, poortruimte en oplosser mee, en dit vervang die app se verbinding aan die backend-netwerk. Die naam db was nooit abstrak nie: dit het op daardie netwerk geleef en deur sy ingeboude DNS opgelos. Verwyder die verbinding en die naam het nêrens om op te los nie.

Bevestig dit van binne die houers eerder as van die gasheer. ’n Opsoek wat in die app misluk maar in die databasishouer slaag, beteken die naam is reg en die lidmaatskap is nie. Daardie resultaat plaas ook die regstelling in die compose-topologie eerder as in die app se oplosser-instellings.

Drie vrae voordat jy die lêer wysig

Antwoord dit in volgorde, want elkeen vernou die topologie. Waarop moet die databasis antwoord: ’n hostnaam wat ander houers gebruik, of net die app op loopback? Moet die app ’n poort na die gasheer publiseer, en watter diens sou dit besit? Moet die databasis van die gasheer of van ’n ander masjien bereikbaar wees, of net van binne die tonnel?

As die databasis sy eie naam nodig het en die app publiseer niks, hou hulle op aparte verbindings. As die app ’n poort moet publiseer en alles loop deur die tonnel, plaas die databasis in die VPN-naamruimte en gebruik loopback. Om die twee te meng lewer ’n stapel wat skoon begin en by verbindingstyd faal.

Hou die databasis waar dit is

Die kleiner verandering verbind die eienaar van die naamruimte aan die netwerk wat reeds die databasis bevat. Die app erf daardie verbinding omdat dit die vpn-stapel deel, en db los presies op soos voorheen.

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

Moenie networks ook by die app voeg nie. Compose verwerp daardie eienskap saam met network_mode in dieselfde diens, en die fout wys na die lêer eerder as na die paar. As die VPN-kliënt die backend-bestemming binne sy naamruimte filter, pas dan ook sy ondersteunde plaaslike-netwerkbeleid aan; ’n gedeelde verbinding bied ’n pad maar oorheers nie daardie filter nie.

Skuif die databasis in die naamruimte in

Die groter verandering plaas die databasis in dieselfde naamruimte en wys die app na 127.0.0.1 met die werklike poort. Twee prosesse kan nie albei dieselfde adres en poort bind net omdat hulle in verskillende houers begin het nie, so ’n databasis wat ook op die wildcard-adres luister, sal bots met wat ook al anders daar luister. Kontroleer die luisteraar voordat jy dit skuif.

Gepubliseerde poorte hoort by die diens wat die naamruimte besit. Om ports by die app te voeg, word saam met network_mode verwerp, en om ’n aparte app-adres te versin beskryf ’n koppelvlak wat nie bestaan nie.

Gereedheid, blokkering en die oplosser

depends_on orden die begin van houers; dit is nie bewys dat die tonnel op is nie, en dit stop nie verkeer wanneer die tonnel val nie. Behandel bereikbaarheid, tonnelgereedheid en foutblokkering as drie aparte vereistes. ’n Stapel wat net die eerste bevredig, slaag op ’n goeie dag ’n handtoets en lek op ’n slegte dag. Skryf die drie antwoorde langs die compose-lêer, waar die volgende persoon sal kyk.

Deel van ’n naamruimte beteken ook dat die app die VPN-houer se oplosser erf, wat help wanneer die tonnel DNS-bedieners stoot en verwar wanneer dit dit nie doen nie. Kontroleer wat die naamruimte werklik bevat in plaas daarvan om aan te neem die gasheer se oplosser geld. Die Compose-diensverwysing dokumenteer network_mode, ports en afhanklikheidsgedrag op een plek, insluitend waarom ’n network_mode-diens geen eie adres het nie.

Verwante artikels