أتمتة تنظيف Docker بـ systemd timers: استرجاع 40GB أسبوعياً بدون cron

#!/usr/bin/env bash
set -euo pipefail

LOG_TAG="docker-cleanup"
THRESHOLD_GB=50

before=$(df -BG /var/lib/docker | awk 'NR==2 {print $3}' | tr -d 'G')

# containers موقوفة أقدم من 24 ساعة
docker container prune -f --filter "until=24h"

# images مش مربوطة بـ tag (dangling) + unused أقدم من 72 ساعة
docker image prune -af --filter "until=72h"

# volumes يتيمة (مفيش container بيستخدمها)
docker volume prune -f

# build cache أقدم من 7 أيام
docker builder prune -af --filter "until=168h"

after=$(df -BG /var/lib/docker | awk 'NR==2 {print $3}' | tr -d 'G')
freed=$((before - after))

logger -t "$LOG_TAG" "freed ${freed}GB (before=${before}G after=${after}G)"

if [ "$freed" -gt "$THRESHOLD_GB" ]; then
  curl -s -X POST "$DISCORD_WEBHOOK" \
    -H "Content-Type: application/json" \
    -d "{\"content\":\"docker-cleanup حرّر ${freed}GB — قياس شاذ، راجع production.\"}"
fi

2) الـ service: /etc/systemd/system/docker-cleanup.service

3) الـ timer: /etc/systemd/system/docker-cleanup.timer

التفعيل

الـ trade-offs بوضوح

• until=72h على images: بتكسب أمان أن image بتستخدمها للـ rollback الحالي متتمسحش. بتخسر ~8–15GB لو التحديثات كتيرة جدًا. لو بتـ deploy 10 مرات في اليوم قلّلها لـ 24h.
• volume prune بدون فلتر: بتكسب تنظيف كامل. بتخسر احتمال تمسح data في volume نسيت تربطه بـ container (حالة نادرة، لكن حصلت). لو عندك data مهم داخل named volumes، استخدم docker volume prune --filter "label!=keep" وحط label: keep على الـ volumes الحساسة في الـ compose.
• threshold 50GB للتنبيه: الرقم ده مبني على فرضية إن السيرفر الطبيعي عندك بيستهلك أقل من 50GB أسبوعيًا. لو السيرفر أكبر، ارفعها. القياسات الفعلية من 3 سيرفرات production عندي: متوسط التحرير اليومي 3–7GB، والأسبوعي 20–40GB.
• RandomizedDelaySec=15m: بتكسب عدم ضرب كل السيرفرات في نفس الثانية (مفيد لو عندك 20 سيرفر بيشيروا نفس الـ registry). بتخسر وقت تنفيذ غير ثابت بدقة.

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

لو بتشغّل CI/CD builder على نفس السيرفر، image prune -a هيمسح layers الـ base images اللي الـ builds بتعتمد عليها، وهيخلّي كل build بعدها يعيد الـ pull. في الحالة دي استبدل -a بـ --filter "label=auto-cleanup" وحط اللبل على images محددة بس. كمان لو عندك Docker Swarm بـ services قديمة متعلّقة بـ image قديم، مسحه هيكسر الـ redeploy عند restart. راجع docker image ls --filter "dangling=false" والـ services الحالية قبل ما تشغّل السكربت لأول مرة. وأخيرًا، لو سيرفر صغير أقل من 20GB disk كله، الـ pruning الأسبوعي مش هيكفي — محتاج monitoring لـ disk يوقف deploy لما يتعدى 80%.

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

افتح السيرفر دلوقتي، شغّل df -h /var/lib/docker وشوف النسبة. لو فوق 60% نفّذ السكربت يدويًا مرة أولى بـ sudo /usr/local/bin/docker-cleanup.sh وشوف كم حرّر. بعدها ابنِ الـ timer وسيبه يشتغل. بعد 3 أيام افتح journalctl -u docker-cleanup.service --since "3 days ago" وتأكد إن الرقم اليومي مستقر. لو فيه يوم حرّر أكتر من 50GB هتوصلك رسالة Discord — ده مؤشر إن deploy أو build loop عمل مشكلة تستحق التحقيق.

المصادر

• Docker docs — docker system prune: docs.docker.com/reference/cli/docker/system/prune
• Docker docs — storage drivers (overlay2): docs.docker.com/engine/storage/drivers/overlayfs-driver
• systemd.timer manual: freedesktop.org/software/systemd/man/systemd.timer
• systemd.service manual (oneshot): freedesktop.org/software/systemd/man/systemd.service
• Docker reference — docker builder prune: docs.docker.com/reference/cli/docker/builder/prune