فحوصات الصحة وترتيب ثابت للإصدار في بيئة Docker

عودة الأمر لا تعني نظامًا سليمًا

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

اسأل في كل طبقة

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

انتظر بمهلة

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

أبقِ خطوات الإصدار بترتيب واحد

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

افصل «حي» عن «أي إصدار»

فحص الصحة يقول إن النظام حي، ولا يقول ما الذي يعمل. نقطة إصدار صغيرة منفصلة عن فحص الصحة تجيب على السؤال الذي تطرحه بعد كل إصدار: هل نُشر البناء الجديد؟

في منتجاتنا

تعطي بيئة Rveta كلًا من التطبيق وخادم الويب وMySQL وRedis فحص حاوية خاصًا، ويقوم سكربت التهيئة فيها بانتظار الخدمات حتى تصبح سليمة ضمن مهلة قبل المتابعة. ويتبع سكربت نشر RumuzePMO الترتيب أعلاه وينتهي بفحص مسار الصحة. وتعرض Rumuze Core الإصدار العامل على نقطة داخلية منفصلة عن فحص الصحة.