أحاول فهم إعداد “توقف صفري” (zero downtime). الإعداد الحالي لدي يتضمن عدة نسخ من Discourse لمجتمعات مختلفة. كلاهما يحتوي على تكوين حاوية data/web 2. لدي Nginx على مستوى المضيف يتولى إنهاء SSL ويستخدم اتصالاً عبر socket يتم تمريره إلى Nginx داخل الحاوية.
لقد عثرت على هذين الموضوعين للاهتمام:
لذا أنا أحاول فهم هذه العملية. يبدو أن هناك بعض المعرفة المفترضة لإنجاز ذلك. أي مساعدة يمكن لأي شخص تقديمها هنا ستكون رائعة.
أول شيء أود فهمه هو كيفية معرفة متى تحتاج حاوية البيانات (data-container) إلى ترقية. يبدو أن هناك حالات لا يمكنك فيها ببساطة إعادة بناء حاوية الويب (web-container). كيف أعرف بشكل قاطع متى يكون هذا هو الحال؟ هل هذا يشمل جميع الحالات التي يكون فيها خيار الترقية معطلاً (رمادي اللون) في لوحة إدارة الترقية، بالإضافة إلى الأعمال المخصصة المحتملة مع السمات والإضافات؟ هل سأتمكن من معرفة ذلك بشكل قاطع من خلال النظر في هجرات مخطط قاعدة البيانات؟ هل سأحتاج إلى وجود بيئة تجريبية (staging) ومحاولة ذلك فقط لأعرف بشكل قاطع؟
الشيء التالي الذي أود معرفته هو كيفية تشغيل ترقية بتوقف صفري. كما أفهم من رابطين، هل ستقوم بإعادة بناء حاوية البيانات وحاوية الويب على أي حال؟ لا أستطيع فك شفرة هذا. هل سأحتاج إلى حاويات data/web منفصلة لتحقيق التوقف الصفري في النهاية؟
أي توجيه سيكون رائعًا! ربما يمكنني قضاء ساعات طويلة واكتشاف شيء بدا وكأنه يعمل، لكنني أفضل الوقوف على أكتاف العمالقة وعدم الاضطرار إلى اكتشاف الحالات الحافة بالطريقة الصعبة (في بيئة الإنتاج) إذا أمكن ذلك.
إذا كنت بحاجة إلى أي معلومات إضافية حول إعدادي المحدد، فيرجى طلب التوضيح. سأرد مباشرة وأحدث هذا المنشور.
I don’t know much about “post deployment migration”, but according to what I remember having read (here on meta), one way to achieve this is by using 3 containers: 1 data and 2 web. You update the web-container not running, and switch it as the one you use once updated.
I think this makes sense. So the data container does not run a rebuild via launcher? I would just handle load balancing via the host level Nginx. Let me see if I can sort this:
data container:
./launcher enter data_container
SKIP_POST_DEPLOYMENT_MIGRATIONS=1 rake db:migrate
It all depends on what updates need to be made to the data container.
The Postgres 12 update is a good example of unavoidable downtime. Even if you had a duplicate data container you would need to run your dupe site read-only while the database upgrade happened.
The only way to never have downtime is to never upgrade. Updates via /admin/upgrade on a single container install are already zero downtime. Updates made via ssh such as when the base image needs updating will have varying degrees for downtime based on your budget and appetite for complexity.
The best way to avoid downtime is to build a staging copy, otherwise you run a small risk of downtime after every update when plugins or customizations encounter compatibility issues.
Okay. So to ensure I would not have a major issue, do a run in staging and observe results… so I would attempt the above procedure and see if the data container failed?
If so my staging could consist of 1 data, 1 web and production would be 2 data, 2 web. Worst case scenario if attempted first in staging would be to in production:
If users can’t access the site that’s downtime, obviously.
If they can’t register, post, reply or like would you consider that to be downtime?
If this is a large community the costs of running multiple data containers on ssd will be considerable. Have you considered an external postgres server such as Amazon RDS?
The kind of details that @Stephen is pointing out are really important. Because we need to understand what zero downtime is, for example I could hack a Zero Downtime requirement by doing the following:
I define zero downtime as never responding to the user with a code other than HTTP 200 when the request is valid (keeping 300 and 400 open as needed). Then I deploy Discourse in a 10$ droplet in a one-container solution and add Adding an offline page when rebuilding to accomplish the no 500 errors. This way I don’t show a site that has been down.
Would I in a rational mindset think that this is zero downtime? Never. Does it works as proposed? Of course. And I could go ahead and add a standby server in another region to be even more zero downtime proof.
That is why qualification and semantics are important. Is not the same to always show something to always have functionality on the site.
Just help us understand. What do you need to accomplish your zero downtime definition? Can users suffer 10-30 minutes of read-only? Are you savvy enough to hack a solution? Are you looking to get our users a nice page that says Under maintenance, be right back. We need more details to give you a more accurate solution that really works for you. Or, at least, point you in the right direction.\
This discussion was getting a bit heated and off topic. Please remember to be respectful to each other while discussing a topic. Clarification questions are asked to give a more precise answer, as everyone’s setup and goals are different.
وعدم الاضطرار إلى اكتشاف الحالات الحافة بالطريقة الصعبة (في بيئة الإنتاج) إذا أمكن ذلك.