أتمتة تنظيف Docker على السيرفر — سكربت أسبوعي يوفّر 40GB كل شهر

السكربت الأسبوعي الكامل

الأدوات: docker + bash + cron + webhook Slack للتنبيه. احفظ الملف في /usr/local/bin/docker-cleanup.sh:

خلّيه قابل للتنفيذ:

جدولته في cron

حماية الـ volumes المهمة

لو عندك volume فيه data إنتاج (postgres، redis persistence، uploaded files)، علّمه بـ label وقت الإنشاء:

السكربت بيتخطّاه تلقائيًا بسبب الشرط label == "true".

ملاحظة مهمة: Docker مش بيدعم إضافة label لـ volume موجود بدون إعادة إنشاء. لو عندك volumes قديمة مش معلّمة، الحل الآمن: اربط الـ volume بـ container شغّال دايمًا (مثلًا حطّه في docker-compose.yml مع restart: always). ساعتها مش هيظهر أصلًا في dangling=true.

الأرقام من سيرفر حقيقي

على سيرفر إنتاج بيعمل CI builds 15-20 مرة يوميًا (stack: Node.js + PostgreSQL + Redis):

• قبل السكربت: 92GB مستهلك من 100GB disk.
• أول تشغيل: حرّر 52GB (معظمها images قديمة من 6 شهور لـ Node.js 16 كانت بتترص من كل build قديم).
• من الأسبوع الثاني: بيحرّر 8-12GB كل أحد.
• على مدار شهر: متوسط 40GB محرّرة، مع ثبات الاستهلاك حوالين 55-65GB بدل ما يتجاوز 90GB.

trade-offs ومتى مش مناسب

المكسب: مش هتحتاج تتذكر تفضّي السيرفر يدويًا. بتكسب ~10-15 دقيقة شهريًا من شغل idle، والأهم إنك بتتفادى الكابوس بتاع disk full وسط deploy.

الثمن:

1. أول build بعد الـ cleanup ممكن يطول دقيقة-دقيقتين لأن base images هتتسحب من الـ registry تاني.
2. لو Slack webhook بتاعك معلّق أو URL غلط، مفيش تنبيه = ممكن تنسى الموضوع تمامًا. ضيف healthcheck خارجي (زي healthchecks.io) لو السكربت نفسه مهم عندك.
3. --keep-storage 10GB في BuildKit ممكن يكون كبير أو صغير حسب حجم سيرفرك. ابدأ بـ 10 وعدّل لو شايف الـ cache بيمتلي أو الـ builds بطيئة.
4. السكربت مش بيتعامل مع images معلّمة بـ tag لكن مش مستخدمة حاليًا — هتفضل موجودة. ده مقصود عشان متكسرش rollback.

الافتراضات اللي الحل مبني عليها: Docker 23.0+ (BuildKit هو الـ default). لو عندك Docker أقدم، شيل سطر docker builder prune لأنه هيفشل. السكربت كمان بيفترض إن Docker data موجودة على الـ partition الرئيسية (/). لو عندك /var/lib/docker mounted على partition منفصل، غيّر الـ df -BG / لـ df -BG /var/lib/docker.

متى لا تستخدم هذه الطريقة

• سيرفر فيه image واحد بيشتغل شهور بدون builds — مفيش تراكم أصلًا، السكربت overkill.
• بيئة فيها compliance تتطلب audit log لكل حاجة اتمسحت — السكربت مبيحتفظش بـ manifest للـ images المحذوفة؛ هتحتاج تزوّد logging أعمق.
• Kubernetes cluster — في K8s، إدارة الـ image garbage collection شغل kubelet نفسه عبر imageGCHighThresholdPercent و imageGCLowThresholdPercent. تشغيل السكربت ده على node فيه kubelet بيشتغل = مخاطرة إنك تحذف images الـ kubelet لسه محتاجها.
• Docker Swarm نشط بـ services دايمًا scaling — استخدم فلاتر أكثر تحفظًا (until=30*24h) لأن الـ services بتحتاج الـ images جاهزة أي لحظة.

الخطوة التالية

شغّل السكربت يدويًا دلوقتي مرة واحدة قبل ما تحطه في cron:

لو توفّر أقل من 5GB في أول تشغيل، معناه السيرفر نظيف أصلًا والأتمتة مش أولوية — دوّر على سبب تاني لامتلاء الـ disk (logs، uploads، backups محلية). لو توفّر 20GB+، ضيفه للـ cron فورًا وروح نام.

المصادر

• Docker Docs — docker system prune
• Docker Docs — docker builder prune (BuildKit cache)
• Docker Docs — Volumes & labels
• Kubernetes Docs — Image Garbage Collection
• Slack Incoming Webhooks