‫حسنا. لقد بدأت في هاتين المحاضرتين الأخيرتين
‫في رؤية جميع المجالات المختلفة لـ Kubernetes التي تتوسع
‫، أليس كذلك. إذا كنت تفكر في الأمر
‫على أنه مثل هذا المركز الصغير للكرة الأرضية للثنائيات والبنية التحتية
‫الأساسية لـ Kubernetes ، تستمر الحلقات
‫في التكاثر بشكل أكبر ، أليس كذلك.
‫مع
‫Ingress ونمط المشغل وتعريفات الموارد المخصصة.
‫انها فقط تكبر.
‫الآن ، أريد أن أتحدث إليكم عن
‫كيفية زيادة حجمها. في الواقع ، ربما يكون هذا هو المجال الوحيد الذي يكون
‫فيه الجنون بعض الشيء.
‫هذا في مجال الآراء حول كيفية
‫نشر YAML لهذه الموارد ، صحيح.
‫حتى الآن ، لقد رأيت تطبيق kubectl.
‫حسنًا ، سيساعدك هذا على البدء ، ومن المحتمل أن يساعدك ذلك
‫في أول عملية نشر لمنظم حاوية ، صحيح.
‫سوف ... سواء
‫كنت تستخدم Swarm أو Kubernetes ، ستحصل على
‫YAML هذا ، وسيكون لديك ريبو ، وستخزنه هناك ، وسيكون ذلك منطقيًا.
‫بمجرد أن تبدأ في توسيع ذلك ، ويكون لديك فرق ، ولديك أذونات
‫وأنواع مختلفة من الأذونات ،
‫والأشخاص الذين يتعين عليهم التحكم في الأشياء
‫أو الموافقة عليها ، يصبح كل شيء أكثر تعقيدًا.
‫ما حدث في هذا العالم حول كيفية نشر تطبيقاتك
‫على Kubernetes ، وهذا أساسًا
‫ما يدور حوله هذا الأمر. سوف نتحدث عن حقيقة أنه
‫يوجد الآن أكثر من 60 ، حسنًا ، هناك مثل 80 ،
‫لكن الكثير منها لم يعد مشاريع حقيقية أو
‫ميتة أو مؤرشفة.
‫ولكن هناك 60 طريقة على الأقل
‫لإضافة أدوات أعلى Kubernetes لمجرد
‫نشر تطبيقاتك على Kubernetes.
‫هناك الكثير من الآراء ، صحيح.
‫هذا هو المكان الذي تبدأ فيه الآراء في الظهور
‫حول كيفية القيام بذلك. كل شيء من Jenkins X إلى Helm
‫وما بعده. هناك كل هذه الأشياء
‫والآراء المختلفة حول ، حسنًا ، Kubernetes
‫ليست بنية تحتية لها رأي ، لذا فنحن بحاجة إلى آراء لتوجيه
‫الأشخاص خلال عملية نشر وتحديث
‫تطبيقاتهم.
‫لذلك ، كل شخص لديه واحدة. إذا كنت قد قرأت أي شيء
‫عن كيفية القيام بذلك في Kubernetes ، فمن
‫المحتمل أنك سمعت عن Helm. Helm to Kubernetes هو Kubernetes
‫للحاويات بشكل أساسي. Helm هي الطريقة الواقعية التي
‫يبحث بها كل شخص عن إنشاء
‫قوالب واستخدام معايير قوالب لنشر تطبيقات
‫الجهات الخارجية أو إنشاء مخططات Helm مخصصة
‫خاصة بهم.
‫هذا ما يطلق عليه هو المخططات.
‫إنه في الأساس نموذج YAML ، ولكنه يسمح لشركة
‫Helm بإنشاء أو إخراج YAML الذي
‫سينتقل بعد ذلك إلى مجموعة Kubernetes
‫من أجلك. لكن ، هذا ليس الرأي الوحيد ، صحيح.
‫قلت أن هناك أكثر من 60 على الأقل في المرة الأخيرة التي نظرت فيها.
‫هناك بالفعل ورقة Google التي وضعتها في الروابط
‫المرجعية. إنها قديمة بعض الشيء ، لكنها آخر قائمة
‫معروفة لجميع الأماكن التي يمكن أن تجد هذه
‫الطرق المختلفة للنشر فيها. لدى Docker أنفسهم رأيهم الخاص المثير
‫للاهتمام ، خاصة إذا كنت تريد أن تكون محكمًا في نظام
‫Docker البيئي. هذا هو إنشاء
‫على Kubernetes.
‫إذا كان لديك Docker Desktop ، فيمكنك
‫اليوم تمكين Kubernetes ، وهو ما ربما تكون قد قمت به بالفعل في
‫هذا الجزء من الدورة التدريبية. يمكنك استخدام نشر مكدس عامل
‫الإرساء وبدلاً من الانتقال إلى Swarm ، يمكنك إرساله
‫إلى Kubernetes.
‫إذا نظرت إلى أمر نشر مكدس عامل الإرساء ونظرت
‫إلى المساعدة الخاصة بذلك ، فسترى أن هناك
‫خيارًا هناك لتحديد المنسق الذي تريد
‫استخدامه. في الواقع ، في إعدادات
‫Docker Desktop ، يمكنك إخباره بتفضيل Kubernetes أو اختياره
‫افتراضيًا لأوامر نشر المكدس.
‫هذا مثير للاهتمام لأنني اعتقدت أن Compose YAML كان مختلفًا
‫عن Kubernetes YAML.
‫حسنًا ، هذا ما يفعله تطبيق Compose على Kubernetes الآن.
‫إنها أداة خارجية بشكل أساسي.
‫إنها طريقة عنيدة ، من Docker ، حول كيفية نشر ،
‫أو تفسير ، أو ترجمة ، YAML of Compose ، تنسيق
‫Compose ، إلى تنسيق YAML الخاص بـ
‫Kubernetes.
‫لذلك ، لقد وضعت رابطًا هنا لتتمكن من التحقق
‫من ذلك إذا كنت شخصًا سيعتبر Docker Enterprise
‫كأداة مؤسستك لـ Kubernetes و Swarm و Docker
‫بشكل عام.
‫بعد ذلك ، يجب عليك بالتأكيد التحقق من ذلك لأن ذلك يأتي خارج
‫الصندوق. أحد الأشياء اللطيفة
‫حول هذه الميزة هو أن سير العمل يظل بسيطًا
‫للغاية. في الأساس ، أنت تستخدم
‫Compose YAML طوال خط الأنابيب بأكمله ، ويمكنك استخدامه
‫في Ops و Dev. لا يجب عليك أن تقول ، حسنًا
‫للمطورين ، يجب أن يكون لديك YAML لـ Compose وللإنتاج
‫والخوادم ، يجب أن يكون لديك Kubernetes YAML هذا ، وهي
‫غير متوافقة ، صحيح.
‫كانت الفكرة مع Docker هي أنهم يعتقدون أن هذا أمر معقد
‫للغاية. دعونا نبسطها.
‫دعنا فقط نستخدم معيار YAML واحدًا لخط أنابيب التحكم
‫بالكامل.
‫وأنا أحبه. تكمن المشكلة في أنه لا
‫يدعم كل شيء تحت الشمس يمكن لـ Kubernetes
‫القيام به ، أليس كذلك. أعني بوضوح ، أن لدينا
‫صفحة واحدة في Docker Docs لإدراج جميع ميزات
‫ملف Compose. لكن Kubernetes YAML معقد
‫للغاية بحيث يتعين علينا البحث في أوامر متعددة
‫ومراجع API وكل ذلك ، صحيح.
‫من الواضح أنه لا يمكن أن يفعل كل شيء.
‫الشيء الجميل موجود على موقع الويب Compose for Kubernetes
‫، حيث يتحدثون في GitHub عن الميزات المختلفة التي يدعمها.
‫إنها قاعدة 80/20 هناك.
‫بمعنى آخر ، إنه يدعم 20 بالمائة من ميزات Kubernetes
‫التي ربما يحتاجها 80 بالمائة منا.
‫لذلك ، يمكنك البدء في ذلك ومعرفة ما إذا كان سير العمل
‫هذا سيعمل من أجلك. شيء جميل آخر هو أنه
‫في أواخر عام 2018 ، قاموا بفتح المصدر الذي
‫Compose على Kubernetes بحيث يمكنك الآن نشره على
‫أي بنية تحتية لـ Kubernetes لديك ، وهو يعمل
‫فقط كمترجم فوري. إنه يترجم في أي وقت تستخدم
‫فيه ملف Compose من Docker وباستخدام أوامر Docker ، فإنه
‫سيربط مجموعة Kubernetes الخاصة بك نيابةً عنك ،
‫ويترجم ذلك تلقائيًا إلى Kubernetes YAML ويذهب
‫بعيدًا. يمكنك في الواقع ،
‫في هذه المرحلة ، تجاهل الكثير من Kubernetes YAML
‫لتطبيقاتك. كما تعلم ، ربما تستخدم
‫Kubernetes YAML لأشياء البنية التحتية التي
‫لا تنشرها كل يوم. ولكن ، ربما لمطوريك لتسهيل
‫كتابة Compose YAML وإدخال الأشياء إلى الإنتاج
‫بشكل أسرع ، يمكنك اختيار استخدام Compose على Kubernetes
‫كسير عمل.
‫بعد ذلك ، ربما تستخدم مخططات Helm ، والتي
‫تعد نوعًا من المعايير التنافسية للبنية التحتية الرئيسية
‫الخاصة بك. لأن الشيء المتعلق بـ Helm
‫هو أنه يأتي خارج الصندوق مع الكثير من قوالب المخططات
‫هذه بحيث يمكنك نشر تسجيل Prometheus أو Elasticsearch
‫باستخدام ELK ، أو شيء من هذا القبيل.
‫سيأتي مع تلك القوالب الجاهزة التي
‫تسمح لك بالبدء بشكل أسرع.
‫أيضًا ، فقط تذكر أن هذه كلها اختيارية ، أليس كذلك.
‫يمكنك عمل Kubernetes باستخدام YAML القياسي الذي
‫كنت تلعب به حتى الآن ، ولا بأس بذلك.
‫لا يتطلب هذه الأشياء الأخرى.
‫إنها مجرد أدوات اختيارية تابعة لجهات خارجية.
‫تقليديًا ، مع نمو الفريق ، عندما تحصل على
‫مجموعات Kubernetes متعددة للإنتاج وهناك
‫فرق متعددة تشارك ، يصبح كل شيء أكثر صعوبة
‫، ومن المحتمل أن ينتهي بك الأمر بأكثر من
‫حل واحد. قد ينتهي بك الأمر مع هيلم في مجموعات معينة.
‫قد ينتهي بك الأمر بـ Compose on Kubernetes لمطوريك
‫، أو شيء من هذا القبيل.
‫أو إحدى هذه الأدوات الستين الإضافية الأخرى في
‫النظام البيئي.
‫النقطة الأخيرة هي أنه نظرًا لأن Helm هو بالفعل الرائد في
‫هذا المجال في الوقت الحالي ، فإن
‫كل توزيع تقريبًا يستخدمه ، أو يدعمه ، أو حتى يأتي معه
‫خارج الصندوق. فقط ضع في اعتبارك
‫أنه عند النظر إلى هذه الأدوات ، ربما لا يمكنك
‫تجنب Helm في بيئة كبيرة.
‫عليك فقط استخدامه.
‫الشيء الجميل في الوقت الحاضر أنه في 3. 0 وأن هناك الكثير
‫من خيارات النشر الأبسط في الإصدار
‫3. 0 مقابل 1. 0 و 2.
‫0. لذلك
‫، تتحسن الأمور وتسهل مع ذلك طوال الوقت. تساعد الكثير من أدوات النشر
‫هذه في تصميم نموذج YAML الخاص بك بطرق مختلفة.
‫Kubernetes
‫نفسها لم يكن لديها أي شيء حقًا لأطول وقت.
‫في الإصدارات الأخيرة ، تم طرح شيء
‫يسمى Kustomize مع K.
‫عندما تبدأ في رؤية هذه الكلمة بحرف K ، فأنت تعلم
‫أنها ميزة خاصة.
‫يتيح لك القيام بأشياء مشابهة لبرنامج Helm
‫وحلول النشر الأخرى هذه ، ولكنه ليس
‫بنفس قوة Helm ، أليس
‫كذلك.
‫لذا ، هيلم لا يزال القائد.
‫Kustomize هو نوع من الطفل الجديد في الكتلة ، لكنه يأتي خارج
‫الصندوق مع كل ما تفعله في Kubernetes.
‫يدعمها الأمر kubectl.
‫ما هو عليه حقًا ، بدلاً من YAML
‫النموذجي ، إنه يأخذ YAML لديك بالفعل وهو
‫Kubernetes YAML القياسي ، ويمكنك بعد
‫ذلك أخذ هذا الملف ثم تشغيل شيء آخر فوقه
‫وتغييره مع تجاوز من نوع ما.
‫نوع مشابه لما نفعله في Swarm.
‫لدينا بالفعل في Swarm و Compose ، لدينا تجاوز للملفات
‫وأشياء من هذا القبيل.
‫لديهم الآن هذا المبني خارج الصندوق.
‫لديها الكثير من الميزات.
‫أعتقد ، بشكل أو بآخر ، أنه ليس موجودًا تمامًا من حيث مجموعة
‫الميزات لما يمتلكه Helm ، ولكنه على الأقل يأتي خارج الصندوق.
‫تذكر ، إذا كان لديك Docker ، أحدث
‫إصدار ، 19. 03 أو أحدث من Docker ، يحتوي
‫الآن على الأمر الفرعي لتطبيق docker ، والذي يقوم بعمل قوالب
‫خاصة به لـ Compose YAML وهو حقًا مشابه جدًا
‫لهذا الخيار المخصص لـ Kubernetes.
‫مرة
‫أخرى ، إذا كنت ستلتزم بمسار Docker وستفكر
‫في Docker Enterprise أو كنت تحب حقًا كيف يركز Docker على
‫سير عمل المطور ، فابحث في الأمر الفرعي
‫لتطبيق docker وأيضًا تطبيق docker app ، والذي سأضع الموارد
‫هنا.
‫نظرًا لأن لديهم وثائق حول كيفية استخدام
‫Compose YAML ، فاستخرج أشياء مثل متغيرات البيئة
‫والأشياء الأخرى. قم بتجميع كل ذلك في
‫صورة واحدة ثم قم بشحن YAML كصورة.
‫مما يعني أنه يمكنك الآن إصدار YAML الخاص
‫بك ونشره بسطر واحد دون الحاجة إلى القيام
‫به مثل سحب YAML ثم كتابة أوامر طويلة.
‫إنها طريقة ممتعة جدًا للقيام بذلك.
‫إنه يستخدم شيئًا جديدًا يسمى معيار CNAB
‫، والذي لن ندخل إليه هنا ، ولكن
‫هذا هو C N A B.
‫كان إعلانًا أصدرته شركة Docker و Microsoft
‫في عام 2018.
‫يمكنك التحقق من كل ذلك على موقع تطبيق
‫Docker في الموارد. مرة أخرى ، كل هذه الأشياء
‫تدور حول طرق خارجية اختيارية لتخصيص YAML الافتراضي
‫وتوسيعه لتسهيل الأمر على فريقك أثناء نموك.