‫Kubernetes أو Swarm.
‫إنه أحد الأسئلة الأكثر شيوعًا التي أحصل عليها بعد أن يتعلم
‫شخص ما ما يكفي عن التنسيق ليرغب بعد ذلك في اتخاذ قرار بشأن
‫أي منها يجب استخدامه.
‫أوصي بأن تشاهد أولاً مقاطع الفيديو
‫على Swarm ، خاصةً الفيديو الأول
‫لذلك. هذا هو Orchestration
‫المدمج في وضع Swarm لأنه مرة أخرى ، سيعطيك هذا خلفية
‫حول سبب أهمية التنسيق لحل مشاكل معينة.
‫ثم
‫شاهد أيضًا مقاطع الفيديو مسبقًا في هذا القسم حول Kubernetes حتى
‫تفهم خلفية كلتا الأداتين قبل المتابعة.
‫كخط
‫أساس هنا ، كلاهما أداتان تحلان مشاكل متشابهة. كلاهما منسق حاويات
‫يعملان في أعلى وقت
‫تشغيل الحاوية.
‫في سلسلة الفيديو هذه ، تعرفت على وقت تشغيل
‫حاوية Docker.
‫هناك أنواع أخرى الآن ، containerd و CRI-O.
‫حقًا ، Docker هو رقم 1.
‫يتم استخدامه في كل حالة تقريبًا.
‫كلاهما مدعوم من البائعين وفرق الأشخاص
‫الذين يعملون على المنتجات.
‫بشكل عام ، إذا اضطررت إلى إجراء تغريدة
‫للمقارنة بين الاثنين ، فسيكون من السهل إنشاء Swarm ، ومن السهل
‫إضافة العقد إليه ، ومن السهل البدء فيه ،
‫وإدارته بسهولة. لذا ، من السهل بالتأكيد
‫الشيء الوحيد الذي أود قوله لـ Swarm.
‫ولكنه لا يحل جميع حالات الاستخدام التي
‫تتمتع فيها Kubernetes بوظائف ومرونة وتخصيص
‫أكثر بكثير. يمكن أن تحل المزيد من المشاكل
‫، بطرق أكثر ، ولها أيضًا اعتماد ودعم على نطاق
‫أوسع.
‫بالنسبة لك ، من أجل مساعدتك في تحديد
‫أي واحد تريد استخدامه ، سنستعرض بعض
‫مزايا كل منها. أعتقد أنه من المهم حقًا بالنسبة
‫لنا جميعًا إذا كنت ستشارك في مجتمع DevOps وتستخدم هذه
‫الأدوات لحل مشاكل العمل ، يجب أن تعرف كليهما.
‫يجب أن تكون قادرًا على تثبيت كليهما ثم نشر التطبيقات
‫عليهما ، ومعرفة بعض الوظائف الأساسية
‫حول نشر التطبيقات ، وإنشاء خيارات الدخول لحركة المرور
‫الواردة ، ثم تحديث تلك التطبيقات.
‫أعتقد
‫أن هذا وحده سيوفر لك ما يكفي من الإلمام بالأدوات حتى تعرف الأداة
‫التي يجب استخدامها لحل المشكلات.
‫هناك العديد من المزايا لكل منها.
‫دعونا نقسم هذا بسرعة حقيقية. على جانب Swarm ،
‫كما كنت تتعلم طوال هذه الدورة ، فهي
‫تأتي مع Docker. لذلك ، فهو حل واحد يدعمه البائع.
‫مما يعني أن وقت تشغيل الحاوية والمنسق تم
‫إنشاؤهما بواسطة نفس الشركة.
‫هذا يجني الكثير من المكافآت ، بما في ذلك أقل تعقيدًا ، واستخدام
‫موارد أصغر لمجرد تشغيل الشيء.
‫يمتلك
‫تشغيل Swarm القليل جدًا من استخدام الموارد أعلى Docker.
‫تم تصميمه مع وضع سير عمل المطور في
‫الاعتبار. لذلك ، من الجيد جدًا
‫استخدام Ops والمطورين. كما قلت ، من السهل
‫نشر وإدارة منسق من هذا النوع.
‫يمكن أن تنمو بسهولة إلى عدة مئات ، إن لم يكن
‫الآلاف ، من العقد ، ولن تحتاج بالضرورة إلى
‫فريق كبير لإدارتها. قد تقول إنها
‫تتبع قاعدة 80/20 ، حيث تحتوي على 20٪ من
‫ميزات Kubernetes ، وهذا يحل 80٪ من حالات
‫الاستخدام لتشغيل الحاويات والتزامن.
‫الآن ، هذه ليست مقارنة علمية.
‫لا أعرف حقًا رقم الميزة بالضبط. لا أعرف حتى كيف
‫يمكنك فعل ذلك حقًا.
‫ولكن ، يبدو أن هذا هو الشعور عندما تقوم بتشغيل كلاً من أن تدرك أن
‫Swarm يحل غالبية حالات الاستخدام لتشغيل تطبيقات
‫الويب حلول تشغيل طويلة على الخوادم ، سواء كان ذلك في السحابة
‫أو مركز البيانات ، أو حتى على الأجهزة الصغيرة.
‫يبدو
‫أنه يعمل بشكل جيد خارج الصندوق. لديها ما تحتاجه. لديها الشبكات.
‫لديها الدخول. لديها التشفير.
‫كل تلك المواد. لديها قاعدة البيانات.
‫لذا ، خارج الصندوق ، إنه يحل بالفعل الكثير من المشاكل.
‫لكنها لا تحل جميع حالات الاستخدام ، لجميع السيناريوهات ، لتشغيل
‫تطبيق على جهاز.
‫هذا هو المكان الذي يمكن أن يملأ فيه Kubernetes الفجوة.
‫ميزة أخرى كبيرة لهذا هو أنه يعمل أينما
‫يعمل Docker. يبلغ عمر محرك Docker الآن
‫ست سنوات وبداية ثورة الحاوية بأكملها ، ويعمل
‫المحرك في أماكن أكثر من أي أداة أخرى.
‫إنه لا يعمل فقط على Linux ، بل يعمل على Windows.
‫إنه يعمل على Mainframe.
‫يتم تشغيله على أجهزة ARM ، مما يعني Embedded
‫و IoT و Raspberry Pis.
‫يعمل على ARM القديم ، ARM الجديد ،
‫32 بت ، 64 بت. كما قلت ، إنه فقط في كل مكان.
‫يتم تشغيله أصلاً على Windows Server لسنوات
‫حتى الآن منذ Server 2016.
‫لذلك ، فهو بالتأكيد أطول منسق مدعوم لبيئة
‫معمارية متنوعة ومتعددة ، إذا كانت هذه هي
‫احتياجاتك.
‫خارج الصندوق ، إنه آمن ، وقد سمعتني
‫أتحدث عن ذلك في هذه الدورة ، أنه عندما
‫تقوم بإنشاء Swarm وتضيف عقدًا ، فإنها تضمن مصادقة
‫Telus المتبادلة. يقوم بتشفير مستوى التحكم ويقوم بتشفير
‫قاعدة البيانات لحماية أسرارك في حالة
‫رغبتك في تخزينها.
‫هذا رائع لأنني وجدت الكثير من الفرق ، عندما تسرع في
‫المواعيد النهائية أو ربما
‫تكون غارقة قليلاً في التعقيد ، تميل
‫إلى نسيان أو تخطي بعض متطلبات الأمان التي تتطلبها أدوات أخرى
‫مثل Kubernetes. أخيرًا هنا ، أعتقد أنه من الأسهل
‫استكشاف الأخطاء وإصلاحها نظرًا لوجود أجزاء متحركة
‫أقل بها. هناك أشياء أقل يجب إدارتها.
‫نظرًا لأنه مدمج في Docker افتراضيًا ، إذا كنت تعرف كيفية استكشاف
‫أخطاء Docker وإصلاحها ، فمن المحتمل أنك تعرف كيفية استكشاف
‫أخطاء Swarm وإصلاحها.
‫يستخدم نفس سجلات البرنامج الخفي. يستخدم نفس أمر Docker
‫logs للتطبيقات. يستخدم نفس أمر أحداث Docker للنظر
‫في الأحداث الموجودة على العقد و Swarm نفسه.
‫الآن
‫يبدو هذا وكأنه الكثير من المزايا للسرب ، لكنني لا أريدك أن تعتقد
‫أن هذا سيكون دائمًا الشيء المناسب لك.
‫بشكل عام ، Swarm هي الأداة التي أوصي بها عندما يبدأ
‫الناس في العمل ويبدأون صغيرًا.
‫ربما يكون شخصًا واحدًا ، أو شخصًا واحدًا
‫أو شخصين أو ثلاثة في فريقهم ، وعليهم معرفة
‫ما إذا كان منسق صغير وبسيط سيعمل
‫معهم. أوصي دائمًا بـ Swarm أولاً ، ما
‫لم تكن تعلم تمامًا أنه يجب عليك استخدام Kubernetes ،
‫فإنني أوصي بـ Swarm. بمجرد أن تعتقد أنك وصلت إلى
‫بعض الحدود في Swarm وتعتقد أنه لا يمكنك الحصول على ما تحتاج إليه تمامًا
‫، فهذا هو الوقت المناسب لإلقاء نظرة
‫على Kubernetes.
‫دعنا نتحدث عن بعض هذه المزايا الآن.
‫أولاً ، يحب البائعون والسحب دعم Kubernetes
‫حقًا. نظرًا لأنه أصبح شائعًا للغاية
‫، وخاصة نوعًا من روح العصر في الأخبار ووسائل الإعلام
‫، فهو شيء يتطلع كل بائع الآن إلى التحقق
‫منه في قائمتهم التي ندعمها Kubernetes.
‫لذلك ، أود أن أقول إنه يتمتع على الإطلاق بأوسع خدمة سحابة
‫ودعم للموردين.
‫يقدم كل بائع سحابي عرضًا لـ Kubernetes ، لذلك إذا
‫كنت لا ترغب في تشغيله بنفسك ، فيمكنك فقط السماح
‫لهم ببدء تشغيل جميع الأنظمة ومن ثم تقوم
‫فقط بتشغيل تطبيقاتك هناك باستخدام ملفات نشر
‫Kubernetes. حتى بائعي البنية التحتية
‫لديهم الآن توزيع Kubernetes الخاص بهم بما في ذلك VMware
‫و Red Hat. حتى الشركات مثل Netflix
‫، التي تعتبر تقليديًا مجرد بائع تخزين ، لديها نسختها المعتمدة
‫أو التوزيع الخاص بها من Kubernetes.
‫لذا يبدو أن الشيء الواضح هنا هو أنه يتمتع بأكبر
‫قدر من التبني والدعم ، وهذا صحيح بالتأكيد.
‫ولكن بعد ذلك ، فإنه يحتوي أيضًا على أكبر مجموعة من حالات الاستخدام
‫المدعومة. نظرًا لأنه
‫يحتوي على العديد من الأشياء التي يجب تبديلها والتلاعب
‫بها ، والعديد من الميزات المختلفة وخيارات
‫الطرف الثالث ، فإنه يغطي بالتأكيد المزيد من حالات الحافة
‫ثم Swarm. في الواقع ، ستبدأ في رؤية هذا
‫مع البائعين الذين ربما تعمل معهم بالفعل اليوم
‫حيث سيقدمون الدعم الأول لـ Kubernetes
‫، وهي طريقتي للقول إن البائعين سيتطلعون لمعرفة كيف يمكنهم
‫دعم Kubernetes بمنتجهم قبل أن يزعجوا ذلك للذهاب لإلقاء نظرة على منتج
‫Docker's Swarm.
‫نظرًا لأن الصناعة نوعًا ما في هذا الموقف من
‫كل شيء يحتاج إلى دعم Kubernetes
‫، فستجد أن البائعين الذين لديك بالفعل قد يكون
‫لديهم بالفعل توزيع أو حل لتشغيل أدواتهم على
‫Kubernetes. على سبيل المثال ، مع Jenkins
‫، من شركة CloudBees.
‫إذا كنت قد اشتريت حل Enterprise الخاص بهم ، فإنهم
‫يقدمون لك أدوات Kubernetes ونماذج حول كيفية تشغيله.
‫هذا لا يعني أنه لا يمكنك تشغيل Jenkins على Swarm.
‫إنه يعمل بشكل رائع هناك.
‫هذا يعني فقط أنك ستحصل على دعم أفضل
‫من البائع لذلك.
‫الميزة الأخيرة التي سأذكرها هنا هي نوع
‫من الميزة الغريبة. سأقوم بإلقاء الضوء على هذا المصطلح
‫حيث لم يتم طرد أي شخص من قبل لشراء شركة IBM.
‫الآن كان هذا القول شائعًا منذ عقود عندما كانت IBM
‫أكبر بائع للحوسبة والاستعانة بمصادر خارجية لأجهزتك
‫، والإطارات الرئيسية الخاصة بك ، وأجهزة الكمبيوتر الخاصة
‫بك ، وكان هناك طوال هذا الوقت حيث كانوا يقتلونها
‫حقًا في السوق.
‫بشكل أساسي ، إذا لم تتمكن من اتخاذ قرار بشأن البائع
‫الذي تريد الذهاب معه. إذا ذهبت للتو إلى الطريق
‫الآمن ، فستذهب إلى شركة IBM.
‫لن يتم طردك حقًا بسبب ذلك لأنه كان البائع
‫الموثوق به في ذلك الوقت.
‫أود أن أقول ، بشكل عام ، بالنسبة لمنصة Kubernetes
‫ككل ، أصبح هذا هو الحال الآن.
‫أود أن أزعم أنه قد وصل إلى حد كونه عنصر تحقق من مدراء
‫المعلومات ومديري المعلومات.
‫قد يكون ذلك جيدًا وسيئًا بعض الشيء ، لأن هذا قد يعني
‫أنه سيتم إخبارك بتشغيل Kubernetes على الرغم من عدم وجود
‫متطلبات فنية لديك حتى الآن.
‫لقد أخبرت للتو من قبل إدارتك أننا بحاجة إلى تشغيل
‫Kubernetes. قد يكون هذا ، بالنسبة لهم
‫، مجرد شيء يريدون تشغيله بغض النظر عن المتطلبات أو
‫الفوائد الفنية ، أو مقارنته بمنصات مختلفة.
‫من الواضح أن هذا جزء من هذا العالم السياسي حيث لا يتم دائمًا
‫اتخاذ قرارات تكنولوجيا المعلومات بناءً على الجدارة أو المتطلبات
‫التقنية وحدها.
‫يمكن أن يكون ذلك في كثير من الأحيان من خلال
‫سهولة استخدام شرائه. بمعنى آخر ، إذا كان لديك
‫بالفعل بائع لديه بائع ، فيمكنك فقط استخدام منتجهم بدلاً
‫من منتج آخر لأنه أسهل.
‫حسنًا ، قد تتمتع تجربة فريقك في الخلفية بتجربة
‫أفضل من وظائفهم أو مشاريعهم السابقة.
‫لذا ، ستنشر ذلك لأن شخصًا ما
‫يعرفه بالفعل. أو ربما ستشتريه لأنه لسوء الحظ
‫، قرأت إدارتك مجلة ، أو قرأت الإنترنت ، وأخبرهم
‫الإنترنت أنهم بحاجة إلى اختيار منتج معين
‫مثل Kubernetes.
‫لذلك ، هذا هو الشيء الذي يطلبون منك استخدامه.
‫في الواقع ، عندما أقوم بورش عمل مباشرة وأسأل الناس
‫عن سبب اختيارهم للمنسق الذي يديرونه ، فإن الإجابة
‫الأكثر شيوعًا التي أحصل عليها منهم ، للأسف ، لا تزال ، قال لي
‫رئيسي أن أفعل ذلك.
‫لذلك ، لا يكون للناس دائمًا رأي في ما يديرونه ، ولهذا
‫السبب أحاول منحك توازنًا جيدًا بين الأدوات والميزات
‫الخاصة بكل منهما حتى تكون الشخص الأكثر تعليمًا في فريقك وتكون
‫قادرين على مساعدتهم في تلبية المتطلبات الفنية
‫الحقيقية ومساعدتك في اتخاذ القرار الأفضل.