network_mode: service:vpn og det forsvundne værtsnavn db

Du tilføjer network_mode: service:vpn til appen, genstarter stakken, og appen dør, fordi db ikke længere slår op. Intet er omdøbt i compose-filen, så de oplagte mistænkte er DNS og databasen. Den faktiske ændring er mindre og mærkeligere: appen holdt op med at være medlem af det Compose-netværk, hvor navnet findes. Indtil du beslutter, hvilket navnerum databasen skal svare fra, er enhver værtsnavn-rettelse gætværk.

Hvorfor værtsnavnet db holdt op med at slå op

En tjeneste, der bruger network_mode, har ingen egen adresse på et Compose-netværk; den låner den navngivne tjenestes navnerum. Det navnerum bringer sine egne interfaces, ruter, portområde og resolver med og erstatter appens tilknytning til backend-netværket. Navnet db var aldrig abstrakt: det boede på det netværk og blev slået op via dets indbyggede DNS. Fjern tilknytningen, og navnet har intet sted at slå op.

Bekræft det inde fra containerne i stedet for fra værten. Et opslag, der fejler i appen men lykkes i databasecontaineren, betyder, at navnet er i orden, og medlemskabet ikke er. Det resultat placerer også rettelsen i compose-topologien i stedet for i appens resolverindstillinger.

Tre spørgsmål, før du redigerer filen

Svar på dem i rækkefølge, fordi hvert svar indsnævrer topologien. Hvad skal databasen svare på: et værtsnavn, som andre containere bruger, eller kun appen på loopback? Skal appen udgive en port til værten, og hvilken tjeneste skulle eje den? Skal databasen kunne nås fra værten eller fra en anden maskine, eller kun inde fra tunnelen?

Hvis databasen har brug for sit eget navn, og appen ikke udgiver noget, så hold dem på separate tilknytninger. Hvis appen skal udgive en port, og alt går gennem tunnelen, så sæt databasen i VPN-navnerummet og brug loopback. At blande de to giver en stak, der starter rent og fejler ved forbindelse.

Lad databasen blive, hvor den er

Den mindre ændring knytter navnerummets ejer til det netværk, der allerede indeholder databasen. Appen arver den tilknytning, fordi den deler vpn-stakken, og db slår op præcis som før.

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

Føj ikke networks til appen også. Compose afviser den egenskab sammen med network_mode i samme tjeneste, og fejlen peger på filen i stedet for på parret. Hvis VPN-klienten filtrerer backend-destinationen inde i sit navnerum, skal du også justere dens understøttede lokalnetværkspolitik; en delt tilknytning giver en vej, men tilsidesætter ikke det filter.

Flyt databasen ind i navnerummet

Den større ændring sætter databasen i samme navnerum og peger appen på 127.0.0.1 med den rigtige port. To processer kan ikke begge binde samme adresse og port, bare fordi de startede i forskellige containere, så en database, der også lytter på wildcard-adressen, vil støde sammen med hvad som helst andet, der gør det. Kontroller lytteren, før du flytter den.

Udgivne porte hører til den tjeneste, der ejer navnerummet. At føje ports til appen afvises sammen med network_mode, og at opfinde en separat appadresse beskriver et interface, der ikke findes.

Klarhed, blokering og resolveren

depends_on ordner containeropstart; det er ikke bevis for, at tunnelen er oppe, og det stopper ikke trafik, når tunnelen falder. Behandl tilgængelighed, tunneklarehed og fejlblokering som tre separate krav. En stak, der kun opfylder det første, består en manuel test på en god dag og lækker på en dårlig. Skriv de tre svar ved siden af compose-filen, hvor den næste person vil kigge.

Navnerumsdeling betyder også, at appen arver VPN-containerens resolver, hvilket hjælper, når tunnelen skubber DNS-servere, og forvirrer, når den ikke gør. Kontroller, hvad navnerummet faktisk indeholder, i stedet for at antage, at værtens resolver gælder. Compose-tjenestreference dokumenterer network_mode, ports og afhængighedsadfærd på ét sted, inklusive hvorfor en network_mode-tjeneste ikke har sin egen adresse.