عميل Go واحد على Linux وOpenWrt: خيارات نشر Fleetd

يبدو تثبيت العميل على خادم وعلى موجّه منزلي متشابهًا في البداية: نسخ برنامج وكتابة إعدادات ثم تشغيله. لكن التشغيل المستمر يطرح أسئلة أخرى: من يشغّله بعد إعادة تشغيل الجهاز؟ ماذا لو لم تكن الشبكة جاهزة؟ أين السجلات؟ وهل تبقى هوية الجهاز وسجلات الطلبات بعد إعادة التشغيل؟

يدير Fleetd خوادم Linux وموجّهات OpenWrt وiStoreOS. بعد شرح تسجيل الأجهزة وتوقيع الأوامر في المتصفح، ننتقل إلى تشغيل العميل كخدمة مستمرة يمكن تشخيصها. نتناول v0.3.0: يدعم المثبّت amd64 وarm64 مع systemd أو procd في OpenWrt، ولا يعني ذلك دعم كل جهاز يستخدم نواة Linux.

شيفرة مشتركة وملفات تنفيذية حسب المعمارية

OpenWrt هو Linux أيضًا. يمكن مشاركة الاتصالات والتحقق من الهوية وتفويض الأوامر وقراءة المؤشرات الأساسية من النواة. لذلك لا يقسم Fleetd العميل إلى نسخة للخوادم وأخرى للموجّهات؛ يبني المصدر نفسه لـLinux وينتج ملفين لمعماريتَي amd64 وarm64.

العميل نفسه يعني مصدرًا وبروتوكولًا مشتركين، لا ملفًا يمكن نقله بين المعماريات.

المعمارية التي يبلغ عنها الجهاز	اختيار المثبّت
`x86_64` أو `amd64`	`amd64`
`aarch64` أو `arm64`	`arm64`
غير ذلك	يتوقف المثبّت الحالي

يغطي OpenWrt أجهزة MIPS وARM ذات 32 بت لا يشملها مسار التثبيت الحالي. دعم Go للبناء المتقاطع لا يساوي دعم المشروع لجميع الأهداف. إضافة معمارية تتطلب فحص الاعتماديات والملفات الناتجة والتعرف عليها والتحديثات والسلوك على العتاد الحقيقي.

الأمر uname -m فحص أولي مفيد، لكن النواة وبيئة المستخدم ووظائف النظام المتاحة تظل مهمة.

ملف واحد يقلل تجهيز بيئة التشغيل

يُبنى العميل باستخدام CGO_ENABLED=0 لتقليل الاعتماد على بيئة C ذات الربط الديناميكي في الجهاز. لا يحتاج كل جهاز إلى مترجم Go أو بيئة Node.js أو Python لتشغيله، وهذا مفيد في الموجّهات محدودة التخزين والحزم.

لكن المتطلبات لا تختفي: يجب أن تكون الشبكة قابلة للوصول، وأن تتوفر بيئة ثقة صالحة لشهادات HTTPS، ومساحة قابلة للكتابة للإعدادات، ووظائف النواة اللازمة. بعض أدوات الجمع تستدعي برامج خارجية، مثل docker للحاويات وwg لـWireGuard.

الفكرة هي تخفيف أساس النشر مع توضيح اعتماديات الميزات الإضافية.

فحص البيئة قبل تسجيل الخدمة

يسير المثبّت بهذا الترتيب:

يتحقق من صلاحية root ومعمارية المعالج.
يحدد وجود systemd أو بيئة procd في OpenWrt.
ينزّل العميل المناسب من خادم Fleetd الخاص بك.
يشغّل version للتأكد من قدرة الملف على البدء على الأقل.
ينشئ الإعدادات أو يحتفظ بها، ويثبت البرنامج ويسجل الخدمة ويشغّلها.
يعرض بصمة الجهاز لمقارنتها والموافقة عليها في اللوحة.

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

يُفضّل curl ويُستخدم wget عند غيابه. في البيئات المختصرة، تأكد من أن الأداة المتاحة تدعم طلبات HTTPS المطلوبة. لا توجد هنا تعليمة موحدة لتثبيت الحزم، لأن إصدارات OpenWrt ومحتويات البرامج الثابتة تختلف.

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

systemd وprocd يديران العملية نفسها

بعد التثبيت يتولى مدير خدمات النظام دورة حياة العملية.

العنصر	جهاز systemd	جهاز OpenWrt / procd
البرنامج	`/usr/local/bin/fleetd-agent`	`/usr/bin/fleetd-agent`
الإعدادات	`/etc/fleetd/agent.yaml`	`/etc/fleetd/agent.yaml`
تعريف الخدمة	`/etc/systemd/system/fleetd-agent.service`	`/etc/init.d/fleetd-agent`
الحالة عند تثبيت جديد	`/var/lib/fleetd`	`/etc/fleetd`
السجلات	سجل systemd	سجل نظام OpenWrt

تشير وحدة systemd إلى العميل في ExecStart، وتستخدم Restart=always مع مهلة خمس ثوانٍ، وتضبط ترتيب التشغيل بالنسبة إلى network-online.target.

ينشئ فرع OpenWrt ملف بدء يستخدم USE_PROCD=1، مع ترتيب إقلاع وأمر العملية وإعدادات respawn. وتذهب المخرجات العادية والأخطاء إلى سجل النظام. يشغّل الفرعان المدخل نفسه ويقرآن النوع نفسه من YAML، وتبقى اختلافات التوزيعات في التثبيت وربط الخدمة.

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

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

في OpenWrt، مكان الحالة مهم

يؤثر ذلك مباشرة في منع إعادة الإرسال الذي شرحناه سابقًا. يناسب /var/lib/fleetd عادةً الخادم، لكن /var في ترتيبات OpenWrt الشائعة يعتمد على تخزين مؤقت في RAM. إعادة تشغيل العملية وإعادة تشغيل الجهاز ليستا متكافئتين بالنسبة إلى الملفات.

لذلك يضبط مثبّت OpenWrt قيمة state_dir على /etc/fleetd. يجب تمييز ثلاثة ملفات:

الملف	الوظيفة
`agent.yaml`	الاتصال والمفاتيح الموثوقة والصلاحيات ومجلد الحالة
`agent.key`	مفتاح هوية العميل نفسه
`seen.json`	معرّفات الطلبات المقبولة لمنع تكرارها

يوجد الأولان افتراضيًا في /etc/fleetd. ويتبع seen.json قيمة state_dir: في تثبيت systemd الجديد يكون في /var/lib/fleetd، وفي OpenWrt يكون في /etc/fleetd.

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

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

للتخزين على الذاكرة الوميضية تكلفة كتابة. يحدّث العميل الحالي سجل منع التكرار عند قبول طلبات مفوضة جديدة، ولا يكتب فيه كل تقرير مؤشرات ذي عشر ثوانٍ. إذا توسع إلى تنفيذ مهام عالية التردد، فستحتاج وتيرة الحفظ وخصائص الذاكرة إلى إعادة تقييم. لا توجد هنا ضمانات مقاسة للعمر أو معدل المعالجة.

الاحتفاظ بالإعدادات لا يعيد الخدمة تلقائيًا

يضيف مثبّت OpenWrt المسار /etc/fleetd/ إلى /etc/sysupgrade.conf. يساعد ذلك في حفظ الإعدادات والهوية في إجراءات التحديث التي تدعم حفظ الإعدادات وتفعّله. لكنه لا يضمن بقاء /usr/bin/fleetd-agent و/etc/init.d/fleetd-agent.

قد تبقى الإعدادات بعد تحديث البرنامج الثابت بينما يحتاج البرنامج أو ملف البدء إلى إعادة تثبيت. إعادة ضبط المصنع أو التحديث مع حذف الإعدادات خارج نطاق آلية الاحتفاظ هذه.

عند التحقق من الاستعادة افحص:

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

هذه فحوص مقترحة، وليست ادعاء بإجراء تجربة تفليش لهذا المقال.

إعادة تشغيل المثبّت تحتفظ بملف agent.yaml الموجود، وتستبدل البرنامج وتعيد كتابة تعريف الخدمة. هذا مفيد للاستعادة، لكن قيم --permission و--server و--signer الجديدة لا تستبدل الإعدادات المحفوظة تلقائيًا. كذلك لن يصحح المثبّت مسار حالة قديمًا خاطئًا؛ افحص الملف وأعد تشغيل العميل بعد التعديل.

عميل مشترك لا يعني تغطية مراقبة متطابقة

تأتي المؤشرات الأساسية غالبًا من /proc: المعالج والذاكرة والحمل ومدة التشغيل وحركة الشبكة التراكمية. يحتاج استخدام المعالج وسرعة الشبكة إلى عينتين؛ العينة الأولى بعد البدء لا تمثل فترة قياس مكتملة. إذا أُعيد إنشاء واجهة وانخفضت العدادات، يتجاوز العميل حساب السرعة لتلك العينة بدل طرح قيم غير منطقية.

يعتمد الجمع الموسع على البيئة:

المعلومات	الاعتماد الحالي
الخدمات الفاشلة	`systemctl list-units --state=failed`
الحاويات	`docker ps -a`
أقران WireGuard	`wg show all dump`

تشغيل العميل تحت procd لا يعني تنفيذ جمع صحة خدمات procd. ما زال فحص الخدمات الفاشلة يستخدم systemd. عند غياب أداة أو فشلها، لا يعيد ذلك الجامع بيانات ويمكن للمراقبة الأساسية الاستمرار. هذا يجنب فرض Docker على كل موجّه، لكن غياب بيانات الأعطال لا يثبت سلامة جميع الخدمات.

لا يشرح التنفيذ الحالي كل أسباب البيانات المفقودة شرحًا كاملًا. يجب تمييز ميزة غير منطبقة وأداة غائبة واستدعاء فاشل ونتيجة فارغة فعلًا؛ ليست كلها صفر أعطال.

تُجدول التقارير الأساسية كل عشر ثوانٍ، وتُجمع الأقراص والخدمات والحاويات وWireGuard كل ست جولات. هذه سياسة جدولة وليست ضمانًا صارمًا للزمن الحقيقي؛ تؤثر الأوامر الخارجية والشبكة وحمل الجهاز في الفواصل الفعلية.

تحقق من سلسلة التشغيل كاملة

بالنسبة إلى عميل دائم، المهم هو البدء والإشراف وإعادة الاتصال وحفظ الهوية والإعدادات بعد إعادة التشغيل. ابدأ في systemd بالحالة والسجلات الحديثة:

systemctl status fleetd-agent
journalctl -u fleetd-agent -n 50 --no-pager

وفي OpenWrt افحص سجل النظام:

logread -e fleetd

هذه أوامر تشخيص ولا تعيد تشغيل الجهاز. لتطبيق تغييرات الإعدادات أعد تشغيل العميل باستخدام systemctl restart fleetd-agent، أو /etc/init.d/fleetd-agent restart على OpenWrt.

ثم تحقق من الموافقة على الجهاز وتقدم أوقات التقارير في اللوحة، وانتظر العينات اللاحقة للمعالج والشبكة. يمكن لجهاز المراقبة البقاء على monitor؛ لا حاجة إلى فتح أوامر root لمجرد الاختبار.

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

تشمل CI اختبارات وبناء amd64 وarm64، لكن نجاح البناء المتقاطع لا يثبت تشغيل كل صورة OpenWrt على العتاد. ولا تقدم المقالة قياسات RAM أو عبء المعالج أو الحد الأدنى للذاكرة الوميضية؛ افحص المساحة الحرة وراقب حملك الفعلي.

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