Docker Compose: Bind mount మరియు Named volume మధ్య తేడాలు

Bind mount లేదా named volume: క్లుప్త సమాధానం

Docker Compose volumes రెండు రకాలుగా ఉంటాయి, ఫైళ్లను ఎవరు నియంత్రిస్తారనే దానిపై ఎంపిక ఆధారపడి ఉంటుంది. మీరు స్వయంగా రాసే లేదా చదివే ఫైళ్ల కోసం (ఉదాహరణకు: config, templates, static sites) bind mount ఉపయోగించండి. అప్లికేషన్ సొంతంగా నిర్వహించే డేటా కోసం (ఉదాహరణకు: database files, search indexes, uploaded media) named volume ఉపయోగించండి. Bind mount అనేది హోస్ట్ మెషీన్‌లోని ఒక పాత్‌ను సూచిస్తుంది, దీన్ని మీరు ఎడిటర్‌లో నేరుగా తెరవవచ్చు. Named volume అనేది Docker సృష్టించి, నిర్వహించే నిల్వ (storage), దీన్ని మీరు Docker ద్వారా మాత్రమే యాక్సెస్ చేయగలరు.

రెండూ ఒక సర్వీస్ లోపల ఒకే volumes: కీ కింద కనిపిస్తాయి, అందుకే వీటి మధ్య గందరగోళం ఏర్పడుతుంది. వీటి మధ్య తేడా కోలన్ (:) కు ఎడమ వైపున ఉంటుంది. ఎడమ వైపున . లేదా / తో ప్రారంభమైతే అది హోస్ట్ పాత్, అంటే అది bind mount. మిగిలినవన్నీ ఒక పేరును సూచిస్తాయి, కాబట్టి అది named volume అవుతుంది. అటువంటి పేరును తప్పనిసరిగా టాప్-లెవల్ volumes: బ్లాక్‌లో డిక్లేర్ చేయాలి.

Compose ఫైల్‌లోని రెండు సింటాక్స్‌లు

services:
  db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: changeme
    volumes:
      - pgdata:/var/lib/postgresql/data
  web:
    image: nginx:1.27
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./site:/usr/share/nginx/html:ro

volumes:
  pgdata:

pgdata:/var/lib/postgresql/data అనేది ఒక named volume. ./nginx.conf:/etc/nginx/nginx.conf అనేది ఒక bind mount, మరియు :ro దీనిని read-only మోడ్‌లో మౌంట్ చేస్తుంది. కంటైనర్ ఎప్పుడూ మార్చకూడని కాన్ఫిగరేషన్ ఫైళ్లకు ఇదే సరైన డిఫాల్ట్ పద్ధతి. టాప్-లెవల్ volumes: ఎంట్రీని మర్చిపోతే, Compose service "db" refers to undefined volume pgdata ఎర్రర్‌తో ఆగిపోతుంది.

దీనిని ప్రారంభించి, Docker ఏమి సృష్టించిందో చూడండి:

docker compose up -d
docker volume ls

ఈ వాల్యూమ్ పేరు pgdata కాదు. దీని పేరు <project>_pgdata, ఇక్కడ ప్రాజెక్ట్ పేరు డిఫాల్ట్‌గా compose ఫైల్ ఉన్న డైరెక్టరీ పేరును తీసుకుంటుంది. ఒక డైరెక్టరీ పేరు myapp అయితే, అది myapp_pgdata అని మారుతుంది. డైరెక్టరీ పేరు మార్చినప్పుడు కొత్త ఖాళీ వాల్యూమ్ సృష్టించబడుతుంది కాబట్టి, అప్లికేషన్ తన డేటాను కోల్పోయినట్లు కనిపిస్తుంది. నిజానికి డేటా పోలేదు: పాత వాల్యూమ్ ఇప్పటికీ docker volume ls ద్వారా కనిపిస్తుంది. డైరెక్టరీ మారే అవకాశం ఉంటే, compose ఫైల్‌లో name: తో పేరును స్థిరపరచండి లేదా COMPOSE_PROJECT_NAME ను సెట్ చేయండి. ఇటువంటి సెట్టింగ్‌లు మీ ఇతర Compose environment files and secrets తో పాటు ఉండాలి.

bind mount లలో మాత్రమే permission లోపాలు ఎందుకు వస్తాయి

ఇది ఆచరణాత్మకమైన అతిపెద్ద వ్యత్యాసం, ఇది ఒకే నియమంపై ఆధారపడి ఉంటుంది: మొదటిసారి ఉపయోగించినప్పుడు ఖాళీగా ఉన్న named volume, image నుండి డేటాను పొందుతుంది (seeded), కానీ bind mount అలా ఎప్పటికీ చేయదు.

Docker ఒక ఖాళీ named volume ను, ఇప్పటికే కంటెంట్ ఉన్న directory పై mount చేసినప్పుడు, అది ఆ కంటెంట్‌ను volume లోకి కాపీ చేస్తుంది. అప్పుడు image లో సెట్ చేసిన ownership మరియు modes అలాగే ఉంటాయి. అధికారిక Postgres image, /var/lib/postgresql/data ను దాని సొంత postgres user ఆధీనంలో ఉంచుతుంది, కాబట్టి volume కూడా అదే numeric id తో వస్తుంది మరియు database ప్రారంభమవుతుంది.

Bind mount దీనికి విరుద్ధంగా పనిచేస్తుంది. Host లో ఏది ఉంటే అదే container కు కనిపిస్తుంది, ownership తో సహా. ఆ path లో ఉన్న image కంటెంట్ దాచబడుతుంది. ఒకవేళ host directory లేకపోతే, Docker daemon దానిని సృష్టిస్తుంది. Daemon అనేది root గా రన్ అవుతుంది కాబట్టి, మీకు root:root ఆధీనంలో ఉన్న directory లభిస్తుంది. అప్పుడు non-root user గా రన్ అయ్యే container process అందులో రాయలేదు:

PermissionError: [Errno 13] Permission denied: '/data/app.db'

దీనికి పరిష్కారం, numeric id లను సరిపోల్చడం. Bind mount లో ownership ను పేరుతో కాకుండా, numeric user id తో పోలుస్తారు, ఎందుకంటే container కు దాని సొంత /etc/passwd ఉంటుంది. Container లోపల app అని పిలిచే user కు host పై ఎటువంటి అర్థం ఉండదు. Uid 1000 అంటే రెండు వైపులా uid 1000 అని అర్థం.

id -u
mkdir -p ./data
docker compose exec web id
sudo chown -R 1000:1000 ./data

docker compose exec web id కమాండ్, container process వాస్తవానికి ఏ uid తో రన్ అవుతుందో చూపిస్తుంది. Host directory ని ఆ నంబర్‌కు మార్చండి, లేదా service లో user: "1000:1000" ఉపయోగించి container ను మీ నంబర్‌కు pin చేయండి. మీరు స్వయంగా రాసిన అప్లికేషన్ అయితే user: తో pin చేయడం సులభంగా ఉంటుంది. మీరు రాయనటువంటి image అయితే, host directory కి chown చేయడం సురక్షితం. ఎందుకంటే కొన్ని images root గా entrypoint ను ప్రారంభించి, ఆ తర్వాత privileges తగ్గించుకుంటాయి మరియు నిర్దిష్ట ownership ను ఆశిస్తాయి.

తెలుసుకోవలసిన మరో రెండు విషయాలు ఉన్నాయి. Fedora, RHEL మరియు SELinux (security-enhanced Linux) ఎన్‌ఫోర్స్ చేసే ఇతర సిస్టమ్‌లలో, bind mount ను relabel చేసే వరకు అనుమతించరు. కాబట్టి, కంటైనర్ల మధ్య షేర్ చేసే path కోసం :z ని, లేదా ఒకే కంటైనర్ ఉపయోగించే path కోసం :Z ని (దీనిని - ./data:/data:Z గా రాయాలి) జోడించండి. అలాగే, directory కి బదులుగా ఒకే file ను bind mount చేసినప్పుడు, ఒక editor ఆ file ను మార్చినప్పుడు (replace చేసినప్పుడు) అది విఫలమవుతుంది, ఎందుకంటే mount అనేది అసలు inode ను అనుసరిస్తుంది. మీరు container ను restart చేసే వరకు అది పాత కంటెంట్‌నే చూపిస్తుంది. File తరచుగా ఎడిట్ చేయబడుతుంటే, దాని parent directory ని mount చేయండి.

పనితీరు: వ్యత్యాసం ఎక్కడ ఉంటుంది

Linux సర్వర్‌పై రెండు రకాల మౌంట్లు ఒకే kernel పాత్ ద్వారా వెళ్తాయి, కాబట్టి throughput లో వ్యత్యాసం చాలా తక్కువగా ఉంటుంది; దీని ఆధారంగా మీరు నిర్ణయం తీసుకోవాల్సిన అవసరం లేదు. డిఫాల్ట్ local డ్రైవర్‌ను ఉపయోగించే Named volumes, Docker లోని మిగిలిన ఫైల్ సిస్టమ్‌తో పాటు /var/lib/docker/volumes/ కింద ఉంటాయి, కానీ bind mount మీరు సూచించిన చోట ఉంటుంది.

macOS మరియు Windows కోసం Docker Desktop లో ఈ వ్యత్యాసం కనిపిస్తుంది, ఎందుకంటే అక్కడ కంటైనర్లు ఒక virtual machine లో నడుస్తాయి. అక్కడ ఒక bind mount హోస్ట్ ఫైల్ సిస్టమ్ నుండి ఫైల్ షేరింగ్ లేయర్ ద్వారా virtual machine లోకి వెళ్తుంది. Node.js డిపెండెన్సీ ట్రీ లేదా PHP ఫ్రేమ్‌వర్క్ కాష్ వంటి అనేక చిన్న ఫైల్ ఆపరేషన్లు ఉన్నప్పుడు పనితీరు గణనీయంగా తగ్గుతుంది. Named volumes ఆ virtual machine లోనే ఉంటాయి కాబట్టి ఈ భారం ఉండదు. అందుకే చాలా డెవలప్‌మెంట్ compose ఫైల్స్ సోర్స్ డైరెక్టరీని bind-mount చేస్తాయి, కానీ node_modules పై Named volume ను డిక్లేర్ చేస్తాయి.

మరో ముఖ్యమైన వ్యత్యాసం డేటా ఎక్కడ నిల్వ అవుతుందనేది. /mnt/backup కి bind mount చేస్తే డేటా ఆ డిస్క్‌పై ఉంటుంది. Named volume అనేది /var/lib/docker ఉన్న ఫైల్ సిస్టమ్‌పై ఉంటుంది, VPS లలో ఇది సాధారణంగా రూట్ డిస్క్ అవుతుంది. Named volume లో పెరుగుతున్న డేటాబేస్ మీ సిస్టమ్ లాగ్స్ ఉన్న డిస్క్‌నే నింపేస్తుంది. సమస్యగా మారకముందే దీన్ని తనిఖీ చేయండి:

docker system df -v
df -h /var/lib/docker

docker system df -v ప్రతి వాల్యూమ్ పరిమాణాన్ని జాబితా చేస్తుంది మరియు ఏ కంటైనర్ ఉపయోగించని వాల్యూమ్‌లను గుర్తిస్తుంది.

Named volume ను పరిశీలించడం

Named volume అనేది ఒక అపారదర్శకమైన పెట్టె కాదు. అది ఎక్కడ ఉందో Docker ను అడగండి:

docker volume inspect myapp_pgdata

Mountpoint ఫీల్డ్ ఒక వాస్తవ host path ను చూపుతుంది, ఇది సాధారణంగా /var/lib/docker/volumes/myapp_pgdata/_data గా ఉంటుంది. మీరు దీన్ని sudo ls తో చదవవచ్చు, ఇది త్వరిత తనిఖీకి ఉపయోగపడుతుంది. అయితే, ఫైళ్లను సవరించడానికి దీనిని ఒక ప్రదేశంగా పరిగణించవద్దు. root గా అక్కడ రాయడం వల్ల పైన పేర్కొన్న ownership సమస్యలు మళ్లీ తలెత్తుతాయి, మరియు ఈ path అనేది local డ్రైవర్‌కు సంబంధించిన ఒక అంతర్గత వివరము మాత్రమే, ఇది ఇతర volume డ్రైవర్లలో ఉండకపోవచ్చు.

దీని లోపల చూడటానికి సురక్షితమైన మార్గం ఏమిటంటే, ఆ volume ను mount చేసే ఒక తాత్కాలిక (throwaway) container ను ఉపయోగించడం:

docker run --rm -v myapp_pgdata:/vol alpine ls -la /vol

ఇది ఏ డ్రైవర్‌కైనా పనిచేస్తుంది, అసలు container చూసే అదే permissions ను ఇది కూడా చూస్తుంది, మరియు --rm కారణంగా ఇది ఎటువంటి వ్యర్థాలను మిగిల్చదు.

ప్రతి రకమైన బ్యాకప్‌ను నిర్వహించడం

Bind mount అనేది ఒక సాధారణ డైరెక్టరీ, కాబట్టి ఏదైనా ఫైల్-స్థాయి బ్యాకప్ సాధనం దీనిని సులభంగా హ్యాండిల్ చేస్తుంది. హోస్ట్ పాత్ (host path) వద్దకు బ్యాకప్‌ను పాయింట్ చేస్తే సరిపోతుంది. Named volume విషయంలో ఒక అదనపు దశ అవసరం, ఎందుకంటే ఆ సాధనం వాల్యూమ్ లోపలికి వెళ్లాల్సి ఉంటుంది. వాల్యూమ్‌ను మరియు ఒక హోస్ట్ డైరెక్టరీని ఒకే తాత్కాలిక కంటైనర్‌లోకి మౌంట్ చేసి, ఆపై ఒక ఆర్కైవ్‌ను క్రియేట్ చేయండి:

docker run --rm \
  -v myapp_pgdata:/data:ro \
  -v "$PWD":/backup \
  alpine tar czf /backup/pgdata.tar.gz -C /data .

దీనిని రివర్స్ చేయడం ద్వారా కొత్త వాల్యూమ్‌లోకి రీస్టోర్ చేయండి:

docker volume create myapp_pgdata_restored
docker run --rm \
  -v myapp_pgdata_restored:/data \
  -v "$PWD":/backup \
  alpine tar xzf /backup/pgdata.tar.gz -C /data

tar కంటైనర్ లోపల root యూజర్‌గా రన్ అయినప్పుడు సంఖ్యాపరమైన యాజమాన్యాన్ని (numeric ownership) అలాగే ఉంచుతుంది, దీనివల్ల రీస్టోర్ చేసిన వాల్యూమ్‌ను అప్లికేషన్ ఉపయోగించుకోగలదు.

రెండు రకాలకు ఒక హెచ్చరిక వర్తిస్తుంది. డేటాబేస్ రన్ అవుతున్నప్పుడు దాని ఫైళ్లను కాపీ చేయడం వల్ల, మారుతున్న డేటా యొక్క ఆర్కైవ్ తయారవుతుంది, ఇది రీస్టోర్ చేసినప్పుడు డేటా కరప్ట్ అయ్యేలా చేయవచ్చు. ముందుగా సర్వీస్‌ను ఆపండి, లేదా docker compose exec -T db pg_dump -U postgres appdb > appdb.sql లో చూపిన విధంగా డేటాబేస్ సొంత సాధనం ద్వారా డంప్ తీసుకోండి. దీనివల్ల ఒక సాధారణ ఫైల్ తయారవుతుంది, దీనిని మీరు మీ compose ఫైళ్లతో పాటు సాధారణ encrypted restic backup routine లో చేర్చుకోవచ్చు.

Bind mount ను named volume కు మార్చడం

ఈ మార్పు కేవలం కాపీ మాత్రమే, పేరు మార్చడం కాదు. దీనికి సుమారు ఒక నిమిషం సమయం పడుతుంది.

docker compose down
docker volume create myapp_pgdata
docker run --rm \
  -v "$PWD/data":/from \
  -v myapp_pgdata:/to \
  alpine sh -c 'cp -a /from/. /to/'

cp -a కమాండ్ ఫైల్ యాజమాన్యం (ownership), మోడ్‌లు మరియు టైమ్‌స్టాంపులను అలాగే ఉంచుతుంది. కాబట్టి పాత డైరెక్టరీని చదవగలిగిన కంటైనర్ యూజర్, కొత్త వాల్యూమ్‌ను కూడా చదవగలరు. ఆ తర్వాత, సర్వీస్‌ను pgdata:/var/lib/postgresql/data ఉపయోగించేలా మార్చండి, టాప్-లెవల్ volumes: బ్లాక్‌కు pgdata ని జోడించండి, docker compose up -d ని రన్ చేయండి, మరియు పాత డైరెక్టరీని తొలగించే ముందు అప్లికేషన్ లాగ్‌లను పరిశీలించండి. దీనికి విరుద్ధంగా చేయాలంటే, ఇదే కమాండ్‌లో /from మరియు /to లను పరస్పరం మార్చి ఉపయోగించండి.

పరీక్షించేటప్పుడు ఒక విషయాన్ని గుర్తుంచుకోండి. docker compose down కమాండ్ named volumes ను ఏమీ చేయదు, కానీ docker compose down -v కమాండ్ ప్రాజెక్ట్‌లో ప్రకటించిన ప్రతి named volume ను తొలగిస్తుంది. దీనిని వెనక్కి తీసుకునే (undo) అవకాశం లేదు. Bind mount మాత్రం ఈ రెండు కమాండ్ల నుండి సురక్షితంగా ఉంటుంది, ఎందుకంటే ఆ డైరెక్టరీపై Docker కు యాజమాన్యం ఉండదు. ఒకవేళ మీకు ఈ lifecycle కమాండ్లు కొత్తగా ఉంటే, VPS కోసం Docker Compose ప్రాథమిక మార్గదర్శిని మీకు సహాయపడుతుంది.

సేవను బట్టి ఎంపిక చేసుకోవడం

ఫైల్‌ను ఎవరు రాస్తారో గమనించండి. మీరు టెక్స్ట్ ఎడిటర్‌లో ఎడిట్ చేసి git లో commit చేసే కాన్ఫిగరేషన్ ఫైల్స్ bind mount లో ఉండాలి, అంటే :ro లో mount చేయాలి, ఎందుకంటే అవి మీకు కనిపించాలి మరియు version control లో ఉండాలి. మీరు ఎప్పుడూ మాన్యువల్‌గా తెరవని అప్లికేషన్ స్టేట్ (application state) named volume లో ఉండాలి, ఎందుకంటే Docker వాటి అనుమతులను (permissions) సరిగ్గా సెట్ చేస్తుంది మరియు ఆ డేటా హోస్ట్ పాత్‌పై ఆధారపడి ఉండదు.

వీటి రెండింటి కలయిక మీడియా ఫైల్స్ విషయంలో ఉంటుంది. ఫోటో లైబ్రరీని అప్లికేషన్ రాస్తుంది, కానీ మీరు కూడా దానిని నిర్వహిస్తారు. ఇది తరచుగా పెద్ద పరిమాణంలో ఉంటుంది కాబట్టి, దీని కోసం ప్రత్యేక డిస్క్ అవసరం కావచ్చు. దానిని ఆ డిస్క్‌లోని ఒక పాత్‌కు bind mount చేయండి మరియు ఒకసారి జాగ్రత్తగా ownership సెట్ చేయండి. చాలా self-hosted స్టాక్‌లు అనుసరించే పద్ధతి ఇదే: డేటాబేస్‌లు మరియు కాష్‌ల కోసం named volumes, కాన్ఫిగరేషన్ మరియు మీరు జాగ్రత్తగా చూసుకోవాల్సిన పెద్ద డైరెక్టరీల కోసం bind mounts వాడటం. VPS పై నడుస్తున్న Chatwoot వంటి సపోర్ట్ డెస్క్ అప్లికేషన్లు సరిగ్గా ఈ పద్ధతినే పాటిస్తాయి; ఇందులో Postgres ఒక named volume లో ఉంటుంది మరియు అప్‌లోడ్ చేసిన అటాచ్‌మెంట్‌లు మీరు బ్యాకప్ తీసుకోవడానికి వీలుగా ఒక పాత్‌లో ఉంటాయి.

FAQ

bind mount మరియు named volume మధ్య తేడా ఏమిటి?

bind mount అనేది హోస్ట్ మెషీన్‌లోని ఒక పాత్‌ను కంటైనర్‌లోకి మ్యాప్ చేస్తుంది. దీనివల్ల రెండు వైపులా ఒకే డైరెక్టరీ కనిపిస్తుంది మరియు మీరు సాధారణ టూల్స్‌తో దానిని ఎడిట్ చేయవచ్చు. named volume అనేది Docker సృష్టించి నిర్వహించే స్టోరేజ్. దీనిని పేరుతో పిలుస్తారు మరియు టాప్-లెవల్ volumes: బ్లాక్‌లో డిక్లేర్ చేస్తారు. ఆచరణాత్మక విభజన ఏమిటంటే: మీరు నిర్వహించే కాన్ఫిగరేషన్ కోసం bind mounts, అప్లికేషన్ నిర్వహించే డేటా కోసం named volumes వాడాలి.

bind mount వాడినప్పుడు "permission denied" అని ఎందుకు వస్తుంది, named volume లో ఎందుకు రాదు?

ఖాళీగా ఉన్న named volume ఇమేజ్ నుండి సీడ్ చేయబడుతుంది, కాబట్టి అది ఇమేజ్ సెట్ చేసిన ఓనర్‌షిప్‌ను పొందుతుంది మరియు కంటైనర్ యూజర్ దానిలో రాయగలరు. bind mount హోస్ట్ డైరెక్టరీని ఉన్నది ఉన్నట్లుగా చూపిస్తుంది. ఒకవేళ Docker ఆ డైరెక్టరీని సృష్టించాల్సి వస్తే, అది root ఓనర్‌షిప్‌తో సృష్టించబడుతుంది. కంటైనర్ ఉపయోగిస్తున్న numeric idని చూడటానికి docker compose exec <service> id రన్ చేయండి, ఆపై హోస్ట్ డైరెక్టరీని sudo chown -R <uid>:<gid> చేయండి, లేదా సర్వీస్‌పై user: "1000:1000" సెట్ చేయండి.

Docker named volumes ను డిస్క్‌లో ఎక్కడ నిల్వ చేస్తుంది?

డిఫాల్ట్ local డ్రైవర్‌తో అవి /var/lib/docker/volumes/<volume>/_data కింద ఉంటాయి, మరియు docker volume inspect <volume> ఖచ్చితమైన Mountpoint ను ప్రింట్ చేస్తుంది. ఏదైనా తనిఖీ చేయాలంటే అక్కడ చదవండి, కానీ కంటైనర్ ద్వారా మాత్రమే రాయండి. ఎందుకంటే హోస్ట్‌పై root గా ఎడిట్ చేయడం వల్ల కంటైనర్ ఊహించని విధంగా ఓనర్‌షిప్ మారిపోతుంది.

named volume ను బ్యాకప్ చేయడం ఎలా?

వాల్యూమ్ మరియు హోస్ట్ డైరెక్టరీ రెండింటినీ మౌంట్ చేసి ఒక చిన్న కాలపరిమితి గల కంటైనర్‌ను రన్ చేయండి, ఆపై docker run --rm -v myvol:/data:ro -v "$PWD":/backup alpine tar czf /backup/myvol.tar.gz -C /data . తో ఒకదాని నుండి మరొకదానికి ఆర్కైవ్ చేయండి. డేటాబేస్ కోసం, లైవ్ ఫైళ్లను కాపీ చేసే బదులు డేటాబేస్ సొంత టూల్‌తో డంప్ తీయండి. ఎందుకంటే రైట్స్ జరుగుతున్నప్పుడు కాపీ చేసిన ఫైల్స్ పాడైపోయే అవకాశం ఉంది.

docker compose down నా వాల్యూమ్‌లను డిలీట్ చేస్తుందా?

docker compose down కంటైనర్లు మరియు నెట్‌వర్క్‌లను తొలగిస్తుంది, కానీ named volumes అలాగే ఉంటాయి. docker compose down -v ప్రాజెక్ట్ డిక్లేర్ చేసిన ప్రతి named volume ను శాశ్వతంగా తొలగిస్తుంది. Bind mounts ఏ కమాండ్‌తోనూ తొలగించబడవు, ఎందుకంటే ఆ డైరెక్టరీ హోస్ట్‌కు చెందినది, Docker కు కాదు.