SSD Nodes Learn 🎉 VPS $5.50/ماہ سے
تعلیمی Matt Connorتحریر: Matt Connor

Docker prune: VPS پر disk space کیسے خالی کریں

VPS کی ڈسک بھر گئی ہے؟ جانیں images، containers، build cache یا volumes میں جگہ کہاں ہے، پھر درست Docker prune کمانڈ چلائیں، بغیر ضروری data حذف کیے۔

پروننگ سے پہلے معلوم کریں کہ ڈسک کی جگہ کون استعمال کر رہا ہے

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 تک محدود رکھتا ہے۔ اس لیے یہ کسی mount کے ذریعے الگ volume میں داخل ہو کر اسے دوبارہ شمار نہیں کرتا۔ یہاں پانچ 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

یہ اعداد ایک مشین سے لیے گئے ہیں اور آپ کے سسٹم کے بارے میں کچھ نہیں بتاتے۔ اعداد کی ساخت دیکھیں۔ TOTAL objects کی تعداد بتاتا ہے، ACTIVE اس وقت استعمال ہونے والے objects کی تعداد بتاتا ہے، اور RECLAIMABLE اس row سے prune کے ذریعے خالی ہونے والی جگہ کا Docker کا تخمینہ ہے۔

RECLAIMABLE کے بارے میں دو باتیں اکثر نظرانداز ہو جاتی ہیں۔ یہ shared image layers کو استعمال کرنے والی ہر image کے لیے ایک بار شمار کرتا ہے، اس لیے image row عموماً دستیاب ہونے والی اصل جگہ سے زیادہ جگہ دکھاتی ہے۔ یہ container log files کو کبھی شامل نہیں کرتا، کیونکہ Docker log file کو reclaimable 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 کی value ہی اس بات کا مکمل test ہے کہ volume prune commands اس volume پر لاگو ہوں گی۔

بے نام images اور غیر استعمال شدہ images

یہ دونوں اصطلاحات ایک جیسی معلوم ہوتی ہیں، لیکن ایسا نہیں ہے۔ Filters مختلف انداز میں کام کرتے ہیں کیونکہ متعلقہ objects مختلف ہوتے ہیں۔

بے نام image وہ image ہے جس پر کوئی tag نہیں ہوتا۔ یہ docker images میں <none> کے طور پر دکھائی دیتی ہے۔ ہر rebuild پر ایسی image بنتی ہے: docker build -t myapp:latest . tag myapp:latest کو نئی image پر منتقل کر دیتا ہے، جبکہ پرانی image اپنی تمام layers برقرار رکھتی ہے لیکن اس کا نام ختم ہو جاتا ہے۔ کوئی چیز اس کا حوالہ نہیں دیتی، اور یہ خود بخود صاف نہیں ہوتی۔

غیر استعمال شدہ image ایسی کوئی بھی image ہے، چاہے اس پر tag ہو یا نہ ہو، جس کا فی الحال کوئی container حوالہ نہ دے رہا ہو۔ پچھلے ماہ pull کی گئی postgres:16، جسے آپ اس وقت نہیں چلا رہے، غیر استعمال شدہ ہے، لیکن بے نام نہیں ہے۔

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" سے مراد موجودہ container object ہے، چاہے وہ running ہو یا stopped۔ اگر آپ نے docker compose down چلایا، تو containers ختم ہو جاتے ہیں۔ اس لیے ان services کے استعمال کردہ تمام images اب غیر استعمال شدہ ہو جاتے ہیں، اور -a ان سب کو delete کر دیتا ہے۔ ایسی کوئی چیز ضائع نہیں ہوتی جسے دوبارہ حاصل نہ کیا جا سکے، لیکن اگلا docker compose up -d تمام images دوبارہ pull یا rebuild کرے گا۔ چھوٹے VPS پر اس میں bandwidth اور build time خرچ ہوتا ہے۔ یہ ایک عملی وجہ ہے کہ prune کرنے سے پہلے یہ جاننا ضروری ہے کہ docker compose down کیا remove کرتا ہے اور stop کیا چلتا رہنے دیتا ہے۔

ایک filter حالیہ images کو دائرۂ کار سے باہر رکھتا ہے۔

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

یہ 240 hours (10 days) سے زیادہ پرانی غیر استعمال شدہ images کو remove کرتا ہے اور نئی images کو برقرار رکھتا ہے۔ until value ایسی Go duration string قبول کرتی ہے جیسے 240h، یا absolute timestamp جیسے 2026-08-01T00:00:00۔

Build cache کیا ہے اور یہ لامحدود کیوں بڑھتا ہے

BuildKit وہ builder ہے جسے Docker، Docker Engine 23.0 سے docker build اور docker compose build کے لیے بطور default استعمال کرتا ہے۔ یہ چلنے والی ہر Dockerfile کے ہر step کا نتیجہ cache کرتا ہے اور اس cache کو /var/lib/docker/buildkit میں رکھتا ہے۔ یہی cache ہے جس کی وجہ سے دوسری build چند seconds میں مکمل ہو جاتی ہے، اس لیے یہ اپنا کام کر رہا ہے۔ مسئلہ یہ ہے کہ default طور پر پرانی entries کو expire کرنے کا کوئی طریقہ موجود نہیں۔ اگر آپ ایسی image کو پچاس بار build کریں جس میں COPY step ہر بار تبدیل ہو، تو layers کے پچاس sets محفوظ رہیں گے۔

Build cache docker image prune کو نظر نہیں آتا۔ یہ ایک الگ object type ہے اور اس کے لیے الگ command موجود ہے۔

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 صاف کرنے کی واحد قیمت یہ ہے کہ اگلی build صرف ایک بار آہستہ چلے گی۔ ایسے VPS پر جہاں images باقاعدگی سے rebuild ہوتی ہیں، Build Cache اکثر docker system df میں سب سے بڑی row ہوتی ہے، اس لیے یہ وہ بڑی چیز ہے جسے delete کرنا عموماً سب سے محفوظ ہوتا ہے۔

محفوظ سے تباہ کن تک prune commands کی ترتیب

اس فہرست میں اوپر سے نیچے جائیں اور جیسے ہی df -h / دوبارہ درست دکھائی دے، رک جائیں۔ ہر command مکمل ہونے پر Total reclaimed space: line دکھاتی ہے۔

  1. docker container prune stopped containers کو remove کرتا ہے۔ ان کی writable layers بھی remove ہو جاتی ہیں، اس لیے container نے volume کے باہر جو کچھ لکھا ہو، وہ بھی اس کے ساتھ delete ہو جاتا ہے۔ Volumes متاثر نہیں ہوتے۔
  2. docker image prune صرف dangling images کو remove کرتا ہے۔ یہ سب سے محفوظ image command ہے۔
  3. docker builder prune dangling build cache کو remove کرتا ہے۔ اس کی قیمت صرف ایک slow build ہے۔
  4. docker image prune -a ہر وہ image remove کرتا ہے جسے کوئی container refer نہیں کرتا۔ اس کے بعد image دوبارہ pull یا rebuild کرنی پڑے گی۔
  5. docker system prune پہلے تین commands ایک ساتھ چلاتا ہے اور unused networks بھی شامل کرتا ہے۔
  6. docker volume prune unused anonymous volumes کو remove کرتا ہے۔
  7. docker volume prune -a named volumes سمیت تمام unused volumes کو remove کرتا ہے۔ Databases حذف کرنے والی command یہی ہے۔

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 images تک پھیل جاتا ہے۔ Production host پر مکمل docker system prune -a --volumes -f چلانے سے space خالی کرنے کی کوشش میں data ضائع ہو سکتا ہے۔

والیومز کو prune کرنے سے آپ کا database کیوں حذف ہو جاتا ہے

یہ حصہ دو بار پڑھیں۔

جب کسی volume کے ساتھ کوئی container منسلک نہ ہو تو وہ unused شمار ہوتا ہے۔ یہی مکمل جانچ ہے۔ Docker یہ نہیں دیکھتا کہ volume خالی ہے یا نہیں، compose file میں وہ اب بھی declare کیا گیا ہے یا نہیں، یا اس میں آپ کے database کی واحد copy موجود ہے یا نہیں۔ LINKS 0 کو docker system df -v میں شامل کرنے کا مطلب ہے کہ وہ prunable ہے، اور اس کا مطلب اس کے سوا کچھ نہیں۔

اب دو عام actions مسلسل انجام دیں۔ آپ stack کو صاف طریقے سے restart کرنے کے لیے docker compose down چلاتے ہیں۔ یہ containers کو remove کرتا ہے اور named volumes کو برقرار رکھتا ہے، جو اس command کی documented کارکردگی ہے۔ اب آپ کا Postgres volume کسی container کے ساتھ منسلک نہیں ہے۔ دس منٹ بعد آپ space خالی کرنے کے لیے docker volume prune -a چلاتے ہیں، اور database ختم ہو جاتا ہے۔ دونوں commands نے درست طور پر کام کیا۔ اس sequence نے data تباہ کر دیا۔

Docker Engine 23.0 (API version 1.42) کے بعد سادہ command پہلے کی نسبت زیادہ محدود ہے۔

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

Anonymous volume وہ volume ہے جسے Docker آپ کے لیے بناتا ہے۔ عموماً ایسا اس لیے ہوتا ہے کہ image میں VOLUME declare کیا گیا ہو اور آپ نے اسے کوئی نام نہ دیا ہو۔ ان میں عموماً وہ data ہوتا ہے جسے آپ نے محفوظ رکھنے کے لیے خاص طور پر منتخب نہیں کیا۔ Named volume، یعنی وہ قسم جسے آپ نے اپنی compose file میں لکھا ہے، صرف اس وقت remove ہوتا ہے جب آپ -a شامل کریں۔ پرانے Docker versions سادہ command کے ساتھ دونوں اقسام remove کرتے تھے۔ اس لیے اس machine پر بنی عادتوں پر بھروسا نہ کریں جسے آپ بعد میں upgrade کر چکے ہیں۔ یہ فرق اسی وقت واضح ہوتا ہے جب آپ جانتے ہوں کہ named volumes، bind mounts سے کیسے مختلف ہیں، کیونکہ bind mount، Docker volume نہیں ہوتا اور کوئی بھی prune command اسے کبھی متاثر نہیں کرے گی۔

حذف کرنے سے پہلے جانچ کریں۔ myapp_pgdata کو اس volume کے نام سے بدلیں جسے آپ check کر رہے ہیں۔

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 کی فہرست بنانے سے معلوم ہوتا ہے کہ اس کے اندر حقیقت میں کیا موجود ہے۔ اگر وہاں pgdata یا mysql directory ملے تو رک جائیں اور مزید کارروائی سے پہلے اس کی copy بنائیں۔ یہی data destruction docker compose down -v کے ذریعے بھی ہوتا ہے۔ یہ compose file میں declare کیے گئے ہر volume کو remove کرتا ہے اور پہلے آپ سے کوئی تصدیق نہیں لیتا۔

Docker host پر volume وہ واحد چیز ہے جسے rebuild دوبارہ تخلیق نہیں کر سکتا۔ اسی لیے volume data کو server سے باہر چلنے والے restic backup میں محفوظ کریں، جہاں غلط flag اسے متاثر نہیں کر سکتا۔

جب کچھ بھی prune نہ ہو: container کی log files

آپ ہر چیز prune کر چکے ہیں، docker system df تقریباً کچھ بھی reclaimable نہیں دکھاتا، لیکن 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 ہوتا ہے، جس کا مطلب unlimited ہے۔ اس لیے crash loop میں پھنسا ہوا ایک container partition بھرنے تک لکھتا رہتا ہے۔ کوئی بھی prune command ان files کو حذف نہیں کرتی، کیونکہ انہیں پیدا کرنے والے containers چل رہے ہوتے ہیں۔ تعریف کے مطابق وہ prunable نہیں ہوتے۔

File حذف نہ کریں۔ کھلی ہوئی log file پر rm چلانے سے کوئی جگہ خالی نہیں ہوتی، کیونکہ Docker daemon اب بھی open file descriptor اپنے پاس رکھتا ہے، اور kernel ان blocks کو اس وقت تک allocated رکھتا ہے جب تک وہ handle بند نہ ہو جائے۔ df بالکل آگے نہیں بڑھے گا۔ اس کے بجائے file کو 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 کمانڈ نے کیا کیا، اس کے بارے میں کبھی اندازہ نہ لگائیں۔ پہلے ایک پیمائش لیں، ایک کمانڈ چلائیں، پھر دوبارہ پیمائش لیں۔

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 بتائے کہ جگہ خالی ہوئی ہے، تو ایک open file handle حذف شدہ blocks کو تھامے ہوئے ہے۔ یہی اوپر بیان کیا گیا log file کا مسئلہ ہے۔ اگر دونوں میں تبدیلی آئے اور disk ایک دن کے اندر دوبارہ بھر جائے، تو مسئلہ cleanup کے بجائے growth کا ہے۔ اس کا حل log 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 کے تحت ہر value string ہونی چاہیے، جن میں numeric values بھی شامل ہیں۔ Restart کرنے سے پہلے تصدیق کریں کہ file درست طور پر parse ہو رہی ہے، کیونکہ malformed 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 میں limits، docker inspect کے LogConfig section میں ظاہر ہوتی ہیں۔ یہی اہم نکتہ ہے: یہ setting صرف نئے containers پر لاگو ہوتی ہے۔ موجودہ containers وہی configuration برقرار رکھتے ہیں جس کے ساتھ وہ بنائے گئے تھے، اس لیے انہیں دوبارہ create کریں۔

docker compose up -d --force-recreate

Compose file میں یہی limit ہر service کے لیے الگ بھی مقرر کی جا سکتی ہے۔ جب کسی ایک noisy service کے لیے اپنی limit درکار ہو تو یہ بہتر انتخاب ہے۔

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

محدود prune schedule کریں۔ اسے ہفتہ وار چلائیں اور صرف dangling images اور پرانے build cache تک محدود رکھیں۔ Scheduled job میں کبھی بھی -a یا --volumes شامل نہ کریں، کیونکہ stack کے down ہونے کے دوران چلنے والی 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 execution سے پہلے آپ اس کا output دیکھ سکیں۔ File executable ہونی چاہیے، اور اس کے نام میں dot شامل نہیں ہونا چاہیے، کیونکہ run-parts non-executable files اور extension والی files دونوں کو skip کرتا ہے۔

خالی disk space پر alert لگائیں۔ Disk بھر جانے کے بعد کیا جانے والا prune recovery ہے۔ 80 percent پر 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 کے ساتھ استعمال کریں، کیونکہ failing disk اور full disk دونوں آپ کے containers کو روک دیتے ہیں اور دونوں کے لیے مختلف fixes درکار ہوتے ہیں۔

اوپر دی گئی تمام ہدایات standard install فرض کرتی ہیں، جس میں data root /var/lib/docker پر ہے۔ اگر آپ نے اسے daemon.json میں موجود data-root key کے ذریعے منتقل کیا ہے تو ہر command میں اپنی path استعمال کریں۔ نئی machine پر یہ layout درست طور پر بنانا VPS پر Docker setup کرنے کا حصہ ہے، اور 40 GB کے containers غلط partition پر موجود ہونے سے پہلے فیصلہ کرنا کہیں آسان ہوتا ہے۔

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 set کرنے تک یہ مسلسل بڑھتی رہتی ہیں۔ دوسری وجہ ایسی deleted 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 form ہر وہ image حذف کرتی ہے جسے کوئی موجودہ container refer نہ کرتا ہو، بشمول ان tagged images کے جو آپ نے جان بوجھ کر pull کی ہوں۔ docker compose down کے بعد containers ختم ہو جاتے ہیں، اس لیے -a اس stack کی images بھی حذف کر دے گا۔ کچھ مستقل طور پر ضائع نہیں ہوتا، کیونکہ اگلی start پر یہ دوبارہ pull یا rebuild ہو جاتی ہیں، لیکن سست link پر اس میں کافی وقت لگ سکتا ہے۔

Docker logs کو disk بھرنے سے کیسے روکوں؟

/etc/docker/daemon.json میں log-opts کے تحت max-size اور max-file set کریں، پھر sudo systemctl restart docker سے daemon restart کریں۔ یہ setting صرف اس restart کے بعد بنائے گئے containers پر لاگو ہوتی ہے، اس لیے running containers کو docker compose up -d --force-recreate سے دوبارہ بنائیں۔ Compose file میں ہر service کے لیے یہی دونوں options logging key کے تحت set کیے جا سکتے ہیں۔ جب کوئی ایک service باقی services کے مقابلے میں بہت زیادہ logs بناتی ہو تو یہی طریقہ استعمال کریں۔

کیا cron job میں docker system prune چلانا محفوظ ہے؟

سادہ docker system prune -f ایسے host پر محفوظ ہے جہاں ہر stack چلتی رہتی ہو، لیکن یہ stopped containers حذف کرتی ہے۔ اس لیے یہ ایسا container بھی حذف کر دے گی جسے آپ نے جان بوجھ کر روک کر بعد میں دوبارہ start کرنے کا ارادہ کیا ہو۔ زیادہ محفوظ scheduled job docker image prune -f اور docker builder prune -f --filter until=168h پر مشتمل ہے۔ یہ تیزی سے بڑھنے والی دو اقسام کا data صاف کرتی ہے اور کسی volume کو نہیں چھیڑتی۔ -a یا --volumes کو کبھی schedule نہ کریں۔

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