أحاول فهم إعداد “توقف صفري” (zero downtime). الإعداد الحالي لدي يتضمن عدة نسخ من Discourse لمجتمعات مختلفة. كلاهما يحتوي على تكوين حاوية data/web 2. لدي Nginx على مستوى المضيف يتولى إنهاء SSL ويستخدم اتصالاً عبر socket يتم تمريره إلى Nginx داخل الحاوية.
لقد عثرت على هذين الموضوعين للاهتمام:
لذا أنا أحاول فهم هذه العملية. يبدو أن هناك بعض المعرفة المفترضة لإنجاز ذلك. أي مساعدة يمكن لأي شخص تقديمها هنا ستكون رائعة.
أول شيء أود فهمه هو كيفية معرفة متى تحتاج حاوية البيانات (data-container) إلى ترقية. يبدو أن هناك حالات لا يمكنك فيها ببساطة إعادة بناء حاوية الويب (web-container). كيف أعرف بشكل قاطع متى يكون هذا هو الحال؟ هل هذا يشمل جميع الحالات التي يكون فيها خيار الترقية معطلاً (رمادي اللون) في لوحة إدارة الترقية، بالإضافة إلى الأعمال المخصصة المحتملة مع السمات والإضافات؟ هل سأتمكن من معرفة ذلك بشكل قاطع من خلال النظر في هجرات مخطط قاعدة البيانات؟ هل سأحتاج إلى وجود بيئة تجريبية (staging) ومحاولة ذلك فقط لأعرف بشكل قاطع؟
الشيء التالي الذي أود معرفته هو كيفية تشغيل ترقية بتوقف صفري. كما أفهم من رابطين، هل ستقوم بإعادة بناء حاوية البيانات وحاوية الويب على أي حال؟ لا أستطيع فك شفرة هذا. هل سأحتاج إلى حاويات data/web منفصلة لتحقيق التوقف الصفري في النهاية؟
أي توجيه سيكون رائعًا! ربما يمكنني قضاء ساعات طويلة واكتشاف شيء بدا وكأنه يعمل، لكنني أفضل الوقوف على أكتاف العمالقة وعدم الاضطرار إلى اكتشاف الحالات الحافة بالطريقة الصعبة (في بيئة الإنتاج) إذا أمكن ذلك.
إذا كنت بحاجة إلى أي معلومات إضافية حول إعدادي المحدد، فيرجى طلب التوضيح. سأرد مباشرة وأحدث هذا المنشور.
لا أعرف الكثير عن “هجرة ما بعد النشر”، ولكن وفقًا لما أتذكر قراءته (هنا على ميتا)، إحدى الطرق لتحقيق ذلك هي استخدام 3 حاويات: حاوية بيانات واحدة وحاويتان ويب. تقوم بتحديث حاوية الويب غير النشطة، ثم تجعلها الحاوية المستخدمة بعد التحديث.
أعتقد أن هذا منطقي. إذن، حاوية البيانات لا تقوم بإعادة بناء عبر المشغل؟ سأقوم فقط بإدارة موازنة التحميل على مستوى المضيف عبر Nginx. دعني أرى ما إذا كان بإمكاني ترتيب هذا:
حاوية البيانات:
./launcher enter data_container
SKIP_POST_DEPLOYMENT_MIGRATIONS=1 rake db:migrate
كل ذلك يعتمد على التحديثات التي يجب إجراؤها على حاوية البيانات.
يُعد تحديث Postgres 12 مثالًا جيدًا على توقف الخدمة الذي لا مفر منه. حتى لو كانت لديك حاوية بيانات مكررة، فستحتاج إلى تشغيل موقع النسخة المكررة في وضع القراءة فقط أثناء عملية ترقية قاعدة البيانات.
الطريقة الوحيدة لتجنب توقف الخدمة تمامًا هي عدم الترقية أبدًا. التحديثات عبر /admin/upgrade في تثبيت حاوية واحدة تكون بالفعل بدون توقف. أما التحديثات التي تتم عبر ssh، مثل تلك المطلوبة عند الحاجة لتحديث صورة النظام الأساسية، فستتفاوت درجة توقف الخدمة فيها بناءً على ميزانيتك واستعدادك للتعقيد.
أفضل طريقة لتجنب توقف الخدمة هي إنشاء نسخة تجريبية (Staging)، وإلا فإنك تخاطر بتوقف الخدمة بشكل طفيف بعد كل تحديث عندما تواجه الإضافات أو التخصيصات مشاكل في التوافق.
حسناً. لذا، لضمان عدم حدوث مشكلة كبيرة، قم بتشغيل الاختبار في بيئة الاختبار (staging) وراقب النتائج… لذا سأحاول الإجراء المذكور أعلاه وأرى ما إذا كان حاوية البيانات ستفشل؟
في حال حدوث ذلك، يمكن أن تتكون بيئة الاختبار من 1 خادم بيانات و1 خادم ويب، بينما تتكون بيئة الإنتاج من 2 خادم بيانات و2 خادم ويب. وفي أسوأ السيناريوهات، إذا تم التطبيق أولاً في بيئة الاختبار ثم في الإنتاج، فسيكون الإجراء كالتالي:
تعيين وضع القراءة فقط
نسخ البيانات باستخدام الأمر: cp -rp shared/data1 إلى shared/data2
التفاصيل التي يشير إليها @Stephen مهمة جدًا. لأننا بحاجة إلى فهم ما هو التوقف الصفري، على سبيل المثال، يمكنني التلاعب بمتطلب التوقف الصفري عن طريق القيام بما يلي:
أعرّف التوقف الصفري على أنه عدم الرد على المستخدم أبدًا بكود غير HTTP 200 عندما يكون الطلب صحيحًا (مع إبقاء الأكواد 300 و400 مفتوحة حسب الحاجة). ثم أقوم بنشر Discourse على خادم droplet بقيمة 10$ في حل مكون من حاوية واحدة وأضيف Add an offline page to display when Discourse is rebuilding or starting up لتحقيق عدم ظهور أخطاء 500. بهذه الطريقة لا أظهر موقعًا كان معطلًا.
هل سأعتقد بعقلانية أن هذا هو التوقف الصفري؟ أبدًا. هل يعمل كما هو مقترح؟ بالتأكيد. ويمكنني المضي قدمًا وإضافة خادم احتياطي في منطقة أخرى لأكون أكثر إثباتًا ضد التوقف الصفري.
لهذا السبب فإن التأهيل والدلالات مهمان. ليس الأمر نفسه أن نعرض شيئًا دائمًا كما هو الحال في أن يكون لدينا وظائف دائمة على الموقع.
ساعدنا فقط على الفهم. ما الذي تحتاجه لتحقيق تعريفك للتوقف الصفري؟ هل يمكن للمستخدمين تحمل 10-30 دقيقة من الوضع للقراءة فقط؟ هل تمتلك الخبرة الكافية لابتكار حل؟ أم أنك تبحث عن توفير صفحة أنيقة للمستخدمين تقول: “قيد الصيانة، سنعود قريبًا”. نحتاج إلى مزيد من التفاصيل لتقديم حل أكثر دقة يناسبك حقًا. أو على الأقل، توجيهك نحو المسار الصحيح.
وعدم الاضطرار إلى اكتشاف الحالات الحافة بالطريقة الصعبة (في بيئة الإنتاج) إذا أمكن ذلك.