Docker-taltion liittäminen epäonnistuu VPN-yhteyden jälkeen: tarkista daemon

Lähes jokainen tämän ongelman kuvaus syyttää taltiota, ja juuri siksi korjaus kestää niin kauan. Sinulla oli toimiva bind mount, yrityksen VPN yhdisti ja docker compose up epäonnistuu nyt puuttuvalla lähdepolulla, tyhjällä hakemistolla tai liitännällä, jota moottori kieltäytyy luomasta. Ympäristöissä, joita olen siivonnut, Compose-tiedosto ei ollut muuttunut ja polku oli oikein. Muuttui se, mikä daemon vastaanotti pyynnön, ja liitäntävirhe oli vain ensimmäinen paikka, jossa ero tuli näkyväksi.

Taltio ei koskaan liikkunut; pyyntö liikkui

Lippu -v /srv/app:/app ei ole shellisi tekemä hakemistokopio. Asiakas muuttaa sen API-pyynnöksi, ja vastaava daemon ratkaisee /srv/app oman tiedostojärjestelmänsä mukaan. Kun molemmat puolet ajetaan samalla ytimellä, tämä polku on se, jonka näet tiedostonhallinnassasi. Kun endpoint vaihtuu, sama merkkijono etsitään koneelta, joka ei ole koskaan kuullut projektihakemistostasi, ja daemon joko ilmoittaa lähteen puuttuvaksi tai luo hiljaa tyhjän hakemiston sen tilalle.

Siksi myös nimetty taltio toimii edelleen, kun taas bind mount ei. -v appdata:/app nimeää tallennustilan, jonka daemon omistaa, joten minkään isäntäpolun ei tarvitse olla missään tietyssä paikassa. Jos yhden palvelun vaihtaminen bind mountista nimettyyn taltioon saa virheen katoamaan, et ole korjannut ongelmaa. Olet vahvistanut, että asiakas ja daemon ovat eri mieltä siitä, mihin tiedostojärjestelmään polku kuuluu, ja tuo erimielisyys palaa heti, kun tarvitset jälleen oikean isäntähakemiston.

Tulosta endpoint ennen kuin kosket liitäntään

Useat asetukset voivat ohjata asiakkaan endpointiin, eivätkä ne aina ole samaa mieltä: lippu --context , DOCKER_CONTEXT, DOCKER_HOST nykyisessä shellissä, ja asiakkaan kokoonpanoon tallennettu konteksti. Sen sijaan että pohtisit etusijaa, tulosta kaikki ja vertaa vastauksia.

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

Asiakkaan kokoonpano sijaitsee polussa ~/.docker/config.json Linuxissa ja macOS:ssa sekä polussa %USERPROFILE%\.docker\config.json Windowsissa, ja nykyisessä päätteessä viety arvo ohittaa tallennetun vain kyseisen istunnon ajaksi. Jos endpoint on isäntänimi paikallisen socketin sijaan, nimien ratkaisu ja reitit päättävät, mihin se laskeutuu, ja juuri ne VPN-asiakas kirjoittaa uudelleen. Tunneli, joka lisää reitin tai vaihtaa resolverin, voi lähettää nimen, joka ennen tarkoitti tätä kannettavaa, osoitteeseen yritysverkon sisällä.

Vertaa tilaa kokoonpanon sijaan. Suorita docker ps -a ja docker images tunneli alhaalla ja sitten uudelleen ylhäällä. Erilainen konttiluettelo on vahvempi todiste kuin mikään kokoonpanotiedosto, koska se osoittaa, että eri daemon vastasi pyyntöösi.

Kysy daemonilta, onko polku siellä olemassa

Kun tiedät, mihin daemoniin pääsit, laita se katsomaan hakemistoa. Muoto --mount epäonnistuu selkeämmällä viestillä kuin lyhyt lippu, koska se validoi lähteen ennen kontin käynnistämistä:

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

Jos se ilmoittaa lähteen puuttuvaksi, luo se koneelle, joka vastasi, tai osoita palvelu nimettyyn taltioon ja kopioi tiedot sinne. Mitä sinun ei pitäisi tehdä, on luoda taltiot uudelleen ja asentaa moottori uudelleen ennen tätä tarkistusta. Ne toimet muuttavat ympäristöä tarpeeksi peittääkseen ristiriidan mutta jättävät sen paikoilleen.

Vielä yksi polku kulkee aivan muualla: imagen vetäminen on daemonin työtä, ei asiakkaan. Onnistunut veto todistaa vain, että daemon pääsee registryyn, ja toimiva bind mount vain, että polku ratkesi. Testaa jokainen polku siellä, missä se todella suoritetaan, tai vietät iltapäivän väärän parissa.

Intranetin nimet epäonnistuvat eri syystä

Saman raportin toinen puoli on yleensä se, että kontti ei pääse osoitteeseen intranet.corp.example. Se on erillinen mekanismi, ei toinen taltio-ongelma. Kontti saa /etc/resolv.conf käynnistyessään daemonin resolver-asetuksista generoituna, joten DNS-palvelin, jonka VPN lisäsi kontin luomisen jälkeen, ei näy siellä ennen kuin kontti luodaan uudelleen.

Dockerin sisäänrakennettu resolver käyttäjän määrittämässä verkossa välittää ulkoiset haut isännän määritetyille palvelimille, mikä auttaa, kun VPN kirjoittaa isännän resolverin uudelleen, ja haittaa, kun jaettu DNS lähettää sisäisen vyöhykkeen palvelimelle, jota daemon ei enää näe. Kapea, selkeä kartoitus kiertää väittelyn nimistä, jotka eivät koskaan muutu:

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

Tämä kirjoittaa merkinnän kontin hosts-tiedostoon, joten kontti ei opi tunnelista mitään, ja se myös jäädyttää osoitteen. Kun sisäinen isäntä siirtyy, merkintä pysyy vääränä, kunnes joku muokkaa Compose-tiedostoa. Käytä sitä kiinteälle laitteelle tai kiinnitetylle tietokannalle, ja jätä liikkuvat nimet DNS:n hoidettavaksi.

Mitä uudelleenasennus todella muuttaa

Docker Desktopin uudelleenasennus luo uudelleen VM:n, socketin ja kontekstiluettelon, ja liitäntä alkaa taas toimia. Tulos on todellinen eikä opeta mitään, minkä vuoksi sama vika palaa seuraavan VPN-päivityksen jälkeen. Uudelleenasennus korvasi endpointin, jota asiakas käytti; se ei sovittanut projektisi nimeämää polkua siihen tiedostojärjestelmään, jota daemon todella lukee.

Työjärjestykseni on lyhyt. Vahvista, mitä endpointia asiakas käyttää. Vahvista konttiluetteloita vertaamalla, mikä daemon vastasi. Pyydä sitä daemonia listaamaan lähdepolku. Vasta sitten muokkaa liitäntää, lisää hosts-merkintä tai vaihda taltion tyyppi. Jos ylläpidät Compose-tiedostoa tiimille, joka työskentelee VPN:n yli, suosi nimettyjä taltioita tiedoille, jotka daemonin pitäisi omistaa, jotta isäntäpolusta ei koskaan tule osa sopimusta.