network_mode: service:vpn és az eltűnt db-gazdanév

A VPN névterének megosztása topológiai döntés. Vagy a db megtartja a saját címét, és a vpn csatlakozik ahhoz a hálózathoz, vagy minden a loopbacken válaszol.

Hozzáadja a network_mode: service:vpn elemet az alkalmazáshoz, újraindítja a vermet, és az alkalmazás meghal, mert a db már nem oldódik fel. A compose-fájlban semmit sem neveztek át, így a nyilvánvaló gyanúsítottak a DNS és az adatbázis. A tényleges változás kisebb és furcsább: az alkalmazás megszűnt tagja lenni annak a Compose-hálózatnak, amelyben ez a név létezik. Amíg nem dönti el, melyik névtérből kell az adatbázisnak válaszolnia, minden gazdanév-javítás találgatás.

Miért szűnt meg a db gazdanév feloldása

A network_mode elemet használó szolgáltatásnak nincs saját címe egy Compose-hálózaton; kölcsönveszi a megnevezett szolgáltatás névterét. Az a névtér saját interfészeket, útvonalakat, portteret és feloldót hoz, és lecseréli az alkalmazás backend-hálózathoz való csatlakozását. A db név soha nem volt absztrakt: azon a hálózaton élt, és a beágyazott DNS-en keresztül oldódott fel. Távolítsa el a csatlakozást, és a névnek nincs hol feloldódnia.

Ezt a konténerek belsejéből erősítse meg, ne a gazdagépről. Az a lekérdezés, amely az alkalmazásban meghiúsul, de az adatbázis konténerében sikerül, azt jelenti, hogy a név rendben van, a tagság viszont nem. Ez az eredmény a javítást a compose-topológiába helyezi, nem az alkalmazás feloldóbeállításaiba.

Három kérdés a fájl szerkesztése előtt

Sorrendben válaszoljon rájuk, mert mindegyik szűkíti a topológiát. Mire kell az adatbázisnak válaszolnia: egy gazdanévre, amelyet más konténerek használnak, vagy csak az alkalmazásra a loopbacken? Publikálnia kell az alkalmazásnak egy portot a gazdagép felé, és melyik szolgáltatás birtokolná azt? Elérhetőnek kell lennie az adatbázisnak a gazdagépről vagy egy másik gépről, vagy csak az alagút belsejéből?

Ha az adatbázisnak saját névre van szüksége, és az alkalmazás semmit sem publikál, tartsa őket külön csatlakozásokon. Ha az alkalmazásnak portot kell publikálnia, és minden az alagúton keresztül megy, tegye az adatbázist a VPN névterébe, és használjon loopbacket. A kettő keverése olyan vermet ad, amely tisztán indul, és csatlakozáskor meghiúsul.

Hagyja az adatbázist a helyén

A kisebb változtatás a névtér tulajdonosát ahhoz a hálózathoz csatolja, amely már tartalmazza az adatbázist. Az alkalmazás örökli ezt a csatolást, mert megosztja a vpn vermet, és a db pontosan úgy oldódik fel, mint korábban.

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

Ne adja hozzá a networks elemet is az alkalmazáshoz. A Compose elutasítja ezt a tulajdonságot a network_mode mellett ugyanabban a szolgáltatásban, és a hiba a fájlra mutat, nem a párra. Ha a VPN-kliens a backend-célt a névterén belül szűri, állítsa be a támogatott helyi hálózati irányelvét is; a megosztott csatolás utat kínál, de nem írja felül ezt a szűrőt.

Helyezze át az adatbázist a névtérbe

A nagyobb változtatás ugyanabba a névtérbe teszi az adatbázist, és az alkalmazást a valódi porttal a 127.0.0.1 címre irányítja. Két folyamat nem tudja mindkettő ugyanazt a címet és portot kötni csak azért, mert különböző konténerekben indult, ezért a wildcard címen is figyelő adatbázis ütközni fog mindennel, ami szintén ezt teszi. A mozgatás előtt ellenőrizze a figyelőt.

A publikált portok ahhoz a szolgáltatáshoz tartoznak, amely a névtér tulajdonosa. A ports hozzáadása az alkalmazáshoz a network_mode mellett elutasításra kerül, és egy külön alkalmazáscím kitalálása olyan interfészt ír le, amely nem létezik.

Készenlét, blokkolás és a feloldó

A depends_on a konténerek indítását rendezi; ez nem bizonyíték arra, hogy az alagút él, és nem állítja le a forgalmat, amikor az alagút leesik. Kezelje az elérhetőséget, az alagút készenlétét és a hiba blokkolását három külön követelményként. Az a verem, amely csak az elsőt teljesíti, jó napon átmegy egy kézi teszten, rossz napon pedig szivárog. Írja a három választ a compose-fájl mellé, ahol a következő ember megnézi.

A névtér megosztása azt is jelenti, hogy az alkalmazás örökli a VPN-konténer feloldóját, ami segít, amikor az alagút DNS-kiszolgálókat kényszerít, és összezavar, amikor nem. Ellenőrizze, mit tartalmaz valójában a névtér, ahelyett hogy feltételezné, hogy a gazdagép feloldója érvényes. A Compose szolgáltatásreferencia egy helyen dokumentálja a network_mode, a ports és a függőségek viselkedését, beleértve azt is, miért nincs saját címe egy network_mode szolgáltatásnak.

Kapcsolódó cikkek