network_mode: service:vpn a zmiznuté meno hostiteľa db

Pridáte network_mode: service:vpn do aplikácie, reštartujete stack a aplikácia zomrie, pretože db sa už neprekladá. V súbore compose sa nič nepremenovalo, takže zjavnými podozrivými sú DNS a databáza. Skutočná zmena je menšia a zvláštnejšia: aplikácia prestala byť členom siete Compose, kde toto meno existuje. Kým nerozhodnete, z ktorého menného priestoru má databáza odpovedať, je každá oprava mena hostiteľa hádaním.

Prečo sa meno hostiteľa db prestalo prekladať

Služba používajúca network_mode nemá v sieti Compose vlastnú adresu; požičiava si menný priestor pomenovanej služby. Ten menný priestor prináša vlastné rozhrania, trasy, priestor portov a resolver a nahrádza pripojenie aplikácie k sieti backend. Meno db nebolo nikdy abstraktné: žilo v tejto sieti a prekladalo sa cez jej vstavaný DNS. Odoberte pripojenie a meno nemá kde prekladať.

Overte to zvnútra kontajnerov, nie z hostiteľa. Vyhľadanie, ktoré zlyhá v aplikácii, ale v kontajneri databázy uspeje, znamená, že meno je v poriadku a členstvo nie. Tento výsledok tiež umiestňuje opravu do topológie compose, a nie do nastavení resolvera aplikácie.

Tri otázky pred úpravou súboru

Odpovedzte na ne v poradí, pretože každá zužuje topológiu. Na čom má databáza odpovedať: na mene hostiteľa, ktoré používajú iné kontajnery, alebo len na aplikácii na loopbacku? Má aplikácia publikovať port do hostiteľa, a ktorá služba by ho vlastnila? Má byť databáza dostupná z hostiteľa alebo z iného stroja, alebo len zvnútra tunela?

Ak databáza potrebuje vlastné meno a aplikácia nič nepublikuje, držte ich na oddelených pripojeniach. Ak aplikácia musí publikovať port a všetko ide tunelom, umiestnite databázu do menného priestoru VPN a použite loopback. Miešanie oboch vytvorí stack, ktorý sa čisto spustí a zlyhá pri pripojení.

Nechajte databázu tam, kde je

Menšia zmena pripája vlastníka menného priestoru k sieti, ktorá už databázu obsahuje. Aplikácia toto pripojenie dedí, pretože zdieľa stack vpn, a db sa prekladá presne ako predtým.

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

Nepridávajte networks aj do aplikácie. Compose toto vlastníctvo odmieta vedľa network_mode v tej istej službe a chyba ukazuje na súbor, nie na dvojicu. Ak klient VPN filtruje cieľ backend v rámci svojho menného priestoru, upravte aj jeho podporovanú politiku miestnej siete; zdieľané pripojenie ponúka cestu, ale tento filter neruší.

Presuňte databázu do menného priestoru

Väčšia zmena umiestni databázu do rovnakého menného priestoru a nasmeruje aplikáciu na 127.0.0.1 so skutočným portom. Dva procesy nemôžu oba obsadiť rovnakú adresu a port len preto, že štartovali v rôznych kontajneroch, takže databáza, ktorá tiež počúva na adrese wildcard, narazí na čokoľvek ďalšie, čo to robí. Pred presunom skontrolujte poslucháča.

Publikované porty patria službe, ktorá vlastní menný priestor. Pridanie ports do aplikácie sa odmieta vedľa network_mode a vymýšľanie samostatnej adresy aplikácie opisuje rozhranie, ktoré neexistuje.

Pripravenosť, blokovanie a resolver

depends_on zoraďuje spúšťanie kontajnerov; nie je to dôkaz, že tunel beží, a nezastaví prevádzku, keď tunel spadne. Berte dostupnosť, pripravenosť tunela a blokovanie zlyhaní ako tri samostatné požiadavky. Stack, ktorý spĺňa len prvú, prejde ručným testom v dobrý deň a presakuje v zlý. Napíšte tri odpovede vedľa súboru compose, tam, kam sa pozrie ďalší človek.

Zdieľanie menného priestoru tiež znamená, že aplikácia dedí resolver kontajnera VPN, čo pomáha, keď tunel pretláča DNS servery, a mýli, keď to nerobí. Skontrolujte, čo menný priestor skutočne obsahuje, namiesto toho, aby ste predpokladali, že platí resolver hostiteľa. Referencia služieb Compose dokumentuje network_mode, ports a správanie závislostí na jednom mieste, vrátane toho, prečo služba s network_mode nemá vlastnú adresu.