التنفيذ الدفعي المتدرّج باستخدام serial

يُعد تحديث كل خادم في عملية واحدة سريعًا، لكن التغيير السيئ قد يعطّل الأسطول بأكمله في اللحظة نفسها. وتتجنب التحديثات التدريجية ذلك.

تخبر الكلمة المفتاحية serial الـ play بالعمل على المضيفات ضمن دفعات بدلًا من العمل عليها كلها معًا. تُحدّث مجموعة منها، ثم تنتقل إلى التالية.

امنح serial رقمًا، وستضم كل دفعة ذلك العدد من المضيفات. مع serial 2، يُكمل Ansible الـ play بالكامل على مضيفين قبل الانتقال إلى بقية المضيفات.

تتوسع النسبة المئوية مع حجم الأسطول. يحدّث serial: 25% ربع المضيفات في كل موجة، سواء كان لديك 8 خوادم أو 800.

مرّر قائمة لزيادة حجم الدفعات مع ازدياد الثقة: ابدأ بمضيف واحد، ثم أضف المزيد. هذا هو النمط التقليدي لبدء النشر بمضيف canary ثم إكمال النشر على الجميع.

الأهم أن serial يشغّل الـ play بالكامل على دفعة قبل الانتقال إلى الدفعة التالية. تكون المجموعة الأولى قد اكتملت تمامًا، بينما لم يبدأ العمل على المضيفات اللاحقة بعد.

اجمع بين serial وmax_fail_percentage لإيقاف النشر إذا فشل عدد كبير جدًا من المضيفات في دفعة ما، وبذلك تمنع التغيير السيئ من الانتشار.

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

بما أن الدفعات الأخرى تواصل تقديم حركة المرور، تمنحك التحديثات التدريجية عدم توقف الخدمة؛ إذ يظل التطبيق متاحًا طوال عملية النشر.

داخل الدفعة، يظل forks متحكمًا في التوازي. يحدّد serial عدد المضيفات التي تتعامل معها الموجة، بينما يحدّد forks عدد المضيفات التي تعمل في الوقت نفسه داخلها.

يجعل البدء باستخدام serial: 1 المضيف الأول بمثابة canary. وإذا حدث عطل، يتوقف التنفيذ عنده ويبقى باقي أسطولك سليمًا.

تريد تحديث 100 خادم ويب على دفعات صغيرة دون انقطاع في الخدمة.

استخدم serial لنشر التغييرات على دفعات، وزِد حجمها باستخدام قائمة، وأضف max_fail_percentage للتوقف مبكرًا عند الحاجة. هكذا تنفّذ عمليات نشر دون توقف الخدمة. 🌊