لماذا Komodo بدلاً من Portainer أو Dockge؟
Portainer وDockge واجهتا إدارة لخادم واحد: تقرآن socket Docker المحلي وتعرضان ما يعمل على تلك الآلة فقط. بمجرد امتلاكك خادمين أو أكثر، تحتاج إلى تبويبين، وأن تتذكر أي خدمة تعمل أين، وتكرار كل تغيير يدوياً. يكسر Komodo هذا الحاجز ببنية Core/Periphery: Core مركزي يُشغّل وكلاء Periphery خفيفة على كل آلة. تنشر وتعيد التشغيل وتحدّث أي حزمة من واجهة واحدة، مع سجل كامل بمن فعل ماذا ومتى.
ما يضيفه Komodo فوق إدارة الحاويات
- GitOps أصلي — اربط مستودع Git، عرّف Procedure نشر، وشغّلها تلقائياً عند كل
git pushعبر webhook HMAC. - Procedures قابلة لإعادة الاستخدام — سلسل سحب الصورة وترحيل قاعدة البيانات وإعادة تشغيل الحزمة وإشعار Slack في workflow واحد قابل للإصدار.
- Docker Swarm — أدِر خدمات Swarm والنسخ والتحديثات المتدحرجة من نفس واجهة حزم Compose.
- تنبيهات Slack/Discord أصلية — أعدّ قنوات تنبيه لإخفاقات النشر والحاويات الموقوفة والموارد الحرجة.
- RBAC متعدد المستخدمين — امنح صلاحيات دقيقة حسب الدور (viewer, builder, deployer) دون مشاركة حساب المسؤول.
- API REST كاملة — أتمتة النشر من خط CI/CD الخاص بك (GitHub Actions, Woodpecker, Forgejo) دون المرور بالواجهة الرسومية.
بنية Core/Periphery في الممارسة
Core هو العقل: يخزّن الإعدادات في FerretDB (طبقة متوافقة مع MongoDB)، ويعرض واجهة الويب على المنفذ 9120 ويستقبل الـ webhooks. وكلاء Periphery هم الأذرع: كل منها يعمل على خادم هدف، ويُوكّل socket Docker للآلة إلى Core عبر قناة مشفّرة وينفّذ الأوامر التي يرسلها Core. يضمن زوج المفاتيح غير المتماثل المولَّد عند التهيئة أن Core الخاص بك فقط يستطيع التحكم بوكلائك — لا أسرار إضافية تحتاج لإدارتها.
نشر Komodo على خادم VPS ServOrbit
طلب الخادم الافتراضي
خادم افتراضي بـ 1 vCPU / 1 GB RAM على Ubuntu 24.04 LTS كافٍ لمستوى التحكم في Komodo. يستهلك Core Rust أقل من 256 MB في حالة الخمول. إذا كنت تخطط لتشغيل خدمات أخرى على نفس الخادم، فيُنصح بـ 2 GB RAM.
النشر من marketplace ServOrbit
في espace client ServOrbit، اذهب إلى Marketplace ← نشر التطبيقات وـDevOps ← Komodo وانقر Deploy. أدخل نطاقك أو نطاقاً فرعياً — مطلوب لـ
KOMODO_HOST. يولّد playbook تلقائياً أسرار JWT وزوج مفاتيح Core/Periphery وكلمة مرور المسؤول، ثم يشغّل الخدمات.تسجيل الدخول والتحقق من الوكيل المحلي
افتح
https://your-domain.com:9120وسجّل الدخول بـ adminوكلمة المرور المعروضة في espace client. في قائمة Servers يجب أن ترى خادم 'Local' مسجّلاً بالفعل — هذا هو وكيل Periphery على خادم الاستضافة. غيّر كلمة مرورك من إعدادات الحساب في أول جلسة.ربط خادم بعيد عبر Periphery
على كل خادم افتراضي إضافي لإدارته، ثبّت وكيل Periphery:
docker run -d --restart=unless-stopped --network host -v /var/run/docker.sock:/var/run/docker.sock ghcr.io/moghtech/komodo-periphery:latest. ثم في Komodo، اذهب إلى Servers ← Add Server، أدخل عنوان IP والمنفذ 8120. يظهر أسطول خوادمك فوراً في لوحة التحكم.إنشاء أول حزمة من marketplace
في Komodo، اذهب إلى Stacks ← New Stack. اختر الخادم الهدف، والصق YAML لـ Docker Compose أو أشر إلى مسار مستودع Git، وانقر Deploy. يكتب Komodo الملف على الخادم البعيد، يشغّل
docker compose up -dويعرض السجلات في الوقت الفعلي.إعداد تنبيهات Slack أو البريد الإلكتروني
في Komodo، اذهب إلى Alerters ← New Alerter. اختر النوع (Slack أو Discord أو بريد إلكتروني) والصق رابط webhook أو عنوان الوجهة. ثم اربط المنبّه بمواردك عبر قسم Alerts في كل مورد. تصل الإشعارات فور حدوث إخفاق في النشر أو إيقاف حاوية.
إعداد خط أنابيب GitOps
أضف webhook في مستودع GitHub يشير إلى
https://your-domain.com/api/webhook/komodoمع سر HMAC المعرّف في Komodo. أنشئ Procedure مع خطوات النشر. سيُشغّل كل git pushخط الأنابيب تلقائياً بعد التحقق من التوقيع.دمج CI/CD عبر API REST
يعرض Komodo API REST كاملة على
/api. من GitHub Actions، أطلق النشر باستدعاء POST /api/execute/procedure/<name>ورمز API الخاص بحساب الخدمة. يتيح لك هذا الدمج تسلسل الاختبارات وبناء الصور والنشر في workflow واحد.
GitOps مع webhooks: النشر عند كل push
تقوم دورة GitOps في Komodo على ثلاثة مكوّنات: مستودع Git، وwebhook HTTP، وProcedure. في GitHub، أنشئ webhook في Settings ← Webhooks، وأشر إلى https://your-domain.com/api/webhook/komodo، واختر نوع المحتوى application/json وعرّف سراً. في Komodo، في قسم Webhooks لـ Stack أو Procedure، الصق هذا السر ذاته — يحسب Komodo HMAC SHA-256 لكل حمولة واردة ويرفض الطلبات التي لا تتطابق توقيعاتها.
تسلسل Procedure النشر النموذجي ثلاثة إجراءات: PullImage (تحميل أحدث صورة)، DeployStack (إعادة إنشاء الحاويات)، ثم SendAlert (إخطار قناة Slack). إذا فشلت أي خطوة، يوقف Komodo Procedure ويرسل الخطأ كاملاً إلى منبّهك.
تفصيل مهم: يتحقق Komodo من الفرع المدفوع مقابل الفرع المُعدّ في Stack قبل الإطلاق. push على فرع ميزة لن يُطلق نشر إنتاج، حتى لو كان webhook يستهدف نفس URL. أعدّ Stack لكل بيئة (staging على dev، الإنتاج على main) وستحصل على خط ترقية آلي كامل.
إنشاء Procedure في Komodo: سحب، ترحيل، إعادة تشغيل
إنشاء Procedure
في Komodo، اذهب إلى Procedures ← New Procedure. أعطها اسماً (
deploy-app) واختر الخادم الهدف. Procedure هي قائمة مرتبة من الخطوات — لكل خطوة نوع (PullImage, DeployStack, RunCommand, SendAlert) ومعاملات.إضافة خطوة PullImage
انقر Add Step ← PullImage. أدخل اسم الصورة (مثلاً
ghcr.io/myorg/myapp:latest) والخادم الذي ستُسحب عليه. إذا كانت صورتك في registry خاص، أضف بيانات الاعتماد في Settings ← Registries قبل هذه الخطوة.إضافة أمر الترحيل
انقر Add Step ← RunCommand. في حقل Command، أدخل أمر الترحيل لتشغيله داخل الحاوية. فعّل خيار 'Stop on error': إذا فشل الترحيل، تتوقف Procedure قبل إعادة تشغيل الخدمة، مما يمنع ترك تطبيق بمخطط بيانات غير متسق.
إضافة إعادة تشغيل الحزمة
انقر Add Step ← DeployStack واختر Stack المستهدفة. يشغّل Komodo
docker compose up -d --pull neverويعيد إنشاء الحاويات المعدّلة. متغيرات البيئة المعرّفة في Stack تُمرَّر تلقائياً.إضافة إشعار الانتهاء
انقر Add Step ← SendAlert واختر منبّه Slack أو Discord الخاص بك. يمكنك تضمين متغيرات السياق في الرسالة (
{{ procedure.name }}، {{ server.name }}) لتحديد أي Procedure على أي خادم أُنجزت للتو.
Komodo مقابل Portainer مقابل Dockge
مرّر الجدول أفقيًا
| الميزة | Komodo | Portainer CE | Dockge |
|---|---|---|---|
| خوادم متعددة أصلياً | ✅ Core/Periphery غير محدودة | ⚠️ وكلاء Edge (مدفوع) | ❌ مضيف واحد فقط |
| GitOps / webhooks | ✅ أصلي، HMAC محقَّق | ❌ غير أصلي | ❌ غير أصلي |
| Procedures / أتمتة | ✅ محرك مدمج | ⚠️ محدود CE | ❌ لا |
| API REST | ✅ كاملة | ✅ كاملة | ❌ لا |
| تنبيهات أصلية | ✅ Slack وDiscord والبريد | ⚠️ جزئي CE | ❌ لا |
| سجل المراجعة | ✅ جميع العمليات | ⚠️ جزئي CE | ❌ لا |
| الرخصة / السعر | GPL-3.0، مجاني | Zlib (CE مجاني) / Business مدفوع | MIT، مجاني |
استكشاف الأخطاء: المشكلات الشائعة وحلولها
وكيل Periphery غير متاح. الخطأ الأكثر شيوعاً عند إضافة خادم جديد. تحقق أولاً من أن جدار الحماية على الخادم البعيد يسمح بالاتصالات الواردة على المنفذ 8120 من IP الخاص بـ Core. ثم تحقق من أن قيمة KOMODO_HOST لوكيل Periphery تتطابق مع IP أو النطاق الذي يستخدمه Core للوصول إليه.
فشل سحب الصورة. يُرجع Komodo هذا الخطأ عندما لا يكون registry الخاص متاحاً أو تكون بيانات الاعتماد مفقودة. أضف بياناتك في Settings ← Registries قبل إطلاق السحب. إذا كانت الصورة عامة وظل الخطأ قائماً، تحقق من وصول الخادم الهدف إلى الإنترنت على المنفذ 443.
Webhook لا يُطلَق. سببان رئيسيان: السر HMAC المعدّ في Komodo لا يطابق ذلك المُدخَل في GitHub، أو أن URL الخاص بـ Core غير متاح من خوادم GitHub. تحقق من علامة التبويب 'Recent Deliveries' في GitHub لرؤية كود HTTP المُعاد — يشير 401 إلى سر خاطئ، بينما يشير timeout إلى مشكلة شبكة. تحقق أيضاً من أن فرع الـ push يطابق الفرع المُعدّ في Stack أو Procedure.
بطء الإقلاع الأول (FerretDB). يُجري FerretDB تهيئة داخلية لقاعدة البيانات عند الإطلاق الأول، مما قد يستغرق 30 إلى 60 ثانية قبل أن تستجيب واجهة Komodo. إذا رأيت خطأ اتصال مباشرة بعد النشر، انتظر دقيقة وأعد تحميل الصفحة قبل تشخيص مشكلة تثبيت.
Komodo + Dockge: الأفضل من العالمين
Komodo وDockge لا يتعارضان. Dockge رائع لتحرير ملفات Compose بشكل تفاعلي على آلة واحدة (واجهة YAML مع تلوين الصياغة). Komodo يتولى التنسيق متعدد الخوادم ونشر Git والـ workflows. انشر Dockge عبر Komodo على آلات التطوير، واستخدم Komodo لتنسيق نشر الإنتاج.
