network_mode: service:vpn og det forsvunne db-vertsnamnet

Du legg til network_mode: service:vpn i appen, startar stakken på nytt, og appen døyr fordi db ikkje lenger blir slått opp. Ingenting er omdøypt i compose-fila, så dei openberre mistenkte er DNS og databasen. Den faktiske endringa er mindre og merkelegare: appen slutta å vere medlem av Compose-nettet der namnet finst. Inntil du avgjer kva namnerom databasen skal svare frå, er kvar vertsnamn-retting gjetting.

Kvifor vertsnamnet db slutta å bli slått opp

Ein teneste som brukar network_mode, har inga eiga adresse på eit Compose-nett; ho låner namnerommet til den namngjevne tenesta. Det namnerommet bringer med seg eigne grensesnitt, ruter, portområde og resolver, og det erstattar tilknytinga til appen mot backend-nettet. Namnet db var aldri abstrakt: det levde på det nettet og vart slått opp gjennom den innebygde DNS-en. Fjern tilknytinga, og namnet har ingen stad å bli slått opp.

Stadfest det inne frå containarane i staden for frå verten. Eit oppslag som feilar i appen men lukkast i databasecontainaren, tyder at namnet er i orden og medlemskapen ikkje. Det resultatet plasserer òg rettinga i compose-topologien i staden for i resolverinnstillingane til appen.

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

Svar på dei i rekkjefølgje, fordi kvart svar snevrar inn topologien. Kva skal databasen svare på: eit vertsnamn som andre containarar brukar, eller berre appen på loopback? Skal appen publisere ein port til verten, og kva teneste skulle eige han? Skal databasen vere tilgjengeleg frå verten eller frå ein annan maskin, eller berre inne frå tunnelen?

Viss databasen treng sitt eige namn og appen ikkje publiserer noko, hald dei på separate tilknytingar. Viss appen må publisere ein port og alt går gjennom tunnelen, set databasen i VPN-namnerommet og bruk loopback. Å blande dei to gir ein stakk som startar reint og feilar ved tilkopling.

Lat databasen bli der han er

Den mindre endringa knyter eigaren av namnerommet til nettet som allereie inneheld databasen. Appen arvar den tilknytinga fordi han deler vpn-stakken, og db blir slått opp nøyaktig som før.

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

Ikkje legg networks til appen òg. Compose avviser den eigenskapen saman med network_mode i same teneste, og feilen peikar på fila i staden for på paret. Viss VPN-klienten filtrerer backend-destinasjonen inne i namnerommet sitt, juster òg den støtta lokalnettverkspolicyen hans; ei delt tilknyting gir ein veg, men overstyrer ikkje det filteret.

Flytt databasen inn i namnerommet

Den større endringa set databasen i same namnerom og peikar appen mot 127.0.0.1 med den ekte porten. To prosessar kan ikkje båe binde same adresse og port berre fordi dei starta i ulike containarar, så ein database som òg lyttar på wildcard-adressa, vil kollidere med kva som helst anna som gjer det. Kontroller lyttaren før du flyttar han.

Publiserte portar høyrer til tenesta som eig namnerommet. Å leggje ports til appen blir avvist saman med network_mode, og å finne opp ei eiga appadresse skildrar eit grensesnitt som ikkje finst.

Beredskap, blokkering og resolveren

depends_on ordnar containerstart; det er ikkje prov på at tunnelen er oppe, og det stoppar ikkje trafikk når tunnelen fell. Handsaming av tilgjenge, tunnelberedskap og feilblokkering må sjåast som tre separate krav. Ein stakk som berre oppfyller det første, går gjennom ein manuell test på ein god dag og lekk på ein dårleg. Skriv dei tre svara ved sida av compose-fila, der den neste personen vil sjå.

Namneromsdeling tyder òg at appen arvar resolveren til VPN-containaren, noko som hjelper når tunnelen skyv DNS-tenarar og forvirrar når han ikkje gjer det. Kontroller kva namnerommet faktisk inneheld i staden for å anta at resolveren til verten gjeld. Compose-tenestereferansen dokumenterer network_mode, ports og oppførda til avhengnader på ein stad, inkludert kvifor ei network_mode-teneste ikkje har si eiga adresse.