البنية التحتية السحابية وDevOps

نحن ندير بنيتنا التحتية بأنفسنا، وهذا معظم ما يؤهلنا لإدارة بنيتك. خادم الإنتاج لدينا يشغّل عشرات الحاويات: الخلفيات والواجهات لـFanDesk وMobile Master وProbe361 وEnergyFile وهذا الموقع، إلى جانب MongoDB وPostgreSQL وRedis وقاعدة بيانات Qdrant المتجهية ومنظومة مراقبة كاملة. لا نستخدم Kubernetes لذلك، ونعتقد أن معظم الشركات بحجمنا أو بحجمك لا تحتاجه أيضًا. Docker Compose مع وكيل عكسي جيد وانضباط في النشر والنسخ الاحتياطي يكفي لمسافة طويلة.

لمن هذه الخدمة

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

كيف نعمل

1. مراجعة ما يعمل اليوم. الخدمات، قواعد البيانات، مكان الأسرار، طريقة النشر، وما الذي يُنسخ احتياطيًا. وغالبًا يكون أول اكتشاف أن النسخ الاحتياطية لم تُستعد قط.
2. التحويل إلى حاويات. تحصل كل خدمة على Dockerfile ومكان في ملف Compose، مع فحوص صحة وحدود ذاكرة وسياسات إعادة تشغيل. وتنتقل الإعدادات إلى ملفات بيئة لا تدخل git.
3. التوجيه وTLS. يقف Traefik في الواجهة، يكتشف الحاويات عبر الوسوم ويدير الشهادات تلقائيًا، وخلف Cloudflare حيث يكون ذلك منطقيًا.
4. المراقبة والسجلات والنسخ الاحتياطي. مقاييس ولوحات، وسجلات الحاويات في مكان واحد قابل للبحث، وفحوص توافر من الخارج، ونسخ ليلية تُنقل إلى جهاز ثانٍ.
5. سكربتات النشر والتسليم. نشر مؤتمت وقابل للتكرار، ودليل تشغيل قصير: كيف ننشر، وكيف نتراجع، وكيف نستعيد.

التقنيات التي نستخدمها فعلًا

Docker وDocker Compose لكل خدمة. Traefik كوكيل عكسي مع شهادات Let's Encrypt. يجمع Prometheus مقاييس الخادم وكل حاوية من node-exporter وcAdvisor، ويعرضها Grafana. ينقل Promtail سجلات الحاويات إلى Loki، وهذا لا يعمل جيدًا إلا إذا كتبت التطبيقات سجلاتها على stdout، وهو درس كتبنا عنه بعد أن اختفت سجلات nginx حين احتجناها. يفحص Uptime Kuma كل نطاق عام عبر HTTPS. ويعمل CI على GitHub Actions، بما في ذلك runner على خادمنا ينفّذ تجربة الاستعادة الأسبوعية.

أمثلة من بنيتنا الخاصة

نشر blue-green. الأمر العادي docker compose up -d يوقف الحاوية القديمة قبل جاهزية الجديدة، فيعيد Traefik أخطاء لبضع ثوانٍ. أما سكربت النشر لدينا فيشغّل الحاوية الجديدة بجانب القديمة، وينتظر حتى يعلن فحص الصحة أنها سليمة (يرسل Traefik إليها الطلبات عندها بالفعل)، ثم يزيل القديمة ويعيد تسمية الجديدة مكانها. وإذا لم تصبح الجديدة سليمة، تُحذف وتستمر القديمة في الخدمة. لا شيء ينكسر.

خادم بلا إنترنت. أحد أهداف النشر لدينا لا يصل إلى الإنترنت ولا إلى أي registry، ويقع خلف jump host. نبني الصور من جهتنا وننقلها عبر SSH باستخدام docker save وdocker load، ثم نبدّلها بنفس سكربت blue-green. يعمل هناك Probe361 وEnergyFile.

نسخ احتياطي تتم استعادته. في Mobile Master تأخذ مهمة ليلية نسخة من MongoDB، وتتحقق من الملف، وتنسخه إلى خادم آخر وتقارن الـchecksum في الطرفين. ومرة كل أسبوع يستعيد CI أحدث نسخة في قاعدة بيانات مؤقتة ويتحقق من المجموعات وعدد المستندات. النسخة الاحتياطية التي لم يستعدها أحد مجرد أمل.

وبنفس الأسلوب يعمل FanMail، خدمة البريد الإلكتروني ذاتية الاستضافة المبنية على Stalwart Mail Server.

قراءات إضافية

• سجلات الحاويات مكانها stdout لا الملفات (بالإنجليزية)
• إعداد Docker خلف نظام إدارة المحتوى ذاتي الاستضافة لدينا

الأسئلة الشائعة

هل تستخدمون Kubernetes؟

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

هل يمكنكم النشر على خادم بلا إنترنت؟

نعم، ونفعل ذلك الآن. تُبنى الصور في مكان آخر وتُنقل عبر SSH، وكذلك الصور الأساسية، فلا يحتاج الخادم الهدف إلى registry أبدًا.

ماذا يعني النشر دون توقف عمليًا؟

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

مع أي مزوّد سحابي تعملون؟

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

كيف تُختبر النسخ الاحتياطية؟

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

هل يمكنكم استلام خادم قائم لدينا؟

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