network_mode: service:vpn ja kadunud db-hostinimi

Lisate rakendusele network_mode: service:vpn, taaskäivitate virna ja rakendus sureb, sest db ei lahene enam. Compose-failis ei ole midagi ümber nimetatud, seega ilmsed kahtlusalused on DNS ja andmebaas. Tegelik muudatus on väiksem ja kummalisem: rakendus lakkas olemast selle Compose-võrgu liige, kus see nimi eksisteerib. Kuni te ei otsusta, millisest nimeruumist andmebaas peab vastama, on iga hostinime parandus oletus.

Miks db-hostinimi enam ei lahene

network_mode kasutaval teenusel ei ole Compose-võrgus oma aadressi; see laenab nimetatud teenuse nimeruumi. See nimeruum toob kaasa oma liidesed, marsruudid, pordiruumi ja resolveri ning asendab rakenduse kinnituse backend-võrgu külge. Nimi db ei olnud kunagi abstraktne: see elas selles võrgus ja lahenes selle sisseehitatud DNS-i kaudu. Eemaldage kinnitus ja nimel ei ole enam kusagil lahenduda.

Kinnitage seda konteinerite seest, mitte hostist. Otsing, mis rakenduses ebaõnnestub, kuid andmebaasi konteineris õnnestub, tähendab, et nimi on korras ja liikmelisus mitte. See tulemus paigutab paranduse ka compose-topoloogiasse, mitte rakenduse resolveri seadetesse.

Kolm küsimust enne faili muutmist

Vastake neile järjekorras, sest igaüks kitsendab topoloogiat. Millele peab andmebaas vastama: hostinimele, mida teised konteinerid kasutavad, või ainult rakendusele loopbackil? Kas rakendus peab avaldama pordi hostile, ja milline teenus seda omaks? Kas andmebaas peab olema kättesaadav hostist või teisest masinast, või ainult tunneli seest?

Kui andmebaas vajab oma nime ja rakendus ei avalda midagi, hoidke neid eraldi kinnitustel. Kui rakendus peab pordi avaldama ja kõik käib tunneli kaudu, pange andmebaas VPN-i nimeruumi ja kasutage loopbacki. Kahe segamine annab virna, mis käivitub puhtalt ja ebaõnnestub ühendamisel.

Jätke andmebaas sinna, kus see on

Väiksem muudatus kinnitab nimeruumi omaniku võrgu külge, mis juba sisaldab andmebaasi. Rakendus pärib selle kinnituse, sest jagab vpn-virna, ja db laheneb täpselt nagu enne.

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

Ärge lisage networks ka rakendusele. Compose keeldub sellest atribuudist koos network_mode-ga samas teenuses ja viga osutab failile, mitte paarile. Kui VPN-klient filtreerib backend-sihtmärki oma nimeruumis, kohandage ka selle toetatud kohaliku võrgu poliitikat; jagatud kinnitus pakub tee, kuid ei tühista seda filtrit.

Viige andmebaas nimeruumi

Suurem muudatus paneb andmebaasi samasse nimeruumi ja suunab rakenduse 127.0.0.1-le tegeliku pordiga. Kaks protsessi ei saa mõlemad siduda sama aadressi ja porti lihtsalt sellepärast, et nad käivitusid eri konteinerites, seega andmebaas, mis kuulab ka wildcard-aadressil, põrkub kõige muuga, mis seda teeb. Kontrollige kuulajat enne selle liigutamist.

Avaldatud pordid kuuluvad teenusele, mis omab nimeruumi. ports lisamine rakendusele lükatakse tagasi koos network_mode-ga ja eraldi rakenduse aadressi leiutamine kirjeldab liidest, mida ei ole olemas.

Valmidus, blokeerimine ja resolver

depends_on järjestab konteinerite käivitumist; see ei ole tõestus, et tunnel töötab, ega peata liiklust, kui tunnel langeb. Käsitlege kättesaadavust, tunneli valmidust ja tõrgete blokeerimist kolme eraldi nõudena. Virn, mis täidab ainult esimese, läbib käsitsi testi heal päeval ja lekib halval. Kirjutage kolm vastust compose-faili kõrvale, kuhu järgmine inimene vaatab.

Nimeruumi jagamine tähendab ka seda, et rakendus pärib VPN-konteineri resolveri, mis aitab, kui tunnel surub peale DNS-serverid, ja ajab segadusse, kui ei tee seda. Kontrollige, mida nimeruum tegelikult sisaldab, selle asemel et eeldada, et hosti resolver kehtib. Compose'i teenuste viide dokumenteerib network_mode, ports ja sõltuvuste käitumise ühes kohas, sealhulgas miks network_mode'iga teenusel ei ole oma aadressi.