‫تحديثات الخدمة. من المحتمل أنك افترضت طوال الوقت أن هناك طريقة ما لتحديث خدماتك
‫على الرغم من أننا لم نركز على ذلك بعد.
‫دعنا نتحدث عن ذلك لأن التحديثات تحتوي على الكثير من الأشياء التي تحدث تحت الأغطية. تتمحور وظيفة تحديث Swarm حول نمط تحديث
‫متجدد للنسخ المتماثلة الخاصة بك. مما يعني أنه إذا كانت لديك خدمة تحتوي على أكثر من
‫نسخة متماثلة ، ونأمل أن تفعل ذلك ، فسيتم تمريرها افتراضيًا ، واحدًا تلو الآخر
‫، وتحديث كل حاوية عن طريق استبدالها بالإعدادات الجديدة التي تضعها في التحديث
‫يأمر.
‫سيقول الكثير من الناس أن المنسقين يمنعون التوقف في التحديثات ، لكنني لن أقول إن هذا
‫يمنع التوقف عن العمل.
‫سأقول إنه يحد من وقت التوقف عن العمل. لأن منع التوقف في أي نظام هو مهمة الاختبار.
‫تحتاج حقًا إلى بدء اختبار كيفية إجراء تحديثاتك وتحديد ما إذا كان يؤثر على المستخدمين لدي؟
‫هل تحديث قاعدة البيانات يؤثر على تطبيق الويب الخاص بي؟ ربما يفعل.
‫سيتم تحديث كل تطبيق لديك خدمة له والتأثير على الأشياء الأخرى المحيطة به
‫بشكل مختلف.
‫هذا ليس عمل منسق.
‫لا يستطيع
‫المنسق تحديد أن هذا البروتوكول هو بروتوكول قاعدة بيانات ، وهذا البروتوكول هو بروتوكول تطبيق REST
‫سهل.
‫لذلك ستكون هذه أشياء مختلفة ومعقدة تحتاج إلى التعامل معها.
‫في حالة تحديثات الخدمة ، إذا كانت مجرد واجهة برمجة تطبيقات REST أو واجهة ويب لا تفعل أي شيء خيالي
‫مثل مآخذ الويب أو الاقتراع الطويل ، إذا كان شيئًا بسيطًا جدًا كهذا أو موقع ويب ثابت ، فمن
‫المحتمل أن يكون لديك تحديث سهل و لن تكون مشكلة.
‫لكن خدمات أخرى مثل قواعد البيانات أو التخزين الدائم أو أي شيء يتطلب اتصالاً مستمراً ...
‫هذه ستكون دائمًا تحديًا بغض النظر عن ما تحاول تحديثه.
‫لذا اختبر مبكرًا واختبر كثيرًا.
‫كما قلت من قبل ، سيحل هذا بالتأكيد محل الحاويات في معظم التحديثات. ما لم تكن تقوم بتحديث ملصق أو بعض
‫البيانات الوصفية الأخرى بالخدمة ، فسيتم
‫طرح كل حاوية وتغييرها بواحدة جديدة تمامًا.
‫فقط كن مستعدا لذلك لديها العديد من الخيارات. في الواقع ، آخر مرة حسبتها
‫، كان هناك 77 خيارًا على الأقل لأمر التحديث. ولكن كل ما تريد القيام به
‫يمكن تعديله.
‫الكثير من الخيارات في أمر التحديث هي في الواقع إنشاء خيارات تحتوي
‫على a -rm و a -add في نهايتها. لأنه إذا كان خيارًا يمكن استخدامه لقيم متعددة
‫، دعنا نقول منفذًا للنشر أو متغير بيئة ، يمكنك استخدام العديد منها.
‫حق؟
‫لذلك ، يجب أن تكون قادرًا على إخبار أمر التحديث الذي تقوم بإضافته وتلك التي تقوم بإزالتها.
‫سنرى هؤلاء في دقيقة.
‫يتضمن هذا أيضًا خيارات التراجع والفحص الصحي.
‫يجب أن تنظر إلى الخيارات الخاصة بهم ومعرفة ما إذا كانت قيمهم الافتراضية ليست مثالية لتطبيقك
‫واختبار إعدادات مختلفة لمعرفة ما إذا كان ذلك يجعل التحديث أسهل بالنسبة لك ونظامك.
‫سترى أيضًا أن لدينا خيارات القياس والتراجع هنا وهي أوامر خاصة بهم الآن.
‫لقد اعتادت أن تكون خيارات يتعين عليك تحديدها باستخدام مقياس الارتداد أو - ، ولكن الكثير من الأشخاص يستخدمون
‫تلك الخيارات بشكل متكرر لدرجة أن Docker يجعلهم الآن نوعًا من المواطنين من الدرجة الأولى في سطر
‫الأوامر.
‫قد يضيفون المزيد من هؤلاء في المستقبل.
‫أخيرًا ، قبل أن نصل إلى بعض الأمثلة ، إذا كنت تقوم بعمل مكدسات ، فإن نشر المكدس على نفس المكدس يعد
‫تحديثًا.
‫في الواقع ، لا يوجد خيار منفصل لتحديثات المكدس.
‫أنت فقط تقوم بنشر مكدس بنفس الملف الذي تم تحريره.
‫بعد ذلك ، ستعمل مع أوامر الخدمة والشبكات وكل شيء آخر تقوم به. ستعمل معهم للتأكد من
‫ضرورة إجراء أية تغييرات ، وتطبيقها.
‫دعنا نلقي نظرة على بعض الأمثلة السريعة ثم ننتقل إلى سطر الأوامر.
‫ربما يكون هذا المثال هو المثال الأكثر شيوعًا الذي ستستخدمه ، وهو تغيير صورة
‫الخدمة.
‫في كل مرة تقوم فيها بتحديث تطبيقك وتقوم بإنشاء صورة جديدة ، سيتعين
‫عليك تنفيذ أمر تحديث الخدمة ، مع اسم الصورة ، ثم اسم الخدمة.
‫لذلك في هذه الحالة ، ربما كان لدي طلبي بعلامة 1. 2. 0.
‫وفي هذه الحالة ، أقوم الآن بتطبيق 1. 2. صورة واحدة ، وستحدد الخدمة
‫، آه نعم ، هذه صورة مختلفة عما لدي في خدمتي
‫، وسنذهب ونقوم بتحديثها. في الخطوة التالية ، نعرض كيف يمكنك القيام بأشياء متعددة في وقت
‫واحد داخل أمر تحديث واحد.
‫يمكنك إضافة متغير بيئة مع env-add ، وبعد ذلك يمكنك إزالة منفذ مع publish
‫-rm.
‫يمكننا أيضًا إضافة وإزالة متغيرات البيئة ونشر المنافذ في نفس
‫أمر التحديث بقدر ما نريد. في هذا الأخير ، يوضح هذا كيف يمكننا استخدام أوامر القياس
‫والتراجع الجديدة هذه على خدمات متعددة في نفس الوقت. ومن مزايا استخدامها على أمر التحديث
‫أنها يمكن أن تنطبق على خدمات متعددة.
‫في هذه الحالة ، سأقوم بالفعل بتغيير عدد النسخ المتماثلة للويب وخدمات واجهة برمجة
‫التطبيقات في نفس الوقت.
‫كما قلت منذ فترة ، في تحديثات Swarm ، ليس لديك أمر نشر مختلف.
‫إنه مجرد نشر مكدس عامل الإرساء نفسه ، مع الملف الذي قمت بتحريره ، وتتمثل مهمته في العمل مع
‫جميع الأجزاء الأخرى من واجهة برمجة التطبيقات لتحديد
‫ما إذا كانت هناك أي تغييرات مطلوبة ، ثم نشرها مع تحديث الخدمة.
‫حسنا. لنبدأ بإنشاء خدمة بالفعل حتى نتمكن من معالجتها ببعض أوامر التحديث.
‫تنشئ خدمة docker -p 8088 80 name web ، وسنستخدم Nginx ، وسنقوم بتحديد إصدار كما
‫ينبغي دائمًا في الإنتاج.
‫إنه لأمر رائع ، الآن بعد أن أصبح لدينا بالفعل في النصف الأخير من عام 2017 ، خيار الفصل من خلال خدمتنا الخاصة بإنشاء الأوامر وتحديثها
‫، يمكننا بالفعل رؤية هذا يحدث بشكل متزامن في الوقت الفعلي.
‫لذلك سيكون هذا مفيدًا لأوامر التحديث لمعرفة كيفية طرح التحديثات فعليًا عبر سطر الأوامر.
‫حسنا. الآن ، إذا قمنا بعمل خدمة لرسو السفن ، فإننا نرى أن خدمتنا
‫تعمل وأنها تحتوي على نسخة واحدة من نسخة متماثلة واحدة ، لذا فمن الجيد أن تبدأ.
‫الآن دعنا نوسع نطاق خدمتنا حتى نتمكن من الحصول على المزيد من النسخ المتماثلة للعمل معها. مقياس خدمة عامل الإرساء
‫الويب = 5. وقد رأيت للتو أن أحد هؤلاء كان يعمل بالفعل ، وكان
‫على الأربعة الآخرين أن يبدأوا. لقد مر بسرعة كبيرة بالنسبة لي لأنني قمت بالفعل
‫بتنزيل الصورة ، ولكن قد تستغرق صورتك بضع دقائق بينما تكون في حالة انتظار حيث يتم تنزيل الصورة على العقد
‫الأخرى.
‫حسنا.
‫لنقم بتحديث مستمر بتغيير صورة Nginx.
‫سترى هنا أنني اخترت صورة أقدم.
‫الآن ، لا يهتم Docker بما هي الصورة في الواقع.
‫يمكن أن يكون تطبيقًا مختلفًا
‫تمامًا لكل ما يهمه. إنها تعرف فقط أنه في هذه الخدمة ، أقوم بتغييرها إلى صورة مختلفة.
‫تذكر ، بشكل افتراضي ، سوف يمر هنا واحدًا تلو الآخر.
‫ستقوم أولاً بإزالته ، وإنشاء واحدة جديدة ، وبعد ذلك عندما يكون هذا الشخص
‫جيدًا ، ويبدو جيدًا ، سيبدأ في المرحلة التالية. في المثال التالي ، سنقوم بتغيير المنفذ المنشور.
‫لكن لا يمكنك تغيير منفذ.
‫عليك فعلاً إضافتها وإزالتها في نفس الوقت.
‫لذلك في هذه الحالة ، نظرًا لأننا نشرناها لأول مرة برقم 8088 ، نحتاج إلى إجراء تحديث لخدمة
‫عامل الإرساء لنشر rm 8088. لست بحاجة إلى تحديد القيمة. أنا فقط بحاجة إلى تحديد المفتاح. ثم سنقوم بنشر
‫النسخة الجديدة 9090. ثم القيمة ، وهي في هذه الحالة 80. سترى أنه سيقوم بنفس عملية
‫التحديث كما كان من قبل.
‫المثال الأخير الذي أريد التحدث عنه هو نوع من الإكرامية. لأنك غالبًا ما تواجه تحديًا في شيء
‫يسمى إعادة التوازن. أو إذا قمت بتغيير عدد العقد أو إذا قمت بتحريك الكثير من الأشياء ، إذا كان
‫لديك الكثير من الحاويات في سربك ، فقد تجد أنها ليست متساوية بالفعل. ربما يكون لديك بعض العقد التي
‫تعتبر خفيفة جدًا على عدد الحاويات قيد التشغيل والأخرى
‫التي تحتوي على الكثير. إذا كان لديك الكثير من الأشياء المتغيرة ، فلن يقوم Swarm بتحريك الأشياء
‫للحفاظ على توازن كل شيء من حيث عدد الموارد المستخدمة.
‫ولكن ، ما يمكنك فعله هو أنه يمكنك فرض تحديث للخدمة حتى بدون تغيير أي شيء في تلك الخدمة.
‫بعد ذلك ، سيعيد إصدار المهام ، وفي هذه الحالة ، سيختار العقد الأقل استخدامًا ، وهو شكل من أشكال إعادة التوازن.
‫في كثير من الأحيان في سرب أصغر عندما أقوم بتحريك شيء كبير ، أو إضافة مجموعة من العقد ، أصبح لدي فجأة مجموعة
‫من الخوادم الفارغة لا تفعل شيئًا وأحتاج إلى العمل عليها.
‫لذا ما سأفعله هو أخذ واحدة أو اثنتين من خدماتي ، وسأقوم بتحديث خدمة عامل الإرساء
‫- القوة ، وفي هذه الحالة سوف يتم تنفيذ المهام واستبدالها بالكامل.
‫بالطبع سيستخدم الجدول الافتراضي للبحث عن العقد مع أقل عدد من الحاويات
‫وأقل عدد من الموارد المستخدمة.
‫هذا نوع من الحيلة للالتفاف على قدر غير متساو من العمل على عقدك.
‫تذكر أن تقوم بالتنظيف بإزالة الخدمة التي أنشأناها في هذه المحاضرة.