Docker disk space खाली कैसे करें: VPS prune गाइड

किसी भी चीज़ को हटाने से पहले यह पता लगाएँ कि डिस्क स्पेस का उपयोग कौन कर रहा है

Docker एक VPS पर चार जगहों पर डिस्क स्पेस लेता है: images, रुके हुए 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 फ्लैग du को एक ही filesystem तक सीमित रखता है, ताकि यह किसी अलग volume के mount को फॉलो न करे और उसे दो बार न गिने। यहाँ पाँच निर्देशिकाएँ (directories) महत्वपूर्ण हैं: overlay2 में image और container layers होती हैं, volumes में volume डेटा होता है, 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/* जैसा कमांड भी विफल हो जाता है, क्योंकि आपका shell sudo के चलने से पहले ही * को expand कर देता है, और आपका shell उस निर्देशिका को पढ़ नहीं सकता। नीचे दिया गया हर कमांड इसी कारण से 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

ये आँकड़े एक मशीन से हैं और आपकी मशीन के बारे में कुछ नहीं बताते। इसके बजाय इनके स्वरूप को समझें। TOTAL ऑब्जेक्ट्स की गिनती करता है, ACTIVE उन ऑब्जेक्ट्स की गिनती करता है जो अभी उपयोग में हैं, और RECLAIMABLE Docker का अनुमान है कि prune करने से उस पंक्ति से कितनी जगह खाली हो सकती है।

RECLAIMABLE के बारे में दो बातें लोगों को उलझाती हैं। यह shared image layers को हर उस image के लिए एक बार गिनता है जो उनका उपयोग करती है, इसलिए image पंक्ति अक्सर उससे अधिक खाली करने का वादा करती है जितना वास्तव में होता है। और इसमें container log files कभी शामिल नहीं होतीं, क्योंकि Docker log file को reclaimable ऑब्जेक्ट नहीं मानता। जब du किसी निर्देशिका को docker system df द्वारा बताए गए आकार से कहीं बड़ा दिखाता है, तो इसका कारण log files होती हैं, और इसके बारे में नीचे एक सेक्शन दिया गया है।

प्रति-ऑब्जेक्ट विवरण के लिए -v जोड़ें।

docker system df -v

यह सारांश को प्रति-ऑब्जेक्ट प्रकार के एक सेक्शन में विभाजित करता है। image सेक्शन में SHARED SIZE और UNIQUE SIZE कॉलम जुड़ जाते हैं, ताकि आप देख सकें कि एक single image वास्तव में आपको कितना खर्च करवा रही है। volume सेक्शन में LINKS की गिनती जुड़ जाती है, जो उस volume से जुड़े containers की संख्या है। LINKS को याद रखें, क्योंकि 0 का मान ही वह एकमात्र परीक्षण है जिस पर volume prune कमांड लागू होते हैं।

Dangling images और unused images में अंतर

ये दोनों शब्द एक जैसे लग सकते हैं, लेकिन इनमें काफी अंतर है। इनके फिल्टर अलग तरह से काम करते हैं क्योंकि ये अलग-अलग ऑब्जेक्ट्स हैं।

Dangling image वह इमेज है जिसका कोई tag नहीं होता। यह <none> में docker images के रूप में दिखाई देती है। आप हर बार rebuild करने पर एक ऐसी इमेज बनाते हैं: docker build -t myapp:latest ., myapp:latest tag को नई इमेज पर ले जाता है, और पुरानी इमेज अपनी सभी layers को बरकरार रखती है लेकिन उसका नाम हट जाता है। कोई भी चीज़ इसे reference नहीं करती है, और यह अपने आप साफ नहीं होती है।

Unused image कोई भी ऐसी इमेज है, चाहे वह tagged हो या न हो, जिसे वर्तमान में कोई container उपयोग नहीं कर रहा है। कोई postgres:16 जिसे आपने पिछले महीने pull किया था और अभी run नहीं कर रहे हैं, वह unused है, और वह dangling नहीं है।

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]

उस प्रॉम्प्ट को ध्यान से पढ़ें। "Associated to them" का अर्थ है कोई मौजूदा container ऑब्जेक्ट, चाहे वह चल रहा हो या बंद हो। यदि आपने docker compose down चलाया, तो containers हट जाते हैं, इसलिए उन services द्वारा उपयोग की जाने वाली हर इमेज अब unused हो जाती है, और -a उन सभी को हटा देता है। ऐसा कुछ भी नष्ट नहीं होता जिसे आप वापस नहीं पा सकते, लेकिन अगला docker compose up -d पूरी प्रक्रिया को फिर से pull या rebuild करेगा, जिसमें एक छोटे VPS पर bandwidth और build time खर्च होता है। यही एक व्यावहारिक कारण है कि docker compose down क्या हटाता है और stop क्या चालू रखता है यह जानना जरूरी है, इससे पहले कि आप कुछ भी prune करें।

एक फिल्टर हाल की इमेजेस को दायरे से बाहर रखता है।

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

यह 240 घंटे (10 दिन) पहले बनाई गई unused इमेजेस को हटा देता है और नई इमेजेस को सुरक्षित रखता है। until मान एक Go duration string जैसे 240h, या 2026-08-01T00:00:00 जैसा एक absolute timestamp स्वीकार करता है।

Build cache क्या है और यह बिना किसी सीमा के क्यों बढ़ता है

BuildKit वह builder है जिसे Docker, Docker Engine 23.0 के बाद से docker build और docker compose build के लिए डिफ़ॉल्ट रूप से उपयोग करता है। यह हर उस Dockerfile के हर चरण के परिणाम को cache करता है जिसे वह चलाता है, और यह उस cache को /var/lib/docker/buildkit में रखता है। यह cache ही कारण है कि आपका दूसरा build कुछ ही सेकंड में पूरा हो जाता है, इसलिए यह अपना काम सही ढंग से कर रहा है। समस्या यह है कि डिफ़ॉल्ट रूप से पुरानी entries को हटाने (expire करने) वाला कोई mechanism नहीं है। यदि आप एक ही image को पचास बार एक ऐसे COPY चरण के साथ build करते हैं जो हर बार बदलता है, तो आप पचास sets of layers को बनाए रखते हैं।

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 या आपके डेटा को प्रभावित नहीं करता है। build cache को साफ़ करने की एकमात्र कीमत यह है कि अगला build एक बार धीरे चलेगा। एक VPS पर जो नियमित रूप से images को rebuild करता है, Build Cache अक्सर docker system df में सबसे बड़ी पंक्ति होती है, जो इसे हटाने के लिए सबसे सुरक्षित बड़ी चीज़ बनाती है।

Prune commands, सुरक्षित से विनाशकारी के क्रम में

इस सूची में नीचे की ओर बढ़ें और जैसे ही df -h / फिर से healthy दिखे, रुक जाएँ। हर command पूरा होने पर एक Total reclaimed space: लाइन print करती है।

1. docker container prune रुके हुए containers को हटाता है। उनकी writable layers भी हट जाती हैं, इसलिए volume के बाहर container द्वारा लिखी गई कोई भी चीज़ उसके साथ delete हो जाती है। Volumes को नहीं छुआ जाता है।
2. docker image prune केवल dangling images को हटाता है। यह सबसे सुरक्षित image command है।
3. docker builder prune dangling build cache को हटाता है। इसकी कीमत एक धीमी build है।
4. docker image prune -a हर उस image को हटाता है जिसे कोई container refer नहीं करता है। इसकी कीमत एक re-pull या rebuild है।
5. docker system prune पहले तीन को एक साथ करता है और unused networks को भी जोड़ता है।
6. docker volume prune unused anonymous volumes को हटाता है।
7. docker volume prune -a unused volumes को हटाता है, जिसमें named volumes भी शामिल हैं। यह वह command है जो databases को delete कर देती है।

docker system prune चलने से पहले अपना scope बताता है।

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 फिर से scope में आ जाते हैं। -a जोड़ने से image step का दायरा dangling images से बढ़कर हर unused image तक हो जाता है। production host पर एक पूर्ण docker system prune -a --volumes -f चलाने से ही लोग space खाली करने की कोशिश में अपना data खो देते हैं।

प्रूनिंग (pruning) करने पर वॉल्यूम डिलीट क्यों हो जाते हैं

यह वह सेक्शन है जिसे आपको दो बार पढ़ना चाहिए।

एक वॉल्यूम तब 'unused' (अप्रयुक्त) माना जाता है जब उससे कोई कंटेनर अटैच न हो। बस यही एकमात्र पैमाना है। Docker यह चेक नहीं करता कि वॉल्यूम खाली है या नहीं, क्या कोई compose file अभी भी उसे डिक्लेयर कर रही है, या क्या उसमें आपके डेटाबेस की एकमात्र कॉपी मौजूद है। LINKS 0 का docker system df -v में मतलब केवल 'prunable' (हटाने योग्य) है, इसके अलावा कुछ नहीं।

अब दो सामान्य क्रियाओं को एक साथ देखें। आप स्टैक को क्लीन तरीके से रीस्टार्ट करने के लिए docker compose down रन करते हैं। यह कंटेनर्स को हटा देता है और named volumes को वहीं छोड़ देता है, जो कि इसके डॉक्यूमेंटेशन के अनुसार बिल्कुल सही व्यवहार है। अब आपका Postgres वॉल्यूम किसी से भी अटैच नहीं है। दस मिनट बाद आप स्पेस खाली करने के लिए docker volume prune -a रन करते हैं, और डेटाबेस गायब हो जाता है। दोनों कमांड्स ने सही तरीके से काम किया। इस क्रम ने डेटा को नष्ट कर दिया।

Docker Engine 23.0 (API version 1.42) के बाद से, साधारण कमांड का दायरा पहले की तुलना में सीमित हो गया है।

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

एक anonymous volume वह है जिसे Docker ने आपके लिए बनाया है, आमतौर पर इसलिए क्योंकि इमेज में VOLUME डिक्लेयर किया गया है और आपने उसे कोई नाम नहीं दिया। इनमें आमतौर पर ऐसा डेटा होता है जिसे आपने रखने के लिए नहीं कहा था। एक named volume, जिसे आप अपनी compose file में लिखते हैं, केवल तभी हटाया जाता है जब आप -a जोड़ते हैं। पुराने Docker वर्ज़न साधारण कमांड के साथ दोनों को हटा देते थे, इसलिए उन आदतों पर भरोसा न करें जो आपने उस सिस्टम पर बनाई थीं जिसे आपने बाद में अपग्रेड किया है। यह अंतर तभी समझ में आता है जब आप named volumes और bind mounts के बीच का अंतर जानते हों, क्योंकि bind mount वास्तव में Docker वॉल्यूम नहीं है और कोई भी prune कमांड उसे कभी प्रभावित नहीं करेगी।

डिलीट करने से पहले देखें। जिस वॉल्यूम को आप चेक कर रहे हैं, उसके नाम के साथ myapp_pgdata को बदलें।

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

वॉल्यूम पर dangling=true फिल्टर का मतलब 'unreferenced' (असंदर्भित) है, 'empty' (खाली) नहीं। _data को लिस्ट करने से आपको पता चलता है कि अंदर वास्तव में क्या है। यदि आपको वहां कोई pgdata या mysql डायरेक्टरी मिलती है, तो रुकें और आगे बढ़ने से पहले उसकी एक कॉपी ले लें। यही विनाश docker compose down -v के माध्यम से भी होता है, जो compose file में डिक्लेयर किए गए हर वॉल्यूम को हटा देता है और आपसे कुछ नहीं पूछता।

वॉल्यूम Docker होस्ट पर वह एकमात्र चीज़ है जिसे रीबिल्ड (rebuild) दोबारा नहीं बना सकता। इसीलिए वॉल्यूम डेटा सर्वर से बाहर चलने वाले restic बैकअप में होना चाहिए, जहाँ कोई गलत टाइप किया गया फ्लैग उसे नुकसान न पहुँचा सके।

जब कुछ भी prune न हो: container log files

आपने सब कुछ prune कर दिया है, docker system df लगभग कुछ भी reclaimable नहीं दिखा रहा है, और disk अभी भी full है। 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 में लिखता है। डिफ़ॉल्ट install में max-size unset होता है, जिसका अर्थ है कि इसकी कोई सीमा नहीं है। इसलिए, crash loop में फंसा एक container तब तक लिखता रहता है जब तक partition full न हो जाए। कोई भी prune command इन files को नहीं हटाती है, क्योंकि इन्हें बनाने वाले containers चल रहे होते हैं, जिससे वे परिभाषा के अनुसार prunable नहीं होते हैं।

File को delete न करें। किसी open log file पर rm चलाने से कुछ भी खाली नहीं होता है, क्योंकि Docker daemon के पास अभी भी एक open file descriptor होता है और kernel उन blocks को तब तक allocate रखता है जब तक वह handle बंद न हो जाए। df बिल्कुल भी नहीं बदलेगा। इसके बजाय truncate करें, जो उसी inode को बनाए रखता है और daemon को लिखना जारी रखने देता है।

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

यह एक अस्थायी समाधान है। उन containers के लिए docker logs अब कुछ भी नहीं लौटाएगा, और files तुरंत फिर से बढ़ना शुरू हो जाएंगी। वास्तविक समाधान 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 की तुलना करें। केवल यही वह संख्या है जो यह तय करती है कि आपका सर्वर सेवा देना जारी रखेगा या नहीं। docker system df फिर आपको बताता है कि वास्तव में कौन सी row स्थानांतरित हुई, और प्रत्येक prune अपना स्वयं का Total reclaimed space: आंकड़ा प्रिंट करता है।

यदि df नहीं बदला लेकिन docker system df कहता है कि space खाली कर दिया गया है, तो एक open file handle डिलीट की गई blocks को रोके हुए है, जो ऊपर बताई गई 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 के लॉग को 30 MB तक सीमित रखता है। log-opts के अंतर्गत प्रत्येक मान एक string होना चाहिए, जिसमें संख्यात्मक मान भी शामिल हैं। restart करने से पहले जांचें कि फाइल सही ढंग से parse हो रही है या नहीं, क्योंकि एक गलत daemon.json daemon को start होने से रोक देगा और सभी containers को बंद कर देगा।

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 अनुभाग में दिखाई देती हैं, जो कि एक महत्वपूर्ण विवरण है: यह सेटिंग केवल नए containers पर लागू होती है। मौजूदा containers उसी configuration को बनाए रखते हैं जिसके साथ उन्हें बनाया गया था, इसलिए उन्हें recreate करें।

docker compose up -d --force-recreate

यही सीमा compose file में प्रति service भी निर्धारित की जा सकती है, जो तब बेहतर विकल्प होता है जब किसी एक अधिक लॉग उत्पन्न करने वाली service को अपनी अलग सीमा की आवश्यकता हो।

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

एक सीमित prune शेड्यूल करें। साप्ताहिक रूप से, केवल dangling images और पुराने build cache तक सीमित रखें। कभी भी -a या --volumes को scheduled job में न डालें, क्योंकि यदि कोई job तब चलती है जब stack down हो, तो वह उस stack की images को हटा देगी, और --volumes के साथ यह आपके डेटा पर काम करना शुरू कर देगी।

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

वह अंतिम पंक्ति script को एक बार मैन्युअल रूप से चलाती है ताकि आप इसे बिना निगरानी के चलाने से पहले इसका output देख सकें। फाइल का executable होना आवश्यक है, और इसके नाम में dot नहीं होना चाहिए, क्योंकि run-parts किसी भी non-executable फाइल और extension वाली फाइल को छोड़ देता है।

खाली जगह के लिए अलार्म लगाएँ। डिस्क भरने के बाद किया गया prune एक recovery है। 80 प्रतिशत पर अलर्ट मिलना एक रोकथाम है।

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

इसे cron में उस notifier के साथ डालें जिसका आप पहले से उपयोग कर रहे हैं। खाली जगह पूरी स्थिति का केवल आधा हिस्सा है, इसलिए अलार्म को अपने VPS पर डिस्क हेल्थ मॉनिटरिंग के साथ जोड़ें, क्योंकि खराब हो रही डिस्क और भरी हुई डिस्क दोनों ही आपके containers को रोक देती हैं और दोनों के लिए अलग-अलग समाधान की आवश्यकता होती है।

ऊपर दी गई हर बात एक मानक install को मानती है जहाँ data root /var/lib/docker पर है। यदि आपने इसे daemon.json में data-root key के साथ स्थानांतरित किया है, तो प्रत्येक command में अपने path का उपयोग करें। एक नए सर्वर पर उस layout को सही ढंग से सेट करना VPS पर Docker सेट करने का हिस्सा है, और गलत partition पर 40 GB के containers होने से पहले यह निर्णय लेना कहीं अधिक आसान है।

FAQ

क्या docker system prune मेरे volumes को हटा देता है?

नहीं। साधारण command केवल रुके हुए containers, अप्रयुक्त networks, dangling images और अप्रयुक्त build cache को हटाती है, और इसकी पुष्टि के लिए आने वाला 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 सेट नहीं करते, ये बिना किसी सीमा के बढ़ती रहती हैं। दूसरा कारण वह हटाई गई file है जिसे कोई process अभी भी open रखे हुए है: यदि आपने 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 को हटाती है, यानी वे images जिन्होंने अपना tag खो दिया है, जो लगभग हमेशा rebuild के कारण होता है। -a रूप उन सभी images को हटा देता है जिन्हें कोई भी मौजूदा container refer नहीं करता है, जिसमें आपके द्वारा जानबूझकर pull की गई tagged images भी शामिल हैं। docker compose down के बाद containers हट जाते हैं, इसलिए -a उस stack की images को भी साथ ले जाएगा। कुछ भी स्थायी रूप से नष्ट नहीं होता है, क्योंकि अगली बार start करने पर वे फिर से pull या rebuild हो जाती हैं, लेकिन slow link पर इसमें लंबा समय लग सकता है।

मैं Docker logs को disk भरने से कैसे रोकूँ?

/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 के साथ फिर से बनाएँ। आप compose file में logging key के अंतर्गत प्रत्येक service के लिए यही दो options सेट कर सकते हैं, जो तब उपयोगी होता है जब कोई एक service बाकी की तुलना में बहुत अधिक logs generate कर रही हो।

क्या cron job में docker system prune चलाना सुरक्षित है?

साधारण docker system prune -f उस host पर सुरक्षित है जहाँ हर stack हमेशा चलता रहता है, लेकिन यह रुके हुए containers को हटा देता है, इसलिए यह उस container को भी हटा देगा जिसे आपने जानबूझकर रोका था और बाद में restart करना चाहते थे। अधिक सुरक्षित scheduled job docker image prune -f के साथ docker builder prune -f --filter until=168h है, जो उन दो चीजों को साफ करता है जो सबसे तेजी से बढ़ती हैं और यह किसी volume को नहीं छू सकता। -a या --volumes को कभी भी schedule न करें।