VPN కనెక్ట్ అయిన తర్వాత Docker వాల్యూమ్ మౌంట్ విఫలమవుతుంది: daemon తనిఖీ చేయండి

ఈ సమస్య గురించిన దాదాపు ప్రతి రచన వాల్యూమ్‌ను నిందిస్తుంది, అందుకే పరిష్కారం ఇంత సమయం తీసుకుంటుంది. మీకు పనిచేసిన bind mount ఉంది, కార్పొరేట్ VPN కనెక్ట్ అయింది, మరియు docker compose up ఇప్పుడు లేని source path, ఖాళీ డైరెక్టరీ లేదా ఇంజిన్ సృష్టించడానికి నిరాకరించే mount తో విఫలమవుతుంది. నేను శుభ్రం చేసిన వాతావరణాల్లో Compose ఫైల్ మారలేదు మరియు మార్గం సరిగ్గా ఉంది. మారినది ఏ daemon అభ్యర్థనను స్వీకరించిందో, మరియు mount లోపం ఆ భేదం మొదట కనిపించిన స్థలం మాత్రమే.

వాల్యూమ్ ఎప్పుడూ కదలలేదు; అభ్యర్థన కదిలింది

ఒక -v /srv/app:/app flag అనేది మీ shell చేసే డైరెక్టరీ కాపీ కాదు. క్లయింట్ దాన్ని API అభ్యర్థనగా మారుస్తుంది, సమాధానం ఇచ్చే daemon /srv/app ను తన స్వంత ఫైల్ సిస్టమ్ ఆధారంగా పరిష్కరిస్తుంది. రెండు వైపులా ఒకే కెర్నల్‌లో నడిచినప్పుడు, ఆ మార్గమే మీ ఫైల్ మేనేజర్‌లో కనిపిస్తుంది. endpoint మారినప్పుడు, అదే స్ట్రింగ్ మీ ప్రాజెక్ట్ డైరెక్టరీ గురించి ఎప్పుడూ వినని మెషీన్‌లో వెతకబడుతుంది, daemon మూలం లేదని నివేదిస్తుంది లేదా దాని స్థానంలో నిశ్శబ్దంగా ఖాళీ డైరెక్టరీని సృష్టిస్తుంది.

పేరున్న వాల్యూమ్ పని చేస్తూనే bind mount చేయకపోవడానికి ఇదే కారణం. -v appdata:/app daemon సొంతమైన నిల్వకు పేరు పెడుతుంది, కాబట్టి ఏ host path కూడా నిర్దిష్ట స్థలంలో ఉండాల్సిన అవసరం లేదు. ఒక సేవను bind mount నుండి పేరున్న వాల్యూమ్‌కు మార్చడం లోపాన్ని మాయం చేస్తే, మీరు సమస్యను సరిచేయలేదు. మార్గం ఏ ఫైల్ సిస్టమ్‌కు చెందుతుందనే విషయంలో క్లయింట్ మరియు daemon ఏకీభవించడం లేదని మీరు నిర్ధారించారు, ఆ భేదం మీకు మళ్లీ నిజమైన host డైరెక్టరీ అవసరమైన క్షణంలో తిరిగి వస్తుంది.

మౌంట్‌ను తాకే ముందు endpoint ముద్రించండి

అనేక సెట్టింగ్‌లు క్లయింట్‌ను endpoint వైపు చూపగలవు, అవి ఎప్పుడూ ఏకీభవించవు: --context flag, DOCKER_CONTEXT, DOCKER_HOST ప్రస్తుత shell లో, మరియు క్లయింట్ కాన్ఫిగరేషన్‌లో సేవ్ చేసిన context. ప్రాధాన్యత గురించి ఆలోచించడం బదులు అన్నింటినీ ముద్రించి సమాధానాలను పోల్చండి.

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

క్లయింట్ కాన్ఫిగ్ ఇక్కడ ఉంది: ~/.docker/config.json Linux మరియు macOS లో, మరియు ఇక్కడ: %USERPROFILE%\.docker\config.json Windows లో, మరియు ప్రస్తుత టెర్మినల్‌లో export చేసిన విలువ సేవ్ చేసిన దాన్ని ఆ సెషన్‌కు మాత్రమే భర్తీ చేస్తుంది. endpoint స్థానిక socket కాకుండా hostname అయితే, పేరు పరిష్కారం మరియు మార్గాలు అది ఎక్కడ దిగుతుందో నిర్ణయిస్తాయి, మరియు VPN క్లయింట్ సరిగ్గా వాటినే తిరిగి రాస్తుంది. మార్గాన్ని జోడించే లేదా resolver మార్చే tunnel, గతంలో ఈ ల్యాప్‌టాప్‌ను సూచించిన పేరును కార్పొరేట్ నెట్‌వర్క్ లోపలి చిరునామాకు పంపవచ్చు.

కాన్ఫిగరేషన్ కాకుండా స్థితిని పోల్చండి. tunnel మూసి ఉన్నప్పుడు docker ps -a మరియు docker images నడపండి, తర్వాత tunnel తెరిచి ఉన్నప్పుడు మళ్లీ. భిన్నమైన కంటైనర్ జాబితా ఏదైనా కాన్ఫిగ్ ఫైల్ కంటే బలమైన సాక్ష్యం, ఎందుకంటే మీ అభ్యర్థనకు వేరే daemon సమాధానం ఇచ్చిందని చూపిస్తుంది.

మార్గం అక్కడ ఉందా అని daemon ను అడగండి

మీరు ఏ daemon కు చేరుకున్నారో తెలిసిన తర్వాత, దాన్ని డైరెక్టరీ చూడమనండి. --mount రూపం చిన్న flag కంటే స్పష్టమైన సందేశంతో విఫలమవుతుంది, ఎందుకంటే కంటైనర్ ప్రారంభించే ముందు మూలాన్ని ధృవీకరిస్తుంది:

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

మూలం లేదని నివేదిస్తే, సమాధానం ఇచ్చిన మెషీన్‌లో దాన్ని సృష్టించండి, లేదా సేవను పేరున్న వాల్యూమ్ వైపు మళ్లించి డేటాను అక్కడికి కాపీ చేయండి. ఈ తనిఖీకి ముందు వాల్యూమ్‌లను తిరిగి సృష్టించడం మరియు ఇంజిన్‌ను మళ్లీ ఇన్‌స్టాల్ చేయడం మీరు చేయకూడనిది. ఆ చర్యలు అసంగతిని దాచడానికి తగినంతగా వాతావరణాన్ని మారుస్తాయి, కానీ దాన్ని దాని స్థానంలోనే ఉంచుతాయి.

మరో మార్గం పూర్తిగా వేరే చోట నడుస్తుంది: image లాగడం daemon పని, క్లయింట్ పని కాదు. విజయవంతమైన లాగింగ్ daemon ఒక registry చేరుకోగలదని మాత్రమే నిరూపిస్తుంది, పనిచేసే bind mount ఒక మార్గం పరిష్కరించబడిందని మాత్రమే. ప్రతి మార్గాన్ని అది నిజంగా నడిచే చోటే పరీక్షించండి, లేకపోతే తప్పుదానిపై మధ్యాహ్నం గడుపుతారు.

ఇంట్రానెట్ పేర్లు వేరే కారణంతో విఫలమవుతాయి

అదే నివేదికలో రెండవ సగం సాధారణంగా కంటైనర్ intranet.corp.exampleకు చేరుకోలేకపోవడం. అది ప్రత్యేక యంత్రాంగం, రెండవ వాల్యూమ్ సమస్య కాదు. కంటైనర్ తన /etc/resolv.conf ను ప్రారంభంలో పొందుతుంది, అది daemon resolver సెట్టింగ్‌ల నుండి ఉత్పన్నమవుతుంది, కాబట్టి కంటైనర్ సృష్టించిన తర్వాత VPN జోడించిన DNS సర్వర్ కంటైనర్ తిరిగి సృష్టించబడే వరకు అక్కడ కనిపించదు.

వినియోగదారు నిర్వచించిన నెట్‌వర్క్‌లో Docker అంతర్నిర్మిత resolver బాహ్య ప్రశ్నలను host లో కాన్ఫిగర్ చేసిన సర్వర్లకు పంపుతుంది, ఇది VPN host resolver ను తిరిగి రాసినప్పుడు సహాయపడుతుంది మరియు విభజిత DNS అంతర్గత జోన్‌ను daemon ఇకపై చూడని సర్వర్‌కు పంపినప్పుడు హాని చేస్తుంది. సన్నని, స్పష్టమైన మ్యాపింగ్ ఎప్పుడూ మారని పేర్ల కోసం ఈ వాదనను దాటవేస్తుంది:

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

ఇది కంటైనర్ hosts ఫైల్‌లో ఎంట్రీ రాస్తుంది, కాబట్టి కంటైనర్ tunnel గురించి ఏమీ నేర్చుకోదు, మరియు చిరునామాను గడ్డకట్టిస్తుంది. అంతర్గత host కదిలినప్పుడు, ఎవరైనా Compose ఫైల్ సవరించే వరకు ఎంట్రీ తప్పుగానే ఉంటుంది. స్థిర పరికరం లేదా పిన్ చేసిన డేటాబేస్ కోసం దీన్ని ఉపయోగించండి, కదిలే పేర్లను DNS కు వదిలేయండి.

పునఃస్థాపన నిజంగా ఏమి మారుస్తుంది

Docker Desktop ను తిరిగి ఇన్‌స్టాల్ చేయడం VM, socket మరియు context జాబితాను తిరిగి సృష్టిస్తుంది, మౌంట్ మళ్లీ పని చేయడం ప్రారంభిస్తుంది. ఆ ఫలితం నిజమైనది మరియు అది ఏమీ నేర్పదు, అందుకే తదుపరి VPN నవీకరణ తర్వాత అదే వైఫల్యం తిరిగి వస్తుంది. పునఃస్థాపన క్లయింట్ ఉపయోగించిన endpoint ను భర్తీ చేసింది; మీ ప్రాజెక్ట్ పేరు పెట్టే మార్గాన్ని daemon నిజంగా చదివే ఫైల్ సిస్టమ్‌తో అది సమన్వయపరచలేదు.

నా పని క్రమం చిన్నది. క్లయింట్ ఏ endpoint ఉపయోగిస్తుందో నిర్ధారించండి. కంటైనర్ జాబితాలను పోల్చి ఏ daemon సమాధానం ఇచ్చిందో నిర్ధారించండి. ఆ daemon ను source path జాబితా చేయమనండి. ఆ తర్వాతే మౌంట్ సవరించండి, hosts ఎంట్రీ జోడించండి, లేదా వాల్యూమ్ రకం మార్చండి. VPN ద్వారా పని చేసే బృందం కోసం Compose ఫైల్ నిర్వహిస్తుంటే, daemon సొంతం చేసుకోవాల్సిన డేటా కోసం పేరున్న వాల్యూమ్‌లకు ప్రాధాన్యం ఇవ్వండి, అలా host path ఎప్పుడూ ఒప్పందంలో భాగం కాదు.