network_mode: service:vpn a zmizelé jméno hostitele db

Sdílení jmenného prostoru VPN je volba topologie. Buď si db ponechá vlastní adresu a vpn se připojí k této síti, nebo všechno odpovídá na loopbacku.

Přidáte network_mode: service:vpn do aplikace, restartujete stack a aplikace umře, protože db se už nepřekládá. V souboru compose se nic nepřejmenovalo, takže zjevnými podezřelými jsou DNS a databáze. Skutečná změna je menší a podivnější: aplikace přestala být členem sítě Compose, kde toto jméno existuje. Dokud nerozhodnete, z kterého jmenného prostoru má databáze odpovídat, je každá oprava jména hostitele hádáním.

Proč se jméno hostitele db přestalo překládat

Služba používající network_mode nemá v síti Compose vlastní adresu; vypůjčuje si jmenný prostor pojmenované služby. Ten jmenný prostor přináší vlastní rozhraní, trasy, prostor portů a resolver a nahrazuje připojení aplikace k síti backend. Jméno db nikdy nebylo abstraktní: žilo v této síti a překládalo se přes její vestavěný DNS. Odeberte připojení a jméno nemá kde překládat.

Ověřte to zevnitř kontejnerů, ne z hostitele. Vyhledání, které v aplikaci selže, ale v kontejneru databáze uspěje, znamená, že jméno je v pořádku a členství ne. Tento výsledek také přesouvá opravu do topologie compose, nikoli do nastavení resolveru aplikace.

Tři otázky, než soubor upravíte

Odpovězte na ně v pořadí, protože každá zužuje topologii. Na čem má databáze odpovídat: na jménu hostitele, které používají jiné kontejnery, nebo jen na aplikaci na loopbacku? Má aplikace publikovat port do hostitele, a která služba by ho vlastnila? Má být databáze dostupná z hostitele nebo z jiného stroje, nebo jen zevnitř tunelu?

Pokud databáze potřebuje vlastní jméno a aplikace nic nepublikuje, držte je na oddělených připojeních. Pokud aplikace musí publikovat port a všechno jde tunelem, umístěte databázi do jmenného prostoru VPN a použijte loopback. Smíchání obojího vytvoří stack, který se čistě spustí a selže při připojení.

Nechte databázi tam, kde je

Menší změna připojuje vlastníka jmenného prostoru k síti, která už databázi obsahuje. Aplikace toto připojení dědí, protože sdílí stack vpn, a db se překládá přesně jako dřív.

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

Nepřidávejte networks také do aplikace. Compose toto vlastnictví odmítá vedle network_mode ve stejné službě a chyba ukazuje na soubor, nikoli na dvojici. Pokud klient VPN filtruje cíl backend uvnitř svého jmenného prostoru, upravte také jeho podporovanou politiku místní sítě; sdílené připojení nabízí cestu, ale tento filtr nepřekonává.

Přesuňte databázi do jmenného prostoru

Větší změna umístí databázi do stejného jmenného prostoru a nasměruje aplikaci na 127.0.0.1 se skutečným portem. Dva procesy nemohou oba obsadit stejnou adresu a port jen proto, že startovaly v různých kontejnerech, takže databáze, která také naslouchá na adrese wildcard, narazí na cokoli dalšího, co to dělá. Před přesunem zkontrolujte posluchač.

Publikované porty patří službě, která vlastní jmenný prostor. Přidání ports do aplikace se odmítá vedle network_mode a vymýšlení samostatné adresy aplikace popisuje rozhraní, které neexistuje.

Připravenost, blokování a resolver

depends_on řadí spouštění kontejnerů; není to důkaz, že tunel běží, a nezastaví provoz, když tunel spadne. Berte dostupnost, připravenost tunelu a blokování selhání jako tři samostatné požadavky. Stack, který splňuje jen první, projde ručním testem v dobrý den a prosakuje ve špatný. Napište tři odpovědi vedle souboru compose, tam, kam se podívá další člověk.

Sdílení jmenného prostoru také znamená, že aplikace dědí resolver kontejneru VPN, což pomáhá, když tunel protlačuje DNS servery, a mate, když ne. Zkontrolujte, co jmenný prostor skutečně obsahuje, místo abyste předpokládali, že platí resolver hostitele. Reference služeb Compose dokumentuje network_mode, ports a chování závislostí na jednom místě, včetně toho, proč služba s network_mode nemá vlastní adresu.

Související články