SSD Nodes Learn 🎉 VPS $5.50/నెల నుండి
మార్గదర్శకాలు Matt Connorద్వారా Matt Connor · అప్‌డేట్ చేయబడింది 2026-08-16

VPSలో Docker డిస్క్ స్థలాన్ని ఖాళీ చేయడం ఎలా

VPS డిస్క్ నిండితే ముందుగా images, containers, build cache, volumesలో స్థలాన్ని ఏది తీసుకుంటుందో కనుగొనండి. డేటా కోల్పోకుండా సరైన Docker prune ఆదేశాన్ని ఎంచుకోండి.

prune చేసే ముందు డిస్క్ స్థలాన్ని ఏది ఉపయోగిస్తుందో కనుగొనండి

Docker VPSలో నాలుగు చోట్ల డిస్క్ స్థలాన్ని ఉపయోగిస్తుంది: images, stopped containers, build cache మరియు local volumes. ముందుగా docker system df ను అమలు చేసి స్థలాన్ని ఏది ఆక్రమించిందో తెలుసుకోండి. తరువాత దాన్ని తొలగించడానికి అవసరమైనంత పరిమితమైన prune ఆదేశాన్ని అమలు చేయండి. క్రమం ముఖ్యం. ఎందుకంటే ఈ గైడ్‌లోని చివరి ఆదేశమైన docker volume prune -a డేటాను తొలగిస్తుంది. దాన్ని తిరిగి రద్దు చేయలేరు.

Dockerతో ప్రారంభించకుండా filesystemతో ప్రారంభించండి.

df -h /
sudo du -xh --max-depth=1 /var/lib/docker | sort -h

df సమస్య తీవ్రతను చూపిస్తుంది. du స్థలం ఎక్కడికి వెళ్లిందో చూపిస్తుంది. -x flag du ను ఒకే filesystemకు పరిమితం చేస్తుంది. అందువల్ల అది వేరే volumeలోకి mountను అనుసరించదు, అలాగే దాన్ని రెండుసార్లు లెక్కించదు. ఇక్కడ ఐదు directories ముఖ్యమైనవి: overlay2 లో image మరియు container layers ఉంటాయి, volumes లో volume data ఉంటుంది, containers లో container metadata మరియు log files ఉంటాయి, buildkit లో build cache ఉంటుంది, image లో layer metadata ఉంటుంది.

sudo మరియు shell wildcards గురించి ఒక విషయం గమనించాలి. ఇది చాలా సమయం వృథా చేస్తుంది. /var/lib/docker ను root యాజమాన్యంలో ఉంచుతారు. మీ సాధారణ user దాన్ని చదవలేరు. అందువల్ల ls /var/lib/docker, Permission denied ను తిరిగి ఇస్తుంది. sudo du -sh /var/lib/docker/* వంటి ఆదేశం కూడా విఫలమవుతుంది. కారణం, sudo అమలు కాకముందే మీ shell * ను expand చేస్తుంది. మీ shell ఆ directoryను చదవలేరు. అందుకే దిగువన ఉన్న ప్రతి ఆదేశం wildcardకు బదులుగా find లేదా --max-depth ను ఉపయోగిస్తుంది.

ఇప్పుడు Docker స్వంత దృష్టికోణాన్ని చూడండి.

docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          24        6         12.4GB    8.91GB (71%)
Containers      31        6         1.42GB    1.39GB (97%)
Local Volumes   14        5         6.03GB    4.11GB (68%)
Build Cache     212       0         9.87GB    9.87GB

ఈ గణాంకాలు ఒక machine నుంచి వచ్చాయి. అవి మీ machine గురించి ఏమీ చెప్పవు. బదులుగా వాటి నిర్మాణాన్ని పరిశీలించండి. TOTAL objects సంఖ్యను లెక్కిస్తుంది, ACTIVE ప్రస్తుతం ఉపయోగంలో ఉన్న objects సంఖ్యను లెక్కిస్తుంది, RECLAIMABLE ఆ row నుంచి prune ద్వారా ఎంత స్థలం ఖాళీ చేయవచ్చో Docker అంచనా చూపిస్తుంది.

RECLAIMABLE గురించి రెండు విషయాలు తరచుగా గందరగోళానికి గురిచేస్తాయి. ఒకే shared image layerను ఉపయోగించే ప్రతి image కోసం అది దాన్ని ఒక్కసారి లెక్కిస్తుంది. అందువల్ల image row సాధారణంగా వాస్తవంగా పొందేదానికంటే ఎక్కువ స్థలాన్ని చూపిస్తుంది. అలాగే ఇది container log filesను ఎప్పుడూ చేర్చదు. Docker log fileను తిరిగి పొందగల objectగా పరిగణించదు. du ఒక directory, docker system df చూపించే పరిమాణం కంటే చాలా పెద్దదిగా చూపిస్తే, దానికి log files కారణం. దాని గురించి దిగువన ఒక section ఉంది.

ప్రతి object యొక్క విడి వివరాల కోసం -v ను జోడించండి.

docker system df -v

ఇది summaryను ప్రతి object type కోసం ఒక sectionగా విభజిస్తుంది. Image sectionలో SHARED SIZE మరియు UNIQUE SIZE columns అదనంగా ఉంటాయి. అందువల్ల ఒక image వాస్తవంగా ఎంత స్థలాన్ని ఉపయోగిస్తుందో చూడవచ్చు. Volume sectionలో LINKS count అదనంగా ఉంటుంది. ఇది ఆ volumeకు అనుసంధానమైన containers సంఖ్య. LINKS ను గుర్తుంచుకోండి. దాని విలువ 0 అయితేనే volume prune commands వర్తిస్తాయి.

dangling images మరియు unused images

ఈ రెండు పదాలు పరస్పరం మార్చి ఉపయోగించగలవిగా కనిపించినా, అవి ఒకటే కావు. Objects వేర్వేరుగా ఉండటంతో filters కూడా వేర్వేరుగా పనిచేస్తాయి.

dangling image కు tag ఉండదు. ఇది docker images లో <none> గా కనిపిస్తుంది. ప్రతి rebuild సమయంలో ఇలాంటి image ఏర్పడుతుంది: docker build -t myapp:latest . ద్వారా myapp:latest tag కొత్త image కు మారుతుంది. పాత image తన layers అన్నింటినీ ఉంచుకుంటుంది, కానీ తన పేరు కోల్పోతుంది. దానిని ఏదీ reference చేయదు. అది స్వయంగా cleanup కూడా కాదు.

unused image అంటే ప్రస్తుతం ఏ container కూడా reference చేయని image. దానికి tag ఉన్నా లేకపోయినా ఇది వర్తిస్తుంది. గత నెలలో pull చేసిన, ప్రస్తుతం నడపని postgres:16 unused image అవుతుంది. కానీ అది dangling image కాదు.

docker image prune        # dangling images only
docker image prune -a     # every image no container refers to

రెండవది ముందుగా ప్రశ్నిస్తుంది.

WARNING! This will remove all images without at least one container associated to them.
Are you sure you want to continue? [y/N]

ఆ prompt ను జాగ్రత్తగా చదవండి. "Associated to them" అంటే running లేదా stopped అయినా, ఇప్పటికే ఉన్న container object అని అర్థం. మీరు docker compose down అమలు చేసి ఉంటే containers తొలగిపోయాయి. అందువల్ల ఆ services ఉపయోగించిన ప్రతి image ఇప్పుడు unused అవుతుంది. -a వాటన్నింటినీ తొలగిస్తుంది. తిరిగి పొందలేని ఏదీ కోల్పోరు. అయితే తరువాత docker compose up -d మళ్లీ మొత్తం pull లేదా rebuild చేస్తుంది. చిన్న VPS లో దీనికి bandwidth మరియు build time ఖర్చవుతాయి. అందువల్ల ఏదైనా prune చేయడానికి ముందు docker compose down తొలగించేది, stop నడుస్తూనే ఉంచేది ఏమిటో తెలుసుకోవడం ఒక ఆచరణాత్మక కారణం.

ఒక filter ఇటీవలి images ను పరిధిలోకి రాకుండా ఉంచుతుంది.

docker image prune -a --filter "until=240h"

ఇది 240 గంటలు (10 రోజులు) కంటే పాత unused images ను తొలగిస్తుంది. కొత్త images ను అలాగే ఉంచుతుంది. until విలువకు 240h వంటి Go duration string లేదా 2026-08-01T00:00:00 వంటి absolute timestamp ఇవ్వవచ్చు.

Build cache అంటే ఏమిటి, అది ఎందుకు పరిమితి లేకుండా పెరుగుతుంది

Docker Engine 23.0 నుంచి docker build మరియు docker compose build కోసం Docker డిఫాల్ట్‌గా ఉపయోగిస్తున్న builder BuildKit. ఇది అమలు చేసే ప్రతి Dockerfile లోని ప్రతి దశ ఫలితాన్ని cache చేస్తుంది. ఆ cache ను /var/lib/docker/buildkit లో ఉంచుతుంది. రెండో build కొన్ని సెకన్లలో పూర్తవడానికి ఇదే కారణం. కాబట్టి ఇది సరిగ్గా పనిచేస్తోంది. సమస్య ఏమిటంటే, పాత entries ను డిఫాల్ట్‌గా ఏదీ expire చేయదు. ప్రతి సారి మారే COPY దశతో ఒకే image ను 50 సార్లు build చేస్తే, 50 layer సెట్లను ఉంచుకుంటారు.

Build cache ను docker image prune చూడదు. ఇది స్వంత command కలిగిన ప్రత్యేక object type.

docker builder prune                        # dangling cache
docker builder prune -a                     # all unused cache
docker builder prune --filter until=168h    # cache untouched for 7 days

ఇవేవీ మీ images లేదా data ను ప్రభావితం చేయవు. Build cache ను clear చేయడం వల్ల కలిగే ఏకైక ఖర్చు, తదుపరి build ఒకసారి నెమ్మదిగా నడవడం. Images ను క్రమం తప్పకుండా rebuild చేసే VPS లో Build Cache సాధారణంగా docker system df లో అతిపెద్ద row గా ఉంటుంది. అందువల్ల తొలగించడానికి ఇది పెద్దదైనా అత్యంత సురక్షితమైన అంశం.

భద్రత నుంచి విధ్వంసక ప్రభావం వరకు క్రమబద్ధీకరించిన prune commands

df -h / మళ్లీ సక్రమంగా కనిపించే వరకు ఈ జాబితాలోని commands ను క్రమంగా అమలు చేసి, వెంటనే ఆపండి. ప్రతి command పూర్తయ్యే సమయంలో ఒక Total reclaimed space: line ను ముద్రిస్తుంది.

  1. docker container prune ఆపివేసిన containers ను తొలగిస్తుంది. వాటి writable layers కూడా తొలగిపోతాయి. అందువల్ల volume వెలుపల container రాసిన ఏదైనా డేటా container తో పాటు తొలగిపోతుంది. Volumes ప్రభావితం కావు.
  2. docker image prune dangling images ను మాత్రమే తొలగిస్తుంది. అందుబాటులో ఉన్న image commands లో ఇది అత్యంత సురక్షితమైనది.
  3. docker builder prune dangling build cache ను తొలగిస్తుంది. దీని ప్రభావం ఒకసారి build నెమ్మదిగా పూర్తవడం మాత్రమే.
  4. docker image prune -a ఏ container కూడా సూచించని ప్రతి image ను తొలగిస్తుంది. తరువాత image ను మళ్లీ pull చేయాలి లేదా rebuild చేయాలి.
  5. docker system prune మొదటి మూడు చర్యలను ఒకేసారి చేసి, unused networks ను కూడా తొలగిస్తుంది.
  6. docker volume prune unused anonymous volumes ను తొలగిస్తుంది.
  7. docker volume prune -a named volumes తో సహా unused volumes ను తొలగిస్తుంది. Databases ను తొలగించేది ఇదే command.

docker system prune అమలు కావడానికి ముందు తన పరిధిని స్వయంగా తెలియజేస్తుంది.

WARNING! This will remove:
        - all stopped containers
        - all networks not used by at least one container
        - all dangling images
        - unused build cache
Are you sure you want to continue? [y/N]

Volumes ను ఉద్దేశపూర్వకంగానే ఆ జాబితాలో చేర్చలేదు. --volumes జోడిస్తే anonymous volumes కూడా పరిధిలోకి వస్తాయి. -a జోడిస్తే image దశ dangling images నుంచి ప్రతి unused image వరకు విస్తరిస్తుంది. Production host పై పూర్తి docker system prune -a --volumes -f అమలు చేయడం ద్వారా స్థలం ఖాళీ చేయడానికి ప్రయత్నిస్తూ డేటాను కోల్పోయే పరిస్థితి ఏర్పడుతుంది.

volumes ను prune చేయడం వల్ల మీ database ఎందుకు తొలగిపోతుంది

ఈ section ను రెండుసార్లు చదవాలి.

ఏ container కూడా attach అయి లేకపోతే volume ను unused గా పరిగణిస్తారు. పరీక్ష మొత్తం ఇదే. Volume ఖాళీగా ఉందా, compose file లో అది ఇంకా declare అయిందా, లేదా అది మీ database యొక్క ఏకైక copy ను కలిగి ఉందా అనే విషయాలను Docker పరిశీలించదు. LINKS 0 ను docker system df -v లో ఉపయోగిస్తే అది prunable అని అర్థం; అంతకంటే మరేమీ కాదు.

ఇప్పుడు రెండు సాధారణ చర్యలను వరుసగా చేయండి. Stack ను సక్రమంగా restart చేయడానికి docker compose down అమలు చేస్తారు. అది containers ను తొలగించి, named volumes ను అలాగే ఉంచుతుంది. ఇది దాని documentation లో చెప్పిన ప్రవర్తనే. ఇప్పుడు మీ Postgres volume కు ఏ container కూడా attach అయి ఉండదు. పది నిమిషాల తరువాత స్థలాన్ని ఖాళీ చేయడానికి docker volume prune -a అమలు చేస్తారు, అప్పుడు database తొలగిపోతుంది. రెండు commands సరిగ్గా పనిచేశాయి. కానీ ఆ క్రమం data ను నాశనం చేసింది.

Docker Engine 23.0 (API version 1.42) నుండి plain command మునుపటి కంటే పరిమితంగా పనిచేస్తుంది.

WARNING! This will remove anonymous local volumes not used by at least one container.

Anonymous volume అంటే Docker మీ కోసం సృష్టించిన volume. సాధారణంగా image లో VOLUME declare అయి ఉండి, మీరు దానికి పేరు ఇవ్వనప్పుడు ఇది ఏర్పడుతుంది. సాధారణంగా మీరు ఉంచాలని ప్రత్యేకంగా కోరని data వీటిలో ఉంటుంది. మీరు compose file లో రాసిన named volume, -a ను జోడించినప్పుడు మాత్రమే తొలగించబడుతుంది. పాత Docker versions plain command తో రెండింటినీ తొలగించేవి. కాబట్టి తరువాత upgrade చేసిన machine పై ఏర్పడిన పాత అలవాట్లను నమ్మవద్దు. named volumes మరియు bind mounts మధ్య తేడా ఏమిటో తెలుసుకున్నప్పుడే ఈ తేడా సరిగ్గా అర్థమవుతుంది. ఎందుకంటే bind mount అనేది Docker volume కాదు, అలాగే ఏ prune command కూడా దాన్ని ఎప్పుడూ తాకదు.

తొలగించే ముందు పరిశీలించండి. మీరు తనిఖీ చేస్తున్న volume name స్థానంలో myapp_pgdata ను ఉపయోగించండి.

docker volume ls -f dangling=true
docker volume inspect myapp_pgdata
sudo ls -la /var/lib/docker/volumes/myapp_pgdata/_data

Volume పై ఉన్న dangling=true filter అంటే unreferenced అని, empty అని కాదు. _data ను list చేస్తే దాని లోపల వాస్తవంగా ఉన్నదేమిటో కనిపిస్తుంది. అందులో pgdata లేదా mysql directory కనిపిస్తే ఆపండి. ముందుకు వెళ్లే ముందు copy తీసుకోండి. ఇదే విధమైన destruction docker compose down -v ద్వారా కూడా జరుగుతుంది. ఇది compose file declare చేసిన ప్రతి volume ను తొలగిస్తుంది, ముందుగా మీ అనుమతి కూడా అడగదు.

Docker host పై rebuild ద్వారా మళ్లీ సృష్టించలేని ఏకైక విషయం volume data. అందుకే volume data ను server వెలుపల అమలయ్యే restic backup లో ఉంచాలి. అప్పుడు తప్పుగా ఇచ్చిన flag ఆ data ను చేరుకోలేడు.

కంటైనర్ log files ను prune చేసినా స్థలం ఎందుకు ఖాళీ కాకపోవచ్చు

మీరు అన్నింటినీ prune చేశారు. docker system df లో reclaim చేయగల స్థలం దాదాపు ఏమీ కనిపించడం లేదు. అయినా disk నిండే ఉంది. Logs ను పరిశీలించండి.

sudo find /var/lib/docker/containers -name '*-json.log' -exec du -h {} + | sort -h | tail -10

ప్రతి container తన standard output మరియు standard error ను /var/lib/docker/containers/ లోని JSON file లో రాస్తుంది. Default install లో max-size unset గా ఉంటుంది. అంటే దీనికి పరిమితి ఉండదు. Crash loop లో చిక్కుకున్న ఒకే container partition నిండే వరకు రాస్తూనే ఉండవచ్చు. ఈ files ను ఏ prune command కూడా తొలగించదు. వాటిని సృష్టిస్తున్న containers running లో ఉండటం వల్ల, నిర్వచనం ప్రకారం అవి prunable కావు.

File ను delete చేయవద్దు. Open log file పై rm అమలు చేసినా ఏ స్థలమూ ఖాళీ కాదు. Docker daemon ఆ file descriptor ను ఇంకా open గా ఉంచుతుంది. ఆ handle close అయ్యే వరకు kernel ఆ blocks ను allocated గానే ఉంచుతుంది. df లో పరిమాణం ఏమాత్రం తగ్గదు. దాని బదులుగా truncate చేయండి. అప్పుడు అదే inode కొనసాగుతుంది మరియు daemon writing కొనసాగించగలదు.

sudo find /var/lib/docker/containers -name '*-json.log' -exec truncate -s 0 {} +
df -h /

ఇది తాత్కాలిక పరిష్కారం మాత్రమే. ఇప్పుడు ఆ containers కోసం docker logs ఏ output ఇవ్వదు. అయితే files వెంటనే మళ్లీ పెరగడం ప్రారంభిస్తాయి. అసలు పరిష్కారం log rotation. అది తదుపరి section లో ఉంది.

ముందు మరియు తర్వాత పరిమాణాన్ని ప్రతిసారీ కొలవండి

prune ఏమి చేసిందో ఎప్పుడూ ఊహించవద్దు. ముందుగా ఒక కొలత తీసుకోండి, ఒక command అమలు చేయండి, తర్వాత మరో కొలత తీసుకోండి.

df -h /
docker system df
docker builder prune -f --filter until=168h
docker image prune -f
docker system df
df -h /

రెండు df outputs ను పోల్చండి. మీ server సేవలను కొనసాగిస్తుందా లేదా నిర్ణయించే ఏకైక సంఖ్య అదే. docker system df లో ఏ row వాస్తవంగా మారిందో తెలుస్తుంది. ప్రతి prune తన స్వంత Total reclaimed space: విలువను కూడా ముద్రిస్తుంది.

df మారకపోయినా docker system df లో space freed అని కనిపిస్తే, తొలగించిన blocks ను ఒక open file handle పట్టుకుని ఉంది. పైన వివరించిన log file సమస్య ఇదే. రెండూ మారి, disk ఒక రోజులో మళ్లీ నిండిపోతే, ఇది cleanup సమస్య కాదు; growth సమస్య. దీనికి rotation తో పాటు scheduled job అవసరం.

మళ్లీ డిస్క్ నిండిపోకుండా ఎలా ఆపాలి

లాగ్ పరిమాణాన్ని పరిమితం చేయండి. /etc/docker/daemon.json ను సృష్టించండి లేదా సవరించండి.

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

దీనివల్ల ప్రతి container యొక్క logs 30 MBకి పరిమితం అవుతాయి. log-opts లోని ప్రతి విలువ string అయి ఉండాలి; సంఖ్యా విలువలు కూడా అలాగే ఉండాలి. restart చేయడానికి ముందు file ను parse చేయగలుగుతుందో పరిశీలించండి. తప్పుగా రూపొందిన daemon.json వల్ల daemon అసలు ప్రారంభం కాకపోవచ్చు, దాంతో ప్రతి container కూడా ఆగిపోతుంది.

python3 -m json.tool /etc/docker/daemon.json
sudo systemctl restart docker
docker info | grep -i 'logging driver'

ఇప్పుడు docker info, Logging Driver: json-file ను చూపించాలి. restart తర్వాత సృష్టించిన container లోని docker inspect యొక్క LogConfig section లో ఈ పరిమితులు కనిపిస్తాయి. ఇది ముఖ్యమైన విషయం: ఈ setting కొత్త containers కు మాత్రమే వర్తిస్తుంది. ఇప్పటికే ఉన్న containers అవి సృష్టించబడినప్పుడు ఉన్న configuration నే ఉంచుకుంటాయి. కాబట్టి వాటిని మళ్లీ సృష్టించండి.

docker compose up -d --force-recreate

compose file లో ప్రతి service కు ఇదే పరిమితిని విడిగా సెట్ చేయవచ్చు. ఎక్కువ logs సృష్టించే ఒక service కు ప్రత్యేక విలువ అవసరమైనప్పుడు ఇది మెరుగైన ఎంపిక.

services:
  app:
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

పరిమిత పరిధిలో prune షెడ్యూల్ చేయండి. Dangling images మరియు పాత build cache కు మాత్రమే వర్తించేలా వారానికి ఒకసారి అమలు చేయండి. షెడ్యూల్ చేసిన job లో ఎప్పుడూ -a లేదా --volumes ఉపయోగించవద్దు. Stack ఆపివున్న సమయంలో job అమలైతే, ఆ stack కు చెందిన images తొలగిపోతాయి. --volumes ఉన్నప్పుడు అది మీ data పై కూడా పనిచేయడం ప్రారంభిస్తుంది.

sudo tee /etc/cron.weekly/docker-prune >/dev/null <<'EOF'
#!/bin/sh
docker image prune -f
docker builder prune -f --filter until=168h
EOF
sudo chmod +x /etc/cron.weekly/docker-prune
sudo /etc/cron.weekly/docker-prune

చివరి line script ను ముందుగా చేతితో ఒకసారి అమలు చేస్తుంది. అందువల్ల unattended గా అమలు కావడానికి ముందే దాని output ను చూడవచ్చు. File executable అయి ఉండాలి. దాని పేరులో dot ఉండకూడదు. ఎందుకంటే run-parts executable కాని files ను, extension ఉన్న files ను దాటవేస్తుంది.

ఖాళీ స్థలంపై హెచ్చరిక ఏర్పాటు చేయండి. డిస్క్ నిండిన తర్వాత మీరు అమలు చేసే prune recovery చర్య మాత్రమే. 80 శాతం వద్ద వచ్చే alert prevention చర్య.

usage=$(df --output=pcent / | tr -dc '0-9')
[ "$usage" -ge 80 ] && echo "root filesystem at ${usage} percent full"

మీరు ఇప్పటికే ఉపయోగిస్తున్న notifier తో cron లో దీన్ని ఉంచండి. Free space మొత్తం పరిస్థితిలో సగం మాత్రమే. కాబట్టి ఈ alert ను మీ VPSలో disk health monitoring తో కలిపి ఉపయోగించండి. విఫలమవుతున్న disk మరియు నిండిన disk రెండూ మీ containers ను ఆపుతాయి, కానీ వాటికి వేర్వేరు పరిష్కారాలు అవసరం.

పైన ఉన్న ప్రతిదీ data root /var/lib/docker వద్ద ఉన్న standard install ను ఆధారంగా చేసుకుంటుంది. daemon.json లోని data-root key ను ఉపయోగించి దాన్ని మార్చి ఉంటే, ప్రతి command లో మీ path ను substitute చేయండి. కొత్త server పై ఈ layout ను సరిగ్గా ఏర్పాటు చేయడం VPSలో Docker ఏర్పాటు చేయడం లో భాగం. తప్పు partition పై 40 GB containers చేరిన తర్వాత నిర్ణయించడంకన్నా, ముందుగానే నిర్ణయించడం చాలా సులభం.

FAQ

docker system prune నా volumes ను తొలగిస్తుందా?

లేదు. సాధారణ command stopped containers, unused networks, dangling images మరియు unused build cache ను తొలగిస్తుంది. దాని confirmation prompt లో కూడా ఇదే జాబితా ఉంటుంది. --volumes ను జోడించినప్పుడు మాత్రమే volumes కూడా పరిధిలోకి వస్తాయి. Docker Engine 23.0 నుంచి ఆ flag named volumes కు కాకుండా anonymous volumes కు వర్తిస్తుంది. Named volumes ను docker volume prune -a మరియు docker compose down -v తొలగిస్తాయి. ఈ రెండు commands తోనే జాగ్రత్తగా ఉండాలి.

docker prune అమలు చేసిన తర్వాత కూడా నా disk ఎందుకు full గానే ఉంది?

సాధారణంగా రెండు కారణాలు ఉంటాయి. మొదటిది /var/lib/docker/containers/ కింద ఉన్న container log files. ఏ prune command కూడా వీటిని తాకదు. max-size ను సెట్ చేసే వరకు ఇవి పరిమితి లేకుండా పెరుగుతాయి. రెండవది, ఒక process ఇంకా open గా ఉంచుకున్న deleted file. Container నడుస్తున్నప్పుడు rm తో log ను తొలగిస్తే, daemon file descriptor ను ఉంచుకుంటుంది. Kernel blocks ను release చేయదు. అందువల్ల df లో మార్పు కనిపించదు. మీ పరిస్థితి ఏదో తెలుసుకోవడానికి sudo du -xh --max-depth=1 /var/lib/docker ను docker system df తో పోల్చండి.

docker image prune మరియు docker image prune -a మధ్య తేడా ఏమిటి?

సాధారణ command dangling images ను మాత్రమే తొలగిస్తుంది. అంటే వాటి tag కోల్పోయిన images. ఇవి దాదాపు ఎల్లప్పుడూ rebuild కారణంగా ఏర్పడతాయి. -a రూపం ఏ existing container కూడా సూచించని ప్రతి image ను తొలగిస్తుంది. మీరు ఉద్దేశపూర్వకంగా pull చేసిన tagged images కూడా ఇందులో ఉంటాయి. docker compose down తర్వాత containers తొలగించబడతాయి. అందువల్ల -a ఆ stack కు చెందిన images ను కూడా తొలగిస్తుంది. ఏదీ శాశ్వతంగా కోల్పోరు. తదుపరి start సమయంలో అవి మళ్లీ pull లేదా rebuild అవుతాయి. అయితే నెమ్మదైన link పై దీనికి ఎక్కువ సమయం పడుతుంది.

Docker logs వల్ల disk full కాకుండా ఎలా ఆపాలి?

/etc/docker/daemon.json లోని log-opts కింద max-size మరియు max-file ను సెట్ చేయండి. తరువాత sudo systemctl restart docker తో daemon ను restart చేయండి. ఈ setting restart తర్వాత సృష్టించే containers కు మాత్రమే వర్తిస్తుంది. అందువల్ల నడుస్తున్న containers ను docker compose up -d --force-recreate తో recreate చేయండి. Compose file లోని logging key కింద ప్రతి service కు ఇదే రెండు options ను సెట్ చేయవచ్చు. మిగిలిన services కంటే ఒక service చాలా ఎక్కువ logs రాసే సందర్భంలో ఇది ఉపయోగకరం.

cron job లో docker system prune అమలు చేయడం సురక్షితమేనా?

ప్రతి stack నిరంతరం నడుస్తున్న host పై సాధారణ docker system prune -f సురక్షితం. అయితే ఇది stopped containers ను తొలగిస్తుంది. ఉద్దేశపూర్వకంగా ఆపి, తరువాత మళ్లీ start చేయాలనుకున్న container కూడా తొలగించబడుతుంది. షెడ్యూల్ చేయడానికి మరింత సురక్షితమైన job docker image prune -f మరియు docker builder prune -f --filter until=168h. ఇవి వేగంగా పెరిగే రెండు అంశాలను తొలగిస్తాయి. Volume ను మాత్రం తాకవు. -a లేదా --volumes ను ఎప్పుడూ schedule చేయవద్దు.

#docker#disk-space#prune#volumes#maintenance