Docker Compose: Bind mount vs Named volume வேறுபாடுகள்

Bind mount அல்லது named volume: சுருக்கமான பதில்

Docker Compose volumes இரண்டு வகைகளாக உள்ளன. கோப்புகளை யார் நிர்வகிக்கிறார்கள் என்பதே இதற்கான தேர்வு. நீங்கள் நேரடியாகப் படிக்கும் அல்லது எழுதும் கோப்புகளுக்கு (உதாரணமாக: config, templates, static sites) bind mount-ஐப் பயன்படுத்தவும். பயன்பாடு (application) சொந்தமாக உருவாக்கும் தரவுகளுக்கு (உதாரணமாக: database files, search indexes, uploaded media) named volume-ஐப் பயன்படுத்தவும். Bind mount என்பது host-ல் உள்ள ஒரு பாதையைக் குறிக்கும், அதை நீங்கள் ஒரு editor மூலம் திறக்க முடியும். Named volume என்பது Docker-ஆல் உருவாக்கப்பட்டு நிர்வகிக்கப்படும் சேமிப்பகம், இதை நீங்கள் Docker மூலமாகவே அணுக முடியும்.

இரண்டுமே ஒரு service-க்குள் ஒரே volumes: key-ன் கீழ் வருவதால், குழப்பம் ஏற்பட வாய்ப்புள்ளது. இவற்றிற்கு இடையிலான வேறுபாடு colon-க்கு இடதுபுறம் உள்ள பகுதியில் உள்ளது. இடதுபுறம் . அல்லது / என்று தொடங்கினால் அது host path, அதாவது அது ஒரு bind mount. மற்றவை அனைத்தும் ஒரு பெயரைக் குறிக்கும், எனவே அது ஒரு named volume. அந்தப் பெயர் மேல்மட்டத்தில் உள்ள 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 என்பது ஒரு named volume ஆகும். ./nginx.conf:/etc/nginx/nginx.conf என்பது ஒரு bind mount ஆகும், மேலும் :ro அதை read-only முறையில் mount செய்கிறது. ஒரு container மாற்றியமைக்கக் கூடாத configuration கோப்புகளுக்கு இதுவே சரியான இயல்புநிலை (default) அமைப்பாகும். மேல்மட்டத்திலுள்ள volumes: உள்ளீட்டை நீக்கினால், service "db" refers to undefined volume pgdata பிழையுடன் Compose நின்றுவிடும்.

இதை இயக்கி, Docker உருவாக்கியுள்ளவற்றை பட்டியலிடவும்:

docker compose up -d
docker volume ls

இந்த volume-க்கு pgdata என்று பெயரிடப்படவில்லை. இதற்கு <project>_pgdata என்று பெயரிடப்பட்டுள்ளது; இதில் project-ன் பெயர், compose கோப்பு உள்ள கோப்பகத்தின் (directory) பெயரை இயல்புநிலையாகக் கொள்கிறது. myapp என்ற பெயருடைய கோப்பகம் myapp_pgdata என்பதை உருவாக்குகிறது. கோப்பகத்தின் பெயரை மாற்றினால் புதிய காலி volume உருவாகும் என்பதால் இது முக்கியமானது; அப்போது உங்கள் application தரவுகளை இழந்தது போலத் தோன்றும். உண்மையில் தரவுகள் இழக்கப்படவில்லை: பழைய volume docker volume ls கட்டளையின் மூலம் பட்டியலிடப்படும். கோப்பகம் மாறக்கூடும் என்றால், compose கோப்பில் name: மூலம் பெயரை உறுதிப்படுத்தவும் அல்லது COMPOSE_PROJECT_NAME-ஐ அமைக்கவும். இது போன்ற அமைப்புகள் உங்கள் பிற Compose environment கோப்புகள் மற்றும் ரகசியங்கள் பிரிவில் இடம்பெற வேண்டும்.

bind mount-களில் ஏன் பெரும்பாலும் அனுமதி பிழைகள் ஏற்படுகின்றன

இதுவே நடைமுறையில் உள்ள மிகப்பெரிய வேறுபாடு. இது ஒரு விதியிலிருந்து வருகிறது: முதலில் காலியாக இருக்கும் named volume ஒன்று image-லிருந்து தரவுகளைப் பெற்றுக்கொள்ளும் (seeded), ஆனால் bind mount ஒருபோதும் அவ்வாறு செய்யாது.

Docker ஒரு காலியான named volume-ஐ, ஏற்கனவே image-ல் உள்ளடக்கத்தைக் கொண்ட ஒரு directory-ன் மீது mount செய்யும்போது, அந்த உள்ளடக்கத்தை volume-க்குள் நகலெடுக்கும். அப்போது image அமைத்த ownership மற்றும் modes அப்படியே இருக்கும். அதிகாரப்பூர்வமான Postgres image, அதன் சொந்த postgres user-ஆல் நிர்வகிக்கப்படும் /var/lib/postgresql/data-ஐக் கொண்டுள்ளது. எனவே, அந்த volume-ம் அதே numeric id-ஐக் கொண்ட ownership-ஐப் பெற்று, database தொடங்குகிறது.

அந்த seeding மட்டுமே named volume-க்குக் கிடைக்கும் ஒரே தொடக்க வசதியாகும். Volume எங்கே இருக்கிறது என்பதை Docker நிர்வகித்தாலும், containers அதை சாதாரண filesystem செயல்பாடுகள் மூலமே படிக்கின்றன மற்றும் எழுதுகின்றன. எனவே, bind mount-ல் இருப்பது போலவே இதிலும் ownership மற்றும் modes அமல்படுத்தப்படுகின்றன. Image-ல் இல்லாத ஒரு பாதையில் mount செய்யப்படும் named volume, அல்லது வேறு ஒரு image அல்லது user-ஆல் முதலில் நிரப்பப்பட்ட volume, image-லிருந்து எந்த ownership-ஐயும் பெறாது. அங்கும் root அல்லாத ஒரு process-க்கு அனுமதி மறுக்கப்படலாம். கீழே உள்ள id சோதனை இரண்டு வகைக்கும் பொருந்தும்.

Bind mount இதற்கு நேர்மாறாகச் செயல்படுகிறது. Host-ல் என்ன இருக்கிறதோ அதைத்தான் container பார்க்கும் (ownership உட்பட). அந்தப் பாதையில் உள்ள image-ன் உள்ளடக்கம் மறைக்கப்படும். Host directory இல்லையென்றால், Docker daemon அதை உருவாக்கும். Daemon root-ஆக இயங்குவதால், root:root-க்குச் சொந்தமான ஒரு directory உங்களுக்குக் கிடைக்கும். அப்போது root அல்லாத user-ஆக இயங்கும் ஒரு container process-ஆல் அதில் எழுத முடியாது:

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

இதற்கான தீர்வு, எண்களைச் சரியாகப் பொருத்துவதாகும். Bind mount-ல் ownership என்பது பெயரால் அல்ல, numeric user id-ஆல் ஒப்பிடப்படுகிறது. ஏனெனில், container-க்கு அதன் சொந்த /etc/passwd உள்ளது. Container-க்குள் app என்று அழைக்கப்படும் ஒரு user, host-ல் எந்த மாற்றத்தையும் ஏற்படுத்தாது. Daemon, user-namespace remapping (userns-remap, இது /etc/docker/daemon.json-ல் அல்லது dockerd command line-ல் அமைக்கப்படும்) வசதியுடன் இயங்கினால் ஒழிய, Uid 1000 என்பது இரு பக்கங்களிலும் Uid 1000-ஐயே குறிக்கும். Remapping, ஒவ்வொரு container id-யையும் host-ல் உள்ள ஒரு subordinate வரம்பிற்கு மாற்றும். Docker-ன் உதாரண வரம்பான 231072-ல், container uid 0 என்பது host uid 231072 ஆகும். எனவே, container uid 1000 என்பது host uid 232072 ஆகும்.

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

docker compose exec web id, container process உண்மையில் எந்த uid-ல் இயங்குகிறது என்பதைக் காட்டும். Remapping இல்லையென்றால், host directory-யை அந்த எண்ணிற்குப் பொருத்தவும், அல்லது service-ல் user: "1000:1000" மூலம் container-ஐ உங்கள் எண்ணிற்குப் பூட்டவும் (pin). Remapping செயல்பாட்டில் இருக்கும்போது, user:-ஆல் container-ஐ உங்கள் host எண்ணிற்குப் பூட்ட முடியாது. ஏனெனில் நீங்கள் அமைக்கும் id-யும் மாற்றப்படும்: அந்த உதாரண வரம்பில் user: "1000:1000" என்பது host uid 232072-லேயே அமையும். அதற்குப் பதிலாக, host directory-க்கு mapped host id-யை chown செய்யவும் (உங்கள் சொந்த வரம்பு /etc/subuid மற்றும் /etc/subgid-ல் உள்ளது). Docker ஆவணங்கள், ஒரு தனி container-க்கு remapping-ஐ நிறுத்த docker container create, run அல்லது exec-ல் --userns=host-ஐ மட்டுமே குறிப்பிடுகின்றன. நீங்கள் சொந்தமாக எழுதிய application-க்கு user:-ஐப் பூட்டுவது (pinning) எளிதானது. நீங்கள் எழுதாத ஒரு image-க்கு host directory-யை chown செய்வது பாதுகாப்பானது. ஏனெனில் சில images, entrypoint-ஐ root-ஆகத் தொடங்கி, பின் சலுகைகளைக் குறைத்து (drop privileges), குறிப்பிட்ட ownership-ஐ எதிர்பார்க்கும்.

மேலும் இரண்டு சிக்கல்களைத் தெரிந்துகொள்வது அவசியம். Fedora, RHEL மற்றும் SELinux (security-enhanced Linux) அமலில் உள்ள பிற அமைப்புகளில், bind mount மறுக்கப்படும். எனவே, containers-க்கு இடையே பகிரப்படும் பாதைக்கு :z-ஐச் சேர்க்கவும், அல்லது ஒரு container மட்டும் பயன்படுத்தும் பாதைக்கு :Z-ஐச் சேர்க்கவும் (இது - ./data:/data:Z என எழுதப்படும்). மேலும், directory-க்கு பதிலாக ஒரு கோப்பை (file) மட்டும் bind mount செய்யும்போது, ஒரு editor அந்த கோப்பை மாற்றி எழுதும் (replace) போது mount செயலிழக்கும். ஏனெனில் mount, அசல் inode-ஐப் பின்தொடரும். நீங்கள் restart செய்யும் வரை container பழைய உள்ளடக்கத்தையே பார்க்கும். கோப்பை அடிக்கடி திருத்தினால், அதன் parent directory-யை mount செய்யவும்.

செயல்திறன்: இடைவெளி எங்கே உண்மையானது

Linux server-ல் இரண்டு வகைகளும் ஒரே kernel path வழியாகவே செல்கின்றன, எனவே throughput-ல் உள்ள வித்தியாசம் மிகக் குறைவு; இதை அடிப்படையாகக் கொண்டு நீங்கள் எதையும் தேர்வு செய்ய வேண்டியதில்லை. இயல்பான local driver-ஐப் பயன்படுத்தும் named volumes, Docker-ன் பிற பகுதிகள் இருக்கும் அதே filesystem-ல், /var/lib/docker/volumes/-க்குக் கீழ் அமைகின்றன. ஆனால், bind mount நீங்கள் குறிப்பிடும் எந்த இடத்திலும் அமையும்.

Docker Desktop for macOS மற்றும் Windows-ல் இந்த இடைவெளி தெளிவாகத் தெரியும், ஏனெனில் அங்கு containers ஒரு virtual machine-க்குள் இயங்குகின்றன. அங்கு ஒரு bind mount, host filesystem-லிருந்து அந்த virtual machine-க்குள் ஒரு file sharing layer வழியாகச் செல்கிறது. இதனால், Node.js dependency tree அல்லது PHP framework cache போன்ற பல சிறிய file செயல்பாடுகளைக் கொண்ட workloads குறிப்பிடத்தக்க அளவில் வேகம் குறைகின்றன. Named volumes அந்த virtual machine-க்குள்ளேயே இருப்பதால், இந்தச் செலவை (cost) அவை ஏற்பதில்லை. இதனால்தான் பல development compose files, source directory-ஐ bind-mount செய்தாலும், node_modules-க்கு மேல் ஒரு named volume-ஐ அறிவிக்கின்றன.

மற்றொரு முக்கியமான வித்தியாசம் தரவுகள் எங்கு சேமிக்கப்படுகின்றன என்பதுதான். /mnt/backup-க்கு ஒரு bind mount செய்வது, தரவுகளை அந்த disk-ல் வைக்கிறது. ஒரு named volume, /var/lib/docker இருக்கும் எந்த filesystem-ல் வேண்டுமானாலும் அமையும்; VPS-ல் இது பொதுவாக root disk-ஆகவே இருக்கும். ஒரு named volume-க்குள் வளரும் database, உங்கள் system logs இருக்கும் அதே disk-ஐ நிரப்பிவிடும். ஒரு சிக்கலாக மாறுவதற்கு முன் அதைச் சரிபார்க்கவும்:

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

docker system df -v ஒவ்வொரு volume-ன் அளவையும் பட்டியலிடுகிறது, மேலும் எந்த container-உம் பயன்படுத்தாத volumes-ஐயும் இது குறிக்கும்.

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 driver-ன் ஒரு நுணுக்கம் மட்டுமே, மற்ற volume driver-களில் இது இருக்காது.

அதற்குள் பார்ப்பதற்கான பாதுகாப்பான வழி, அந்த volume-ஐ mount செய்யும் ஒரு தற்காலிக container-ஐப் பயன்படுத்துவதாகும்:

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

இது எந்தவொரு driver-க்கும் வேலை செய்யும், உண்மையான container பார்க்கும் அதே அனுமதிகளை இதுவும் பார்க்கும், மேலும் --rm காரணமாக இது எதையும் பின்னால் விட்டுச் செல்லாது.

ஒவ்வொரு வகைக்கும் பேக்கப் எடுத்தல்

Bind mount என்பது ஒரு சாதாரண directory ஆகும், எனவே எந்தவொரு file-level backup கருவியும் இதை எளிதாகக் கையாளும். Host path-ஐ பேக்கப் கருவியில் குறிப்பிட்டால் போதுமானது. Named volume-க்கு கூடுதல் ஒரு படி தேவை, ஏனெனில் பேக்கப் கருவி அந்த volume-க்குள் நுழைய வேண்டும். ஒரு தற்காலிக container-ல் அந்த volume-ஐயும் ஒரு host directory-யையும் mount செய்து, பின்வருமாறு archive உருவாக்கவும்:

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

புதிய 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

tar, container-க்குள் root பயனர் மூலம் இயங்கும்போது numeric ownership-ஐ அப்படியே பாதுகாக்கிறது. இதுவே மீட்டெடுக்கப்பட்ட volume-ஐ application பயன்படுத்தக்கூடிய நிலையில் வைத்திருக்க உதவுகிறது.

இரண்டு வகைக்கும் ஒரு எச்சரிக்கை பொருந்தும். Database இயங்கிக்கொண்டிருக்கும்போது அதன் கோப்புகளை நகலெடுப்பது, மாறிக்கொண்டிருக்கும் தரவின் archive-ஐ உருவாக்கும்; இது மீட்டெடுக்கும்போது தரவு சிதைந்த நிலைக்கு (corrupt state) செல்லக்கூடும். எனவே, முதலில் service-ஐ நிறுத்தவும் அல்லது docker compose exec -T db pg_dump -U postgres appdb > appdb.sql-ல் உள்ளவாறு database-ன் சொந்தக் கருவியைப் பயன்படுத்தி dump எடுக்கவும். இது ஒரு சாதாரண கோப்பை உருவாக்கும், அதை நீங்கள் உங்கள் compose கோப்புகளுடன் சேர்த்து ஒரு encrypted restic backup routine-ல் இணைக்கலாம்.

Bind mount-ஐ named volume-க்கு மாற்றுதல்

இந்த மாற்றம் ஒரு நகலெடுப்பு (copy) ஆகும், இது பெயர் மாற்றம் (rename) அல்ல. இதற்கு சுமார் ஒரு நிமிடம் ஆகும்.

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, modes மற்றும் timestamps ஆகியவற்றை அப்படியே வைத்திருக்கும். எனவே, பழைய directory-ஐ வாசிக்க முடிந்த container user-ஆல் புதிய volume-ஐயும் தொடர்ந்து வாசிக்க முடியும். அதன் பிறகு, pgdata:/var/lib/postgresql/data-ஐப் பயன்படுத்தும் வகையில் service-ஐ மாற்றவும். top-level volumes: block-ல் pgdata-ஐச் சேர்க்கவும். பின் docker compose up -d-ஐ இயக்கவும். பழைய directory-ஐ நீக்குவதற்கு முன்பு, application-ன் logs-ஐச் சரிபார்க்கவும். இதற்கு நேர்மாறான செயல்பாட்டிற்கு, /from மற்றும் /to ஆகியவற்றை இடமாற்றி அதே கட்டளையைப் பயன்படுத்தவும்.

சோதனை செய்யும்போது ஒரு விஷயத்தை நினைவில் கொள்ளவும். docker compose down ஆனது named volumes-ஐப் பாதிக்காது. ஆனால், docker compose down -v அந்த project-ல் அறிவிக்கப்பட்டுள்ள அனைத்து named volumes-ஐயும் நீக்கிவிடும். இதைத் திரும்பப் பெற (undo) முடியாது. Bind mount-ஐ Docker நிர்வகிப்பதில்லை என்பதால், அது இவ்விரண்டு கட்டளைகளாலும் பாதிக்கப்படாது. Lifecycle கட்டளைகள் உங்களுக்குப் புதியவை என்றால், VPS-க்கான Docker Compose அடிப்படை வழிகாட்டி அவற்றை விரிவாக விளக்குகிறது.

சேவை வாரியாகத் தேர்ந்தெடுத்தல்

கோப்பை யார் எழுதுகிறார்கள் என்பதைக் கவனியுங்கள். நீங்கள் text editor மூலம் திருத்தி git-ல் commit செய்யும் configuration கோப்புகள் bind mount-ல் இருக்க வேண்டும், அவை :ro-ல் mount செய்யப்பட வேண்டும், ஏனெனில் அவை உங்களுக்குத் தெரிய வேண்டும் மற்றும் version-களாகப் பராமரிக்கப்பட வேண்டும். நீங்கள் ஒருபோதும் கைமுறையாகத் திறக்காத application state-கள் named volume-ல் இருக்க வேண்டும், ஏனெனில் Docker அந்த image-லிருந்து அனுமதிகளை (permissions) வழங்குகிறது மற்றும் தரவு host path-ஐச் சார்ந்திருப்பதில்லை.

கலப்பு நிலை என்பது media கோப்புகள் ஆகும். ஒரு photo library-ஐ application எழுதும், ஆனால் அதை நீங்களும் நிர்வகிப்பீர்கள்; அது பெரும்பாலும் ஒரு குறிப்பிட்ட disk-ஐப் பயன்படுத்தும் அளவுக்குப் பெரியதாக இருக்கும். அதை அந்த disk-ல் உள்ள ஒரு path-க்கு bind mount செய்து, அதன் உரிமையாளரை (ownership) ஒருமுறை கவனமாக அமைத்துக்கொள்ளுங்கள். பெரும்பாலான self-hosted stack-கள் இந்த முறையையே பின்பற்றுகின்றன: database மற்றும் cache-களுக்கு named volume-களையும், configuration மற்றும் நீங்கள் முக்கியமாகக் கருதும் பெரிய கோப்பகங்களுக்கு (directories) bind mount-களையும் பயன்படுத்துகின்றன. VPS-ல் இயங்கும் Chatwoot போன்ற ஒரு support desk இந்த முறையில்தான் அமைகிறது; இதில் Postgres ஒரு named volume-லும், பதிவேற்றப்பட்ட இணைப்புகள் (attachments) நீங்கள் backup எடுக்கக்கூடிய ஒரு path-லும் இருக்கும்.

FAQ

Bind mount மற்றும் named volume-க்கு இடையே உள்ள வேறுபாடு என்ன?

Bind mount என்பது host-ல் உள்ள ஒரு பாதையை container-க்குள் வரைபடமாக்குகிறது (map). இதனால் இரு பக்கமும் ஒரே directory தெரியும், நீங்கள் சாதாரண கருவிகளைக் கொண்டு அதைத் திருத்தலாம். Named volume என்பது Docker உருவாக்கி நிர்வகிக்கும் சேமிப்பகம் ஆகும். இது பெயரால் அழைக்கப்பட்டு, உயர்மட்ட volumes: தொகுதியில் அறிவிக்கப்படுகிறது. நடைமுறையில் உள்ள வேறுபாடு ownership ஆகும்: நீங்கள் பராமரிக்கும் config-க்கு bind mount-களையும், application பராமரிக்கும் தரவுகளுக்கு named volume-களையும் பயன்படுத்தவும்.

Bind mount-ல் "permission denied" என்று வருகிறது, ஆனால் named volume-ல் ஏன் வருவதில்லை?

காலியான named volume, image-லிருந்து தரவுகளைப் பெற்றுக்கொள்வதால், அது பொதுவாக image அமைத்த ownership-ஐப் பெறுகிறது. எனவே container user-ஆல் அதில் எழுத முடியும். Image-ல் அந்தப் பாதையில் எதுவும் இல்லையென்றால், இதுவும் அதேபோல் தோல்வியடையலாம். Bind mount, host directory-யை அப்படியே காட்டுகிறது. Docker அந்த directory-யை உருவாக்க வேண்டியிருந்தால், அது root-க்குச் சொந்தமானதாகவே இருக்கும். Container பயன்படுத்தும் numeric id-யைப் பார்க்க docker compose exec <service> id-ஐ இயக்கவும், பின் host directory-க்கு sudo chown -R <uid>:<gid> செய்யவும். அல்லது, daemon user namespaces-ஐ remapping செய்யவில்லை என்றால், service-ல் user: "1000:1000"-ஐ அமைக்கவும். Daemon user-namespace remapping-ஐப் பயன்படுத்தினால், அதற்குப் பதிலாக mapped host id-க்கு chown செய்யவும். ஏனெனில் container-ன் ids host-ல் மாற்றப்படுகின்றன, user: அதை மாற்றாது.

Docker named volume-களை வட்டில் எங்கே சேமிக்கிறது?

இயல்புநிலை local driver-ஐப் பயன்படுத்தும்போது, அவை /var/lib/docker/volumes/<volume>/_data-ன் கீழ் இருக்கும். docker volume inspect <volume>, சரியான Mountpoint-ஐக் காட்டும். ஏதேனும் சரிபார்க்க வேண்டுமென்றால் அதைப் படிக்கவும், ஆனால் container வழியாக மட்டுமே எழுதவும். Host-ல் root-ஆகத் திருத்துவது, container எதிர்பாராத வகையில் ownership-ஐ மாற்றிவிடும்.

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-க்கு, நேரடி கோப்புகளை நகலெடுப்பதற்குப் பதிலாக, database-ன் சொந்தக் கருவியைப் பயன்படுத்தி dump எடுக்கவும். ஏனெனில், எழுதும் பணி நடக்கும்போது எடுக்கப்படும் கோப்பு நகல், மீட்கும்போது சிதைந்த நிலைக்கு (corrupt state) செல்லலாம்.

Docker compose down எனது volume-களை நீக்கிவிடுமா?

docker compose down, containers மற்றும் networks-ஐ நீக்கும், ஆனால் named volume-களை அப்படியே விட்டுவிடும். docker compose down -v, அந்த project-ல் அறிவிக்கப்பட்ட அனைத்து named volume-களையும் நிரந்தரமாக நீக்கிவிடும். Bind mount-கள் எந்தக் கட்டளையாலும் நீக்கப்படாது, ஏனெனில் அந்த directory host-க்குச் சொந்தமானது, Docker-க்கு அல்ல.