كل عملية push تعني الطقوس نفسها: تسجيل الدخول عبر SSH، وسحب المستودع، وإعادة تشغيل حزمة Compose، على أمل ألا يكون شيء قد تعطل، ومحاولة تذكّر ما إذا كنت قد شغّلت الترحيل. هذه الدورة اليدوية تنجح إلى أن تحتاج إلى عمليات نشر قابلة للتكرار، أو سجل واضح لما يعمل فعليًا، أو تعافيًا من الانحراف.
Doco CD إجابة مباشرة على ذلك. إنه خدمة صغيرة مكتوبة بلغة Go تراقب مستودع Git وتطبّق تغييرات Compose عند كل push: عبر webhook أو الاستطلاع الدوري، والخيار لك. يقوم ArgoCD وFlux بالأمر نفسه في Kubernetes، لكن Doco CD يتجاوز Kubernetes لأنه لا يحتاج إلى مستوى تحكم.
تغطي هذه المراجعة ما يفعله Doco CD وما لا يفعله، وكيف يقارن بـ Komodo ووضع GitOps في Portainer وDokploy وسكربت بسيط يعتمد على GitHub Actions + SSH. في النهاية ستعرف ما إذا كان يناسب بيئتك وما البديل إن لم يكن كذلك.
الخلاصة السريعة
- Doco CD وكيل GitOps صغير الحجم ومصمَّم أصلًا لـ Compose: يراقب مستودع Git (مثل GitHub وGitLab وGitea وForgejo وغيرها) ويوفّق حالة حزمتك عند أي تغيير.
- الدعم المدمج لمزوّدي الأسرار الخارجيين، إلى جانب التشفير المعتمد على SOPS، هو ما يميّزه عن كتابة سكربت نشر خاص بك.
- يقدّم نفسه، بحسب ملف README الخاص به، بوصفه "بديلًا بسيطًا لـ Portainer أو ArgoCD في Docker". وهذا التوصيف قريب من الصواب.
- القيود الحقيقية: مالك واحد للشيفرة، وترقيم إصدارات ما قبل 1.0، وغياب واجهة لإدارة أسطول الخوادم، وحالة توفيق لا يُعاد بناؤها إلا بعد الاستطلاع التالي أو حدث webhook التالي.
- اخترْه إذا كنت تشغّل مضيفًا واحدًا أو بضعة مضيفات بـ Compose وتريد أن يكون Git مصدر الحقيقة دون واجهة. اختر Komodo لأساطيل الخوادم، وPortainer إذا أردت واجهة، وDokploy لتجربة أقرب إلى PaaS، وGitHub Actions + SSH حين يتعلق الأمر فعلًا بخدمة واحدة على مضيف واحد.
الفجوة التي يحاول Doco CD سدّها
ثمة منطقة وسطى غريبة أمام كل من يشغّل Docker Compose في عام 2026. فأدوات GitOps الكبرى مثل Argo CD وFlux تستهدف Kubernetes، بينما يعتمد Watchtower على استطلاع سجل الصور فيتفاعل مع تغيّر الصور بدل تطبيق حالة Compose مُدارة بالإصدارات. وقد جرت أرشفة المستودع في 17 ديسمبر 2025، وهو يذكر الآن أن المشروع لم يعد تحت الصيانة.
استخدام GitHub Actions مع خطوة نشر عبر SSH يفي بالغرض. ولخدمة واحدة على مضيف واحد، هذا هو الخيار الصحيح. تبدأ المتاعب عند إضافة مضيف ثانٍ أو حزمة ثانية، أو عندما تريد معرفة أي إصدار من الشيفرة منشور حاليًا. ستظل تحصل على سجلات سير العمل، لكن دون توفيق أصلي على مستوى Compose، ودون تعافٍ من الانحراف، ودون رؤية دائمة لما إذا كان المضيف ما زال مطابقًا للمستودع.
أما وصف Doco CD لنفسه، المأخوذ مباشرة من ملف README هو أنه "بديل بسيط لـ Portainer أو ArgoCD في Docker". وهذا التوصيف هو بيت القصيد: صغير، ومصمَّم أصلًا لـ Compose، وبلا Kubernetes، وبلا واجهة تحتاج إلى صيانة، وبلا مستوى تحكم مركزي يستنزف انتباهك. إن كنت لا تشغّل K8s ولم ترغب في ذلك أصلًا، فهذه هي الفئة التي كنت تبحث عنها.
كيف يعمل Doco CD فعليًا
Doco CD ملف تنفيذي واحد مكتوب بلغة Go يعمل داخل حاوية Docker، ويراقب مستودع Git، ويطبّق تغييرات Compose عندما تتغيّر حالة المستودع. هذه هي الفكرة كلها. أما التفاصيل المثيرة فتكمن في القيم الافتراضية والتكاملات.
المشغّلات. هناك وضعان: webhook أو الاستطلاع الدوري. الوضع الأول شبه فوري لكنه يحتاج منفذًا مكشوفًا، أو بشكل أكثر واقعية وكيلًا عكسيًا أمام Doco CD. أما الاستطلاع فهو جلب دوري: متأخر قليلًا، ولا يتطلب أي منفذ وارد. الاستطلاع هو الخيار الافتراضي الأبسط، ووفق الوثائق الرسمية الوثائق الرسمية فكلا الوضعين مدعوم بالدرجة نفسها. اختر بناءً على ما إذا كان مضيفك يملك نقطة وصول عامة، وعلى السرعة التي تحتاجها في النشر.
إعدادات لكل مستودع. يوضَع ملف .doco-cd.yaml (أو .doco-cd.yml) في جذر المستودع إلى جانب ملف Compose. الحقل الإلزامي الوحيد هو اسم عملية النشر. وإليك أبسط صورة للإعدادات:
# .doco-cd.yaml
name: my-stack
# Everything below is optional. These are the defaults.
timeout: 180 # seconds
remove_orphans: true
prune_images: true
force_recreate: falseهذه هي القيم الافتراضية الموثّقة: مهلة 180 ثانية، وحذف الحاويات اليتيمة، وتنظيف الصور، ودون إعادة إنشاء قسرية.
الاكتشاف التلقائي. عند تفعيل الاكتشاف التلقائي، يفحص Doco CD المجلدات الفرعية بحثًا عن ملفات Compose، فيستطيع مستودع واحد أن يحتضن عدة حزم. كما يدعم عدة إعدادات نشر داخل ملف واحد، مكتوبة كمستندات YAML يفصل بينها سطر من ثلاث شرطات. أما القيم الافتراضية للتنظيف فمحافظة، ويستحق الأمر قراءتها قبل الاعتماد عليها:
| الإعداد | افتراضي | ماذا يعني ذلك |
|---|---|---|
delete | false | يُترك النشر القديم كما هو عندما يختفي تطبيقه من مجلد العمل. |
remove_volumes | false | تبقى الأقراص الافتراضية سليمة عند حذف حزمة اكتُشفت تلقائيًا. |
remove_images | true | تُحذف الصور غير المستخدمة عند حذف حزمة اكتُشفت تلقائيًا. |
بعبارة أخرى، لا شيء يُهدم من وراء ظهرك ما لم تفعّل الحذف بنفسك، وحتى حينها تكون أقراص بياناتك آخر ما يُمس.
مزوّدو Git المدعومون. المدعوم منها: GitHub وGitLab وGitea وForgejo وGogs وAzure DevOps. ويشكّل Azure DevOps الاستثناء فيما يخص الـ webhooks لأن Azure Service Hooks غير مدعومة. ودعم Gitea وForgejo يهمّ إن كنت تستضيف منصة الشيفرة لديك بنفسك.
Docker Swarm. مدعوم كهدف للنشر. أما ما تشير إليه صفحة إعدادات النشر صراحةً فهو: أن التوفيق في وضع Swarm لا يفحص إعادة تشغيل الحاويات ولا حالة السلامة، وأن تنظيف الصور غير مدعوم في Swarm. فإن كان Swarm هو هدفك، ستحصل على عمليات نشر لا على توفيق كامل لحالة السلامة.
التوفيق بين الحالتين. افتراضيًا هناك حدّ بخمس عمليات إعادة تشغيل ضمن نافذة مدتها 300 ثانية، وهو موجود لمنع فحوص السلامة المتذبذبة من الدوران إلى ما لا نهاية. المستودع نفسه مع مرجع مختلف يعمل بالتتابع، والمستودع نفسه مع المرجع نفسه يعمل بالتوازي. هذه النقطة الأخيرة دقيقة لكنها مفيدة: عمليات النشر المتعددة للمرجع نفسه لا تصطف خلف بعضها.
مزوّدو أسرار خارجيون مدمجون. هذا من أقوى الأسباب لتفضيل Doco CD على سكربت نشر بسيط: فهو يدعم AWS Secrets Manager وBitwarden Secrets Manager وBitwarden Vault / Vaultwarden و1Password و1Password Connect وInfisical وOpenBao وWebhook. وبشكل منفصل، يدعم التشفير المعتمد على SOPS لبيانات النشر الحساسة. هكذا تحصل على مخرج نظيف من ملفات env المكشوفة داخل Git، دون أن تبني بنفسك مسار استخراج الأسرار بأكمله.
بقية الميزات. يوفّر Doco CD مقاييس Prometheus وجدولة المهام والإشعارات وصورة حاوية distroless ورخصة Apache-2.0. ووفقًا لـ سجل الإصداراتسجل الإصدارات، وحتى 20 أغسطس 2026، فإن v0.109.2 هي أحدث إصدار مستقر وv0.110.0-rc.1 هي أحدث إصدار تجريبي.
تنتهي مهمة Doco CD عند "تطبيق البيان"، وما بعد ذلك هو Docker عادي. أوامر السجلات الخاصة بـ Compose هي وسيلتك لمعاينة ما يعمل فعليًا.
نصيحة عملية بشأن الأسرار. إذا كان مستودعك الخاص لا يزال يحتوي ملفات env مكشوفة، فابدأ بمزوّدي الأسرار الخارجيين في Doco CD أو بدعمه لـ SOPS. الهدف بسيط: إخراج الأسرار المكشوفة من Git مع إبقاء قدرة عمليات النشر على جلب القيم وقت التشغيل.
ابنِ على خادم Linux VPS بوصول root وتخزين NVMe وقوة AMD EPYC.
عرض باقات Linuxأين يقصّر Doco CD
لكل أداة حدودها، وحدود Doco CD تستحق أن تعرفها قبل أن تنفق عطلة أسبوع كاملة في إعداده.
مالك واحد للشيفرة. يُسنِد ملف CODEOWNERS في المستودع كل المسارات إلى kimdre. لا يزال إيقاع الإصدارات متكررًا، لكن الحوكمة متركّزة في شخص واحد.
ما قبل الإصدار 1.0. لا يزال Doco CD يستخدم ترقيم إصدارات 0.x، لذا ثبّت إصدارًا مجرَّبًا واقرأ ملاحظات الترقية قبل الطرح. وتوضّح مسألة GitHub رقم #851 ، وهي مغلقة الآن، سببَ ذلك: إذ أجبر Docker v29 المشروعَ على الابتعاد عن وحدات Go الخاصة بـ Docker والمهملة.
لا صدفة أوامر داخل حاوية Doco CD. لأسباب أمنية، لا يوفّر Doco CD بيئة صدفة أوامر ولا ينفّذ سكربتات عشوائية على المضيف. لذا يجب تنفيذ المهام السابقة واللاحقة للنشر عبر حاويات تهيئة أو حاويات جانبية أو خطافات دورة حياة Compose، وهو ما يضيف إعدادات مقارنةً بأدوات تشغّل سكربت النشر مباشرةً.
فقدان الحالة عند إعادة التشغيل. تُحفظ حالة التوفيق في الذاكرة. وعندما يُعاد تشغيل Doco CD، لا يُعاد بناء تلك الحالة إلا بعد الاستطلاع التالي أو حدث webhook التالي، فتتوقف طول الفجوة على فترة الاستطلاع لديك أو على موعد وصول webhook آخر.
لا واجهة لإدارة أسطول الخوادم. لم يعد العمل بعدة مضيفات يتطلب وكيلًا لكل مضيف. فمنذ الإصدار v0.102.0 صار بإمكان إعدادات النشر أن تستهدف سياقات Docker البعيدة، بما فيها سياقات SSH، ويمكن لمستودع واحد أن يعرّف عدة أهداف نشر. ولا يزال تشغيل نسخة من Doco CD لكل مضيف خيارًا صالحًا، لكن بات بإمكان نسخة مركزية أن تنشر على مضيفات Docker بعيدة. أما ما ينقص Doco CD حتى الآن فهو واجهة إدارة الأسطول التي يقدّمها Komodo وجرد المضيفات المركزي.
استهلاك الذاكرة والمعالج غير موثّق بالأرقام. تصف الوثائق الرسمية المتطلبات بأنها "ضئيلة" لكنها لا تنشر أي رقم مرجعي. فحدّد حجم الـ VPS بحسب التطبيقات التي سيشغّلها، واترك هامشًا تشغيليًا، وتحقّق من استهلاك Doco CD الفعلي في بيئتك أنت.
نصيحة عملية بشأن تعدد المضيفات. استخدم سياق Docker وهدف نشر منفصلين لكل مضيف، وقيّد الوصول عبر SSH، واجعل أسرار الـ webhook أو الـ API فريدة لكل حالة. وإن كنت تفضّل وكلاء معزولين، فتشغيل نسخة من Doco CD لكل مضيف يبقى خيارًا صالحًا.
Doco CD في مواجهة البدائل
الأدوات الأربع الأخرى التي أضعها في القائمة القصيرة تحاول جميعها حل مسألة "نشر Compose تلقائيًا من Git"، لكن بمقايضات شديدة الاختلاف. القرار ليس هل تفعل ذلك أم لا، فقد حسمت هذا سلفًا. القرار هو أي شكل من الأدوات يناسب بيئتك. وإليك المقارنة جنبًا إلى جنب.
| الأداة | المشغّل | نموذج الأجهزة المتعددة | الأسرار | واجهة الويب | الرخصة |
|---|---|---|---|---|---|
| Doco CD | webhook أو استطلاع دوري | سياقات Docker بعيدة، دون واجهة لإدارة الأسطول | مزوّدون خارجيون بالإضافة إلى SOPS | لا شيء | Apache-2.0 |
| Komodo | webhook بالإضافة إلى مزامنة مجدولة | خدمة Core مركزية بالإضافة إلى وكلاء Periphery | إدارة المتغيّرات والأسرار | نعم | GPL-3.0 |
| Portainer (CE/BE) | webhook أو استطلاع دوري | وكيل Portainer | محدودة، وخيارات أوسع في نسخة BE | نعم | Zlib، وشروط تجارية لنسخة BE |
| Dokploy | يُشغَّل عند الدفع | خوادم متعددة أو Docker Swarm | إدارة مدمجة للبيئات | نعم | Apache-2.0، مع مكوّنات مملوكة |
| GitHub Actions + SSH | يُشغَّل عند الدفع | ما تكتبه في السكربت | ما تكتبه في السكربت | لا شيء | لا ينطبق |
نبذة عن كل واحد منها، فالجدول يعطي الشكل والتعليق يعطي السبب:
Komodo. البديل الجاد لتعدد المضيفات. خدمة Core مركزية إلى جانب وكيل Periphery على كل جهاز، وواجهة واحدة ترى الجميع، وعمليات بناء تقودها Git إلى جانب عمليات النشر، ودعم Docker Swarm. إعداده أثقل لأنك تشغّل قاعدة بيانات ومستوى تحكم، لكنه الشكل الصحيح إن كان لديك أسطول خوادم. وKomodo هو الأنسب حين يهمّ التحكم المركزي بالأسطول.
Portainer (بنسختيه CE أو BE) مع GitOps. واجهة رسومية كاملة فوق المزامنة مع Git. وهو الخيار الصحيح حين يريد الفريق إدارة الحاويات بالنقر إلى جانب التسليم المستمر. فإن كان أحدهم سيقضي وقته في الواجهة على أي حال لقراءة السجلات وإعادة تشغيل الحاويات، فلتكن عمليات التسليم في المكان نفسه. بصمته على الموارد أثقل من Doco CD. أما OIDC/SSO وصلاحيات RBAC الدقيقة فمحجوزة خلف اشتراك Business Edition. ويغطي دليلنا لبدائل Portainer دليلنا لبدائل Portainer المشهد الأوسع لإدارة Docker.
Dokploy. بأسلوب PaaS، أي المنصة كخدمة. أداة ذات رأي واضح، تنشر تلقائيًا عند الدفع، ولها واجهة ويب لكل شيء، وتهيّئ لك Traefik مع عناوين نظيفة منذ البداية. تناسب أكثر الفرق التي تريد إحساس Heroku وتقبل التضحية بمرونة Compose الخام مقابل ذلك. وإن كنت تعاني حساسية من YAML، فهذا أخف طريق إلى "ادفع الشيفرة فينتشر التطبيق".
GitHub Actions + SSH. بلا أي بنية تحتية إضافية. فمهمة النشر تعيش داخل سير العمل الذي تملكه أصلًا. تحصل على سجلات سير العمل، لكن دون توفيق أصلي على مستوى Compose، ودون تعافٍ من الانحراف، ودون رؤية دائمة لحالة المضيف، إلا إذا بنيت تلك القطع بنفسك. مناسب تمامًا لخدمة واحدة على مضيف واحد. لكنه ينهار حالما تضيف هدفًا ثانيًا أو ترغب في معرفة ما يعمل وأين دون الدخول عبر SSH. أما بالنسبة لأبسط شريحة من القرّاء، فما زال GitHub Actions + SSH هو الجواب الصحيح.
وثمة وافد أحدث اسمه stackd ، وهو يقدّم نفسه بلغة مشابهة: "منهجية GitOps دون ضريبة Kubernetes". من المفيد أن تعرف أن هذه الفئة نشطة، لكن لا يستحق أن تفضّله على Doco CD بقرعة اليوم.
متى يكون Doco CD الخيار الصحيح (ومتى لا يكون)
اختر Doco CD حين:
- تشغّل مضيفًا واحدًا أو بضعة مضيفات بـ Docker Compose وتريد أن يكون Git مصدر الحقيقة.
- تفضّل تحرير YAML في محرّرك على التنقّل بالنقر داخل واجهة.
- تريد دعم مزوّدي الأسرار الخارجيين والتشفير المعتمد على SOPS دون أن تبني المسار كله بنفسك.
- لا تمانع مشروعًا بمشرف واحد، ما قبل الإصدار 1.0، لكنه قيد التطوير النشط.
Komodo. اخترْه حين تدير عددًا كبيرًا من المضيفات وتريد تحكمًا مركزيًا بالأسطول، أو حين تحتاج إلى عمليات بناء تقودها Git، لا مجرد عمليات نشر، تحت سقف واحد.
Portainer (بنسختيه CE أو BE). اخترْه حين يريد الفريق واجهة للعمليات اليومية على الحاويات إلى جانب التسليم المستمر، أي حين تكون الطبقة المرئية هي السبب الحقيقي وراء تفكيرك في الأداة.
Dokploy. اخترْه حين تريد تجربة نشر بأسلوب PaaS ولا تحتاج إلى التحكم الخام في Compose.
GitHub Actions + SSH. ابقَ عليه حين يتعلق الأمر بخدمة واحدة على مضيف واحد ولا تحتاج إلى توفيق ولا إلى تعافٍ من الانحراف.
لمن يقفون في تلك المنطقة الوسطى، بعد Watchtower وقبل Kubernetes، يمثّل Doco CD خيارًا خفيفًا وقويًا. رأيي: لمختبر منزلي جديد أو خدمة SaaS صغيرة، سأبدأ بـ Doco CD ما دام أسلوب العمل القائم على Git وبلا واجهة يناسبك، ثم أنتقل إلى Komodo حين يصير الجرد المركزي والصلاحيات ورؤية الأسطول متطلبات فعلية.
أيًّا كانت الأداة التي تختارها، شغّلها على VPS بنظام Linux محدَّد الحجم بحسب أحمال Compose التي سيستضيفها. Linux VPS من Cloudzy بيئة معقولة لهذا الغرض، مع صلاحيات الجذر افتراضيًا. وإن أردت تخطّي رقصة apt، يمكنك أيضًا أن تنشر Docker بنقرة واحدة من سوق التطبيقات لدينا.
كما يضمّ سوق التطبيقات لدينا صورًا جاهزة بنقرة واحدة لـ Gitea، وهو ما يتكامل معه Doco CD أصلًا. وهناك صور أيضًا لـ Komodo أيضًا، وكذلك لـ Portainer، إن قرّرت أن أحدها هو الشكل الذي تريده بدلًا من ذلك.
الأسئلة الشائعة
هل Doco CD جاهز للإنتاج؟
يمكن استخدام Doco CD في الإنتاج إذا كان مستوى المخاطرة فيه يناسب أعباء عملك. فهو قيد التطوير النشط، لكنه ما زال يستخدم ترقيم إصدارات ما قبل 1.0، وملف CODEOWNERS الخاص به يُسنِد المشروع إلى شخص واحد. ثبّت إصدارًا مجرَّبًا، واختبر الترقيات قبل طرحها، وفكّر في حوكمة أوسع إن كانت البنية التحتية حرجة.
كيف أدير عدة مضيفات باستخدام Doco CD؟
استخدم سياق Docker وهدف نشر منفصلين لكل مضيف. تستطيع نسخة واحدة من Doco CD النشر على عدة مضيفات Docker بعيدة عبر SSH أو TCP، وتبقى نسخة لكل مضيف نموذج عزل اختياريًا. واختر Komodo إن كنت تحتاج إلى جرد مركزي وصلاحيات ورؤية شاملة للأسطول.
ما الفرق بين وضع webhook ووضع الاستطلاع الدوري؟
ينشر وضع webhook فور وصول أي push إلى مستودع Git تقريبًا، لكنه يتطلب منفذًا يمكن الوصول إليه من الإنترنت أو وكيلًا عكسيًا أمام Doco CD. أما وضع الاستطلاع فيفحص المستودع وفق جدول زمني، فتتأخر عمليات النشر قليلًا لكن دون حاجة إلى كشف أي منفذ. الاستطلاع هو الخيار الافتراضي الأبسط، أما الـ webhooks فتستحق العناء إن كنت تدفع الشيفرة كثيرًا أو تحتاج إلى حلقات تغذية راجعة سريعة.
كيف يقارن Doco CD بـ Komodo؟
Doco CD أخف ولا واجهة له، ويستطيع إدارة عدة مضيفات عبر سياقات Docker البعيدة. أما Komodo فيعتمد على خدمة Core مركزية ووكلاء Periphery، ويضيف واجهة لإدارة الأسطول وعمليات بناء تقودها Git. اختر Doco CD لنشر Compose دون واجهة، واختر Komodo حين يهمّ التحكم المركزي بالأسطول.
هل يمكن أن يحلّ Doco CD محلّ Watchtower؟
بالنسبة إلى الاستخدام الذي أراده معظم مستخدمي Watchtower، أي "انشر ما هو في Git عندما يتغيّر Git"، فالجواب نعم، وهذا بالضبط ما يفعله Doco CD. أما بالنسبة إلى نموذج Watchtower الحرفي، أي استطلاع سجل الصور وسحب الصورة عند ظهور وسم جديد، فالجواب لا؛ إذ يعتمد Doco CD على Git لا على السجل. والنموذج المعتمد على Git هو الخيار الأكثر أمانًا والأسهل تدقيقًا في أي شيء يتجاوز الخدمات التجريبية.
