أطلق Arcane التحكم الكامل في الوصول المستند إلى الأدوار في 7 يونيو 2026 ضمن الإصدار v2.0.0. كما يفحص صورك بحثًا عن الثغرات المعروفة وفق جدول تحدده أنت. لم يكن أي من ذلك صحيحًا حين نشر Brandon Lee انطباعاته الأولى عن Arcane في 29 ديسمبر 2025، أي قبل أكثر من خمسة أشهر بقليل من إصدار RBAC.
هذه الفجوة هي الجزء المحرج في أي مراجعة لـ Arcane لإدارة Docker في الوقت الحالي. فالأداة وصلت بالفعل إلى الإصدار v2.10.2 الصادر في 5 سبتمبر 2026، أي بعد أقل من أسبوعين من v2.9.0. وقد أصلح الإصدار v2.10.0 تسرب نسخ GitOps المستنسخة الذي نناقشه أدناه، وأضاف سير عمل تجريبيًا باسم Convert to Compose للحاويات قيد التشغيل. وأي قائمة ميزات كُتبت قبل ذلك بأيام قليلة تصف منتجًا مختلفًا.
الخلاصة السريعة
Arcane في الإصدار v2.10.2 بديل عملي لـ Portainer للمشغّل المناسب. فهو يقدم RBAC كاملًا، وتسجيل دخول موحدًا عبر OIDC، وفحص الثغرات عبر Trivy، وإعادة النشر عبر GitOps، بلا تكلفة وبلا سقف لعدد العقد. أما Portainer فيحتفظ بهذا التسلسل الهرمي للأدوار في Business Edition بعد ثلاث عقد. 4 من 5. ما يعيقه هو قِصر عمره، لا قدراته.
- انتقل بمجرد أن تتجاوز العقدة الثالثة في Portainer وتحتاج إلى أدوار تحدد من يمكنه لمس ماذا. تحصل على ستة أدوار مدمجة، وأدوار مخصصة، وتعيين لكل بيئة على حدة، وربط مطالبات المجموعات في OIDC، دون دفع ودون عدّاد.
- فحص الثغرات مدمج في الأداة. يشغّل Arcane أداة Trivy، وهي فاحص صور مفتوح المصدر، وفق جدول cron ويخزّن النتائج لكل صورة على حدة.
- Portainer Business Edition مجاني حتى ثلاث عقد، دون قيود على الميزات. دون هذا الحد لديك بالفعل RBAC وSSO، لذا فإن حجة Arcane حول الوصول المجاني أضعف بكثير.
- لا يزال لا يوجد استيراد مباشر لحزم Portainer. يستطيع الإصدار v2.10.0 تحويل الحاويات قيد التشغيل تجريبيًا إلى مشاريع Compose، وهو ما يقلل بعض العمل اليدوي، لكنك ما زلت بحاجة إلى مراجعة ملف YAML المولَّد والتخطيط لعملية انتقال، لأن الأسماء والمنافذ المنشورة قد تتعارض ما دامت الحاويات الأصلية تعمل. انسخ وحدات التخزين احتياطيًا أولًا.
- حصّن
ENCRYPTION_KEYقبل الإنتاج، واضبطAPP_URLبشكل صحيح.ENCRYPTION_KEYلا يزال يحمل قيمة افتراضية مخصصة للتطوير، ولن يعمل تسجيل الدخول بمفاتيح المرور حتى يشيرAPP_URLإلى اسم مضيف HTTPS الذي يتصفحه المستخدمون فعلًا.JWT_SECRETلم يعد مستخدمًا، وفقًا لوثائق التثبيت الحالية. - خطأ استنفاد القرص في GitOps الذي أُبلغ عنه في v2.8.0 وv2.9.0 تم إصلاحه في v2.10.0. يقوم الإصلاح بتنظيف أدلة الاستنساخ المؤقتة المتبقية من Git بدلًا من تركها تتراكم على مضيف المدير.
- لا يزال LDAP غائبًا. تكامل الهوية يقتصر على OIDC.
كيف أُعد هذا التقييم: هذه مراجعة قائمة على الأدلة، وليست اختبارًا عمليًا. لا رعاية، ولا مقابل مادي، ولا منتج مقدَّم، ولا تواصل مع المشرف على المشروع. كل ادعاء بشأن القدرات جرى التحقق منه مقابل وثائق Arcane وملاحظات إصداراته الحالية، وكل ادعاء بشأن الموثوقية يستند إلى بلاغ مؤرخ في متتبع المشروع العام أو إلى مشغّل مُسمّى يكتب عن نشره الخاص. لم يشغّل أحد هنا Arcane لكتابة هذه المراجعة، لذا حيثما يحدّ ذلك من القراءة (كيف تبدو الواجهة، وكيف تصمد تحت حمل مستمر) يصرّح المقال بذلك بدلًا من التخمين.
ما الذي يقدمه Arcane مجانًا ولا يقدمه Portainer؟
شيء واحد في الأساس: التحكم الكامل في الوصول المستند إلى الأدوار. يمنحك Portainer CE إدارة مستخدمين أساسية، أما التسلسل الهرمي للأدوار فهو من نصيب Business Edition. يقدمه Arcane مجانًا مهما كان عدد العقد، إلى جانب فحص Trivy، وإعادة النشر عبر GitOps، ودعم Swarm، وتسجيل الدخول بمفاتيح المرور، والوكلاء البعيدين، والنسخ الاحتياطي إلى S3 المضاف في v2.9.0.
RBAC هو الجزء الذي يستحق النظر عن قرب، لأن عبارة "يدعم RBAC" تغطي أشياء مختلفة جدًا. وثائق التحكم في الوصول الخاصة بـ Arcane تصف ستة أدوار مدمجة غير قابلة للتعديل: Admin وEditor وNo-Shell Editor وDeployer وMonitor وViewer. يمكنك استنساخ أي منها إلى دور مخصص وتحديد الصلاحيات فرادى، وهي تتبع صيغة <resource>:<action> مثل containers:start. التعيينات إما عامة أو لكل بيئة على حدة، ويمكن للمستخدم أن يحمل عدة تعيينات في آن واحد. وتقدم الوثائق المثال مباشرة: Editor على prod وViewer على staging.
الجزء المهم لأي طرح لتسجيل الدخول الموحد هو أن تعيين الأدوار يمكن أن يُدار من مزود الهوية نفسه: "عند كل تسجيل دخول يقرأ Arcane مطالبة المجموعة الخاصة بالمستخدم ويعيد مزامنة تعييناته المستمدة من OIDC"، والمستخدم الموجود في عدة مجموعات مربوطة يحصل على اتحادها. هذا هو نموذج الصلاحيات الذي لم يمتلكه Portainer CE قط.
فحص الثغرات هو الجزء الثاني. وثائق الفحص الخاصة بـ Arcane تنص على أن "عمليات الفحص اختيارية، وتعمل وفق جدول cron، وتُخزَّن النتائج لكل صورة على حدة"، مع عرض النتائج في الواجهة. الإعداد الافتراضي هو الفحص يوميًا عند منتصف الليل، ويعمل trivyIgnoreUnfixed على حصر النتائج في الثغرات التي لها إصلاح معروف، ويأتي Trivy ضمن صورة أدوات مثبّتة الإصدار، لذا فإن تحديثات الفاحص ليست من مسؤوليتك.
والآن الثقل المقابل، وهو كبير. صفحة Portainer الخاصة بمقارنة CE وBE تقول إن Business Edition "مجاني إلى الأبد حتى 3 عقد. لا فترة تجريبية. لا بطاقة ائتمان. لا قيود على الميزات." وهذه هي حزمة BE الكاملة: RBAC بتسلسله الهرمي الخاص للأدوار، وOIDC، وسجلات تدقيق مع تصدير إلى Syslog، وGitOps متقدم. شروط برنامج Take 3 تصدر ترخيصًا لمدة عام يُجدَّد سنويًا دون تكلفة ما دمت عند ثلاث عقد أو أقل.
إذن لا تبدأ حسابات المستوى المجاني في الميل لصالح Arcane إلا عند العقدة الرابعة. ودون ذلك لا يوجد جدار دفع. لا يزال Arcane يقدم شيئًا عند عقدة أو عقدتين: لا مفتاح ترخيص، ولا تجديد يجب تذكره، ومشروع يمكنك تفريعه. لكن هذه ليست الحجة نفسها القائلة بأن "RBAC يكلف مالًا".
Arcane واحد من أربع أدوات تتنافس بجدية على مقعد Portainer، وتتوزع الأدوات الأخرى على خطوط مختلفة.
ما مدى موثوقية Arcane في الوقت الحالي؟
أفضل مما بدا عليه في v2.9.0، لكنه لا يزال فتيًا. سجل أخطاء Arcane يبدو كسجل مشروع نشط يصلح الأمور، وقد أُصلح خطأ استنفاد القرص الخطير في GitOps الذي أُبلغ عنه في v2.8.0 وv2.9.0 ضمن الإصدار v2.10.0 في 31 أغسطس 2026.
أبلغ أحد المشغّلين في 26 أغسطس 2026 أن مزامنة GitOps تسرّب دليل استنساخ: "gitops-<N> أدلة الاستنساخ تتراكم بمعدل نحو 1,000 يوميًا (~9 جيجابايت/يوم) ولا تُنظَّف أبدًا، حتى تملأ القرص في النهاية." وستة أيام من ذلك بلغت نحو 6,467 دليلًا و40 جيجابايت. وعندما امتلأ القرص لم يعد المدير قادرًا على الكتابة في قاعدة بيانات SQLite الخاصة به ودخل في حلقة إعادة تشغيل، بلغ فيها عدد مرات إعادة التشغيل 389 وأسقط معه اتصالات وكلاء edge واستدعاءات API. البلاغ مغلق الآن، ويأتي الإصدار v2.10.0 بإصلاح تنظيف أدلة الاستنساخ المؤقتة المتبقية من Git.
إذا كنت لا تزال على v2.8.0 أو v2.9.0: حدّث قبل الاعتماد على مزامنة GitOps المتكررة. إصلاح تسرب النسخ المستنسخة يأتي في v2.10.0.
السجل الأقدم أكثر تشجيعًا. فقد تعليق بعد التحديث بين 2.0 و2.0.1 تم حله. وخطأ كان فيه "Update Projects" يطال كل حاوية على المضيف بدلًا من حاويات المشروع المحدد أُغلق بعد دمج طلب الإصلاح PR #2289. استطلاع الصور الذي كان يتوقف بصمت في v1.13.2 أُصلح في v1.14.0. ثلاثة أخطاء، ثلاثة إصلاحات.
العدد الخام للبلاغات المفتوحة لا يقول الكثير بمفرده عن مشروع يصدر بهذه السرعة. فالمشاريع التي لا يبلّغ أحد عن أخطاء فيها ليست بذلك أكثر موثوقية.
قراءتي لا تزال أن هذه مشكلة قِصر عمر لا مشكلة قدرة. فسرعة الإصدار هي سبب إغلاق فجوتي RBAC والفحص أصلًا، وهي أيضًا سبب اضطرار v2.10.0 إلى إصلاح عيب خطير في GitOps بعد أقل من أسبوع من v2.9.0. الشيفرة الجديدة هي موضع الخطر، وتبنّيها خيار.
ما التكلفة الفعلية للانتقال من Portainer؟
نافذة توقف وبعض التنظيف اليدوي، تقريبًا. لا يزال Arcane بلا استيراد مباشر لحزم Portainer، لكن v2.10.0 يضيف إجراءً تجريبيًا باسم Convert to Compose للحاويات قيد التشغيل. فهو يولّد ملف Compose بينما تستمر الحاويات الأصلية في العمل، وهو ما يزيل جزءًا من عمل إعادة بناء YAML. لا تزال بحاجة إلى مراجعة عمليات ربط bind mount والشبكات وقيم البيئة وعملية الانتقال نفسها، وقد تتعارض الأسماء والمنافذ المنشورة حتى تتوقف الحاويات الأصلية، لذا فهذا ليس زر انتقال دون توقف.
قبل v2.10.0 كان منتدى المشروع نفسه يعكس مسارًا يدويًا بالكامل. فقد سأل مشغّل لديه أكثر من 80 حاوية موزعة على خمسة خوادم عما إذا كان الانتقال الحي ممكنًا دون إيقاف الخدمات المواجهة للويب أولًا. وجاء الرد من شخص فعل ذلك بالفعل: "لن يكون أمامك خيار سوى حذف الحاويات الحالية (وبالتالي حزم Portainer) وإعادة إنشائها من الصفر في Arcane." وتسلسله كان: إيقاف نظيف، ثم نسخ احتياطي، ثم حذف، ثم نسخ البيانات، ثم إعادة الإنشاء وإعادة النشر.
عمليًا: نسخ احتياطية لوحدات التخزين قبل لمس أي شيء، ونافذة صيانة محددة الحجم وفق عدد الحزم التي تشغّلها وكمية البيانات التي يجب نقلها معًا. إعادة إنشاء الحاويات عادةً هي الجزء السريع، أما نسخ وحدات التخزين الكبيرة وإعادة تشغيل الخدمات المعتمدة بالترتيب الصحيح فقد يطيل النافذة. ملاحظة اصطلاحية أثناء التخطيط: ما يسميه Portainer حزمة (stack) يسميه Arcane مشروعًا.
تكلفة الوقت تظهر حتى على نطاق المختبر المنزلي. فقد وصف Moises Aguirre، الذي كتب في 28 فبراير 2026 عن نقل مختبر منزلي بعيدًا عن Portainer، الأمر بأنه "عطلة نهاية أسبوع كاملة من العمل (ومواجهة شياطيني)"، وكانت الشياطين هي انحرافه الخاص: فقد اضطر إلى مراجعة كل حاوية يشغّلها وكتابة YAML لخدمات كان "قد أنشأها بالنقر فحسب". هذه تجربته لا قاعدة عامة، لكن شكلها ينطبق على غيره.
شيء واحد يجب الانتباه إليه قبل نقل ملفات Compose. ملاحظات إصدار v2.7.0 حصرت حل المتغيرات في أربعة مصادر: متغيراتك العامة في .env.global، وملف .env الخاص بالمشروع، والقيم الافتراضية المكتوبة في ملف compose نفسه، والمنطقة الزمنية واللغة المحلية من بيئة Arcane. والأثر المعلن هو أن المشروع المنشور عبر Arcane يحل متغيراته بالطريقة نفسها التي يحلها بها docker compose up في دليل المشروع. هذا سلوك أكثر صحة. لكنه يعني أيضًا أن أي شيء كان يرث قيمة بصمت من بيئة حاوية المدير نفسه سيُحل الآن إلى شيء آخر، أو إلى لا شيء، وسيفعل ذلك دون أي شكوى.
لا شيء من هذا عيب في المنتج. إنها تكلفة لمرة واحدة، يمكن التنبؤ بها بما يكفي للتخطيط لها، وهذا هو الشيء الأهم الذي تريده من أي انتقال.
ابنِ على خادم Linux VPS بوصول root وتخزين NVMe وقوة AMD EPYC.
عرض باقات Linuxما الذي يجب تحصينه قبل الإنتاج؟
مفتاح تشفير واحد، وعنوان URL العام، وTLS. ينشئ Arcane حساب مسؤول افتراضيًا عند أول تشغيل ويفرض تغيير كلمة المرور عند أول تسجيل دخول، وهو إعداد افتراضي معقول. هناك إعدادان يجب أن يكونا صحيحين قبل الإنتاج. الأول هو ENCRYPTION_KEY، والثاني هو APP_URL.
مرجع متغيرات البيئة لا يزال يدرج ENCRYPTION_KEY بقيمة افتراضية هي arcane-dev-key-32-characters!!!، بينما تطلب منك وثائق التثبيت توفير قيمة فريدة بطول 32 بايت. غيّرها قبل الإنتاج. وثمة شيء آخر تغيّر: تقول وثائق التثبيت الآن إن JWT_SECRET لم يعد مستخدمًا. يولّد Arcane مفتاح توقيع الجلسات بنفسه، وترك JWT_SECRET مضبوطًا لا ينتج سوى تحذير عند بدء التشغيل، لذا أزله من البيئة. وثائق التثبيت تحدد أن ENCRYPTION_KEY "يجب أن يكون بطول 32 بايت (خام أو base64 أو hex)."
نظافة الإصدارات تنتمي إلى تلك القائمة أيضًا. فقد نشر Arcane عدة تنبيهات أمنية في 2026، وأحدها بدرجة خطورة عالية، نُشر في 29 يوليو 2026، يدرج الإصدارات السابقة لـ v2.5.0 على أنها متأثرة، وقد سمح لصلاحية users:update المفوَّضة بإعادة تعيين كلمة مرور المسؤول. ويحدد التنبيه v2.6.0 على أنه الإصدار المرقّع، لذا فإن v2.10.0 غير متأثر، لكنه سبب ملموس لعدم إبقاء نشر الإنتاج على وسم قديم.
APP_URL قيمته الافتراضية هي http://localhost:3552، ولهذا نتيجة وظيفية تتجاوز النظافة. فتسجيل الدخول بمفاتيح المرور والمصادقة متعددة العوامل بها يعملان كلاهما على WebAuthn، و وثائق مفاتيح المرور الخاصة بـ Arcane صريحة: "لا تتيح المتصفحات واجهة WebAuthn إلا في سياق آمن، لذا تحتاج مفاتيح المرور إلى HTTPS (أو localhost)." ويُشتق معرّف الطرف المعتمد من APP_URL، وترتبط مفاتيح المرور باسم المضيف ذاك، وإذا كان APP_URL لا يحمل اسم مضيف فلن تُهيّأ خدمة مفاتيح المرور. وعلى HTTP العادي يخفي Arcane عناصر التحكم بمفاتيح المرور تمامًا. انشره على عنوان IP مجرد ومنفذ، ولن تجد ميزة المصادقة الأبرز في الإصدار الثاني. والوثائق تقولها بوضوح: "اضبط APP_URL على عنوان URL الذي يتصفحه مستخدموك فعلًا، عبر HTTPS، قبل أن يسجّل أي شخص مفتاح مرور."
الوكلاء البعيدون يحددون ما الذي ستفتحه. وثائق البيئات الخاصة بـ Arcane تقول إنه في الوضع المباشر "يتصل المدير بالوكيل عبر منفذ TCP 3553"، لذا يجب أن يكون هذا المنفذ قابلًا للوصول من الخارج على المضيف البعيد. وفي وضع edge "يتصل الوكيل بالمدير في اتجاه الخروج" ولا يحتاج إلى أي منفذ داخل على الإطلاق.
وفيما بعد ذلك أفضّل الإشارة على التظاهر. ينشر Arcane دليل إعداد وكيل للمقبس (socket proxy) وفرضيته أن ربط المقبس مباشرة "يمنح Arcane وصولًا كاملًا إلى Docker"، وأن الوكيل يحصر ذلك في استدعاءات API التي يحتاجها. إنه التعرض نفسه الذي يجعل عزل مقبس Docker أمرًا يستحق العناء في أي مكان، ويستحق ذلك هنا أيضًا. أنا أقرأ هذه الوثائق كما يقرؤها من ينشر الأداة، لا كمدقق لمخطط الرموز.
ما الذي لا يزال Arcane لا يفعله؟
لا تزال فجوتان قائمتين بحسب وثائق Arcane الحالية: لا يوجد LDAP، ولا يوجد متصفح عام لنظام ملفات الحاوية نفسها. أما عدة فجوات أخرى كانت قائمة قبل الإصدار الثاني فقد أُغلقت منذ ذلك الحين.
LDAP غائب. وثائق تسجيل الدخول الموحد الخاصة بـ Arcane تغطي OIDC وOIDC فقط، ولا تذكر هي ولا صفحة التحكم في الوصول LDAP أو Active Directory في أي موضع. Business Edition من Portainer، في المقابل، يتكامل مع "Active Directory وLDAP ومزودي الهوية المتوافقين مع OIDC". فإذا كانت مؤسستك تصادق مقابل دليل بلا طبقة OIDC أمامه، فهذا توقف تام لا حلًّا التفافيًا.
لا يوجد متصفح ملفات عام داخل الحاويات. تعرض واجهة الحاوية في Arcane الإعدادات ونقاط الربط والسجلات ومصدر Compose، لكنها لا تعرض متصفحًا لنظام ملفات الحاوية نفسها. وقد أصبح لديه الآن Volume Workspace يمكنه تصفح الملفات وتحريرها داخل وحدات تخزين Docker، لذا فإن الفجوة المتبقية أضيق من الوصف القديم "لا يوجد متصفح ملفات".
تستحق هذه التصحيحات أن تُقال صراحة، لأن وصف Arcane بأنه "بلا RBAC وبلا فحص ثغرات" لم يعد صحيحًا. فقد وصل RBAC مع الإصدار v2.0.0 في 7 يونيو 2026، وفحص Trivy موثّق ويعمل وفق جدول. كما تطور تسجيل النشاط: وثائق النشاط الخاصة بـ Arcane تصف مركز نشاط Activity Center يغطي عمليات السحب والبناء وإجراءات دورة الحياة والفحص والتنظيف، إلى جانب سجل أحداث يحمل درجة الخطورة والنوع والطابع الزمني والمستخدم الذي أطلق كل إجراء حيثما يستطيع Arcane نسبته إليه. أما ما إذا كان يصدّر إلى Syslog كما تفعل طبقة Business في Portainer فليس أمرًا تحسمه الوثائق.
ما لا تصلحه سرعة الإصدار هو العمر. فقد أُنشئ مستودع Arcane في أبريل 2025. أما Portainer فخلفه سنوات من إجابات Stack Overflow المتراكمة، وأدلة الأطراف الخارجية، والتكاملات، وحين تصطدم بشيء غريب في الحادية عشرة ليلًا فإن هذا الفارق هو ما تشعر به.
من الذي ينبغي له الانتقال إلى Arcane، ومن لا ينبغي له؟
انتقل إلى Arcane إذا تجاوزت ثلاث عقد على Portainer وأردت وصولًا متعدد المستخدمين محدد النطاق مع ملفات Compose متتبَّعة في git، دون أي نقاش حول التراخيص. وابقَ مكانك إذا كنت عند ثلاث عقد أو أقل. فعدّ المضيفين يحسم معظم هذه المسألة أسرع من أي قائمة ميزات.
ثلاثة ملفات تعريف يكون فيها Arcane خيارًا واضحًا:
- المشغّلون الذين تجاوزوا سقف العقد الثلاث في Portainer ويحتاجون إلى وصول محدد النطاق. فوق ثلاث عقد تكون لهذه القدرات تكلفة عند Portainer ولا تكلفة عند Arcane، والأدوار دقيقة بما يكفي لمنح شخص ما دور Deployer على بيئة واحدة ودور Viewer في كل مكان آخر.
- المشغّلون الذين يريدون ملفات Compose مصدرًا للحقيقة. إذا كان ما يدفع الانتقال هو أن تعريفات الحزم تعيش في قاعدة بيانات بدلًا من مستودع، فهذا توافق بنيوي لا مجرد تفضيل. فعطلة الانتقال تُقضى في معظمها في تدوين ما تشغّله بالفعل، وهو عمل كنت مدينًا به على أي حال.
- المشغّلون الذين يدمجون عدة مضيفين، بما فيهم مضيفون خلف NAT. وكلاء وضع edge لا يحتاجون إلى منفذ داخل على الجانب البعيد، وعناقيد Swarm تُدار من عقدة المدير، والبيئات البعيدة لا تكلف شيئًا.
ملفا تعريف لا يناسبهما:
- أي شخص عند ثلاث عقد أو أقل. Business Edition مجاني عند هذا الحجم بحزمة الميزات الكاملة، لذا فإن الانتقال ينفق نافذة توقف وعطلة نهاية أسبوع للحصول على قدرات تمتلكها بالفعل. كبديل لـ Portainer، Arcane قادر، لكن ذلك لا يزال ليس سببًا للانتقال.
- أي شخص يحتاج إلى LDAP، أو لا يستطيع إيقاف الحزم. مصادقة الدليل غير متاحة، ولا يزال الانتقال يتطلب عملية انتقال مخططة. ولا يوجد لأي منهما حل التفافي ذكي.
يرافق هذا الحكم شرط واحد. إذا كانت إعادة النشر عبر GitOps تحديدًا هي سبب انتقالك، فاستخدم v2.10.0 أو أحدث. فخطأ استنفاد القرص الذي أُبلغ عنه في v2.8.0 وv2.9.0 مُصلح فيه.
الأسئلة الشائعة
هل Arcane مجاني؟
نعم. Arcane مجاني ومرخّص بموجب BSD-3-Clause، بلا مستوى مدفوع، ولا إصدار مؤسسي، ولا حجب للميزات حسب عدد العقد. التحكم في الوصول المستند إلى الأدوار، وتسجيل الدخول الموحد عبر OIDC، وفحص الثغرات، والبيئات البعيدة، وإعادة النشر عبر GitOps، كلها مضمّنة. التكلفة الوحيدة هي الجهاز الذي تشغّله عليه.
كم يحتاج Arcane من ذاكرة RAM؟
لا ينشر المشروع أي حد أدنى. فوثائق تثبيت Arcane لا تحدد حدًا أدنى للذاكرة أو المعالج، والعتاد المدعوم يمتد من خوادم x86 إلى لوحات من فئة Raspberry Pi. وقد أفاد أحد المشغّلين الذي وثّق عملية انتقاله بأن حاوية الإدارة لديه انخفضت "من نحو 150 ميجابايت من RAM (Portainer) إلى نحو 67 ميجابايت (Arcane)". فالتحجيم تحدده الحاويات التي تديرها، لا Arcane.
هل يدعم Arcane عدة مضيفين؟
نعم، عبر وكلاء البيئات البعيدة. في وضع edge يتصل الوكيل بالمدير في اتجاه الخروج، لذا لا يحتاج إلى منفذ داخل ويغطي المضيفين خلف NAT أو جدار ناري، أما في الوضع المباشر فيتصل المدير بالوكيل بدلًا من ذلك. Docker Swarm مدعوم بتحكم كامل على عقد المدير وعروض للقراءة فقط على العقد العاملة.
هل تشغيل Arcane في الإنتاج آمن؟
يعتمد ذلك على ما تفعّله. غيّر كلمة مرور المسؤول الافتراضية عند أول تسجيل دخول، واستبدل القيمة الافتراضية لـ ENCRYPTION_KEY، وضع Arcane خلف TLS مع APP_URLصحيح، وهو ما تحتاجه مفاتيح المرور لتعمل. JWT_SECRET لم يعد مستخدمًا، وتسرب النسخ المستنسخة في GitOps الذي أُبلغ عنه في v2.8.0 وv2.9.0 مُصلح فيه، لذا ينبغي أن تبدأ عمليات نشر الإنتاج من v2.10.0 أو أحدث.
كيف يقارن Arcane بـ Dockge أو Dockhand؟
Dockge أصغر ويقتصر على Compose، وهو الخيار الأنسب إذا كان كل ما تريده محرر حزم. أما Dockhand فيميل أكثر إلى فحص أمان الصور. وArcane هو الأداة الأوسع بين الثلاثة، والوحيدة التي تقدم RBAC مجانًا، فيما يقتصر RBAC في Dockhand على مستوى Enterprise.
النقاش
التعليقات
سجّل الدخول للمشاركة في النقاش.