network_mode: service:vpn og det forsvunne db-vertsnavnet

Du legger til network_mode: service:vpn i appen, starter stakken på nytt, og appen dør fordi db ikke lenger slås opp. Ingenting er omdøpt i compose-filen, så de åpenbare mistenkte er DNS og databasen. Den faktiske endringen er mindre og merkeligere: appen sluttet å være medlem av Compose-nettverket der navnet finnes. Inntil du bestemmer hvilket navnerom databasen skal svare fra, er hver vertsnavn-rettelse gjetning.

Hvorfor vertsnavnet db sluttet å slås opp

En tjeneste som bruker network_mode, har ingen egen adresse på et Compose-nettverk; den låner navnerommet til den navngitte tjenesten. Det navnerommet bringer med seg egne grensesnitt, ruter, portområde og resolver, og det erstatter appens tilknytning til backend-nettverket. Navnet db var aldri abstrakt: det levde på det nettverket og ble slått opp gjennom den innebygde DNS-en. Fjern tilknytningen, og navnet har ingen steder å slås opp.

Bekreft det inne fra containerne i stedet for fra verten. Et oppslag som feiler i appen men lykkes i databasecontaineren, betyr at navnet er i orden og medlemskapet ikke. Det resultatet plasserer også rettelsen i compose-topologien i stedet for i appens resolverinnstillinger.

Tre spørsmål før du redigerer filen

Svar på dem i rekkefølge, fordi hvert svar snevrer inn topologien. Hva skal databasen svare på: et vertsnavn som andre containere bruker, eller bare appen på loopback? Skal appen publisere en port til verten, og hvilken tjeneste skulle eie den? Skal databasen være tilgjengelig fra verten eller fra en annen maskin, eller bare inne fra tunnelen?

Hvis databasen trenger sitt eget navn og appen ikke publiserer noe, hold dem på separate tilknytninger. Hvis appen må publisere en port og alt går gjennom tunnelen, sett databasen i VPN-navnerommet og bruk loopback. Å blande de to gir en stakk som starter rent og feiler ved tilkobling.

La databasen bli der den er

Den mindre endringen knytter navnerommets eier til nettverket som allerede inneholder databasen. Appen arver den tilknytningen fordi den deler vpn-stakken, og db slås opp nøyaktig som før.

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

Ikke legg networks til appen også. Compose avviser den egenskapen sammen med network_mode i samme tjeneste, og feilen peker på filen i stedet for på paret. Hvis VPN-klienten filtrerer backend-destinasjonen inne i navnerommet sitt, juster også dens støttede lokalnettverkspolicy; en delt tilknytning gir en vei, men overstyrer ikke det filteret.

Flytt databasen inn i navnerommet

Den større endringen setter databasen i samme navnerom og peker appen mot 127.0.0.1 med den ekte porten. To prosesser kan ikke begge binde samme adresse og port bare fordi de startet i forskjellige containere, så en database som også lytter på wildcard-adressen, vil kollidere med hva som helst annet som gjør det. Kontroller lytteren før du flytter den.

Publiserte porter tilhører tjenesten som eier navnerommet. Å legge ports til appen avvises sammen med network_mode, og å finne opp en egen appadresse beskriver et grensesnitt som ikke finnes.

Beredskap, blokkering og resolveren

depends_on ordner containerstart; det er ikke bevis for at tunnelen er oppe, og det stopper ikke trafikk når tunnelen faller. Behandle tilgjengelighet, tunnelberedskap og feilblokkering som tre separate krav. En stakk som bare oppfyller det første, består en manuell test på en god dag og lekker på en dårlig. Skriv de tre svarene ved siden av compose-filen, der den neste personen vil se.

Navneromsdeling betyr også at appen arver resolveren til VPN-containeren, noe som hjelper når tunnelen skyver DNS-servere og forvirrer når den ikke gjør det. Kontroller hva navnerommet faktisk inneholder i stedet for å anta at vertens resolver gjelder. Compose-tjenestreferansen dokumenterer network_mode, ports og oppførselen til avhengigheter på ett sted, inkludert hvorfor en network_mode-tjeneste ikke har sin egen adresse.