Docker Compose मध्ये bind mount की named volume?

Bind mount किंवा named volume: थोडक्यात उत्तर

Docker Compose volumes चे दोन प्रकार आहेत. निवड कोणत्या घटकाकडे फाइल्सची मालकी असते यावर अवलंबून असते. तुम्ही स्वतः लिहिता आणि वाचता अशा फाइल्ससाठी bind mount वापरा. उदाहरणार्थ, config, templates आणि static sites. Application च्या मालकीच्या डेटासाठी named volume वापरा. उदाहरणार्थ, database files, search indexes आणि uploaded media. Bind mount हा host वरील अशा path कडे निर्देश करतो, जो तुम्ही editor मध्ये उघडू शकता. Named volume हे Docker तुमच्यासाठी तयार करून त्याचा मागोवा ठेवते असे storage आहे. त्यात प्रवेश Docker द्वारे केला जातो.

दोन्ही प्रकार service मधील एकाच volumes: key अंतर्गत दिसतात. त्यामुळे त्यांची गल्लत होते. फरक colon च्या डाव्या बाजूला असतो. . किंवा / ने सुरू होणारी डावी बाजू host path असते. त्यामुळे तो bind mount असतो. इतर कोणतीही value ही name असते. त्यामुळे तो named volume असतो. हे name top-level volumes: block मध्येही घोषित केलेले असणे आवश्यक आहे.

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 हे नामांकित volume आहे. ./nginx.conf:/etc/nginx/nginx.conf हा bind mount आहे आणि :ro त्याला read only पद्धतीने mount करते. कंटेनरने कधीही पुन्हा लिहू नये अशा config साठी हा योग्य default आहे. वरच्या स्तरावरील volumes: entry विसरल्यास Compose service "db" refers to undefined volume pgdata सह थांबते.

ते सुरू करा आणि Docker ने तयार केलेल्या गोष्टींची यादी करा:

docker compose up -d
docker volume ls

volume चे नाव pgdata नाही. त्याचे नाव <project>_pgdata आहे. compose फाइल असलेल्या directory च्या नावावरून project name चे default ठरते. myapp नावाची directory असल्यास myapp_pgdata मिळते. Directory चे नाव बदलल्यावर नवीन रिकामा volume मिळतो आणि application मधील data हरवल्यासारखे दिसते, हे महत्त्वाचे आहे. तसे झालेले नसते: जुना volume अजूनही docker volume ls ने सूचीबद्ध केलेला असतो. compose फाइलमध्ये name: वापरून नाव निश्चित करा किंवा directory हलवली जाऊ शकते, तेव्हा COMPOSE_PROJECT_NAME सेट करा. अशा settings तुमच्या इतर Compose environment files आणि secrets सोबत ठेवाव्यात.

परवानगीतील त्रुटी फक्त bind mounts मध्येच का येतात

हा सर्वात महत्त्वाचा व्यावहारिक फरक आहे. यामागे एक नियम आहे: प्रथम वापराच्या वेळी रिकामा named volume image मधून भरला जातो, पण bind mount कधीही अशा प्रकारे भरला जात नाही.

जेव्हा Docker image मध्ये आधीपासून सामग्री असलेल्या directory वर रिकामा named volume 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'

उपाय म्हणजे हे numbers समान करणे. 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 त्या number शी जुळवा किंवा service मध्ये user: "1000:1000" वापरून container ला तुमच्या number वर निश्चित करा. तुम्ही स्वतः लिहिलेल्या application साठी user: निश्चित करणे अधिक स्वच्छ पद्धत आहे. तुम्ही न लिहिलेल्या image साठी host directory चे ownership बदलणे अधिक सुरक्षित आहे, कारण काही images root म्हणून entrypoint सुरू करतात, privileges कमी करतात आणि आत विशिष्ट ownership अपेक्षित ठेवतात.

आणखी दोन अडचणी लक्षात ठेवा. Fedora, RHEL आणि SELinux (security-enhanced Linux) enforcing असलेल्या इतर systems वर bind mount ला relabel केल्याशिवाय प्रवेश नाकारला जातो. त्यामुळे containers मध्ये shared केलेल्या path साठी :z किंवा फक्त एका container ने वापरायच्या path साठी :Z जोडा; हे - ./data:/data:Z म्हणून लिहिले जाते. तसेच directory ऐवजी एकाच file चा bind mount केल्यास editor file मध्ये थेट लिहिण्याऐवजी ती बदलून नवीन file तयार करतो तेव्हा समस्या येते, कारण mount मूळ inode शी जोडलेला असतो. Container ला restart करेपर्यंत जुनी सामग्रीच दिसत राहते. File वारंवार edit केली जात असल्यास parent directory mount करा.

कार्यक्षमता: फरक प्रत्यक्ष कुठे दिसतो

Linux server वर दोन्ही प्रकार समान kernel path मधून जातात. त्यामुळे throughput मधील फरक इतका कमी असतो की त्या आधारावर निवड करू नये. Default local driver वापरणारे named volumes Docker च्या उर्वरित भागासोबत त्याच filesystem वर, /var/lib/docker/volumes/ अंतर्गत, साठवले जातात. Bind mount तुम्ही निर्दिष्ट केलेल्या ठिकाणी राहतो.

Docker Desktop for macOS आणि Windows वर हा फरक दिसतो, कारण containers एका virtual machine मध्ये चालतात. तेथे bind mount host filesystem मधून file sharing layer द्वारे त्या virtual machine मध्ये जातो. Node.js dependency tree किंवा PHP framework cache सारख्या अनेक लहान file operations असलेल्या workload ची गती लक्षणीयरीत्या कमी होते. Named volumes virtual machine मध्येच राहतात आणि हा अतिरिक्त खर्च टाळतात. म्हणूनच अनेक development compose files source directory ला bind-mount करतात, पण node_modules वर named volume घोषित करतात.

Bytes कुठे साठवले जातात, हा दुसरा महत्त्वाचा फरक आहे. /mnt/backup वर केलेला bind mount data त्या disk वर ठेवतो. Named volume /var/lib/docker असलेले filesystem ज्या disk वर आहे तेथे साठवले जाते. VPS वर ते सहसा root disk असते. Named volume मधील database वाढत गेल्यास system logs असलेली त्याच disk ची जागा भरते. समस्या निर्माण होण्यापूर्वी हे तपासा:

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

docker system df -v प्रत्येक volume ची size सूचीबद्ध करते आणि आता कोणताही container वापरत नसलेले volume चिन्हांकित करते.

नावाच्या volume चे निरीक्षण

नावाचे volume म्हणजे अपारदर्शक घटक नाही. ते कुठे आहे हे Docker ला विचारा:

docker volume inspect myapp_pgdata

Mountpoint field मध्ये host वरील प्रत्यक्ष path दिलेला असतो. तो सामान्यतः /var/lib/docker/volumes/myapp_pgdata/_data असतो. तो sudo ls वापरून वाचता येतो आणि जलद तपासणीसाठी ते उपयुक्त आहे. फाइल्स संपादित करण्यासाठी ते ठिकाण म्हणून वापरू नका. तेथे root म्हणून लिहिल्यास वर वर्णन केलेली ownership ची समस्या पुन्हा निर्माण होते. तसेच हा path local driver चा तपशील आहे; इतर volume drivers मध्ये तो उपलब्ध असेलच असे नाही.

आतील सामग्री पाहण्याचा सुरक्षित मार्ग म्हणजे volume mount करणारा तात्पुरता container वापरणे:

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

ही पद्धत कोणत्याही driver साठी कार्य करते. प्रत्यक्ष container ला दिसणाऱ्या समान permissions यात दिसतात. --rm मुळे कोणतेही अवशेष मागे राहत नाहीत.

प्रत्येक प्रकारचा बॅकअप

Bind mount ही एक सामान्य directory असते. त्यामुळे file-level backup tool ती आधीपासून हाताळते. Backup साठी host path निर्दिष्ट करा. काम पूर्ण होते. Named volume साठी एक अतिरिक्त पायरी आवश्यक असते, कारण tool ला त्याच्या आत प्रवेश करावा लागतो. Volume आणि host directory एकाच अल्पकालीन container मध्ये mount करा. त्यानंतर archive लिहा:

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

Fresh volume मध्ये प्रक्रिया उलट करून restore करा:

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

Container मध्ये root म्हणून चालवताना tar numeric ownership जतन करते. त्यामुळे restored volume application साठी वापरण्यायोग्य राहते.

दोन्ही प्रकारांसाठी एकच इशारा लागू आहे. Database चालू असताना त्याच्या files कॉपी केल्यास हलणाऱ्या स्थितीचा archive तयार होतो. तो restore केल्यावर corrupt state निर्माण होऊ शकते. आधी service थांबवा. किंवा docker compose exec -T db pg_dump -U postgres appdb > appdb.sql प्रमाणे database च्या स्वतःच्या tool द्वारे dump घ्या. त्यामुळे plain file तयार होते. त्यानंतर ती compose files सोबत सामान्य 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 मालकी, परवानग्या आणि टाइमस्टॅम्प जतन करते. त्यामुळे जुनी directory वाचू शकणारा container user नवीन volume देखील वाचू शकतो. त्यानंतर service मध्ये pgdata:/var/lib/postgresql/data वापरा, top-level volumes: block मध्ये pgdata जोडा, docker compose up -d चालवा आणि जुनी directory हटवण्यापूर्वी application चे logs वाचा. उलट दिशेने जाण्यासाठी त्याच command मध्ये /from आणि /to यांची अदलाबदल करा.

चाचणी करताना एक गोष्ट लक्षात ठेवा. docker compose down named volumes तसेच ठेवते, पण docker compose down -v project ने घोषित केलेले प्रत्येक named volume हटवते आणि ही कृती पूर्ववत करता येत नाही. bind mount दोन्ही कृतींनंतर टिकून राहते, कारण Docker त्या directory ची मालकी घेतलेली नसते. lifecycle commands अजून परिचित नसल्यास, VPS साठी Docker Compose मूलभूत मार्गदर्शक त्यांची पद्धत समजावून सांगते.

सेवेनुसार निवड

फाइल कोण लिहिते हे ठरवा. Text editor मध्ये संपादित करून git मध्ये commit केलेली config bind mount मध्ये ठेवा आणि ती :ro येथे mount करा, कारण ती दृश्यमान आणि versioned हवी असते. तुम्ही हाताने कधीही न उघडणारी application state named volume मध्ये ठेवा, कारण Docker permissions योग्यरीत्या तयार करते आणि डेटा host path वर अवलंबून राहत नाही.

मिश्र प्रकार media चा आहे. Photo library application लिहिते, परंतु तिचे व्यवस्थापन तुम्हीही करता. ती अनेकदा एखादी विशिष्ट disk वापरण्याइतकी मोठी असते. ती त्या disk वरील path वर bind mount करा आणि ownership एकदाच स्पष्टपणे सेट करा. बहुतेक self-hosted stacks मध्ये हीच पद्धत वापरली जाते: databases आणि caches साठी named volumes, config साठी bind mounts आणि तुम्हाला महत्त्वाच्या असलेल्या मोठ्या directory साठी bind mount.

FAQ

बाइंड माउंट आणि नामांकित व्हॉल्यूम यांच्यात काय फरक आहे?

बाइंड माउंट host वरील एखादा path container मध्ये मॅप करतो. त्यामुळे दोन्ही बाजूंना तोच directory दिसतो आणि तुम्ही तो नेहमीच्या साधनांनी संपादित करू शकता. नामांकित व्हॉल्यूम हे Docker तयार करून व्यवस्थापित करणारे storage आहे. त्याचा संदर्भ नावाने घेतला जातो आणि तो top-level volumes: block मध्ये घोषित केला जातो. व्यावहारिक फरक मालकीचा आहे: तुम्ही व्यवस्थापित करत असलेल्या config साठी bind mounts वापरा आणि application व्यवस्थापित करत असलेल्या data साठी named volumes वापरा.

बाइंड माउंटसह "permission denied" का मिळते, पण नामांकित व्हॉल्यूमसह का मिळत नाही?

रिकामा named volume image मधून seed केला जातो. त्यामुळे image ने सेट केलेली ownership त्याला मिळते आणि container user त्यात लिहू शकतो. Bind mount host directory जशी आहे तशीच दाखवतो. Docker ला तो directory तयार करावा लागला असल्यास तो root च्या मालकीचा तयार केला जातो. Container कोणता numeric id वापरतो ते पाहण्यासाठी docker compose exec <service> id चालवा. त्यानंतर host directory वर sudo chown -R <uid>:<gid> चालवा किंवा service वर user: "1000:1000" सेट करा.

Docker named volumes disk वर कुठे साठवते?

Default local driver वापरताना ते /var/lib/docker/volumes/<volume>/_data अंतर्गत साठवले जातात आणि docker volume inspect <volume> अचूक Mountpoint दाखवते. काही तपासायचे असल्यास ते वाचा. मात्र त्यात लेखन फक्त container मार्फत करा, कारण host वर root म्हणून संपादन केल्यास ownership मध्ये असे बदल होतात, ज्यांची container ला अपेक्षा नसते.

Named volume चा backup कसा घ्यावा?

Volume आणि host directory दोन्ही mount करून अल्पकाळ चालणारा container सुरू करा. त्यानंतर docker run --rm -v myvol:/data:ro -v "$PWD":/backup alpine tar czf /backup/myvol.tar.gz -C /data . वापरून एका ठिकाणाहून दुसऱ्या ठिकाणी archive तयार करा. Database साठी live files कॉपी करण्याऐवजी database च्या स्वतःच्या tool ने dump घ्या. कारण लेखन सुरू असताना घेतलेली file copy restore केल्यावर data corrupt स्थितीत येऊ शकतो.

docker compose down माझे volumes हटवते का?

docker compose down containers आणि networks हटवते आणि named volumes तसेच ठेवते. docker compose down -v project ने घोषित केलेले प्रत्येक named volume देखील हटवते. ही कृती कायमस्वरूपी असते. Bind mounts कोणत्याही command मुळे हटवले जात नाहीत, कारण तो directory host च्या मालकीचा असतो, Docker च्या नाही.