Docker bolumenaren muntaketak huts egiten du VPN-a konektatu ondoren: egiaztatu daemona

Arazo honi buruzko ia idazki guztiek bolumena erruduntzen dute, eta horrexegatik hartzen du konponketak hainbeste denbora. Lanean zebilen bind mount bat zenuen, VPN korporatiboa konektatu zen, eta docker compose up orain huts egiten du: falta den iturburu-bide bat, direktorio huts bat edo motorrak sortzeari uko egiten dion muntaketa bat. Nik garbitutako inguruneetan, Compose fitxategia ez zen aldatu eta bidea zuzena zen. Aldatu zena da zein daemon-ek jaso zuen eskaera, eta muntaketa-errorea desberdintasun hori ikusgai egin zen lehen tokia besterik ez zen.

Bolumena ez zen inoiz mugitu; eskaera mugitu zen

Bandera -v /srv/app:/app ez da zure shell-ak egiten duen direktorio-kopia bat. Bezeroak API eskaera bihurtzen du, eta erantzuten duen daemon-ak bere fitxategi-sisteman ebazten du /srv/app . Bi aldeak nukleo berean exekutatzen direnean, bide hori da zure fitxategi-kudeatzailean ikusten duzuna. Endpoint-a aldatzen denean, kate bera zure proiektuaren direktorioaz inoiz entzun ez duen makina batean bilatzen da, eta daemon-ak iturburua falta dela jakinarazten du edo isilik direktorio huts bat sortzen du haren ordez.

Horregatik ere bolumen izendatuak funtzionatzen jarraitzen du bind mount-ak ez bezala. -v appdata:/app daemon-ak duen biltegiratzea izendatzen du, beraz host bide batek ez du leku jakin batean existitu behar. Zerbitzu bat bind mount batetik bolumen izendatu batera aldatzeak errorea desagerrarazten badu, ez duzu arazoa konpondu. Bezeroa eta daemon-a bat ez datozela egiaztatu duzu bidea zein fitxategi-sistemari dagokion, eta desadostasun hori host direktorio erreal bat berriro behar duzun unean itzultzen da.

Inprimatu endpoint-a muntaketa ukitu aurretik

Hainbat ezarpenek bezeroa endpoint batera bidera dezakete, eta ez datoz beti bat: --context banderak, DOCKER_CONTEXT, DOCKER_HOST uneko shell-ean, eta bezeroaren konfigurazioan gordetako testuinguruak. Lehentasunari buruz arrazoitu beharrean, inprimatu guztiak eta konparatu erantzunak.

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

Bezeroaren konfigurazioa hemen dago: ~/.docker/config.json Linux eta macOS-en, eta hemen: %USERPROFILE%\.docker\config.json Windows-en, eta uneko terminalean esportatutako balio batek gordetakoa gainditzen du saio horretarako soilik. Endpoint-a socket lokal bat beharrean host-izena bada, izenen ebazpenak eta ibilbideek erabakitzen dute non lurreratuko den, eta VPN bezeroak hain zuzen horiek berridazten ditu. Ibilbide bat gehitzen duen edo resolver-a aldatzen duen tunel batek portatil hau esan nahi zuen izen bat sare korporatiboko helbide batera bidal dezake.

Konparatu egoera konfigurazioa baino. Exekutatu docker ps -a eta docker images tunela itzalita, eta gero berriro piztuta. Edukiontzi-zerrenda desberdin bat edozein konfigurazio-fitxategik baino froga sendoagoa da, zure eskaerari beste daemon batek erantzun ziola erakusten duelako.

Galdetu daemon-ari ea bidea han existitzen den

Zein daemon-era iritsi zaren jakitean, egin dezala direktorioari begiratu. Formak --mount mezu argiagoarekin huts egiten du bandera laburrak baino, edukiontzia hasi aurretik iturburua baliozkotzen duelako:

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

Iturburua falta dela jakinarazten badu, sortu erantzun zuen makinean, edo bideratu zerbitzua bolumen izendatu batera eta kopiatu datuak hara. Ez zenukeena egin behar da bolumenak berriz sortu eta motorra berriz instalatu egiaztapen honen aurretik. Ekintza horiek ingurunea nahikoa aldatzen dute desadostasuna ezkutatzeko, hura tokian utziz.

Beste bide bat erabat beste leku batean ibiltzen da: irudi bat ateratzea daemon-aren lana da, ez bezeroarena. Ateratze arrakastatsu batek soilik frogatzen du daemon-ak registry batera irits daitekeela, eta funtzionatzen duen bind mount-ak soilik bide bat ebatzi zela. Probatu bide bakoitza benetan exekutatzen den tokian, bestela arratsalde bat emango duzu okerrarekin.

Intranet izenek beste arrazoi batengatik huts egiten dute

Txosten beraren bigarren erdia izan ohi da edukiontziak ezin duela iritsi intranet.corp.examplera. Hori mekanismo bereizi bat da, ez bigarren bolumen-arazo bat. Edukiontziak bere /etc/resolv.conf jasotzen du hastean, daemon-aren resolver ezarpenetatik sortua, beraz VPN-ak edukiontzia sortu ondoren gehitutako DNS zerbitzari bat ez da han agertuko edukiontzia berriz sortu arte.

Erabiltzaileak definitutako sare batean Docker-en resolver integratuak kanpoko kontsultak host-aren zerbitzari konfiguratuetara birbidaltzen ditu, eta horrek laguntzen du VPN-ak host resolver-a berridazten duenean, eta kalte egiten du DNS zatituak barne-zona bat daemon-ak jada ikusten ez duen zerbitzari batera bidaltzen duenean. Mapaketa estu eta esplizitu batek inoiz aldatzen ez diren izenen eztabaida saihesten du:

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

Honek edukiontziaren hosts fitxategian sarrera bat idazten du, beraz edukiontziak ez du tunelari buruz ezer ikasten, eta helbidea izoztu ere egiten du. Barne-host-a mugitzen denean, sarrera oker jarraitzen du norbaitek Compose fitxategia editatu arte. Erabili gailu finko baterako edo finkatutako datu-base baterako, eta utzi DNS-ari mugitzen diren izenak kudeatzen.

Zer aldatzen du berrinstalazio batek benetan

Docker Desktop berriz instalatzeak VM-a, socket-a eta testuinguru-zerrenda birsortzen ditu, eta muntaketak berriro funtzionatzen du. Emaitza hori erreala da eta ez du ezer irakasten, horregatik huts berbera itzultzen da hurrengo VPN eguneraketaren ondoren. Berrinstalazioak bezeroak erabiltzen zuen endpoint-a ordezkatu zuen; ez zuen zure proiektuak izendatzen duen bidea daemon-ak benetan irakurtzen duen fitxategi-sistemarekin adiskidetu.

Nire lan-ordena laburra da. Egiaztatu zein endpoint erabiliko duen bezeroak. Egiaztatu zein daemon-ek erantzun zuen edukiontzi-zerrendak konparatuz. Eskatu daemon horri iturburu-bidea zerrendatzeko. Orduan soilik editatu muntaketa, gehitu hosts sarrera bat edo aldatu bolumen mota bat. VPN baten bidez lan egiten duen talde batentzat Compose fitxategia mantentzen baduzu, hobetsi bolumen izendatuak daemon-ak eduki beharko lituzkeen datuetarako, host bide bat inoiz kontratuaren parte izan ez dadin.