المشكلة: صور Docker تتقادم في صمت
على VPS في بيئة الإنتاج، تعمل حاويات Docker في أغلب الأحيان لأسابيع أو أشهر دون تحديث. هذا ليس إهمالاً — ببساطة لا يوجد إشعار. صورة nginx:latest التي سحبتها في يناير لا تزال هناك في سبتمبر، تحمل الثغرات التي جرى تصحيحها في الأثناء.
تكلفة عدم التحديث موثّقة: الثغرات غير المُصحّحة في صور الأساس هي أحد أكثر مسارات الاختراق شيوعاً في بنى Docker المستضافة ذاتياً. التحديث اليدوي — الاتصال بالـVPS وتشغيل docker pull وإعادة إنشاء الحاوية — هو الممارسة الافتراضية، وهو أيضاً الأقل موثوقية: نؤجل وننسى، ونحدّث الخدمات «المهمة» فقط.
ظهر أداتان لتنظيم هذه العملية: Watchtower الذي يُؤتمت التحديث بنفسه، وDiun (Docker Image Update Notifier) الذي يُرسل تنبيهاً عند توفر صورة جديدة ويترك الإجراء لمسار النشر الخاص بك. الأداتان لا تفعلان الشيء ذاته، والخلط بين الفلسفتين قد يتسبب في توقف الإنتاج.
Watchtower: تحديث تلقائي، لكنه مؤرشف منذ نهاية 2025
يراقب Watchtower حاوياتك الجارية، ويستعلم من الـregistries على فترات منتظمة، وبمجرد توفر صورة جديدة، يسحب الـtag الجديد ويوقف الحاوية الموجودة ويُعيد إنشاءها بنفس الخيارات — volumes والمتغيرات البيئية والشبكة. كل هذا دون تدخل بشري.
ما يفعله عملياً:
- استعلام قابل للضبط بالمدة (كل N ثانية) أو بتعبير cron
- دعم الـregistries الخاصة مع المصادقة
- وضع WATCHTOWER_NOTIFICATIONS لاستقبال التنبيهات دون تنفيذ التحديثات
- تصفية بـlabels Docker لتضمين أو استبعاد حاويات محددة
الخطر في بيئة الإنتاج حقيقي. إذا أدخلت صورة :latest تغييراً غير متوافق في الـAPI أو سلوكاً كاسراً، فسيعيد Watchtower إنشاء حاويتك بهذه الصورة — دون اختبار، دون نافذة صيانة، وربما الساعة 3 فجراً. تعيد الحاوية تشغيلها بالإصدار الخاطئ، والاكتشاف يحدث عبر تنبيه مراقبة أو مكالمة دعم.
تحديث مهم حول الوضع: تم أرشفة مستودع Watchtower على GitHub من قِبل مشرفيه في أواخر 2025. أصبح للقراءة فقط. آخر إصدار منشور هو v1.7.1. يظل المشروع وظيفياً وتستمر صور Docker الموجودة في العمل، لكنه لن يتلقى بعد الآن إصلاحات أمنية ولا ميزات جديدة ولا دعماً لإصدارات Docker المستقبلية. لأداة دورها تحديث صورك، المفارقة لافتة.
بالنسبة لبيئات التطوير أو الـhomelabs حيث تتفوق الراحة على الاستقرار، يظل Watchtower خياراً مشروعاً. بالنسبة للإنتاج، أرشفته تعزز استنتاجاً كان قائماً بالفعل: التحديث التلقائي بدون pipeline تحقق هو خطر تشغيلي.
Watchtower في وضع notify-only
إذا كنت تستخدم Watchtower بالفعل وتريد تعطيل التحديثات التلقائية مع الاحتفاظ بالتنبيهات، عيّن المتغير WATCHTOWER_MONITOR_ONLY=true. الحاوية تراقب الصور وترسل تنبيهات لكنها لا تتصرف. هذا إعداد انتقالي مفيد إذا كنت تنتقل إلى Diun.
Diun: تنبيهات فقط، أنت تحتفظ بالتحكم
يعالج Diun (Docker Image Update Notifier) المشكلة من الجهة الأخرى: يراقب صورك في الـregistries ويرسل إليك إشعاراً عند توفر إصدار جديد. لا يتصرف. حاوياتك تستمر في العمل دون تغيير — قرار التحديث يبقى في مسار نشرك.
مرخّص تحت MIT، Diun في تطوير نشط: الإصدار la version actuelle نُشر في مؤخرًا. يغطي المشروع مجموعة واسعة من المصادر (Docker وContainerd وKubernetes وSwarm وNomad وDockerfile وملف تهيئة) وقنوات الإشعار.
قنوات الإشعار المدعومة:
- البريد الإلكتروني، Slack، Telegram، ntfy، Gotify
- Microsoft Teams، Discord، webhooks عامة
- Healthchecks.io لمراقبة الـwatcher نفسه
ما لا يفعله Diun:
- لا يسحب أي صورة أبداً
- لا يُعيد تشغيل أي حاوية أبداً
- لا يُعدّل أي ملف تهيئة
هذه الفلسفة تحديداً هي ما يجعله مناسباً للإنتاج. عندما يُشير Diun إلى توفر صورة جديدة، يمكنك تشغيل مسار النشر المعتاد — مع اختباراته ونسخته الاحتياطية المسبقة ونافذة الصيانة. تبقى في وضع محكوم.
كذلك Diun متوافق مع stacks المُدارة بأدوات مثل Portainer وCoolify وDokploy: يراقب الصور دون التدخل في تنظيمها.
متى تختار هذا أو ذاك
مرّر الجدول أفقيًا
| السياق | Watchtower | Diun |
|---|---|---|
| بيئة تطوير / staging | مقبول (للراحة) | مبالغ فيه |
| إنتاج بـtags موثوقة (ليس :latest) | تجنّب — يُعيد الإنشاء على نفس الـtag | موصى به |
| إنتاج مع تبعيات API خارجية | محفوف بالمخاطر دون اختبار مسبق | موصى به |
| Homelab / خدمات شخصية | عملي | جيد إذا كانت التنبيهات نشطة |
| Stack مُدار بـCoolify أو Dokploy أو Portainer | تعارض محتمل مع المُنسّق | موصى به |
| مشروع بدون pipeline نشر | مقبول مع monitor-only | موصى به مع ntfy/Slack |
تثبيت Diun على VPS: مثال عملي
يستغرق تثبيت Diun بضع دقائق مع Docker Compose. المثال التالي يراقب جميع الحاويات على socket Docker المحلي ويرسل إشعارات عبر ntfy.
نشر Diun على VPS الخاص بك
إنشاء ملف docker-compose.yml
أنشئ مجلداً مخصصاً وملف Compose:
mkdir -p /opt/diun && cd /opt/diunمحتوى ملف
docker-compose.yml:services: diun: image: crazymax/diun:latest restart: unless-stopped volumes: - /var/run/docker.sock:/var/run/docker.sock - ./data:/data environment: - TZ=Europe/Paris - LOG_LEVEL=info - DIUN_WATCH_WORKERS=20 - DIUN_WATCH_SCHEDULE=0 */6 * * * - DIUN_PROVIDERS_DOCKER=true - DIUN_PROVIDERS_DOCKER_WATCHSTOPPED=true - DIUN_NOTIF_NTFY_ENDPOINT=https://ntfy.example.com - DIUN_NOTIF_NTFY_TOPIC=diun-updatesاستبدل
ntfy.example.com بعنوان URL لنسختك من ntfy (مستضافة ذاتياً على نفس الـVPS أو خارجية).تفعيل المراقبة بالـlabels (اختياري)
بشكل افتراضي، يراقب Diun جميع الحاويات. للتحكم الأدق، انتقل إلى وضع label:
- DIUN_PROVIDERS_DOCKER_WATCHBYDEFAULT=falseثم أضف الـlabel على الحاويات التي تريد مراقبتها:
labels: - "diun.enable=true"هذا النهج مفيد لاستبعاد حاويات النظام (proxies، قواعد البيانات) من الإشعارات، ومراقبة التطبيقات فقط.
التشغيل والتحقق
docker compose up -d docker compose logs -f diunيُجري Diun مسح اكتشاف أولي عند بدء التشغيل. تؤكد السجلات الصور المكتشفة ودورة المراقبة التالية. يمكن تشغيل إشعار اختباري بالأمر:
docker compose exec diun diun notif testتشغيل التحديث من مسار النشر الخاص بك
عندما يرسل Diun إشعاراً، يجب ألا يتم التحديث يدوياً. النهج الصحيح هو تشغيل مسار النشر المعتاد — webhook Gitea أو GitHub Action أو job بـWoodpecker يسحب الصورة الجديدة ويُشغّل الاختبارات ويُعيد إنشاء الحاوية.
إذا لم يكن لديك pipeline بعد، الحد الأدنى العملي هو سكريبت يُستدعى من webhook النتفي:
#!/bin/bash # update-container.sh <container_name> CONTAINER=$1 docker compose -f /opt/${CONTAINER}/docker-compose.yml pull docker compose -f /opt/${CONTAINER}/docker-compose.yml up -dالأساسي هو أن يكون التحديث مُشغَّلاً بشكل مقصود، وليس صامتاً.
المضي قُدُماً: تثبيت الإصدارات والبقاء في السيطرة
التحديث التلقائي بدون tag ثابت هو الخطر الحقيقي — سواء استخدمت Watchtower أو pipeline مُشغَّل بـDiun. الـtag :latest هو alias يمكن أن يشير إلى أي إصدار ينشره المطوّر. تحديث :latest قد يُدخل تغييراً كاسراً دون أن يتغير شيء في تهيئتك.
الممارسة الموصى بها في مجتمع Docker:
ثبّت الإصدارات في ملفات docker-compose.yml في بيئة الإنتاج:
# تجنّب في الإنتاج
image: nginx:latest
# استخدم tag إصدار محدد
image: nginx:1.27aحتفظ بـ:latest لبيئات التطوير والـstaging، حيث يمكن اكتشاف الانحدار قبل أن يمس الإنتاج.
مع الصور ذات الإصدارات، يكتشف Diun الإصدارات الجديدة (الـtags الجديدة) ويُخطرك — تختار الإصدار للترقية إليه، تُحدّث docker-compose.yml، وتنشر بتحكم كامل. هذا ما تسميه قائمة تحقق Docker Compose للإنتاج «الإعلان الصريح عن تبعياتك».
إذا كنت تُدير عدة حاويات على نفس الـVPS، فأداة مراقبة السجلات مثل Dozzle تُكمل Diun بشكل مفيد: Diun يراقب الصور في المراحل الأولى، Dozzle يراقب سجلات الحاويات بعد التحديث.
Diun يراقب أيضاً الصور المتوقفة
بشكل افتراضي، يتجاهل Diun الحاويات المتوقفة. فعّل DIUN_PROVIDERS_DOCKER_WATCHSTOPPED=true لمراقبة صور الحاويات المتوقفة أيضاً — مفيد إذا كنت تُدير خدمات batch أو حاويات صيانة تُعيد تشغيلها بشكل دوري.
ما يجب استخلاصه من هذه المقارنة
- Watchtower يتصرف دون أن يطلب رأيك — مفيد في التطوير، محفوف بالمخاطر في الإنتاج، ومؤرشف منذ أواخر 2025.
- Diun يُخبر دون أن يتصرف — متوافق مع أي pipeline نشر موجود ومُصان بنشاط (la version actuelle).
- للإنتاج، Diun مقرون بمسار نشرك هو الخيار الأكثر متانة.
- تثبيت الإصدارات في docker-compose.yml يبقى الأساس — لا Watchtower ولا Diun يُعوّضان عن إدارة الـtags الصريحة.
- إذا كان Watchtower مثبتاً لديك، وضع
WATCHTOWER_MONITOR_ONLY=trueهو انتقال فوري إلى سلوك أكثر أماناً.
