Upachikaji wa volume ya Docker unashindikana baada ya VPN kuunganisha: angalia daemon

Karibu kila maandishi kuhusu tatizo hili yanalaumu volume, na ndiyo sababu marekebisho huchukua muda mrefu. Ulikuwa na bind mount iliyofanya kazi, VPN ya kampuni iliunganisha, na docker compose up sasa inashindikana kwa njia ya chanzo inayokosekana, saraka tupu au upachikaji ambao injini inakataa kuunda. Katika mazingira niliyosafisha, faili ya Compose haikubadilika na njia ilikuwa sahihi. Kilichobadilika ni daemon gani ilipokea ombi, na hitilafu ya upachikaji ilikuwa tu mahali pa kwanza ambapo tofauti hiyo ilionekana.

Volume haikuhamia kamwe; ombi lilihamia

Bendera -v /srv/app:/app si nakala ya saraka inayofanywa na shell yako. Mteja anaibadilisha kuwa ombi la API, na daemon inayojibu hutatua /srv/app dhidi ya mfumo wake wa faili. Wakati pande zote mbili zinaendeshwa kwenye kernel moja, njia hiyo ndiyo unayoona kwenye kidhibiti faili. Wakati endpoint inabadilika, mfuatano huo huo hutafutwa kwenye mashine ambayo haijawahi kusikia kuhusu saraka ya mradi wako, na daemon ama inaripoti chanzo kikikosekana au kwa utulivu huunda saraka tupu mahali pake.

Ndiyo sababu volume yenye jina inaendelea kufanya kazi wakati bind mount haifanyi. -v appdata:/app hutaja hifadhi ambayo daemon inamiliki, kwa hivyo hakuna njia ya mwenyeji inayohitaji kuwepo mahali maalum. Ikiwa kubadilisha huduma moja kutoka bind mount hadi volume yenye jina kunafanya hitilafu itoweke, hujatatua tatizo. Umethibitisha kuwa mteja na daemon hawakubaliani kuhusu njia hiyo ni ya mfumo gani wa faili, na kutokubaliana huko hurudi wakati unahitaji tena saraka halisi ya mwenyeji.

Chapisha endpoint kabla ya kugusa upachikaji

Mipangilio kadhaa inaweza kuelekeza mteja kwenye endpoint, na si mara zote hukubaliana: --context bendera, DOCKER_CONTEXT, DOCKER_HOST katika shell ya sasa, na muktadha uliohifadhiwa katika usanidi wa mteja. Badala ya kufikiria kuhusu kipaumbele, chapisha zote na linganisha majibu.

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

Usanidi wa mteja uko katika ~/.docker/config.json kwenye Linux na macOS na katika %USERPROFILE%\.docker\config.json kwenye Windows, na thamani iliyohamishwa kwenye terminal ya sasa inabadilisha ile iliyohifadhiwa kwa kikao hicho tu. Ikiwa endpoint ni jina la mwenyeji badala ya socket ya ndani, utatuzi wa majina na njia huamua itakapoangukia, na ndiyo hasa ambayo mteja wa VPN huandika upya. Handaki inayoongeza njia au kubadilisha resolver inaweza kutuma jina ambalo hapo awali lilimaanisha kompyuta hii ya kubebeka kwenye anwani ndani ya mtandao wa kampuni.

Linganisha hali badala ya usanidi. Endesha docker ps -a na docker images handaki ikiwa chini, kisha tena ikiwa juu. Orodha tofauti ya kontena ni ushahidi wenye nguvu zaidi kuliko faili yoyote ya usanidi, kwa sababu inaonyesha kuwa daemon nyingine ilijibu ombi lako.

Uliza daemon ikiwa njia ipo hapo

Ukisha jua ni daemon gani uliifikia, ifanye iangalie saraka. --mount umbo hushindikana kwa ujumbe ulio wazi zaidi kuliko bendera fupi, kwa sababu huthibitisha chanzo kabla ya kuanzisha kontena:

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

Ikikiri chanzo kikikosekana, kiunde kwenye mashine iliyojibu, au elekeza huduma kwenye volume yenye jina na unakili data hapo. Usichopaswa kufanya ni kuunda upya volume na kusakinisha upya injini kabla ya ukaguzi huu. Vitendo hivyo hubadilisha mazingira vya kutosha kuficha kutokubaliana huku vikiiacha mahali pake.

Njia moja zaidi huenda mahali pengine kabisa: kuvuta image ni kazi ya daemon, si ya mteja. Kuvuta kwa mafanikio kunathibitisha tu kwamba daemon inaweza kufikia registry, na bind mount inayofanya kazi inathibitisha tu kwamba njia ilitatuliwa. Jaribu kila njia mahali inapotekelezwa kwa kweli, la sivyo utatumia mchana kwenye ile isiyo sahihi.

Majina ya intranet hushindikana kwa sababu tofauti

Nusu ya pili ya ripoti hiyo hiyo kwa kawaida ni kwamba kontena haliwezi kufikia intranet.corp.example. Hiyo ni mbinu tofauti, si tatizo la pili la volume. Kontena hupata /etc/resolv.conf yake inapoanza, ikitengenezwa kutoka mipangilio ya resolver ya daemon, kwa hivyo seva ya DNS ambayo VPN iliongeza baada ya kontena kuundwa haitaonekana hapo hadi kontena iundwe upya.

Resolver iliyojengwa ndani ya Docker kwenye mtandao uliofafanuliwa na mtumiaji hupeleka maswali ya nje kwa seva zilizosanidiwa za mwenyeji, jambo ambalo husaidia wakati VPN inaandika upya resolver ya mwenyeji na hudhuru wakati DNS iliyogawanywa inatuma eneo la ndani kwa seva ambayo daemon haioni tena. Uchoraji ramani mwembamba na wazi huepuka mjadala kwa majina ambayo hayabadiliki kamwe:

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

Hii huandika ingizo kwenye faili ya hosts ya kontena, kwa hivyo kontena haijifunzi chochote kuhusu handaki, na pia hugandisha anwani. Mwenyeji wa ndani anapohama, ingizo hubaki si sahihi hadi mtu ahariri faili ya Compose. Itumie kwa kifaa kisichohama au hifadhidata iliyobandikwa, na acha DNS ishughulikie majina yanayohama.

Usakinishaji upya hubadilisha nini kwa kweli

Kusakinisha upya Docker Desktop huunda upya VM, socket na orodha ya muktadha, na upachikaji huanza kufanya kazi tena. Matokeo hayo ni ya kweli na hayafundishi chochote, ndiyo sababu hitilafu hiyo hiyo hurudi baada ya sasisho la VPN linalofuata. Usakinishaji upya ulibadilisha endpoint ambayo mteja alikuwa akitumia; haikupatanisha njia ambayo mradi wako inaitaja na mfumo wa faili ambao daemon husoma kwa kweli.

Mpangilio wangu wa kazi ni mfupi. Thibitisha ni endpoint gani mteja atatumia. Thibitisha ni daemon gani ilijibu kwa kulinganisha orodha za kontena. Mwombe daemon huyo kuorodhesha njia ya chanzo. Ndipo tu uhariri upachikaji, uongeze ingizo la hosts au ubadilishe aina ya volume. Ikiwa unasimamia faili ya Compose kwa timu inayofanya kazi kupitia VPN, pendelea volume zenye jina kwa data ambayo daemon inapaswa kumiliki, ili njia ya mwenyeji isiwe kamwe sehemu ya mkataba.