Dockeri mahu paigaldamine ebaõnnestub pärast VPN-ühendust: kontrolli deemonit

Peaaegu iga selle probleemi kirjeldus süüdistab mahtu, ja just seetõttu võtab parandus nii kaua aega. Sul oli bind mount, mis töötas, ettevõtte VPN ühendus ja docker compose up nüüd ebaõnnestub puuduva lähtetee, tühja kataloogi või paigaldusega, mida mootor keeldub loomast. Keskkondades, mida ma koristasin, polnud Compose-fail muutunud ja tee oli õige. Muutus see, milline deemon päringu sai, ja paigaldustõrge oli lihtsalt esimene koht, kus see erinevus nähtavaks sai.

Maht ei liikunud kunagi; päring liikus

Lipp -v /srv/app:/app ei ole kataloogi koopia, mida sinu shell teeb. Klient muudab selle API-päringuks ja vastav deemon lahendab /srv/app omaenda failisüsteemi vastu. Kui mõlemad pooled töötavad samal tuumal, on see tee see, mida sa failihalduris näed. Kui endpoint muutub, otsitakse sama stringi masinal, mis pole sinu projektikataloogist kunagi kuulnud, ja deemon teatab kas, et allikas puudub, või loob selle asemele vaikselt tühja kataloogi.

Seetõttu töötab nimeline maht edasi, samas kui bind mount mitte. -v appdata:/app nimetab salvestust, mille deemon omab, seega ükski hostitee ei pea kuskil konkreetses kohas eksisteerima. Kui ühe teenuse vahetamine bind mountilt nimelisele mahule paneb vea kaduma, ei ole sa probleemi parandanud. Sa kinnitasid, et klient ja deemon ei ole ühel meelel, millisele failisüsteemile tee kuulub, ja see lahkarvamus naaseb hetkel, kui vajad jälle tõelist hosti kataloogi.

Prindi endpoint enne, kui paigaldust puudutad

Mitmed seaded võivad kliendi endpointile suunata ja need ei ole alati ühel meelel: lipp --context , DOCKER_CONTEXT, DOCKER_HOST praeguses shellis, ja kliendi konfiguratsiooni salvestatud kontekst. Selle asemel, et prioriteedi üle arutleda, prindi need kõik ja võrdle vastuseid.

docker context show
docker context ls
docker version
docker info --format "{{.Name}} {{.OperatingSystem}} {{.ServerVersion}}"

Kliendi konfiguratsioon asub ~/.docker/config.json Linuxis ja macOS-is ning %USERPROFILE%\.docker\config.json Windowsis, ja praeguses terminalis eksporditud väärtus alistab salvestatu ainult selle sessiooni jaoks. Kui endpoint on hostinimi, mitte kohalik socket, otsustavad nime lahendamine ja marsruudid, kuhu see maandub, ja just neid kirjutab VPN-klient ümber. Tunnel, mis lisab marsruudi või vahetab resolveri, võib saata nime, mis varem tähendas seda sülearvutit, ettevõtte võrgu sees olevale aadressile.

Võrdle olekut, mitte konfiguratsiooni. Käivita docker ps -a ja docker images tunnel maas, siis uuesti tunnel üleval. Erinev konteinerite nimekiri on tugevam tõend kui ükski konfiguratsioonifail, sest see näitab, et sinu päringule vastas teine deemon.

Küsi deemonilt, kas tee on seal olemas

Kui tead, millise deemonini jõudsid, pane see kataloogi vaatama. Vorm --mount ebaõnnestub selgema teatega kui lühike lipp, sest see valideerib allika enne konteineri käivitamist:

docker run --rm --mount type=bind,source=/srv/app,target=/app alpine ls -la /app

Kui see teatab allika puudumisest, loo see masinal, mis vastas, või suuna teenus nimelisele mahule ja kopeeri andmed sinna. Mida sa ei peaks tegema, on enne seda kontrolli mahte uuesti luua ja mootorit uuesti paigaldada. Need tegevused muudavad keskkonda piisavalt, et lahknevust varjata, jättes selle siiski paigale.

Veel üks tee kulgeb hoopis mujal: image'i tõmbamine on deemoni töö, mitte kliendi töö. Õnnestunud tõmbamine tõestab ainult, et deemon pääseb registry'sse, ja töötav bind mount ainult, et tee lahenes. Testi iga teed seal, kus see tegelikult käivitub, muidu veedad pärastlõuna vale tee peal.

Intraneti nimed ebaõnnestuvad teisel põhjusel

Sama raporti teine pool on tavaliselt see, et konteiner ei pääse intranet.corp.examplejuurde. See on eraldi mehhanism, mitte teine mahuprobleem. Konteiner saab oma /etc/resolv.conf käivitumisel, genereerituna deemoni resolveri seadetest, seega DNS-server, mille VPN lisas pärast konteineri loomist, ei ilmu seal enne, kui konteiner uuesti luuakse.

Dockeri sisseehitatud resolver kasutaja määratud võrgus edastab välised päringud hosti konfigureeritud serveritele, mis aitab siis, kui VPN kirjutab hosti resolveri ümber, ja kahjustab siis, kui split DNS saadab sisemise tsooni serverile, mida deemon enam ei näe. Kitsas, selgesõnaline vastendamine väldib vaidluse nimede puhul, mis kunagi ei muutu:

services:
  web:
    extra_hosts:
      - "intranet.corp.example:10.20.30.40"

See kirjutab kirje konteineri hosts-faili, nii et konteiner ei õpi tunnelist midagi, ja see külmutab ka aadressi. Kui sisemine host liigub, jääb kirje valeks, kuni keegi Compose-faili muudab. Kasuta seda fikseeritud seadme või kinnitatud andmebaasi jaoks, ja jäta liikuvad nimed DNS-i hooleks.

Mida uuesti paigaldamine tegelikult muudab

Docker Desktopi uuesti paigaldamine loob uuesti VM-i, socketi ja kontekstide nimekirja ning paigaldus hakkab jälle tööle. See tulemus on tõeline ja ei õpeta midagi, mistõttu sama tõrge naaseb pärast järgmist VPN-värskendust. Uuesti paigaldamine asendas endpointi, mida klient kasutas; see ei viinud sinu projekti nimetatud teed kooskõlla failisüsteemiga, mida deemon tegelikult loeb.

Minu töökord on lühike. Kinnita, millist endpointi klient kasutab. Kinnita, milline deemon vastas, võrreldes konteinerite nimekirju. Palu sellel deemonil lähtetee loetleda. Alles siis muuda paigaldust, lisa hosts-kirje või vaheta mahu tüüp. Kui haldad Compose-faili meeskonnale, kes töötab VPN-i kaudu, eelista nimelisi mahte andmetele, mida deemon peaks omama, et hostitee ei saaks kunagi lepingu osaks.