Docker के "No Space Left on Device" त्रुटि को कैसे ठीक करें: एक संपूर्ण गाइड

Docker की "no space left on device" त्रुटि अक्सर सबसे गलत समय पर आती है: डिप्लॉयमेंट के बीच में, किसी महत्वपूर्ण बिल्ड के दौरान, या जब आप कोई ज़रूरी इमेज पुल कर रहे होते हैं। मुझे यह त्रुटि कई बार मिली है, और मैं बता सकता/सकती हूँ कि बिना सही डायग्नोसिस के फाइलें हटाने की जल्दबाज़ी, डेटा लॉस का नुस्ख़ा है।

यह त्रुटि चुनौतीपूर्ण इसलिए है क्योंकि इसका कारण शायद ही कभी एक होता है। आप जमे हुए Docker इमेज, बेकाबू कंटेनर लॉग, लाखों छोटी फाइलों से खत्म हुए इनोड्स, या फिर रनिंग प्रोसेस द्वारा पकड़ी गई डिलीटेड फाइलों से खपत होती "फैंटम" स्पेस—इनमें से किसी से जूझ रहे हो सकते हैं। हर स्थिति का समाधान अलग होता है।

इसीलिए मैं हमेशा कार्रवाई से पहले डायग्नोसिस पर ज़ोर देता/देती हूँ। मूल कारण समझ लेने से आप लक्षित समाधान कुशलता से लागू कर सकते हैं और प्रोडक्शन वातावरण में व्यवधान से बच सकते हैं। इस गाइड में, मैं आपको इस निराशाजनक समस्या का व्यवस्थित रूप से निदान, समाधान, और रोकथाम करने का तरीका दिखाऊँगा/दिखाऊँगी।

यदि आप Docker में नए हैं, तो मैं हमारा हैंड्स-ऑन Introduction to Docker कोर्स करने की सलाह देता/देती हूँ, जो कंटेनराइज़ेशन शुरू करने के लिए ज़रूरी सब कुछ कवर करता है।

Docker की "No Space Left on Device" त्रुटि क्या है?

जब Docker यह त्रुटि फेंकता है, तो वह आपके सिस्टम की स्टोरेज से जुड़ी दो बुनियादी समस्याओं में से किसी एक का संकेत देता है:

• फिजिकल डिस्क ब्लॉक की समाप्ति
• इनोड्स की समाप्ति

इन कारणों के फर्क को समझना सही समाधान लागू करने के लिए महत्वपूर्ण है।

“no space left on device” त्रुटि के मूल कारण

पहला और सबसे सीधा कारण है फिजिकल डिस्क ब्लॉक की समाप्ति। आपकी फाइलसिस्टम के पास डेटा लिखने के लिए वास्तविक स्टोरेज स्पेस खत्म हो गया है। यह अधिक सहज परिदृश्य है: आपने Docker इमेज, कंटेनर, लॉग या अन्य फाइलों से अपनी डिस्क भर दी है।

दूसरा, कम स्पष्ट कारण है इनोड्स की समाप्ति। भले ही आपके पास गीगाबाइट्स फ्री स्पेस हो, आपकी फाइलसिस्टम इनोड्स (फाइल और डायरेक्टरी ट्रैक करने के लिए उपयोग होने वाली मेटाडेटा स्ट्रक्चर) से खाली हो सकती है। हर फाइल और डायरेक्टरी एक इनोड लेती है, इसलिए वे एप्लिकेशन जो लाखों छोटी फाइलें बनाते हैं (जैसे PHP सेशन फाइलें या npm के node_modules डायरेक्टरी) डिस्क स्पेस छोड़े रखते हुए भी इनोड्स खत्म कर सकते हैं।

overlay2 स्टोरेज ड्राइवर को समझना

Docker आमतौर पर overlay2 स्टोरेज ड्राइवर का उपयोग करता है, जो Linux OverlayFS पर आधारित है। OverlayFS एक होस्ट पर कई डायरेक्टरी को लेयर करता है और उन्हें एकीकृत फाइलसिस्टम के रूप में प्रस्तुत करता है। इमेज लेयर रीड-ओनली लोअर डायरेक्टरी के रूप में माउंट होती हैं, जबकि हर रनिंग कंटेनर एक पतली राइटेबल अपर लेयर जोड़ता है। मर्ज्ड व्यू कंटेनर को एकल डायरेक्टरी के रूप में दिखता है।

overlay2 ड्राइवर सैद्धांतिक रूप से 128 लोअर OverlayFS लेयर तक सपोर्ट करता है, लेकिन Docker का लेयर स्टोर प्रति इमेज 125 बेस लेयर की व्यावहारिक सीमा लागू करता है। यह इमेज कम्पोज़िशन को कुशल बनाता है और docker build तथा docker commit जैसी प्रक्रियाओं के लिए प्रदर्शन में सुधार करता है। 

भले ही overlay2 पहले के स्टोरेज ड्राइवरों की तुलना में कम इनोड्स खपत के लिए डिज़ाइन किया गया है, लेकिन ऐसे Docker वातावरण जहां बार-बार इमेज बिल्ड, लेयर पुल, या कंटेनर बनाए जाते हैं, समय के साथ डिस्क ब्लॉक और इनोड्स—दोनों—पर पर्याप्त दबाव डाल सकते हैं, खासकर जब इमेज या एप्लिकेशन लेयर में बहुत सी छोटी फाइलें हों।

यह त्रुटि कैसे दिखती है, यह डिप्लॉयमेंट वातावरण पर निर्भर करता है:

• नेटिव Linux सिस्टम पर, यह /var/lib/docker को सपोर्ट करने वाली फाइलसिस्टम को प्रभावित करती है। 

• Windows या macOS के लिए Docker Desktop पर, सीमाएँ Docker की वर्चुअल मशीन डिस्क इमेज (जैसे .raw या .vhdx फाइल) के भीतर होती हैं, जो स्टोरेज रिक्लेम या रिसाइज़ करते समय अतिरिक्त बातों पर विचार कराती हैं।

चरण 1: मूल कारण का निदान करें

कुछ भी हटाने से पहले, मैं हमेशा गहन डायग्नोसिस से शुरू करता/करती हूँ। कुछ मिनट का यह निवेश घंटों की ट्रबलशूटिंग बचा सकता है और आकस्मिक डेटा लॉस से रोक सकता है।

सिस्टम-स्तरीय क्षमता जाँचें

अपने होस्ट सिस्टम की डिस्क उपयोगिता df -H से जाँचें (df का अर्थ है disk free):

df -Hसंचालित द्वारा

WSL में फ्री डिस्क जाँच

यह कमांड डिस्क उपयोगिता को मानव-पढ़नीय प्रारूप में दिखाती है। 100% क्षमता के पास वाले फाइलसिस्टम देखें। 

नेटिव Linux इंस्टॉलेशन पर, विशेष रूप से उस पार्टीशन पर ध्यान दें जहाँ /var/lib/docker स्थित है। यह आमतौर पर आपका रूट पार्टीशन (/) या एक समर्पित Docker पार्टीशन होता है। 

Docker Desktop (Windows/Mac) पर, मुख्य फाइलसिस्टम माउंट (आमतौर पर /dev/sdf या समान) देखें, जो Docker VM का डेटा रखता है—न कि विशिष्ट /var/lib/docker रेफरेंस—क्योंकि Docker एक वर्चुअल मशीन के भीतर चलता है।

अगला, df -i से इनोड्स की समाप्ति जाँचें:

df -iसंचालित द्वारा

इनोड्स समाप्ति जाँच

यदि किसी फाइलसिस्टम पर 100% इनोड उपयोग (IUse%) दिखता है, तो समस्या मिल गई। यह परिदृश्य बिल्ड सर्वर और CI/CD वातावरण में आश्चर्यजनक रूप से आम है, जहाँ Docker कई छोटी फाइलों वाले कंटेनर बार-बार बनाता और नष्ट करता है।

Docker-विशिष्ट उपयोग का विश्लेषण करें

अब जब हमने तय कर लिया कि डिस्क स्पेस या इनोड्स समस्या हैं, तो गहराई में जाकर Docker की विशिष्ट संसाधन खपत देखें। docker system df कमांड एक उच्च-स्तरीय सारांश देता है जो सभी Docker इंस्टॉलेशन पर काम करता है:

docker system dfसंचालित द्वारा

आउटपुट स्पेस उपयोग को चार श्रेणियों में तोड़ता है: इमेज, कंटेनर, लोकल वॉल्यूम, और बिल्ड कैश।

खास तौर पर RECLAIMABLE कॉलम मूल्यवान है। यह दिखाता है कि रनिंग कंटेनरों को प्रभावित किए बिना आप कितना स्पेस वापस पा सकते हैं। इन दो मीट्रिक्स का फर्क समझना अहम है: "active" स्पेस वर्तमान में रनिंग कंटेनरों द्वारा उपयोग में है, जबकि "reclaimable" स्पेस सुरक्षित रूप से खाली कराया जा सकता है।

अधिक सूक्ष्म विवरणों के लिए वर्बोज़ फ्लैग जोड़ें:

docker system df -vसंचालित द्वारा

Docker उपयोग विश्लेषण

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

• Images: हर इमेज का साइज और वह वर्तमान में उपयोग में है या नहीं, दिखाता है। बड़ी, अनयूज्ड या अलग-अलग टैग के साथ डुप्लिकेट इमेज खोजें। "unused" चिह्नित इमेज को रनिंग कंटेनर प्रभावित किए बिना हटाया जा सकता है।

• Containers: हर कंटेनर की राइटेबल लेयर का साइज दिखाता है। यदि किसी रुके हुए कंटेनर में यहाँ उल्लेखनीय SIZE दिखता है, तो वह अपनी फाइलसिस्टम पर डेटा लिख रहा था। CREATED कॉलम भूले-बिसरे पुराने कंटेनर पहचानने में मदद करता है।

• Volumes: वॉल्यूम साइज और उपयोग स्थिति सूचीबद्ध करता है। उपयोग में नहीं दिखने वाले वॉल्यूम हटाने के लिए सुरक्षित उम्मीदवार हैं, फिर भी प्रून करने से पहले सुनिश्चित करें कि उनमें महत्वपूर्ण डेटा न हो।

• Build Cache: अक्सर सबसे बड़ा उपभोक्ता और अक्सर नज़रअंदाज़। ये docker build ऑपरेशन की इंटरमीडिएट लेयर हैं जिन्हें Docker बाद की बिल्ड तेज़ करने हेतु रखता है।

OS-विशिष्ट कमांड

नेटिव Linux उपयोगकर्ता जो फाइलसिस्टम की और गहन समझ चाहते हैं, वे सीधे सबडायरेक्टरी जाँच सकते हैं ताकि पता चले कौन-सी (overlay2, containers, volumes) सबसे अधिक स्पेस खा रही हैं:

sudo du -h --max-depth=1 /var/lib/docker | sort -hसंचालित द्वारा

हालाँकि, Docker Desktop उपयोगकर्ताओं के लिए /var/lib/docker Docker की छिपी वर्चुअल मशीन के भीतर होता है और सीधे सुलभ नहीं होता। अच्छी बात यह है कि docker system df -v प्लेटफ़ॉर्म की परवाह किए बिना आपको सभी कार्यात्मक जानकारी देता है, जिससे यह सबसे विश्वसनीय डायग्नोस्टिक तरीका बनता है।

चरण 2: Docker Prune से सिस्टम साफ़ करें 

जहाँ स्पेस खपत हो रहा है, यह पहचानने के बाद, मैं Docker के बिल्ट-इन प्रूनिंग कमांड से उसे सुरक्षित रूप से रिक्लेम कर सकता/सकती हूँ। ये ऑपरेशन केवल अनयूज्ड संसाधन हटाने के लिए डिज़ाइन किए गए हैं, जिससे रनिंग सेवाओं में व्यवधान का जोखिम न्यूनतम रहता है।

डैन्ग्लिंग संसाधन प्रून करें

Docker "dangling" और "unused" संसाधनों में फर्क करता है। डैन्ग्लिंग इमेज वह है जिसके पास कोई टैग और कोई कंटेनर रेफरेंस नहीं होता। आमतौर पर, असफ़ल या सुपरसिड बिल्ड की इंटरमीडिएट लेयर। इन्हें हटाना हमेशा सुरक्षित है।

बेसिक prune कमांड से शुरू करें:

docker system pruneसंचालित द्वारा

यह सभी अनयूज्ड कंटेनर, नेटवर्क और डैन्ग्लिंग इमेज हटाता है। यह टैग की गई इमेज या वॉल्यूम को तब तक नहीं छूता जब तक आप स्पष्ट रूप से न कहें। आगे बढ़ने से पहले Docker पुष्टि माँगेगा।

अधिक आक्रामक होने और सभी अनयूज्ड इमेज (केवल डैन्ग्लिंग नहीं) हटाने के लिए --all फ्लैग जोड़ें:

docker system prune --allसंचालित द्वारा

Docker system prune

यह कमांड ऐसी हर इमेज हटाता है जो वर्तमान में किसी कंटेनर से जुड़ी नहीं है। सावधान रहें: बाद के डिप्लॉयमेंट को हटाई गई इमेज फिर से पुल करनी होंगी।

यदि आप क्लीनअप में वॉल्यूम (जो पर्सिस्टेंट डेटा रखते हैं) शामिल करना चाहते हैं, तो --volumes फ्लैग जोड़ें:

docker system prune --all --volumesसंचालित द्वारा

चेतावनी: यह अनयूज्ड वॉल्यूम में मौजूद डेटा को स्थायी रूप से डिलीट कर देता है। इस फ्लैग का उपयोग करने से पहले हमेशा सत्यापित करें कि वॉल्यूम में महत्वपूर्ण डेटा नहीं है।

बिल्ड कैश मैनेज करें

यहीं चीज़ें दिलचस्प हो जाती हैं। बिल्ड कैश, जो Docker बिल्ड ऑपरेशन्स की इंटरमीडिएट लेयर रखता है, अक्सर सबसे बड़ा स्पेस उपभोक्ता होता है, फिर भी docker system prune इसे जान-बूझकर बाहर रखता है ताकि बिल्ड प्रदर्शन बना रहे।

बिल्ड कैश को लक्षित करने के लिए:

docker builder pruneसंचालित द्वारा

यदि आप चयनात्मक होना चाहते हैं और हालिया कैश लेयर बचाना चाहते हैं, तो समय-आधारित फिल्टर का उपयोग करें:

docker builder prune --filter "until=24h"संचालित द्वारा

यह केवल 24 घंटे से पुराने कैश लेयर हटाता है, जिससे आपका हालिया काम सुरक्षित रहता है।

वॉल्यूम को सुरक्षित रूप से साफ़ करें

वॉल्यूम में पर्सिस्टेंट डेटा होता है—जैसे डेटाबेस, अपलोडेड फाइलें, और एप्लिकेशन स्टेट—इसलिए अतिरिक्त सावधानी ज़रूरी है। गलत वॉल्यूम हटाने का मतलब स्थायी डेटा लॉस है।

पहले डैन्ग्लिंग वॉल्यूम (जो किसी कंटेनर से जुड़े नहीं हैं) पहचानें:

docker volume ls -f dangling=trueसंचालित द्वारा

इस सूची की सावधानी से समीक्षा करें। यदि सुनिश्चित हों कि ये वॉल्यूम ज़रूरी नहीं हैं, तो उन्हें प्रून करें:

docker volume pruneसंचालित द्वारा

Docker आगे बढ़ने से पहले पुष्टि माँगेगा। संदेह होने पर, प्रून करने से पहले वॉल्यूम का बैकअप लें।

चरण 3: Docker लॉग फाइल समाप्ति संभालें

कंटेनर लॉग चुपचाप बहुत अधिक डिस्क स्पेस खा सकते हैं, कभी-कभी प्रति कंटेनर 50 GB से भी ज़्यादा।

फूले हुए लॉग फाइल पहचानें

Docker का डिफ़ॉल्ट json-file लॉगिंग ड्राइवर सभी कंटेनर stdout और stderr को JSON फाइलों में कैप्चर करता है। यदि max-size सेटिंग नहीं है (डिफ़ॉल्ट -1, अनलिमिटेड), तो ये फाइलें अनियंत्रित रूप से बढ़ती हैं।

सभी वातावरणों में कंटेनर साइज जाँचें:

docker ps -a --format "table {{.ID}}\t{{.Names}}\t{{.Size}}"संचालित द्वारा

किसी विशिष्ट कंटेनर की लॉग फाइल साइज जाँचने के लिए:

ls -lh $(docker inspect --format='{{.LogPath}}' <container-name>)संचालित द्वारा

केवल नेटिव Linux के लिए, सीधे सबसे बड़ी लॉग फाइलें ढूँढें:

sudo find /var/lib/docker/containers/ -name "*-json.log" -exec du -h {} + | sort -h | tail -10संचालित द्वारा

यदि docker logs धीमा हो जाए या कंटेनर शुरू होने में विफल हों, तो संभवतः ओवरसाइज़्ड लॉग कारण हैं। इसे हल करने के लिए आप लॉग ट्रंकेट कर सकते हैं।

लॉग सुरक्षित रूप से ट्रंकेट करें

लॉग ट्रंकेट करने से अधिक स्पेस मिलेगा। हालांकि, कंटेनर रनिंग होने पर rm से लॉग फाइलें कभी डिलीट न करें। Docker डेमन इन लॉग पर ओपन फाइल हैंडल पकड़े रहता है, और उन्हें डिलीट करना "डिलीटेड पर ओपन" फाइलें बनाता है जो डेमन रीस्टार्ट तक स्पेस खाती रहती हैं।

सुरक्षित तरीका है लॉग को ज़ीरो पर ट्रंकेट करना:

sudo truncate -s 0 $(docker inspect --format='{{.LogPath}}' <container-name>)संचालित द्वारा

यह फाइल हैंडल तोड़े बिना तुरंत स्पेस छोड़ देता है। कंटेनर उसी फाइल में लॉगिंग जारी रखेगा।

चरण 4: उन्नत ट्रबलशूटिंग और छिपे मुद्दे

जब मानक क्लीनअप विफल हो जाए, तो संभव है कि आप इन कम आम, पर उतने ही प्रभावशाली मुद्दों में से किसी से जूझ रहे हों:

• इनोड्स समाप्ति: फ्री डिस्क स्पेस होते हुए भी आपकी फाइलसिस्टम के फाइल मेटाडेटा स्ट्रक्चर खत्म हो गए हैं

• डिलीटेड पर ओपन फाइलें: प्रोसेस डिलीटेड फाइलों के फाइल हैंडल पकड़े रखते हैं, जिससे "फैंटम" स्पेस उपयोग बनता है

• Docker Desktop वर्चुअल डिस्क फूली हुई: होस्ट की .raw या .vhdx फाइल VM के अंदर डेटा डिलीट होने के बाद भी सिकुड़ती नहीं

आइए इन परिदृश्यों को क्रमबद्ध तरीके से हल करें।

इनोड्स समाप्ति सुलझाएँ

यह उन एप्लिकेशन से हो सकता है जो लाखों छोटी फाइलें बनाते हैं, जैसे PHP सेशन्स, npm का node_modules, या बिल्ड आर्टिफैक्ट, जो चौंकाने वाली दर से इनोड्स खपा देते हैं।

पहले, इनोड्स समाप्ति सत्यापित करें:

df -iसंचालित द्वारा

Docker कमांड से (सभी वातावरणों में):

docker ps -a | wc -l             # कंटेनर की संख्या जाँचें
docker images | wc -l         # इमेज की संख्या जाँचें
docker image prune -a      # अनयूज्ड इमेज हटाकर इनोड्स खाली करेंसंचालित द्वारा

Linux इंस्टॉलेशन के लिए, इनोड-भारी डायरेक्टरी पहचानें:

for dir in /var/lib/docker/*/; do
    echo "$dir: $(sudo find $dir -type f 2>/dev/null | wc -l) files"
doneसंचालित द्वारा

अनयूज्ड इमेज को docker rmi से हटाना भी इनोड्स खाली करता है। एप्लिकेशन-स्तरीय समस्याओं के लिए, कंटेनरों के भीतर क्लीनअप लागू करें या टेम्पररी फाइलों के लिए वॉल्यूम माउंट का उपयोग करें।

डिलीटेड पर ओपन फाइलें संभालें (केवल Linux)

जब किसी फाइल को डिलीट कर दिया जाता है जबकि कोई प्रोसेस अभी भी उसे ओपन रखता है, तो फाइलसिस्टम तब तक स्पेस नहीं छोड़ता जब तक प्रोसेस फाइल हैंडल बंद न कर दे ("फैंटम" स्पेस उपयोग)।

Linux उपयोगकर्ता ओपन फाइलों की सूची में "deleted" एंट्री ढूँढकर जाँच सकते हैं कि ऐसा हो रहा है या नहीं।

पहले, इन फाइलों की पहचान करें:

sudo lsof | grep deleted संचालित द्वारा

Docker डिलीटेड फाइलें

फिर स्पेस छोड़ने के लिए, विशिष्ट प्रोसेस (जिसका PID lsof से मिला) को रीस्टार्ट करें या Docker को रीस्टार्ट करें। ऐसा करने के बाद, यदि आप कमांड फिर चलाएँगे, तो फाइलें अब नहीं दिखेंगी, जिसका अर्थ है वे सही से हट गई हैं।

अब आख़िरी उन्नत ट्रबलशूटिंग रणनीति देखें, जो केवल Docker Desktop पर लागू है: वर्चुअल डिस्क मैनेज करना।

Docker Desktop वर्चुअल डिस्क मैनेज करना

Docker Desktop डेटा को एक वर्चुअल डिस्क फाइल (.raw Mac पर, .vhdx Windows पर) में स्टोर करता है जो डाइनैमिक रूप से बढ़ती है लेकिन जब आप VM के अंदर डेटा डिलीट करते हैं तो अपने-आप सिकुड़ती नहीं। आप इमेज और कंटेनर प्रून करते हैं, VM के अंदर फ्री स्पेस बढ़ता दिखता है, फिर भी आपका होस्ट डिस्क भरा रहता है।

इसे मैनेज करने के लिए, सबसे सुरक्षित तरीका है fstrim का उपयोग करना, ताकि डेटा खोए बिना डिस्क कॉम्पैक्ट हो जाए:

docker run --privileged --pid=host alpine nsenter -t 1 -m -u -i -n fstrim /संचालित द्वारा

यह कमांड Docker Desktop VM की फाइलसिस्टम को ट्रिम करता है, और अनयूज्ड ब्लॉक आपके होस्ट सिस्टम को लौटा देता है। आपकी इमेज, कंटेनर और वॉल्यूम सुरक्षित रहते हैं।

वैकल्पिक रूप से, यदि आप पूरी तरह से नया शुरू करना चाहते हैं (यह सारा डेटा डिलीट कर देता है), तो Docker Desktop Settings → Troubleshoot → Reset to factory defaults का उपयोग करें। 

चेतावनी: यह विध्वंसक है और सभी इमेज, कंटेनर, वॉल्यूम और सेटिंग्स हटा देती है। सब कुछ विफल होने पर ही इसे आख़िरी विकल्प के रूप में चुनें।

फैक्टरी डिफॉल्ट पर रीसेट

चरण 5: Docker की “No Space Left on Device” त्रुटि से बचाव करें

अब जब हमने तत्काल संकट को टाल दिया है, तो पुनरावृत्ति रोकने के लिए संरचनात्मक बदलाव लागू करें। इन कॉन्फ़िगरेशन में योजना बनती है, लेकिन सिस्टम स्थिरता में भारी लाभ देती है।

Docker रूट डायरेक्टरी स्थानांतरित करें (केवल Linux)

Docker Desktop उपयोगकर्ता डेटा रूट लोकेशन आसानी से नहीं बदल सकते। इसके बजाय, आप ये कर सकते हैं:

• डिस्क स्पेस बढ़ाएँ: चरण 4 में वर्णित वर्चुअल डिस्क कॉम्पैक्शन विधियाँ उपयोग करें

• WSL2 बैकएंड के लिए: .wslconfig फाइल के माध्यम से सीमाएँ मैनेज करें जैसा कि Docker Desktop Settings → Resources में दिखाया गया है

हालाँकि, यदि आप Linux पर हैं और आपका रूट पार्टीशन सीमित है, लेकिन आपके पास बड़ा पार्टीशन उपलब्ध है (शायद एक समर्पित डेटा डिस्क), तो Docker की डेटा डायरेक्टरी को स्थानांतरित करना एक स्थायी समाधान है।

पहले, Docker रोकें:

sudo systemctl stop dockerसंचालित द्वारा

/etc/docker/daemon.json एडिट करें और नया लोकेशन बताएँ:

{
  "data-root": "/mnt/docker-data"
}संचालित द्वारा

मौजूदा डेटा माइग्रेट करें ताकि आपकी इमेज और कंटेनर बने रहें:

sudo rsync -aP /var/lib/docker/ /mnt/docker-data/संचालित द्वारा

अंत में, Docker रीस्टार्ट करें:

sudo systemctl start dockerसंचालित द्वारा

अब Docker सारा डेटा नए स्थान पर स्टोर करता है। पथ की पुष्टि के लिए docker info | grep "Docker Root Dir" चलाकर जाँचें।

ग्लोबल लॉग रोटेशन कॉन्फ़िगर करें

लॉग रोटेशन वह एकल सबसे प्रभावी रोकथाम रणनीति है जिसे मैंने लागू किया है। डिफ़ॉल्ट रूप से, Docker का json-file ड्राइवर max-size: -1 (अनलिमिटेड) रखता है, जो प्रोडक्शन में समस्या का नुस्ख़ा है।

नेटिव Linux इंस्टॉलेशन के लिए, /etc/docker/daemon.json में ग्लोबल सीमाएँ लागू करें:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}संचालित द्वारा

फाइल एडिट करने के बाद, Docker रीस्टार्ट करें।

Docker Desktop उपयोगकर्ताओं के लिए, आप सीधे /etc/docker/daemon.json एडिट नहीं करते। इसके बजाय:

1. Docker Desktop खोलें
2. Settings → Docker Engine पर जाएँ
3. आपको डेमन कॉन्फ़िगरेशन के साथ JSON एडिटर दिखेगा
4. मौजूदा JSON में लॉग रोटेशन सेटिंग्स जोड़ें:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}संचालित द्वारा

अंत में, Apply & Restart पर क्लिक करें।

यह उदाहरण कॉन्फ़िगरेशन हर कंटेनर को 10MB के तीन लॉग फाइल (कुल 30MB) तक सीमित करता है।

महत्वपूर्ण नोट: ये सेटिंग्स केवल नए बनाए गए कंटेनरों पर लागू होती हैं। मौजूदा कंटेनर अपनी मूल लॉग कॉन्फ़िगरेशन बनाए रखते हैं। नई सीमाएँ लागू करने के लिए कंटेनरों को फिर से बनाना होगा।

और बेहतर कंप्रेशन और प्रदर्शन के लिए, लोकल लॉगिंग ड्राइवर पर विचार करें:

{
  "log-driver": "local",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "compress": "true"
  }
}संचालित द्वारा

इसके अतिरिक्त, आप docker-compose.yml में प्रति सर्विस लॉग सेटिंग्स ओवरराइड भी कर सकते हैं:

services:
  web:
    image: nginx
    logging:
      driver: "json-file"
      options:
        max-size: "50m"
        max-file: "5"संचालित द्वारा

मेंटेनेंस ऑटोमेट करें

एक और अच्छी प्रैक्टिस कुछ प्रक्रियाओं को ऑटोमेट करना है। अक्सर कहा जाता है कि रोकथाम, संकट प्रबंधन से बेहतर है। इसलिए, मैं सलाह देता/देती हूँ कि मेंटेनेंस विंडो में चलने वाली क्रॉन जॉब से क्लीनअप ऑटोमेट करें:

# Create a cleanup script
sudo cat > /usr/local/bin/docker-cleanup.sh << 'EOF'
#!/bin/bash
docker system prune -f
docker builder prune -f --filter "until=168h"
EOF

sudo chmod +x /usr/local/bin/docker-cleanup.sh

# Add to crontab to run weekly on Sundays at 2 AM
echo "0 2 * * 0 /usr/local/bin/docker-cleanup.sh" | sudo crontab -संचालित द्वारा

यह स्क्रिप्ट एक शेड्यूल्ड टास्क बनाती है जो हर रविवार रात 2 बजे अपने-आप स्टॉप्ड कंटेनर और अनयूज्ड डेटा हटाती है। यह एक सप्ताह (168 घंटे) से पुराने बिल्ड कैश लेयर भी सुरक्षित रूप से साफ़ करती है ताकि डिस्क उपयोग अनिश्चित रूप से न बढ़े।

इसके अलावा, अपने Dockerfile को मल्टी-स्टेज बिल्ड से ऑप्टिमाइज़ करें ताकि इमेज साइज न्यूनतम हो। मल्टी-स्टेज बिल्ड आपको एक स्टेज में कम्पाइल/बिल्ड (भारी डेवलपमेंट टूल्स के साथ) करने और फिर केवल अंतिम आर्टिफैक्ट्स को साफ-सुथरे, मिनिमल प्रोडक्शन स्टेज में कॉपी करने देता है। 

यह आपके अंतिम इमेज से बिल्ड डिपेंडेंसी, सोर्स कोड और इंटरमीडिएट फाइलें हटा देता है, जिससे साइज और अटैक सरफेस में नाटकीय कमी आती है।

# Build stage
FROM node:16 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# Production stage
FROM node:16-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/index.js"]संचालित द्वारा

यह पैटर्न बिल्ड टूल्स और सोर्स कोड को बाहर रखकर प्रोडक्शन इमेज का साइज घटाता है।

निष्कर्ष

"no space left on device" त्रुटि को ठीक करना एक पूर्वानुमेय पैटर्न का पालन करता है: पहले निदान करें कि आप डिस्क ब्लॉक से जूझ रहे हैं या इनोड्स से; फिर सुरक्षित रूप से प्रून कर स्पेस रिक्लेम करें, बिना डेटा लॉस के; उसके बाद पुनरावृत्ति रोकने के लिए कॉन्फ़िगरेशन ऑप्टिमाइज़ करें।

Docker वातावरण मैनेज करते वर्षों में मैंने सीखा है कि लॉग रोटेशन सबसे प्रभावी रोकथाम रणनीति है। एक साधारण daemon.json कॉन्फ़िगरेशन अधिकांश स्पेस समाप्ति घटनाओं को रोक सकता है।

मैं आपको अपना daemon.json कॉन्फ़िगरेशन अभी ऑडिट करने के लिए प्रोत्साहित करता/करती हूँ। यदि आपके लॉगिंग ड्राइवर के लिए max-size और max-file सेट नहीं हैं, तो उन्हें तुरंत जोड़ें। जब आप अगली स्पेस क्राइसिस से बचेंगे, तो आप स्वयं को धन्यवाद देंगे।

Docker प्रो बनने के लिए तैयार हैं? अगला कदम है हमारे Containerization and Virtualization with Docker and Kubernetes स्किल ट्रैक में नामांकन करना, जिसकी मैं दृढ़ता से सिफारिश करता/करती हूँ।