تكثيف نشر البرامج - برنامج تعليمي لسرب Docker Swarm

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

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

حسنًا ، ولحسن الحظ ، هذا ما وصلنا إليه اليوم.

في هذه المقالة ، سوف نستكشف ماهية Docker Swarm ، جنبًا إلى جنب مع بعض الميزات الرائعة التي تقدمها. ثم سنلقي نظرة على الشكل الذي يبدو عليه استخدام وضع Swarm بالفعل والانتشار في سرب ، وسنختتم ببعض الأمثلة على شكل العمليات اليومية مع سرب منتشر. من المستحسن بالتأكيد معرفة أساسية بـ Docker والحاويات ، ولكن يمكنك التحقق من منشور المدونة الممتاز هذا أولاً إذا كنت جديدًا في الحاويات.

ما هو عامل الميناء سرب؟

قبل أن نتعمق في إنشاء ونشر سربنا الأول ، من المفيد أن يكون لديك فكرة عن ماهية Docker Swarm. كان Docker نفسه موجودًا منذ سنوات ، ويعتقد معظم الناس اليوم أنه وقت تشغيل حاوية. في الواقع ، يتكون Docker من العديد من القطع المختلفة ، تعمل جميعها معًا. على سبيل المثال ، يتم التعامل مع جزء وقت تشغيل الحاوية من خلال مكونين أصغر ، يسمى runC و containerd. نظرًا لتطور Docker وإعادته إلى المجتمع ، فقد اكتشفوا أن إنشاء هذه المكونات الأصغر هو أفضل طريقة للنمو وإضافة الميزات بسرعة. على هذا النحو ، لدينا الآن وضع SwarmKit و Swarm ، والذي تم إنشاؤه مباشرة في Docker.

Docker Swarm هو محرك تنسيق الحاوية. على مستوى عالٍ ، يتطلب الأمر تشغيل عدة محركات Docker على مضيفين مختلفين ويتيح لك استخدامها معًا. الاستخدام بسيط: أعلن عن تطبيقاتك كمكدسات من الخدمات ، ودع Docker يتولى الباقي. يمكن أن تكون الخدمات أي شيء من طبعات التطبيق إلى قواعد البيانات ، أو الأدوات المساعدة مثل Redis أو RabbitMQ. يجب أن يبدو هذا مألوفًا إذا كنت قد عملت مع عامل البناء في التطوير ، حيث إنه نفس المفهوم تمامًا. في الواقع ، إعلان المكدس هو حرفياً مجرد ملف docker-compose.yml مع بناء جملة الإصدار 3.1. هذا يعني أنه يمكنك استخدام تكوين تكوين مشابه (وفي كثير من الحالات متطابق) للتطوير ونشر السرب ، لكني أتقدم على نفسي قليلاً هنا. ماذا يحدث عندما يكون لديك حالات Docker في وضع Swarm؟

لا تسقط من الطوافة

لدينا نوعان من العقد (الخوادم) في عالم Swarm: المديرين والعاملين. من المهم أن تضع في اعتبارك أن المديرين هم أيضًا عمال ، ولديهم فقط مسؤولية إضافية تتمثل في الحفاظ على سير الأمور. يبدأ كل سرب بعقدة مدير واحدة تم تعيينها كقائد. من هناك ، إنها مجرد مسألة تشغيل أمر واحد لإضافة العقد بشكل آمن إلى السرب.

يتوفر Swarm بشكل كبير بفضل تنفيذه لخوارزمية Raft. لن أخوض في الكثير من التفاصيل حول Raft نظرًا لوجود برنامج تعليمي رائع بالفعل حول كيفية عمله ، ولكن إليك الفكرة العامة: تقوم العقدة الرئيسية بالتحقق باستمرار من عقد زملائها من المديرين ومزامنة حالاتهم. من أجل "قبول" تغيير الحالة ، تتوصل عقدة المدير إلى توافق كبير ، والذي يحدث عندما تقر غالبية العقد بتغيير الحالة.

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

لنفترض أن لدينا ثلاث عقد للمدير تسمى A و B و C. بالطبع ، A هو قائدنا الشجاع. حسنًا ، في يوم من الأيام ، يتسبب خطأ عابر في الشبكة في حدوث خطأ في عدم الاتصال بالشبكة ، تاركًا "ب" و "ج" وشأنهما. نظرًا لعدم سماع B و C لفترة طويلة (بضع مئات من المللي ثانية) ، انتظر B و C فترة زمنية عشوائية قبل تقديم أنفسهم للانتخاب وإخطار الآخر. بالطبع ، أول من يتقدم للانتخاب ، في هذه الحالة ، سيتم انتخابه. في هذا المثال ، يصبح B هو القائد الجديد ، ويتم استعادة النصاب القانوني. ولكن بعد ذلك ، تطور الحبكة: ماذا يحدث عندما يعود "أ" إلى الإنترنت؟ سيعتقد أنه لا يزال القائد ، أليس كذلك؟ كل انتخابات لها مصطلح مرتبط بها ، لذلك تم انتخاب "أ" بالفعل في الفصل الدراسي 1. بمجرد عودة "أ" عبر الإنترنت ويبدأ في طلب "ب" و "ج" ، سيتفضلون بإعلامه بأن "ب" هو زعيم الفصل 2 ، و سوف يتنحى A.

هذه العملية نفسها تعمل على نطاق أوسع ، بالطبع. يمكن أن يكون لديك أكثر من ثلاث عقد مدير. سأضيف ملاحظة سريعة أخرى بالرغم من ذلك. يمكن لكل سرب أن يتحمل عددًا محددًا من خسائر المدير. يمكن أن يخسر سرب من عقد المدير (n-1)/2 المديرين دون فقدان النصاب القانوني. هذا يعني أنه بالنسبة لسرب من ثلاثة مدراء ، يمكنك أن تخسر واحدًا ، أما بالنسبة لخمسة مدراء فقد تخسر اثنين ، إلخ. يعود السبب الكامن وراء ذلك إلى فكرة إجماع الأغلبية ، وهو بالتأكيد شيء يجب مراعاته أثناء انتقالك إلى الإنتاج.

جدولة المهام والتسوية

لقد أثبتنا حتى الآن أن مديرينا بارعون حقًا في الحفاظ على المزامنة. رائعة! لكن ماذا يفعلون في الواقع؟ هل تتذكر كيف قلت إنك تنشر مجموعة من الخدمات إلى Swarm؟ عندما تعلن عن خدماتك ، فإنك تزود Swarm بمعلومات مهمة حول الكيفية التي تريد بها تشغيل خدماتك بالفعل. يتضمن هذا معلمات مثل عدد النسخ المتماثلة التي تريدها لكل خدمة ، وكيفية توزيع النسخ المتماثلة ، وما إذا كان يجب تشغيلها فقط على عقد معينة ، وأكثر من ذلك.

بمجرد نشر الخدمة ، فإن مهمة المديرين هي التأكد من استمرار تلبية أي متطلبات نشر قمت بتعيينها. لنفترض أنك نشرت خدمة Nginx وحددت أنه يجب أن يكون هناك ثلاث نسخ متماثلة. سيرى المديرون أنه لا توجد حاويات قيد التشغيل ويوزعون الحاويات الثلاثة بالتساوي عبر العقد المتاحة.

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

اكتشاف الخدمة وموازنة الحمل

أريد أن أشير إلى تفاصيل مهمة ولكنها دقيقة من المثال الأخير: إذا كان Swarm يبدأ بذكاء الحاويات على العقد التي يختارها ، فإننا لا نعرف بالضرورة مكان تشغيل هذه الحاويات. قد يبدو هذا مخيفًا في البداية ، لكنه في الواقع أحد أقوى ميزات Swarm.

متابعةً لمثال Nginx نفسه ، تخيل أننا أخبرنا Docker أن هذه الحاويات يجب أن تعرض المنفذ 80. إذا وجهت متصفحك إلى عقدة تقوم بتشغيل تلك الحاوية على المنفذ 80 ، فسترى محتوى هذه الحاوية. ليس هناك مفاجأة. لكن ما قد يكون مفاجئًا هو أنك إذا أرسلت طلبك إلى عقدة لا تشغل تلك الحاوية ، فستظل ترى نفس المحتوى! ماذا يحصل هنا؟

يستخدم Swarm في الواقع شبكة دخول لإرسال طلبك إلى عقدة متاحة تقوم بتشغيل تلك الحاوية ، وهو يوازنها في نفس الوقت. لذلك إذا قدمت ثلاثة طلبات إلى نفس العقدة ، فمن المحتمل أن تصطدم بالحاويات الثلاثة المختلفة. طالما أنك تعرف IP لعقدة واحدة في السرب ، يمكنك الوصول إلى أي شيء يعمل فيه. على العكس من ذلك ، يتيح لك هذا توجيه موازن التحميل (مثل ELB) على جميع العقد الموجودة في السرب دون الحاجة إلى القلق بشأن ما يتم تشغيله في المكان.

لا يتوقف عند التوصيلات الخارجية. تحتوي الخدمات التي تعمل على نفس المكدس على شبكة تراكب تتيح لها التواصل مع بعضها البعض. بدلاً من الترميز الثابت لعناوين IP في التعليمات البرمجية الخاصة بك ، يمكنك ببساطة استخدام اسم الخدمة كاسم المضيف الذي تريد الاتصال به. على سبيل المثال ، إذا احتاج تطبيقك إلى الاتصال بخدمة Redis المسماة "redis" ، فيمكنه ببساطة استخدام "redis" باعتباره اسم المضيف وسيقوم Swarm بتوجيه طلبه إلى الحاوية المناسبة. ونظرًا لأن هذا يعمل بسلاسة في التطوير مع docker-compose وفي الإنتاج باستخدام Docker Swarm ، فلا داعي للقلق بشأنه عند نشر تطبيقك.

المتداول التحديثات

إذا كنت في عمليات ، فربما تكون قد تعرضت لنوبة ذعر عندما يحدث خطأ فادح في تحديث الإنتاج. قد يكون تحديث رمز سيئًا ، أو حتى مجرد خطأ في التكوين ، ولكن فجأة توقف الإنتاج! الاحتمالات هي أن الرئيس لن يهتم بأي من الحالتين. سيعرفون فقط أنه خطأك. حسنًا ، لا تقلق ، فإن Swarm يدعم هذا أيضًا.

عند تحديث خدمة ما ، يمكنك تحديد عدد الحاويات التي يجب تحديثها في كل مرة وماذا يجب أن يحدث إذا بدأت الحاويات الجديدة في الفشل. بعد حد معين ، يمكن لـ Swarm إما إيقاف التحديث أو (اعتبارًا من Docker 17.04) إعادة الحاويات إلى الصورة والإعدادات السابقة. لا تقلق بشأن إحضار القهوة لرئيسك في العمل صباح الغد.

حماية

أخيرًا ، ولكن ليس في أي مكان قريب ، يأتي Docker Swarm بميزات أمان رائعة خارج الصندوق. عندما تنضم عقدة إلى السرب ، فإنها تستخدم رمزًا لا يتحقق من نفسه فحسب ، بل يتحقق أيضًا من انضمامه إلى السرب الذي تعتقد أنه كذلك. من تلك اللحظة فصاعدًا ، تتم جميع الاتصالات بين العقد باستخدام تشفير TLS المتبادل. يتم توفير هذا التشفير وإدارته تلقائيًا بواسطة Swarm ، لذلك لا داعي للقلق بشأن تجديد الشهادات ومتاعب الأمان النموذجية الأخرى. وبالطبع ، إذا كنت تريد فرض دوران مفتاح ، فهناك أمر لذلك.

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

الغوص في السرب

إذا كنت مثلي ، فأنت تتوق للقفز والاستفادة من كل هذه الميزات في جولة! لذلك دون مزيد من اللغط ، دعنا نتعمق!

مثال على تطبيق Docker Swarm

لقد قمت بإنشاء تطبيق Flask بدائي للغاية لإظهار قوة وسهولة استخدام Docker Swarm. يعرض تطبيق الويب ببساطة صفحة تخبرك بالحاوية التي قدمت طلبك ، وعدد الطلبات الإجمالية التي تم تقديمها ، وما هي كلمة مرور قاعدة البيانات "السرية".

تم تقسيمها إلى ثلاث خدمات: تطبيق Flask الفعلي ، وكيل عكسي Nginx ، ومخزن مفاتيح Redis. في كل طلب ، يزيد التطبيق من مفتاح num_requests في Redis ، لذلك بغض النظر عن مثيل Flask الذي تصل إليه ، سترى العدد الصحيح من الطلبات ينعكس.

جميع الكود المصدري متاح على GitHub إذا كنت تريد "التحقق" مما يحدث.

العب مع Docker!

لا تتردد في استخدام الخوادم الخاصة بك أثناء استعراض هذا البرنامج التعليمي ، لكنني أوصي بشدة باستخدام play-with-docker.com إذا كنت تريد الانتقال إليه فقط. إنه موقع يديره عدد قليل من مطوري Docker ويتيح لك تدوير العديد من الشبكات العقد التي تم تثبيت Docker عليها مسبقًا. سيتم إغلاقها بعد أربع ساعات ، لكن هذا كثير في هذا المثال!

تكوين سرب

حسنا ، ها نحن ذا! انطلق وأنشئ ثلاث مثيلات في PWD (play-with-docker) أو قم بتدوير ثلاثة خوادم في خدمة VPS المفضلة لديك (الخادم الخاص الافتراضي) وقم بتثبيت محرك Docker عليها جميعًا. ضع في اعتبارك أنه يمكنك دائمًا إنشاء صورة وإعادة استخدامها عند إضافة العقد في المستقبل. لا يوجد فرق من حيث البرامج بين عقدة المدير والعقدة العاملة ، لذلك لا تحتاج إلى الاحتفاظ بصورتين مختلفتين.

لا تزال تدور؟ لا تقلق ، سأنتظر. حسنًا ، سنقوم الآن بإنشاء أول عقدة مدير وقائد. في المرة الأولى ، قم بتهيئة سرب:

 docker swarm init --advertise-addr <node ip here>

استبدل <node_ip_here> بعنوان IP الخاص بالعقدة. في PWD ، يتم عرض عنوان IP في الجزء العلوي ، وإذا كنت تستخدم VPS الخاص بك ، فلا تتردد في استخدام عنوان IP الخاص بخادمك طالما أنه يمكن الوصول إليه من العقد الأخرى في شبكتك.

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

 docker swarm join-token manager

انسخ الأمر الناتج وقم بتشغيله على العقدتين الثانية والثالثة. هوذا سرب من ثلاث عقد! دعنا نتحقق من أن جميع عقدنا موجودة بالفعل. سيسرد أمر docker node ls جميع العقد الموجودة في سربنا. يجب أن نرى شيئا من هذا القبيل:

 $ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS su1bgh1uxqsikf1129tjhg5r8 * node1 Ready Active Leader t1tgnq38wb0cehsry2pdku10h node3 Ready Active Reachable wxie5wf65akdug7sfr9uuleui node2 Ready Active Reachable

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

توقف لحظة لتقدير مدى سهولة ذلك ، ودعنا ننشر تطبيقنا الأول!

شحنه!

في غضون ذلك ، وعد فريق تطوير الأعمال العميل بأنه سيتم نشر تطبيقه الجديد وجاهزًا في غضون ساعة! نموذجي ، أعرف. لكن لا داعي للقلق ، فلن نحتاج إلى الكثير من الوقت تقريبًا ، حيث تم بناؤه باستخدام Docker! كان المطورون لطفاء بما يكفي لإعارتنا ملف docker-compose :

 version: '3.1' services: web: image: lsapan/docker-swarm-demo-web command: gunicorn --bind 0.0.0.0:5000 wsgi:app deploy: replicas: 2 secrets: - db_password nginx: image: lsapan/docker-swarm-demo-nginx ports: - 8000:80 deploy: mode: global redis: image: redis deploy: replicas: 1 secrets: db_password: external: true

سنقوم بتفكيكها في لحظة ، لكن ليس هناك وقت لذلك بعد. دعنا ننشرها! انطلق وأنشئ ملفًا على العقدة الأولى يسمى docker docker-compose.yml compose.yml وقم بتعبئته بالتكوين أعلاه. يمكنك القيام بذلك بسهولة باستخدام echo "<pasted contents here>" > docker-compose.yml .

في المعتاد ، يمكننا فقط نشر هذا ، ولكن يشير التكوين الخاص بنا إلى أننا نستخدم سرًا يسمى db_password ، لذلك دعنا ننشئ هذا السر بسرعة:

 echo "supersecretpassword" | docker secret create db_password -

رائعة! كل ما علينا فعله الآن هو إخبار Docker باستخدام التكوين الخاص بنا:

 docker stack deploy -c docker-compose.yml demo

عند تشغيل هذا الأمر ، سترى Docker ينشئ الخدمات الثلاث التي حددناها: web و nginx و redis . ومع ذلك ، نظرًا لأننا أطلقنا اسم العرض التوضيحي المكدس الخاص بنا ، فقد تم تسمية خدماتنا فعليًا باسم demo_web و demo_nginx و demo_redis . يمكننا إلقاء نظرة على خدماتنا قيد التشغيل عن طريق تشغيل الأمر docker service ls ، والذي يجب أن يظهر شيئًا كالتالي:

 $ docker service ls ID NAME MODE REPLICAS IMAGE PORTS cih6u1t88vx7 demo_web replicated 2/2 lsapan/docker-swarm-demo-web:latest u0p1gd6tykvu demo_nginx global 3/3 lsapan/docker-swarm-demo-nginx:latest *:8000->80/ tcp wa1gz80ker2g demo_redis replicated 1/1 redis:latest

هاهو! قام Docker بتنزيل صورنا إلى العقد المناسبة وإنشاء حاويات لخدماتنا. إذا لم تكن النسخ المتماثلة بكامل طاقتها بعد ، فانتظر لحظة وتحقق مرة أخرى. من المحتمل أن Docker لا يزال يقوم بتنزيل الصور.

نظرا لصدقه

لا تأخذ كلامي (أو كلمة Docker) على الرغم من ذلك. دعنا نحاول الاتصال بتطبيقنا. يخبر تكوين خدمتنا Docker أن يعرض NGINX على المنفذ 8000. إذا كنت تستخدم الأشخاص ذوي الإعاقة ، فيجب أن يكون هناك ارتباط أزرق في أعلى الصفحة يقول "8000". اكتشف الأشخاص ذوي الإعاقة تلقائيًا أن لدينا خدمة تعمل على هذا المنفذ! انقر فوق ذلك ، وسوف يوجهك إلى العقدة المحددة على المنفذ 8000. إذا قمت بتدوير الخوادم الخاصة بك ، فانتقل ببساطة إلى أحد عناوين IP لخوادمك على المنفذ 8000.

سيتم الترحيب بك بشاشة ذات تصميم جميل تمنحك بعض المعلومات الأساسية:

قم بتدوين الحاوية التي قدمت طلبك ثم قم بتحديث الصفحة. الاحتمالات تغيرت. لكن لماذا؟ حسنًا ، أخبرنا Docker بإنشاء نسختين متماثلتين من تطبيق Flask الخاص بنا ، ويقوم بتوزيع الطلبات على هاتين الحالتين. لقد تصادف أن تصطدم بالحاوية الأخرى في المرة الثانية. ستلاحظ أيضًا أن عدد الطلبات قد ارتفع لأن حاويتين Flask تتواصلان مع مثيل Redis الفردي الذي حددناه.

لا تتردد في محاولة الوصول إلى المنفذ 8000 من أي عقدة. لا يزال يتم توجيهك بشكل صحيح إلى التطبيق.

تبسيط السحر

في هذه المرحلة ، كل شيء يعمل ، ونأمل أن تكون قد وجدت العملية غير مؤلمة! دعنا نلقي نظرة فاحصة على ملف docker-compose.yml هذا ونرى ما قلناه بالفعل لـ Docker. على مستوى عالٍ ، نرى أننا حددنا ثلاث خدمات: web و nginx و redis . تمامًا مثل ملف الإنشاء العادي ، قمنا بتزويد Docker بصورة لاستخدامها لكل خدمة ، بالإضافة إلى أمر للتشغيل. في حالة nginx ، حددنا أيضًا أن المنفذ 8000 على المضيف يجب أن يربط إلى المنفذ 80 في الحاوية. كل هذا هو بناء الجملة القياسي حتى الآن.

الجديد هنا هو مفاتيح النشر والأسرار. يتم تجاهل هذه المفاتيح من خلال docker-compose ، لذلك لن تؤثر على بيئة التطوير الخاصة بك ، ولكن يتم استخدامها بواسطة docker stack . لنلق نظرة على خدمة الويب. الأمر بسيط بما فيه الكفاية ، نحن نخبر Docker أننا نرغب في تشغيل نسختين متماثلتين من تطبيق Flask الخاص بنا. كما نسمح لـ Docker بمعرفة أن خدمة الويب تتطلب db_password secret. هذا ما يضمن أن تحتوي الحاوية على ملف يسمى /run/secrets/db_password يحتوي على قيمة السر.

بالانتقال إلى Nginx ، يمكننا أن نرى أن وضع global مضبوط على الوضع العام. يتم replicated القيمة الافتراضية (المستخدمة ضمنيًا في الويب) ، مما يعني أننا سنحدد عدد النسخ المتماثلة التي نريدها. عندما نحدد global ، فإنه يخبر Docker أن كل عقدة في السرب يجب أن تشغل مثيلًا واحدًا بالضبط من الخدمة. قم بتشغيل docker service ls مرة أخرى ، ستلاحظ أن nginx يحتوي على ثلاث نسخ متماثلة ، واحدة لكل عقدة في سربنا.

أخيرًا ، طلبنا من Docker تشغيل مثيل واحد من Redis في مكان ما في السرب. لا يهم المكان ، حيث يتم توجيه حاويات الويب الخاصة بنا تلقائيًا إليه عندما يطلبون مضيف Redis.

استخدام سرب يوما بيوم

تهانينا على نشر تطبيقك الأول في Docker Swarm! لنأخذ لحظة لمراجعة بعض الأوامر الشائعة التي ستستخدمها.

تفقد سربك

بحاجة للتحقق من خدماتك؟ جرب docker service ls و docker service ps <service name> . يعرض لك الأول نظرة عامة عالية المستوى لكل خدمة ، ويمنحك الأخير معلومات عن كل حاوية تعمل للخدمة المحددة. يكون هذا مفيدًا بشكل خاص عندما تريد معرفة العقد التي تقوم بتشغيل خدمة.

المتداول التحديثات

ماذا عن الوقت الذي تكون فيه جاهزًا لتحديث التطبيق؟ حسنًا ، الشيء الرائع في docker stack deploy هو أنه سيطبق تحديثات على مكدس موجود أيضًا. لنفترض أنك دفعت صورة Docker جديدة إلى المستودع الخاص بك. يمكنك بالفعل تشغيل نفس أمر النشر الذي استخدمته في المرة الأولى وسيقوم سربك بتنزيل الصورة الجديدة ونشرها.

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

 docker service update \ --image lsapan/docker-swarm-demo-web:latest \ demo_web

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

 docker service update \ --image lsapan/docker-swarm-demo-web:latest \ --update-parallelism 1 --update-delay 30s \ demo_web

سيؤدي ذلك إلى تحديث حاوية واحدة في كل مرة ، في انتظار 30 ثانية بين التحديثات.

توسيع نطاق الخدمات لأعلى أو لأسفل

يعد وجود حاويتين للويب أمرًا رائعًا ، لكنك تعرف أيهما أفضل؟ بعد عشرة! توسيع نطاق الخدمات صعودًا وهبوطًا في سرب أمر سهل مثل:

 docker service scale demo_web=10

قم بتشغيل هذا الأمر وتحقق من إخراج docker service ps demo_web . سترى أن لدينا الآن عشر حاويات ، ثمانية منها بدأت منذ لحظة. إذا كنت مهتمًا ، يمكنك أيضًا الرجوع إلى تطبيق الويب وتحديث الصفحة عدة مرات لترى أنك تحصل الآن على أكثر من معرفي الحاوية الأصليين.

إزالة الأكوام والخدمات

تم نشر مكدساتك وخدماتك وتوسيع نطاقها ، رائع! لكن الآن تريد نقلها إلى وضع عدم الاتصال. يمكن القيام بذلك باستخدام الأمر rm المعني. لإزالة المكدس التجريبي الخاص بنا ، قم بتشغيل الأمر:

 docker stack rm demo

أو ، إذا كنت تفضل إزالة خدمة واحدة فقط ، فاستخدم فقط:

 docker service rm demo_web

عقد الصرف

تذكر عندما قمنا بتشغيل docker node ls في وقت سابق للتحقق من العقد في سربنا؟ قدمت مجموعة من المعلومات حول كل عقدة ، بما في ذلك مدى توفرها . بشكل افتراضي ، تكون العقد نشطة ، مما يعني أنها لعبة عادلة لتشغيل الحاويات. ومع ذلك ، هناك أوقات قد تحتاج فيها إلى فصل العقدة مؤقتًا عن الاتصال بالإنترنت لإجراء الصيانة. بالتأكيد ، يمكنك فقط إيقاف تشغيله وسوف يتعافى السرب ، ولكن من الجيد إعطاء Moby (حوت Docker) بعض الإشعار.

هذا هو المكان الذي تأتي فيه عقد التصريف. عندما تقوم بتمييز عقدة على أنها Drain ، فإن Docker Swarm سيفوض أي حاويات تعمل عليها إلى العقد الأخرى ، ولن تبدأ أي حاويات على العقدة حتى تقوم بتغيير توفرها مرة أخرى إلى نشط .

لنفترض أننا نريد استنزاف node1 . يمكننا الجري:

 docker node update --availability drain node1

سهل! عندما تكون مستعدًا لإعادته إلى العمل:

 docker node update --availability active node1

تغليف

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