‫أحد الوعود الكبيرة للحاويات هو أنه يمكننا بسهولة نشر تطبيقاتنا كما لو كنا خدمة منصة ، كما تعلمون ، مثل
‫Heroku أو شيء من هذا القبيل. يمكننا القيام بذلك على أجهزة أي شخص ، سواء كان ذلك على أجهزتنا
‫، أو مزود خدمة سحابية ، سواء كانت افتراضية أو مادية. باستخدام Docker ، يمكن أن تعمل تطبيقاتنا بنفس الطريقة سواء كانت
‫Amazon أو Azure أو DigitalOcean أو Linode أو Rackspace أو Google Cloud أو أيًا كان. بدون كل ميزات النظام الأساسي هذه ، كيف يمكننا
‫بسهولة نشر وصيانة العشرات أو المئات أو حتى الآلاف من الحاويات عبر العديد
‫من الخوادم أو المثيلات؟ أو العقد أو القطرات أو أيا كان.
‫يؤدي ذلك إلى تحمل بعض المشكلات الجديدة حقًا التي لم تكن في السابق مشكلات للمنظمات الصغيرة.
‫نعلم جميعًا عن Netflix والمؤسسات الكبيرة مثل ذلك النطاق إلى آلاف وآلاف العقد وعشرات
‫الآلاف من العقد ، ولديهم الكثير من المهندسين.
‫ولكن ، إذا كان لديك شخصان فقط في فريقك ، أو إذا كنت مجرد مطور منفرد ، فكيف يمكنك أخذ حاوياتك
‫وتوسيع نطاقها والتعامل مع دورة حياتها بأكملها؟ من نشرها ، إلى بدئها ، إلى إعادة تشغيلها
‫، إلى إعادة إنشائها ، إلى حذفها وتحديثها وكل ذلك.
‫نبدأ في طرح أسئلة حول كيفية قيام Docker بذلك بالضبط أم أنه يفعل ذلك على الإطلاق؟
‫بعض الأسئلة التي نطرحها على أنفسنا هي أشياء مثل ، كيف يمكننا التوسع؟ كيف نرتقي؟ كيف نضمن إعادة
‫تشغيل حاوياتنا إذا فشلت؟
‫كيف نستبدل تلك الحاويات عندما يكون لدينا بالفعل تحديثًا لها؟ وهو ما يسمى نشر الأخضر الأزرق في
‫الوقت الحاضر ، مما يعني أنه ليس لديك أي وقت تعطل وأنك تأخذ الخوادم من
‫التجمع لجلب خوادم جديدة. ينتهي بك الأمر دائمًا بشيء متاح حتى
‫لا تشعر بالإحباط أبدًا عند التحديث. كيف نعرف ما إذا كان لدينا عشرات العقد أو حتى ثلاث عقد
‫فقط حيث بدأنا تلك الحاويات؟ ما هي العقدة التي توجد بها الحاوية الخاصة بنا؟ كيف نتحدث عبر تلك العقد
‫أو الخوادم المختلفة مع شبكتنا داخل الحاويات؟
‫عندما يتعلق الأمر بالأمن ، كيف نتأكد من أن حاوياتنا تعمل فقط على الأجهزة التي
‫كنا نعتزم تشغيلها عليها؟
‫الآن بعد أن قمنا بنقل الأشياء ونشرها ديناميكيًا بسرعة فائقة ، كيف نخزن المعلومات
‫الخاصة التي نحتاجها لحاوياتنا ، مثل الأسرار أو كلمات المرور؟
‫لذلك يقودنا هذا إلى تطور كبير في نطاق ما يحاول Docker حله.
‫عندما يتحدث الناس معي ويعتقدون أن Docker هو مجرد وقت تشغيل للحاوية ،
‫فهذا عندما أذكر للتو Swarm Mode ، وهي ميزة جديدة تمامًا في عام 2016 تجمع سنوات من فهم احتياجات
‫الحاويات وكيفية تشغيلها فعليًا في الانتاج.
‫لذا ، فإن Swarm في جوهره هو في الواقع حل لتجميع الخوادم يجمع أنظمة تشغيل مختلفة أو
‫مضيفين أو عقدًا ، أو
‫أيًا كان ما تريد الاتصال به ، في وحدة واحدة يمكن إدارتها يمكنك بعد ذلك تنظيم دورة حياة
‫الحاويات الخاصة بك فيها. فقط للتوضيح ، نحن لا نتحدث في الواقع عن Swarm ، والذي سأسميه
‫Swarm Classic ، والذي كان مكونًا إضافيًا لـ Docker قبل 1. خرج 12. لقد كانت حقًا حاوية يتم تشغيلها داخل
‫Docker ، والتي أخذت حقًا
‫أوامر تشغيل Docker وكررها على خوادم متعددة.
‫لقد حلت بالفعل بعض المشكلات ، لكن لم يكن بالمقياس الذي نحتاجه حقًا لحل 80٪ من الحالات لكيفية
‫تشغيل الحاويات الخاصة بك.
‫في صيف عام 2016 ، في Dockercon
‫2016 ، أعلن Docker بالفعل عن Swarm Kit ، والتي كانت عبارة عن مجموعة من المكتبات أو مجموعة أدوات تتعلق بمجموعة كاملة
‫من ميزات Swarm الجديدة.
‫ثم تمسكوا بهذا الحق في خادم Docker. طوال هذه الدورة التدريبية ، لديك بالفعل الميزات
‫المتاحة لك في CLI وعلى الخادم الخاص بك.
‫الآن وصلنا أخيرًا إلى الغوص فيها.
‫في يناير من عام 2017 ، 1. تم إصدار 13 ، وبالطبع نظرًا لأن Swarm Mode كان
‫جديدًا في عام 2016 ، فسوف يستمرون في تحسينه في السنوات القادمة.
‫في يناير ، أضافوا ميزات إضافية تسمى Stacks and Secrets ، بالإضافة إلى
‫مكافآت أخرى سنتحدث عنها لاحقًا. من المهم ملاحظة أن Swarm لم يتم تمكينه بالفعل خارج الصندوق.
‫في الواقع ، على جهازك ، لا يمكنك استخدام هذه الأوامر المدرجة هنا الآن. سيعطيك هذا خطأ بالفعل
‫لأنه يجب تمكين Swarm.
‫كان هذا أحد أهداف التصميم هو عدم تأثير أي من رموز Swarm على برنامج Docker
‫الخفي الحالي ، وأن جميع الأدوات والأنظمة الموجودة التي كانت تعتمد بالفعل على
‫Docker ، أو ربما كان لديهم تنسيق خاص بهم فوق Docker ، الاستمرار في العمل وعدم التدخل
‫من قبل Swarm
‫التي أصبحت الآن جزءًا من Docker. بعض المفاهيم الأساسية حقًا قبل أن نبدأ في الغوص ، هي أن هذه
‫المربعات الزرقاء التي تراها في الأعلى هي ما نسميه عقد المدير ، ولديها بالفعل قاعدة بيانات
‫محلية عليها تُعرف باسم قاعدة بيانات Raft.
‫يخزن تكوينهم ويمنحهم جميع المعلومات التي يحتاجونها ليكونوا السلطة
‫داخل سرب.
‫إذن ما لدينا هنا هو ثلاثة مديرين مختلفين تمت إضافتهم جميعًا إلى السرب ، ويحتفظون
‫جميعًا بنسخة من قاعدة البيانات هذه ويقومون بتشفير حركة المرور الخاصة بهم من أجل ضمان النزاهة وضمان الثقة
‫بأنهم قادرون على إدارة هذا السرب بشكل آمن .
‫أدناه باللون الأخضر ، لدينا بالفعل ملاحظات العمال. الآن يمكنك أن ترى في مفهوم Swarm
‫، لدينا الآن مديرين وعمال.
‫سيكون كل واحد من هؤلاء جهازًا افتراضيًا ، أو مضيفًا ماديًا ، يقوم بتشغيل بعض توزيعات خادم
‫Linux أو Windows.
‫يوضح هذا كيف أنهم جميعًا يتواصلون فعليًا بشأن ما نسميه طائرة التحكم ، وهي الطريقة
‫التي يتم بها إرسال الأوامر حول السرب وإجراءات المشاركة. في عرض أكثر تعقيدًا بعض الشيء ، لدينا قاعدة بيانات
‫توافق Raft التي ذكرتها ، والتي يتم تكرارها مرة أخرى بين جميع العقد.
‫يصدرون الأوامر للعمال.
‫يمكن للمديرين أنفسهم أن يكونوا أيضًا عاملين. بالطبع ، يمكنك تخفيض وترقية العمال والمديرين
‫في الدورين المختلفين.
‫عندما تفكر في مدير ، عادة ما تفكر في عامل لديه أذونات للتحكم في السرب.
‫مرة أخرى ، المتطلبات الوحيدة لكل خادم من هذه الخوادم هي تشغيل
‫Docker نفسه الذي تستخدمه بالفعل الآن. مع هذا المفهوم عن السرب ، وهؤلاء المديرين ، لدينا الآن مفاهيم جديدة
‫لما تبدو عليه حاوياتنا.
‫لذلك ، باستخدام أمر Docker run ، يمكننا بالفعل نشر حاوية واحدة فقط.
‫سيؤدي فقط إلى إنشاء حاوية.
‫كان دائمًا على أي جهاز كان Docker CLI يتحدث إليه.
‫عادة ما يكون هذا هو جهازك المحلي ، أو ربما خادم تم تسجيل الدخول إليه. لم يكن لدى أمر Docker run هذا
‫مفاهيم حول كيفية التوسع أو التوسع.
‫لذلك احتجنا إلى أوامر جديدة للتعامل مع ذلك.
‫هذا هو المكان الذي يأتي منه أمر خدمة Docker. في سرب ، يحل محل أمر Docker run
‫، ويسمح لنا بإضافة ميزات إضافية إلى حاويتنا عند تشغيلها ، مثل النسخ المتماثلة
‫لإخبارنا بعدد تلك التي تريد تشغيلها.
‫تُعرف هذه بالمهام.
‫يمكن أن تحتوي خدمة واحدة على مهام متعددة ، وستقوم كل واحدة من هذه المهام بتشغيل حاوية.
‫في هذا المثال ، أنشأنا خدمة باستخدام Docker service التي تم إنشاؤها لتدوير خدمة Nginx باستخدام
‫صورة Nginx كما فعلنا عدة مرات من قبل.
‫لكننا أخبرناها أننا نريد ثلاث نسخ طبق الأصل.
‫لذلك سوف تستخدم عقد المدير لتحديد مكانها في السرب لوضعها. بشكل افتراضي ، يحاول نشرها.
‫ستحصل كل عقدة على نسختها الخاصة من حاوية Nginx حتى النسخ المتماثلة الثلاثة التي أخبرناها
‫أننا بحاجة إليها.
‫هذا فهم سريع وأساسي لكيفية عمل المديرين وما يفعلونه في الخلفية.
‫كل هذه الميزات جديدة.
‫لا يقتصر الأمر على مجرد أخذ الأمر وتشغيله على واجهة برمجة التطبيقات مثلما نختبر مع أمر
‫تشغيل Docker.
‫هناك بالفعل واجهة برمجة تطبيقات Swarm جديدة تمامًا تحتوي على مجموعة من الخدمات الخلفية ، مثل المجدول
‫والمرسل والمخصص والمنسق ، والتي تساعد في اتخاذ قرارات حول ما يجب على العمال
‫تنفيذه في أي لحظة.
‫لذلك يقوم العمال بإبلاغ المديرين باستمرار ويطلبون عملًا جديدًا.
‫يقوم المديرون باستمرار بتوزيع عمل جديد وتقييم ما أخبرتهم بفعله مقابل ما
‫يفعلونه بالفعل.
‫ثم إذا كان هناك أي تسوية ستحدث ، فسيقومون بإجراء تلك التغييرات ، مثل ربما أخبرته
‫بتدوير ثلاث مهام أخرى متكررة في تلك الخدمة.
‫لذا سيدرك المنسق ذلك ثم يصدر الأوامر للعمال وهكذا.
‫مع وضع Swarm هذا ، نحصل في الواقع على مجموعة مليئة بالميزات من القدرات خارج الصندوق والتي تسمح لنا بالفعل باستخدام
‫مهارات Docker الحالية لدينا لنشر حاوياتنا على الإنترنت بطريقة موثوقة ، وحل الكثير
‫من المشاكل التي سنواجهها بمجرد أن نبدأ الإنتاج.