أطلقت Fleetd: إدارة خوادم Linux والموجّهات من لوحة واحدة

عندما يكون لديك عدد قليل من الخوادم والموجّهات، تبدو إدارتها بسيطة: تتصل عبر SSH، تقرأ السجلات إذا تعثرت خدمة، وتنفذ بضعة أوامر لتحديث البرامج.

المشكلة أن هذه الأعمال موزعة بين أماكن مختلفة. للخادم مدخل وللموجّه مدخل آخر. وعند ظهور تنبيه، ما زال عليك العثور على الجهاز وفهم بيئته قبل بدء التحقيق.

أردت جمع هذه الخطوات اليومية: صفحة تعرض الأجهزة المتصلة والتنبيهات، ثم تفاصيل الجهاز، مع إمكان تنفيذ أمر أو فتح طرفية عند الحاجة.

هكذا أنشأت Fleetd، أداة ذاتية الاستضافة لإدارة خوادم Linux والموجّهات. أصبح الكود مفتوح المصدر بترخيص MIT، وأول إصدار عام هو v0.3.0، مع توثيق بالإنجليزية والصينية.

• مستودع المشروع
• التوثيق الإنجليزي
• تنزيل v0.3.0

تتناول هذه المقالة المشكلة والقدرات الحالية والقرارات الأساسية. سأفصل التنفيذ في المقالات التالية.

الانتقال من ملاحظة المشكلة إلى التعامل معها

يمكن للمراقبة أن تخبرني بأن القرص يكاد يمتلئ، لكن عليّ بعدها معرفة المجلد الذي ينمو. والخدمة المتعطلة تحتاج إلى قراءة سجلاتها ومراجعة إعدادها واتخاذ قرار بشأن إعادة تشغيلها.

لمن يدير عددًا محدودًا من الأجهزة، هذه خطوات متصلة. أردت الحفاظ على هذا الاتصال بدل البحث عن الجهاز نفسه كل مرة في أداة أخرى.

المجال	ما يقدمه Fleetd حاليًا
المراقبة	المعالج والذاكرة والحمل والأقراص وسرعات الشبكة، مع سجل لسبعة أيام
حالة التشغيل	وحدات systemd الفاشلة وحاويات Docker وأقران WireGuard
التنبيهات	الأجهزة المنقطعة والتجاوز المستمر للموارد ونقص المساحة ومشكلات الخدمات، مع بريد اختياري
الأوامر البعيدة	أوامر موقعة لجهاز واحد أو عدة أجهزة وفق صلاحيات العميل المحلية
طرفية الويب	جلسة تفاعلية للأجهزة المسموح لها بالوصول الكامل
إدارة العملاء	الموافقة على الأجهزة الجديدة وتوزيع إصدارات العميل الموقعة

جزء من واجهة العرض في توثيق المشروع. القيم توضح الحقول والتخطيط، وليست نتائج اختبار أداء.

تحتاج المعلومات إلى سياق. حالة systemd تخص الأنظمة التي تستخدمه، ولا يفترض أن يقدم OpenWrt القائمة نفسها. وتوقيت مصافحة WireGuard قرينة تشخيصية تُقرأ مع حركة المرور والإعدادات، لا دليلًا منفردًا على تعطل الاتصال.

الأولوية هي توفير نقطة يمكن متابعة التحقيق منها. أما قواعد المراقبة المعقدة والتحليل الطويل وتنسيق الإعدادات بالكامل فيمكن أن تبقى في أدوات متخصصة.

خادم واحد وعميل على كل جهاز

الخادم يقدم لوحة الإدارة وسجلات الأجهزة والمقاييس وتاريخ العمليات، ويستخدم PostgreSQL للتخزين. وعلى كل جهاز Linux عميل يجمع الحالة ويتلقى الطلبات ويقرر هل ينفذها.

واجهة Vue 3 تُضمّن بعد بنائها داخل برنامج الخادم المكتوب بـGo. العميل أيضًا مكتوب بـGo، وتتوفر إصدارات Linux لمعمارتي amd64 وarm64. يجب فحص معمارية جهازك؛ تشغيل OpenWrt لا يعني تلقائيًا توافقه مع الملفات المنشورة.

الحدود واضحة: خادم، وقاعدة بيانات، وعملاء بإعدادات مستقلة. ويمكن تتبع الخلل وفقها: هل اتصل العميل؟ هل أرسل البيانات؟ هل وصل الطلب؟ ولماذا قُبل أو رُفض؟

للموجّهات، ابدأ باتجاه الاتصال

قد يملك الخادم السحابي عنوانًا عامًا، بينما يكون موجّه المنزل خلف NAT. فتح خدمة إدارة واردة إضافية يزيد الإعداد والصيانة.

في Fleetd يبدأ العميل الاتصال بالخادم. إذا استطاع الوصول إلى عنوانه المحدد، فلا يحتاج الجهاز المُدار إلى منفذ وارد خاص بإدارة العميل.

هذا مناسب لجمع أجهزة Linux وOpenWrt وiStoreOS من شبكات مختلفة. يظل الخادم بحاجة إلى عنوان يستطيع العملاء الوصول إليه، ويتطلب الاستخدام الفعلي إعداد HTTPS وتمرير WebSocket وفق الوثائق.

يظهر الجهاز الجديد أولًا بانتظار الموافقة. يقارن المسؤول بصمة المثبّت بالبصمة في اللوحة، ثم يقبل الجهاز أو يرفضه. هل هذا فعلًا الجهاز الذي قصدت إضافته؟ الاسم المألوف أو صف جديد في الجدول لا يعوضان التحقق من الهوية. ستشرح المقالة التالية التسجيل والبصمات وإعادة الاتصال.

رؤية الجهاز لا تعني منحه تحكمًا كاملًا

بعض الأجهزة تحتاج إلى المراقبة فقط، وبعضها إلى أعمال صيانة ثابتة، بينما تحتاج فئة محدودة إلى أوامر حرة وطرفية كاملة.

يضع Fleetd هذا القرار في إعداد العميل المحلي:

الصلاحية	المسموح
monitor	المراقبة فقط، دون تنفيذ أوامر بعيدة
allowlist	إجراءات معرّفة محليًا مسبقًا
full	أوامر حرة وطرفية ويب

تُوقّع الأوامر في متصفح المسؤول. يتحقق العميل باستخدام مفتاح عام موثوق، ثم يفحص الهدف ومدة الصلاحية والأذونات المحلية. الخادم يمرر الطلبات؛ لا يكفي طلب عادي بلا توقيع لإجبار العميل على التنفيذ.

يقلل ذلك الثقة العمياء بتعليمات الخادم، لكنه يعتمد على شرط مهم: يجب أن يبقى المتصفح وكود الواجهة الذي يعمل فيه موثوقين.

الخادم يقدم صفحة الإدارة أيضًا. وإذا اختُرق، فقد يستبدل الصفحة التي تُفتح لاحقًا. عدم قابلية تصدير المفتاح لا يمنع كودًا خبيثًا من محاولة استدعاء عملية التوقيع. لذلك لا يبرر توقيع الأوامر وحده وعدًا بالأمان المطلق بعد اختراق الخادم.

سأخصص مقالة لسلسلة الثقة هذه. كبداية، احتفظ بـmonitor لما يحتاج إلى المراقبة فقط، وفضّل allowlist للأعمال الثابتة، ولا تفعّل full إلا حيث تحتاج إلى طرفية كاملة.

للتحديثات آلية ثقة خاصة بها

نسخ برنامج العميل يدويًا إلى كل جهاز يصبح مرهقًا. لكن تنزيل أي ملف وتشغيله تلقائيًا يترك سؤال أصالته بلا جواب.

يستخدم Fleetd حزم إصدار موقعة. يوقعها الناشر في بيئته، ويتحقق العميل بالمفتاح العام للإصدارات الذي ضُبط مسبقًا. توقيع الأوامر وتوقيع الإصدارات يخدمان غرضين مختلفين.

ملفات العميل التنفيذية العادية في GitHub Releases تصلح للنشر اليدوي على المعمارية المطابقة. أما حزمة .release الموقعة فلا تصلح إلا للعملاء الذين يثقون بمفتاحها.

على من يستضيف النظام بنفسه إنشاء مفاتيحه ومسار تحديثه وفق الوثائق. رفع حزمة المؤلف لا يجعلها مقبولة في كل تثبيت مستقل. فحص الإصدارات وفشل التحقق والاستعادة أثناء التحديث ستكون موضوعًا لاحقًا.

تجربة الخادم باستخدام Docker Compose

بعد تثبيت Docker وإضافة Compose، يمكن التجربة على حاسوبك:

git clone https://github.com/weiyi0/fleetd
cd fleetd
git checkout v0.3.0
docker compose up -d
docker compose run --rm fleetd admin-add admin

حدد كلمة مرور المسؤول عند الطلب، ثم افتح http://localhost:8480. الواجهة تدعم الإنجليزية والصينية.

يثبت checkout الإصدار v0.3.0 ليتوافق مع نطاق المقالة. يبني Compose الخادم من المصدر ويشغل PostgreSQL، ولذلك يتضمن التشغيل الأول تنزيل الاعتماديات والترجمة، ويتغير وقته بحسب الجهاز والشبكة.

هنا تعمل لوحة الإدارة فقط؛ لم تُضف أجهزة بعد. وصورة Docker لا تولد حزم عملاء موقعة تلقائيًا.

اتبع دليل البدء السريع لبناء عميل وتشغيله يدويًا في أول تجربة. وللاستخدام المستمر، اضبط مفتاح الإصدار وارفع الحزم الموقعة واستخدم مسار التثبيت في اللوحة.

إعداد Compose التجريبي يتضمن بيانات اعتماد نموذجية لقاعدة البيانات، كما أن المنفذ 8480 ليس مقيدًا بعنوان loopback. قيّد الوصول خلال التجربة المحلية. وقبل الاستخدام عبر الشبكة، اتبع دليل النشر لتغيير بيانات الاعتماد وضبط HTTPS ونسخ قاعدة البيانات والمفاتيح احتياطيًا.

ابدأ بجهاز اختبار يسهل استعادته: تحقق من البصمة، راقب الحالة وجرب الإجراءات المسموحة. أضف بقية الأجهزة بعد نجاح المسار كاملًا.

لماذا أول إصدار عام هو v0.3.0؟

كانت العملاء في بيئة الاستخدام السابقة قد وصلت إلى 0.2.0. وآلية التحديث تتطلب إصدارًا أحدث من الحالي، لذلك استمر الإصدار العام في هذا التسلسل.

رقم الإصدار يصف التقدم؛ النضج يأتي من الاستخدام والتحقق. يناسب Fleetd حاليًا من يدير عددًا صغيرًا من خوادم Linux والموجّهات، ويريد التحكم ببياناته ومستعدًا لفهم النشر والصلاحيات.

تتيح الشيفرة والملفات والوثائق فحص العمل قبل اعتماده. جدول وظائف لا يكفي لتقديمه بديلًا عن كل أدوات التشغيل الراسخة. الهدف الأول هو وصل حالة الأجهزة والتنبيهات والصيانة اللازمة مع إبقاء صلاحيات كل جهاز واضحة.

ما التالي في السلسلة؟

سأتناول الاتصالات الصادرة والموافقة، وتوقيع المتصفح، والصلاحيات المحلية، ودعم OpenWrt، والتنبيهات والتحديثات. وسأراجع أيضًا تجربة تطوير المشروع بمساعدة الذكاء الاصطناعي.

أريد توثيق قرارات محددة: ما المشكلة التي حلّتها وما القيود التي أضافتها. ستنضم المشكلات الفعلية وسجلات التحقق مع تقدم العمل.

يمكن البدء من الكود والوثائق. الأسئلة العامة تناسب Issues، والثغرات الأمنية تناسب قناة الإبلاغ الخاصة في GitHub. آمل أن تقلل الأداة التنقل بين الأدوات، وأن تفيد هذه التجربة من يبني مشروعًا مشابهًا.