network_mode: service:vpn och det försvunna db-värdnamnet

Du lägger till network_mode: service:vpn i appen, startar om stacken, och appen dör eftersom db inte längre slås upp. Ingenting har bytt namn i compose-filen, så de uppenbara misstänkta är DNS och databasen. Den faktiska ändringen är mindre och märkligare: appen slutade vara medlem i Compose-nätverket där namnet finns. Tills du bestämmer vilken namnrymd databasen ska svara från är varje värdnamnsrättelse en gissning.

Varför värdnamnet db slutade slås upp

En tjänst som använder network_mode har ingen egen adress på ett Compose-nätverk; den lånar den namngivna tjänstens namnrymd. Den namnrymden tar med egna gränssnitt, rutter, portutrymme och resolver, och den ersätter appens anslutning till backend-nätverket. Namnet db var aldrig abstrakt: det levde på det nätverket och slogs upp via dess inbyggda DNS. Ta bort anslutningen och namnet har ingenstans att slås upp.

Bekräfta det inifrån containrarna i stället för från värden. En uppslagning som misslyckas i appen men lyckas i databascontainern betyder att namnet är i ordning och medlemskapet inte. Det resultatet placerar också rättelsen i compose-topologin i stället för i appens resolverinställningar.

Tre frågor innan du redigerar filen

Svara på dem i ordning, eftersom varje svar snävar in topologin. Vad ska databasen svara på: ett värdnamn som andra containrar använder, eller bara appen på loopback? Måste appen publicera en port till värden, och vilken tjänst skulle äga den? Måste databasen vara nåbar från värden eller från en annan maskin, eller bara inifrån tunneln?

Om databasen behöver sitt eget namn och appen inte publicerar något, håll dem på separata anslutningar. Om appen måste publicera en port och allt går genom tunneln, sätt databasen i VPN:s namnrymd och använd loopback. Att blanda de två ger en stack som startar rent och misslyckas vid anslutning.

Låt databasen vara där den är

Den mindre ändringen kopplar namnrymdens ägare till nätverket som redan innehåller databasen. Appen ärver den anslutningen eftersom den delar vpn-stacken, och db slås upp precis som förut.

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

Lägg inte till networks i appen också. Compose avvisar den egenskapen tillsammans med network_mode i samma tjänst, och felet pekar på filen i stället för på paret. Om VPN-klienten filtrerar backend-destinationen inom sin namnrymd, justera även dess stödda lokalnätspolicy; en delad anslutning erbjuder en väg men åsidosätter inte det filtret.

Flytta databasen in i namnrymden

Den större ändringen sätter databasen i samma namnrymd och pekar appen mot 127.0.0.1 med den riktiga porten. Två processer kan inte båda binda samma adress och port bara för att de startade i olika containrar, så en databas som också lyssnar på wildcard-adressen kommer att kollidera med allt annat som gör det. Kontrollera lyssnaren innan du flyttar den.

Publicerade portar tillhör tjänsten som äger namnrymden. Att lägga ports till appen avvisas tillsammans med network_mode, och att hitta på en separat appadress beskriver ett gränssnitt som inte finns.

Beredskap, blockering och resolvern

depends_on ordnar containerstart; det är inte bevis på att tunneln är uppe och det stoppar inte trafik när tunneln faller. Behandla nåbarhet, tunnelberedskap och felblockering som tre separata krav. En stack som bara uppfyller det första klarar ett manuellt test en bra dag och läcker en dålig. Skriv de tre svaren bredvid compose-filen, där nästa person kommer att titta.

Namnrymdsdelning innebär också att appen ärver VPN-containerns resolver, vilket hjälper när tunneln trycker ut DNS-servrar och förvirrar när den inte gör det. Kontrollera vad namnrymden faktiskt innehåller i stället för att anta att värdens resolver gäller. Compose-tjänstreferensen dokumenterar network_mode, ports och beroendenas beteende på ett ställe, inklusive varför en network_mode-tjänst inte har en egen adress.