‫حسنا.
‫أينما كنت تقوم بتشغيل Docker الخاص بك ، يمكننا بالفعل إنشاء سرب عقدة واحد لأغراض الاختبار الخاصة
‫بنا.
‫الطريقة التي يمكنني من خلالها معرفة ما إذا كان Swarm قيد التشغيل أم لا ، يمكنني فقط القيام بمعلومات عامل التحميل وستلاحظ أن Swarm
‫غير نشط.
‫لذلك نحن نعلم أن Swarm لم يتم تمكينه هنا. مرة أخرى ، بشكل افتراضي ، لا يقوم Docker بتمكين
‫أي من ميزات Swarm.
‫يمكنني تشغيل بدء تشغيل سرب عامل ميناء للتهيئة. استغرق ذلك حوالي نصف ثانية وانتهينا.
‫ما لدينا الآن هو سرب عقدة واحدة مع كل الميزات والوظائف التي نخرجها من الصندوق.
‫لذلك ربما كان هذا هو أقصر عرض توضيحي لهذه الدورة التدريبية بأكملها.
‫أعني ، ماذا حدث للتو؟ لقد كتبنا أمرًا واحدًا وسحرًا. لم يكن في الواقع أي سحر.
‫لقد كان الكثير من الأشياء السريعة والفعالة للغاية في برمجة Go لـ Docker ، ولكن بشكل أساسي ، مباشرة
‫خارج الصندوق
‫، يقوم بمجموعة من عناصر PKI والأمان. يقوم بإنشاء شهادة جذر للسرب يستخدمها لتأسيس
‫الثقة وتوقيع الشهادات لجميع العقد وجميع المديرين. ستنشئ شهادة خاصة لعقدة المدير
‫الأولى لأنها مدير مقابل عامل.
‫ثم يقوم بإنشاء هذه الرموز التي يمكننا استخدامها بالفعل على العقد الأخرى للانضمام إلى هذا السرب.
‫ثم مجموعة من الأشياء الأخرى في الخلفية حيث تُمكِّن واجهة برمجة تطبيقات السرب وتنشئ شيئًا يسمى قاعدة
‫بيانات توافق الطوافة ، والتي سنتحدث عنها لاحقًا في جزء الإنتاج من الدورة التدريبية.
‫أضف إلى معلوماتك أن Raft هو بروتوكول يضمن في الواقع الاتساق عبر عقد متعددة ، وهو
‫مثالي للاستخدام في السحابة حيث لا يمكننا ضمان توفر أي شيء في أي
‫وقت.
‫يقوم بإنشاء قاعدة البيانات هذه على القرص. يخزن تكوين السرب والمدير
‫الأول ويقوم بتشفيره بالفعل.
‫بافتراض أنك تستخدم الإصدار 1. 13 أو أحدث. ثم سينتظر أي عقد أخرى قبل أن يبدأ فعليًا
‫في نسخ قاعدة البيانات إليها.
‫مرة أخرى ، سيتم تشفير كل حركة المرور التي ستقوم بها بمجرد إنشاء عقد أخرى.
‫كان أحد المكونات الرئيسية لـ Swarm التي ميزته عند ظهوره لأول مرة
‫هو أننا لسنا بحاجة إلى نظام تخزين قيمة مفتاح إضافي أو بعض بنية قاعدة البيانات لتكون إدارة تكوين
‫الواجهة الخلفية لسربنا.
‫إذا كنت تعمل في هذا المجال لسنوات أو حتى عقود ، فهناك هذا المفهوم عادةً لـ config db ، وهو
‫نظام قاعدة البيانات المنفصل الذي تحتاج عادةً إلى جعله زائدًا عن الحاجة والذي سيخزن جميع المعلومات
‫حول نظام التنسيق والأتمتة الخاص بك. قام Swarm بالفعل ببناء ذلك مباشرة
‫في Docker مباشرة في البرنامج الخفي والتعامل معه لنا.
‫لا نحتاج حقًا إلى فعل أي شيء. لا توجد كلمات مرور تقلق بشأنها. لا توجد خدمات خاصة للبدء
‫أو أي شيء من هذا القبيل.
‫لذا ، عد إلى سطر الأوامر.
‫ستلاحظ هنا أنه يتحدث عن ... إذا كنت أرغب في إضافة عامل إلى السرب
‫، فأنا فقط بحاجة إلى قص هذا ولصقه على الخوادم الأخرى التي أود إضافتها.
‫لاحقًا ، سنقوم بالفعل ببناء سرب متعدد العقد ، لكن في الوقت الحالي ،
‫سنبقي هذا في عقدة واحدة. دعونا نلقي نظرة على اثنين من الأوامر سوف تخرج منه.
‫أول شيء يمكننا القيام به هو docker node ls. في هذه الحالة ، نرى فقط عقدة المدير التي أنشأناها.
‫ستلاحظ أنه تم وضع علامة عليه كقائد ، ولا يمكن أن يكون هناك سوى قائد واحد في كل مرة بين جميع المديرين.
‫مرة أخرى ، نظرًا لأننا حصلنا على واحد فقط ، فمن الواضح أنه القائد. يمكننا إلقاء نظرة على المساعدة لمعرفة
‫الخيارات الأخرى المتوفرة لدينا هنا. حقًا ، أوامر العقد المستخدمة لإدخال الخوادم الخاصة بك
‫وإخراجها من السرب ، أو ترقيتها من العمال إلى المديرين ، أو تخفيض ترتيبها من المديرين إلى العمال.
‫إذا عدت إلى أمر dockers swarm قليلاً ، فسنلاحظ أنه في الواقع نطاق ضيق للغاية
‫للأمر.
‫إنها حقًا مجرد تهيئة ، إما الانضمام أو المغادرة.
‫أمر الفتح الجديد الذي سنتحدث عنه في محاضرة لاحقة.
‫في الوقت الحالي ، دعنا نركز على أمر خدمة Docker الجديد المثير.
‫مرة أخرى ، تحل الخدمة في سرب محل Docker run.
‫لا أعرف حقيقة ، لكنني أعتقد حقًا أن هذا تمحور حول فكرة أننا لا نريد
‫كسر وظيفة تشغيل Docker الحالية ، ولكن تم دائمًا إنشاء Docker run من الألف إلى الياء
‫كحل مضيف واحد.
‫كانت الفكرة كلها هي التركيز على الحاويات المحلية على النظام الذي يتحدث إليه. بينما عندما نبدأ الحديث عن
‫الكتلة ، فإننا لا نهتم كثيرًا بالعقد الفردية.
‫ربما لا نسميها في الواقع. نحن نعاملهم مثل الماشية ، إذا كنت قد سمعت عن
‫الحيوانات الأليفة مقابل تشبيه الماشية حيث أنها مجرد رقم.
‫نحن لا نذهب بشكل فردي إلى كل عقدة ونبدأ في تشغيل حاوية فردية.
‫نحن في الحقيقة نلقي بالمتطلبات على السرب في شكل خدمات وبعد ذلك سننظم كيف يحتاج إلى وضع
‫كل ذلك ، والعقد التي يحتاجون أن يكونوا عليها ،
‫ونعلم فقط أنها تدعمنا. إنشاء خدمة عامل ميناء هو كيف
‫نعطيها بعض الطلبات الجديدة. لنفعل شيئًا بسيطًا حقًا.
‫دعنا في الواقع نبدأ صورة جبال الألب. ثم سنحصل على صورة جبال الألب فقط استخدم الأمر
‫ping لتصل إلى 8. 8. 8. 8 ، وهو في الواقع خادم Google DNS ، لكننا نريد حقًا
‫أن نمنحه شيئًا ما للقيام به أثناء التحقيق في ما يحدث.
‫بعد ذلك ، سترى تشغيل عامل الإرساء ، فإنه يبصق معرفًا ، فقط هذا ليس معرف الحاوية. هذا هو في الواقع معرف
‫الخدمة.
‫سترى أن لدينا الآن خدمة واحدة مدرجة. تمامًا كما هو الحال مع أمر Docker run الخاص بنا ،
‫نظرًا لأننا لم
‫نقم بتسميته ، فقد أعطاها اسمًا عشوائيًا. يمكننا أن نرى أنه تم نسجها بالفعل.
‫واحد من واحد. عندما تنظر إلى الخدمات ، سترى دائمًا
‫هذا الرقم مع / في المنتصف. يمثل ذلك الرقم الموجود على اليسار هو عدد الأشخاص الذين يركضون بالفعل.
‫والواحد الموجود على اليمين هو العدد الذي حددته لتشغيله.
‫هدف المنسق هو جعل هذه الأرقام متطابقة ، مهما تطلب الأمر.
‫لكن هذا مرة أخرى لا يظهر لنا الحاوية الحقيقية.
‫هذا يعرض لنا فقط قائمة بخدماتنا ، حتى نتمكن من التعمق أكثر قليلاً.
‫نحن نقوم بخدمة docker ps ، ومن ثم نعطيها اسم الخدمة أو معرّفها ، وهذا سيُظهر لنا في الواقع المهام
‫أو الحاويات الخاصة بهذه الخدمة. سترى أنه مشابه لأمر docker container ls ، ولكنه يحتوي
‫بالفعل على مكون العقدة هذا لأنه عندما تتعامل مع سيناريوهات خوادم متعددة ، فقد نحتاج إلى
‫معرفة الخادم الذي يعمل عليه بالفعل. ستلاحظ أنها أعطتها بالفعل
‫اسمًا لزيادة اسم الخدمة.
‫إذا عدنا إلى أمر docker container ls ، فسيظل هذا يعمل.
‫في هذه الحالة ، يقوم تزامن Swarm بالفعل بإضافة بعض المعلومات إلى الأسماء والصور
‫الفعلية التي يتم تشغيلها. سنغطي بعض هذه الاختلافات الدقيقة لاحقًا أيضًا.
‫في الوقت الحالي ، دعنا نأخذ هذه الخدمة فعليًا ودعونا نوسعها. لذلك ، نستخدم تحديث خدمة عامل الإرساء ، ثم اسم خدمتنا
‫، أو المعرف في هذه الحالة ، سأقوم بعمل المعرف. وأريد تغيير سمة خاصة بالخدمة.
‫في هذه الحالة ، أريد تغيير عدد النسخ المتماثلة.
‫لذا إذا قمنا بعمل خدمة الرصيف مرة أخرى ، فسنرى الآن ثلاثة من ثلاثة. إذا قمنا بعمل خدمة عامل إرساء ps ، فإننا
‫نرى الآن ثلاث مهام. ستلاحظ أنه تم إنشاء اثنين فقط منذ ثوان.
‫إذا كنا سريعين بما فيه الكفاية ، وإذا كنا ننشر شيئًا كبيرًا بما يكفي ، فيمكننا بالفعل تشغيل الخدمة
‫ls ورؤيتها تظهر لنا صفرًا من ثلاثة. واحد من ثلاثة.
‫ستزداد في الواقع مع بدء الأشياء. لقد حدث فقط أن Alpine كان موجودًا بالفعل على هذا الجهاز
‫، من حيث صورته ، ولم يستغرق الأمر وقتًا طويلاً لبدء أمر ping.
‫لا يمكننا أن نكون بهذه السرعة.
‫الأمر المثير للاهتمام في أمر التحديث هذا هو أنه يمكنك تخيل الفرق بين أمر Docker
‫run الذي قد تستخدمه على مطور واحد أو خادم اختبار أو على جهازك المحلي ، ومخاوف الإنتاج
‫المتمثلة في الاحتفاظ دائمًا بشيء متاح قدر الإمكان.
‫هذا أحد أهداف تصميم Swarm. هذا الأمر الذي لم نستخدمه بالفعل
‫حتى الآن هو أمر تحديث Docker. كان هذا أمرًا لحاويات تشغيل Docker التي سمحت لنا بتحديث
‫بعض المتغيرات على الحاوية قيد التشغيل دون الحاجة إلى قتلها وإعادة تشغيلها.
‫ترتبط جميع هذه الخيارات تقريبًا بتحديد استخدام الموارد لتلك الحاوية والتحكم فيه.
‫نظرًا لأن هذا أحد الأشياء النموذجية التي تراها عند تشغيل تطبيق طويل المدى هو أنك
‫بحاجة إلى تغيير موارده ربما لأن قواعد البيانات أصبحت أكبر وتحتاج إلى المزيد من ذاكرة الوصول العشوائي.
‫أو ربما لديك عملية خارجة عن السيطرة تستهلك الكثير من وحدة المعالجة المركزية وتحتاج إلى الحد منها.
‫إذا قدمنا مساعدة بشأن أمر تحديث خدمة عامل الإرساء ، فسترى أن لدينا الكثير من الخيارات.
‫لأن الهدف من خدمة Swarm هو أنها قادرة على استبدال الحاويات وتحديث التغييرات
‫في الخدمة دون إزالة كل شيء.
‫إذا كانت لديك خدمة بها ثلاث حاويات ، فيمكنك تقنيًا إزالة واحدة تلو الأخرى لإجراء تغيير وإجراء نوع من التحديث المتداول
‫، وهو النمط الأزرق والأخضر الذي تحدثنا عنه. هذا هو السبب في أننا نرى الكثير من الخيارات
‫هنا لأنه يمكننا تغيير هذه الخيارات التي قد تتطلب إعادة تشغيل الحاوية
‫، لكن السرب سيتأكد بذكاء من أن الطريقة التي نقوم بتحديثها في نمط يضمن توافرًا
‫ثابتًا.
‫لذا عد إلى قائمة حاويات عامل الإرساء بسرعة حقيقية. ستلاحظ أن لدينا هؤلاء الثلاثة
‫الآن ، وماذا لو دخلت و ، نوعًا ما كنت مارقًا ، صنعت حاوية رصيف ، وحددت إحدى هذه الحاويات
‫، وأجبرتها ... لنفترض أنني تغلبت على الأول وأخرجته.
‫حسنا.
‫الآن أقوم بخدمة عامل الإرساء ، وترى كيف يظهر اثنان من ثلاثة؟
‫نظرًا لأنني دخلت خلف الجزء الخلفي من Swarm وأخذت بالفعل حاوية جارية
‫، فسوف تحدد ذلك وستطلق حاوية جديدة في غضون ثوانٍ لتحل محل الحاوية التي
‫سقطت.
‫لذا ، إذا قمت بخدمة عامل ميناء ps في حالة فاترة ، فسترى أنها تعرض بالفعل تاريخ المهمة الأولى هنا
‫في القائمة وهي أنها فشلت وبدأت مهمة جديدة منذ 24 ثانية.
‫تتمثل إحدى مسؤوليات نظام تزامن الحاويات في التأكد من أن الخدمات التي
‫حددتها تعمل دائمًا ، وإذا فشلت ، فإنها
‫تتعافى من هذا الفشل. ما هي طريقة مختلفة عن Docker Run ، أليس كذلك؟ لن يؤدي تشغيل عامل الإرساء
‫إلى إعادة إنشاء حاوية.
‫لهذا السبب عندما نقوم بأي من أوامر خدمة Docker هذه ، فإننا في الواقع لا نتحدث
‫مباشرة إلى إجراء مثل إنشاء حاوية.
‫نحن في الواقع نخبر نظام تنسيق ، ضع هذه الوظيفة في قائمة الانتظار الخاصة بك.
‫عندما يمكنك الوصول إليها ، يرجى تنفيذ الإجراءات على السرب التي طلبتها هنا. هذا فرق كبير.
‫إنه خفي في سطر الأوامر ، لكنه فرق كبير لأنه يعني أن هناك احتمالات للتراجع.
‫هناك تخفيف للفشل والكثير من الذكاء المدمج في ذلك.
‫في هذه الحالة ، إذا أردت بالفعل إزالة كل هذه الحاويات
‫، فسيتعين علي إزالة الخدمة. سأضطر إلى القيام بخدمة عامل ميناء rm.
‫ثم فاترة.
‫إذا قمنا بعمل خدمة لرسو السفن ، فإننا لا نرى شيئًا. إذا قمنا بعمل حاوية لرسو
‫السفن ، فإننا نرى ثلاث حاويات.
‫أوه وهناك نذهب.
‫هذا يظهر هناك الأتمتة التي تحدث على الواجهة الخلفية.
‫تمكنا من إظهار أننا حذفنا الخدمة بسرعة ، لكن نظام التنسيق لم يمر بجميع عملياته
‫لتنظيف الخدمة والمهمة التي تكمن وراءها. يجب أن تكون هذه المفاهيم سهلة الفهم لأنها تتوسع
‫حقًا في مفاهيم تشغيل Docker التي كانت لدينا سابقًا في هذه الدورة.
‫بعد ذلك ، دعنا في الواقع نبني سربًا متعدد العقد ونبدأ في توسيع نطاق حاوياتنا.