يمكن تصوير جوهر القصة حول مدير الحزم الأكثر شيوعًا في Kubernetes باستخدام الرموز التعبيرية:
- Box هو Helm (هذا هو أنسب شيء في أحدث إصدار من Emoji) ؛
- قفل - أمان
- الرجل هو الحل للمشكلة.
في الواقع ، سيكون كل شيء أكثر تعقيدًا ، والقصة مليئة بالتفاصيل الفنية حول كيفية القيام بذلك كيف تجعل هيلم آمنًا.
- باختصار ما هو هيلم إن لم تعلم أو نسيت. ما هي المشاكل التي تحلها وأين تقع في النظام البيئي.
- ضع في اعتبارك هندسة هيلم. لا تكتمل أية محادثة حول الأمان وكيفية جعل الأداة أو الحل أكثر أمانًا دون فهم بنية المكون.
- دعونا نناقش مكونات هيلم.
- السؤال الأكثر إلحاحًا هو المستقبل - الإصدار الجديد من Helm 3.
ينطبق كل شيء في هذه المقالة على Helm 2. هذا الإصدار قيد الإنتاج حاليًا وهو على الأرجح الإصدار الذي تستخدمه حاليًا ، وهو الإصدار الذي يحتوي على مخاطر أمنية.
حول المتحدث: الكسندر خيوروف () لمدة 10 سنوات ، مما يساعد على تحسين المحتوى وانضم إلى اللجنة . يعمل الآن في Chainstack كمسؤول تطوير - وهذا مزيج بين مدير التطوير والشخص المسؤول عن تسليم الإصدارات النهائية. أي أنها تقع في موقع الأعمال العدائية ، حيث يحدث كل شيء من إنشاء منتج إلى تشغيله.
Chainstack هي شركة ناشئة صغيرة ونشطة وتتمثل مهمتها في تمكين العملاء من نسيان البنية التحتية وتعقيدات تشغيل التطبيقات اللامركزية ، ويقع فريق التطوير في سنغافورة. لا تطلب من Chainstack بيع أو شراء عملة مشفرة ، ولكن اعرض التحدث عن أطر عمل blockchain للمؤسسات وسوف يجيبون عليك بكل سرور.
قاد
هذا مدير حزمة (مخطط) لـ Kubernetes. الطريقة الأكثر وضوحًا وتنوعًا لجلب التطبيقات إلى مجموعة Kubernetes.
هذا ، بالطبع ، يتعلق بنهج هيكلي وصناعي أكثر من إنشاء قوائم YAML الخاصة بك وكتابة أدوات مساعدة صغيرة.
Helm هو أفضل ما هو متاح الآن وشائع.
لماذا هيلم؟ في المقام الأول لأنه مدعوم من قبل CNCF. Cloud Native هي مؤسسة كبيرة وهي الشركة الأم لـ Kubernetes و etcd و Fluentd وغيرها.
حقيقة مهمة أخرى هي أن هيلم مشروع مشهور جدًا. عندما فكرت في يناير 2019 لأول مرة في الحديث عن كيفية جعل Helm آمنًا ، كان للمشروع ألف نجمة على GitHub. بحلول مايو كان هناك 12 منهم.
يهتم الكثير من الأشخاص بـ Helm ، لذلك حتى لو لم تستخدمه بعد ، فإن معرفة أمانه سيكون مفيدًا لك. السلامة مهمة.
فريق Helm الأساسي مدعوم من Microsoft Azure ، وبالتالي فهو مشروع مستقر إلى حد ما ، على عكس العديد من الآخرين. يشير إصدار Helm 3 Alpha 2 في منتصف شهر يوليو إلى أن الكثير من الأشخاص يعملون في المشروع ، ولديهم الرغبة والقوة لتطوير Helm وتحسينه.
يعالج Helm العديد من مشكلات إدارة تطبيقات الجذر في Kubernetes.
- تغليف التطبيق. حتى تطبيق مثل "Hello، World" على WordPress يتكون بالفعل من عدة خدمات ، ويريدون أن يتم تجميعهم معًا.
- إدارة التعقيد الذي يأتي مع إدارة هذه التطبيقات.
- دورة حياة لا تنتهي بعد تثبيت التطبيق أو نشره. لا يزال يعيش ، ويحتاج إلى التحديث ، ويساعد هيلم في ذلك ويحاول اتخاذ التدابير والسياسات المناسبة لهذا الغرض.
التعبئة مرتبة بطريقة مفهومة: توجد بيانات وصفية متوافقة تمامًا مع عمل مدير الحزم التقليدي لنظام التشغيل Linux أو Windows أو MacOS. وهذا يعني ، المستودع ، والاعتمادات على الحزم المختلفة ، والمعلومات الوصفية للتطبيقات ، والإعدادات ، وميزات التكوين ، وفهرسة المعلومات ، وما إلى ذلك. كل هذا يتيح لك الحصول على التطبيقات واستخدامها.
إدارة التعقيد. إذا كان لديك العديد من التطبيقات من نفس النوع ، فستكون هناك حاجة إلى تحديد المعاملات. تتبع القوالب من هذا ، ولكن حتى لا تبتكر طريقتك الخاصة في إنشاء القوالب ، يمكنك استخدام ما يقدمه Helm من الصندوق.
إدارة دورة حياة التطبيق - في رأيي ، هذه هي القضية الأكثر إثارة للاهتمام والتي لم يتم حلها. لهذا السبب أتيت إلى هيلم ذات مرة. كنا بحاجة إلى تتبع دورة حياة التطبيق ، وأردنا نقل دورات CI / CD والتطبيق الخاصة بنا إلى هذا النموذج.
يسمح لك Helm بما يلي:
- إدارة عمليات النشر ، يقدم مفهوم التكوين والمراجعة ؛
- إجراء التراجع بنجاح ؛
- استخدام الخطافات للأحداث المختلفة ؛
- إضافة فحوصات التطبيق الإضافية والرد على نتائجها.
علاوة على ذلك هيلم لديها "بطاريات" - عدد كبير من الأشياء اللذيذة التي يمكن تضمينها في شكل ملحقات ، مما يبسط حياتك. يمكن كتابة الإضافات بشكل مستقل ، فهي معزولة تمامًا ولا تتطلب بنية متماسكة. إذا كنت ترغب في تنفيذ شيء ما ، فإنني أوصي بفعله كمكوِّن إضافي ، ثم ربما تضمينه في المنبع.
يستند هيلم إلى ثلاثة مفاهيم رئيسية:
- ريبو الرسم البياني - وصف ومجموعة من المعلمات الممكنة للبيان الخاص بك.
- التكوين —القيم المطلوب تطبيقها (نص ، قيم رقمية ، إلخ).
- الإفراج عن يجمع المكونين العلويين ، ويتحولان معًا إلى الإصدار. يمكن إصدار الإصدارات ، وبالتالي تحقيق تنظيم دورة الحياة: صغيرة وقت التثبيت وكبيرة في وقت الترقية أو الرجوع إلى إصدار أقدم أو التراجع.
العمارة هيلم
يصور الرسم التخطيطي من الناحية المفاهيمية بنية هيلم عالية المستوى.
اسمحوا لي أن أذكرك أن Helm شيء متعلق بـ Kubernetes. لذلك ، لا يمكننا الاستغناء عن مجموعة Kubernetes (مستطيل). مكون kube-apiserver موجود على الرئيسي. بدون هيلم ، لدينا Kubeconfig. يقدم Helm برنامجًا ثنائيًا صغيرًا واحدًا ، إذا كان بإمكانك تسميته ، أداة Helm CLI ، المثبتة على جهاز كمبيوتر أو كمبيوتر محمول أو حاسب مركزي - أي شيء.
لكن هذا لا يكفى. يحتوي Helm على مكون خادم يسمى Tiller. يمثل هيلم داخل المجموعة ، وهو تطبيق داخل مجموعة Kubernetes مثل أي تطبيق آخر.
مكون Chart Repo التالي هو مستودع به رسوم بيانية. يوجد مستودع رسمي ، وقد يكون هناك مستودع خاص لشركة أو مشروع.
تفاعل
لنلقِ نظرة على كيفية تفاعل مكونات البنية عندما نريد تثبيت تطبيق باستخدام Helm.
- نحن نتحدث
Helm install، قم بالوصول إلى المستودع (Chart Repo) واحصل على مخطط Helm.
- تتفاعل الأداة المساعدة Helm (Helm CLI) مع Kubeconfig لمعرفة المجموعة التي يجب الرجوع إليها.
- بعد تلقي هذه المعلومات ، تتناول الأداة Tiller ، الموجود في مجموعتنا ، كتطبيق بالفعل.
- يستدعي Tiller Kube-apiserver لتنفيذ إجراءات في Kubernetes ، وإنشاء بعض الكائنات (الخدمات ، والقرون ، والنسخ المتماثلة ، والأسرار ، وما إلى ذلك).
بعد ذلك ، سنعقد المخطط من أجل رؤية متجه الهجوم الذي يمكن أن تتعرض له بنية Helm ككل. وبعد ذلك سنحاول حمايتها.
ناقلات الهجوم
أول ضعف محتمل هو امتياز API-المستخدم. كجزء من المخطط ، هذا هو المتسلل الذي حصل على وصول إداري إلى Helm CLI.
مستخدم API غير مميز يمكن أن يكون أيضًا خطرًا إذا كان في مكان قريب. سيكون لمثل هذا المستخدم سياق مختلف ، على سبيل المثال ، يمكن إصلاحه في مساحة اسم مجموعة واحدة في إعدادات Kubeconfig.
قد يكون ناقل الهجوم الأكثر إثارة هو العملية التي توجد داخل الكتلة في مكان ما بالقرب من Tiller ويمكن الوصول إليها. يمكن أن يكون هذا خادم ويب أو خدمة مصغرة ترى بيئة الشبكة للمجموعة.
هناك نوع غريب من الهجوم ، ولكنه شائع بشكل متزايد ، مرتبط بـ Chart Repo. قد يحتوي الرسم البياني الذي تم إنشاؤه بواسطة مؤلف عديم الضمير على مورد غير آمن ، وسوف تتبعه بإيمان. أو يمكنه استبدال الرسم البياني الذي تقوم بتنزيله من المستودع الرسمي ، وعلى سبيل المثال ، إنشاء مورد في شكل سياسات وتصعيد الوصول إلى نفسه.
دعونا نحاول مقاومة الهجمات من كل هذه الجوانب الأربعة ومعرفة أين توجد مشاكل في هندسة هيلم ، وأين ربما لا توجد.
دعنا نوسع المخطط ، ونضيف المزيد من العناصر ، لكن نحافظ على جميع المكونات الأساسية.
يتواصل Helm CLI مع Chart Repo ، ويتفاعل مع Kubeconfig ، ويتم نقل العمل إلى الكتلة إلى مكون Tiller.
يتم تمثيل تيلر بكائنين:
- Tiller-publish svc ، والذي يعرض خدمة معينة ؛
- Tiller-publish pod (في الرسم التخطيطي في مثيل واحد في نسخة متماثلة واحدة) ، حيث يتم تشغيل التحميل بالكامل ، والذي يصل إلى الكتلة.
للتفاعل ، يتم استخدام بروتوكولات وأنظمة مختلفة. من وجهة نظر أمنية ، نحن مهتمون أكثر بما يلي:
- الآلية التي من خلالها يصل Helm CLI إلى الريبو المخطط: ما هو البروتوكول ، وهل هناك مصادقة ، وما الذي يمكن فعله حيال ذلك.
- البروتوكول الذي من خلاله يتواصل Helm CLI ، باستخدام kubectl ، مع Tiller. هذا هو خادم RPC مثبت داخل الكتلة.
- يتوفر Tiller نفسه للخدمات المصغرة الموجودة في المجموعة ويتفاعل مع Kube-apiserver.
دعونا نناقش كل من هذه المجالات على التوالي.
RBAC
لا جدوى من التحدث عن أي أمان لـ Helm أو أي خدمة أخرى داخل المجموعة ما لم يتم تمكين RBAC.
يبدو أن هذه ليست أحدث توصية ، لكنني متأكد من أن العديد من الأشخاص ما زالوا غير قادرين على تمكين RBAC حتى في الإنتاج ، لأن هناك الكثير من الجلبة وهناك الكثير لتكوينه. ومع ذلك ، أحثك على القيام بذلك.
- موقع محامي لـ RBAC. هناك قدر هائل من المواد المثيرة للاهتمام التي تم جمعها هناك والتي ستساعدك على إنشاء RBAC ، وإظهار سبب كونها جيدة وكيفية التعايش معها من حيث المبدأ في الإنتاج.
سأحاول شرح كيفية عمل Tiller و RBAC. يعمل تيلر داخل الكتلة تحت حساب خدمة معين. عادةً ، إذا لم يتم تكوين RBAC ، فسيكون هذا هو المستخدم المتميز. في التكوين الأساسي ، سيكون Tiller هو المسؤول. هذا هو السبب في كثير من الأحيان يقال أن Tiller هو نفق SSH إلى مجموعتك. في الواقع ، هذه هي الحالة ، لذا يمكنك استخدام حساب خدمة متخصص منفصل بدلاً من حساب الخدمة الافتراضي في الرسم التخطيطي أعلاه.
عند تهيئة Helm في المرة الأولى التي تقوم فيها بتثبيته على خادم ، يمكنك إعداد حساب خدمة باستخدام --service-account. سيسمح لك هذا باستخدام مستخدم لديه الحد الأدنى من مجموعة الحقوق المطلوبة. صحيح ، سيكون عليك إنشاء مثل هذا "الطوق": الدور وربط الدور.
لسوء الحظ ، لن يفعل Helm هذا من أجلك. تحتاج أنت أو مسؤول مجموعة Kubernetes لديك إلى إعداد مجموعة من الدور ، وترابط الدور لحساب الخدمة مسبقًا لتمرير Helm.
السؤال الذي يطرح نفسه - ما هو الفرق بين الدور و ClusterRole؟ الفرق هو أن ClusterRole يعمل مع جميع مساحات الأسماء ، على عكس الدور العادي وترابط الدور ، والذي يعمل فقط مع مساحات الأسماء المتخصصة. يمكنك تكوين السياسات للمجموعة بأكملها وجميع مساحات الأسماء ، بالإضافة إلى تخصيصها لكل مساحة اسم على حدة.
من الجدير بالذكر أن RBAC يحل مشكلة كبيرة أخرى. يشتكي الكثيرون من أن شركة هيلم ، للأسف ، ليست شركة متعددة الشركات (لا تدعم تعدد الشركات). إذا استهلكت عدة فرق مجموعة واستخدمت Helm ، فمن المستحيل من حيث المبدأ وضع سياسات وتمييز وصولهم داخل هذه المجموعة ، نظرًا لوجود حساب خدمة معين يعمل من خلاله Helm ، ويقوم بإنشاء جميع الموارد في الكتلة من أسفل ذلك ، وهو أمر غير مريح للغاية في بعض الأحيان. هذا صحيح - كملف ثنائي بحد ذاته ، كعملية ، هيلم تيلر ليس لديه فكرة عن الشركات المتعددة.
ومع ذلك ، هناك طريقة رائعة تتيح لك تشغيل Tiller عدة مرات في مجموعة. لا توجد مشكلة في هذا ، يمكن تشغيل Tiller في كل مساحة اسم. وبالتالي ، يمكنك استخدام RBAC و Kubeconfig كسياق ، وتقييد الوصول إلى Helm خاص.
سيبدو مثل هذا.
على سبيل المثال ، هناك نوعان من Kubeconfigs مع سياق لفرق مختلفة (مساحتان اسميتان): X Team لفريق التطوير ومجموعة الإدارة. تحتوي مجموعة الإدارة على Tiller الخاص بها ، والذي يقع في مساحة اسم نظام Kube ، على التوالي ، حساب خدمة متقدم. ومساحة اسم منفصلة لفريق التطوير ، سيكونون قادرين على نشر خدماتهم في مساحة اسم خاصة.
هذا نهج عملي ، Tiller ليس شرهًا لدرجة أنه يمكن أن يؤثر بشكل كبير على ميزانيتك. هذا أحد الحلول السريعة.
لا تتردد في تكوين Tiller بشكل منفصل وتزويد Kubeconfig بسياق لفريق أو مطور معين أو للبيئة: Dev ، Staging ، Production (من المشكوك فيه أن يكون كل شيء في نفس المجموعة ، ومع ذلك ، يمكن القيام بذلك) .
استمرارًا لقصتنا ، دعنا ننتقل من RBAC ونتحدث عن ConfigMaps.
خرائط التكوين
يستخدم Helm ConfigMaps كمخزن بيانات خاص به. عندما تحدثنا عن الهندسة المعمارية ، لم يكن هناك في أي مكان قاعدة بيانات تخزن معلومات حول الإصدارات والتكوينات والعودة إلى الحالة السابقة وما إلى ذلك. يتم استخدام ConfigMaps لهذا الغرض.
المشكلة الرئيسية في ConfigMaps معروفة - فهي ليست آمنة من حيث المبدأ غير قادر على تخزين البيانات الحساسة. نحن نتحدث عن كل شيء لا ينبغي أن يتجاوز الخدمة ، على سبيل المثال ، كلمات المرور. الطريقة الأكثر استخدامًا لـ Helm الآن هي الانتقال من استخدام ConfigMaps إلى الأسرار.
يتم ذلك بكل بساطة. تجاوز إعداد Tiller وحدد أن التخزين سيكون أسرارًا. وبعد ذلك ، لن تتلقى ملف ConfigMap ، بل سراً لكل عملية نشر.
قد تجادل بأن الأسرار نفسها هي مفهوم غريب وليست آمنة للغاية. ومع ذلك ، يجب أن يكون مفهوما أن مطوري Kubernetes أنفسهم يفعلون ذلك. بدءًا من الإصدار 1.10 ، أي لفترة طويلة ، من الممكن ، على الأقل في السحب العامة ، توصيل وحدة التخزين الصحيحة لتخزين الأسرار. يعمل الفريق الآن على كيفية توزيع الوصول إلى الأسرار أو الكبسولات الفردية أو الكيانات الأخرى بشكل أفضل.
من الأفضل ترجمة Storage Helm إلى أسرار ، وبالتالي تأمينها مركزيًا.
بالطبع ستبقى حد تخزين البيانات 1 ميجا بايت. يستخدم Helm هنا etcd كمستودع موزع لـ ConfigMaps. وهناك اعتبروا أن هذا جزء بيانات مناسب للتكرار ، إلخ. هناك مناقشة مثيرة للاهتمام على Reddit حول هذا الأمر ، أوصي بإيجاد هذه القراءة المضحكة لعطلة نهاية الأسبوع أو قراءة الضغط .
ريبو الرسم البياني
الرسوم البيانية هي الأكثر ضعفًا اجتماعيًا ويمكن أن تصبح مصدرًا لـ "رجل في المنتصف" ، خاصةً إذا كنت تستخدم أحد حلول الأسهم. بادئ ذي بدء ، نحن نتحدث عن المستودعات التي يتم الكشف عنها عبر HTTP.
بالتأكيد ، أنت بحاجة لفضح Helm Repo عبر HTTPS - هذا هو الخيار الأفضل وغير مكلف.
لاحظ آلية توقيع المخطط. التكنولوجيا بسيطة للعار. إنه نفس ما تستخدمه على GitHub ، وهو جهاز PGP عادي به مفاتيح عامة وخاصة. قم بالإعداد وتأكد من امتلاكك للمفاتيح الصحيحة وتوقيع كل شيء ، أن هذا هو الرسم البياني الخاص بك حقًا.
وبالإضافة إلى ذلك، يدعم عميل Helm بروتوكول TLS (ليس بمعنى HTTP من جانب الخادم ، ولكن بمعنى TLS المتبادل). يمكنك استخدام مفاتيح الخادم والعميل للتواصل. لأكون صادقًا ، لا أستخدم مثل هذه الآلية بسبب كره للشهادات المتبادلة. أساسًا، - الأداة الرئيسية لإعداد Helm Repo لـ Helm 2 - تدعم أيضًا المصادقة الأساسية. يمكنك استخدام المصادقة الأساسية إذا كانت أكثر ملاءمة وهدوءًا.
يوجد أيضًا مكون إضافي ، والذي يسمح لك باستضافة Chart Repos على Google Cloud Storage. هذا مناسب تمامًا ويعمل بشكل رائع وآمن بدرجة كافية ، لأنه يتم استخدام جميع الآليات الموصوفة.
إذا قمت بتمكين HTTPS أو TLS ، فاستخدم mTLS ، وقم بتمكين المصادقة الأساسية لتقليل المخاطر بشكل أكبر ، فستحصل على قناة اتصال آمنة لـ Helm CLI و Chart Repo.
واجهة برمجة تطبيقات gRPC
الخطوة التالية مسؤولة للغاية - لتأمين Tiller ، الموجود في الكتلة وهو ، من ناحية ، خادم ، من ناحية أخرى ، يصل إلى المكونات الأخرى ويحاول التظاهر بأنه شخص ما.
كما قلت ، Tiller هي خدمة تعرض gRPC ، يأتي عميل Helm إليها عبر gRPC. افتراضيًا ، بالطبع ، يتم تعطيل TLS. لماذا يتم ذلك هو سؤال قابل للنقاش ، يبدو لي ، من أجل تبسيط الإعداد في البداية.
للإنتاج وحتى للتشغيل المرحلي ، أوصي بتمكين TLS على gRPC.
في رأيي ، على عكس mTLS للرسوم البيانية ، هذا مناسب هنا ويتم ببساطة شديدة - إنشاء بنية أساسية PQI ، إنشاء شهادة ، تشغيل Tiller ، نقل الشهادة أثناء التهيئة. بعد ذلك ، يمكنك تنفيذ جميع أوامر Helm ، متظاهرًا بأنك الشهادة التي تم إنشاؤها والمفتاح الخاص.
وبالتالي ، سوف تحمي نفسك من جميع الطلبات إلى Tiller من خارج المجموعة.
لذلك ، قمنا بتأمين قناة الاتصال بـ Tiller ، وقد ناقشنا بالفعل RBAC وقمنا بتعديل حقوق خادم Kubernetes ، وقللنا النطاق الذي يمكنه التفاعل معه.
خوذة محمية
لنلق نظرة على الشكل النهائي. إنها نفس البنية بنفس الأسهم.
يمكن الآن رسم جميع الاتصالات بأمان باللون الأخضر:
- بالنسبة إلى Chart Repo ، نستخدم TLS أو mTLS والمصادقة الأساسية ؛
- mTLS لـ Tiller ، ويتم عرضها كخدمة gRPC مع TLS ، نستخدم الشهادات ؛
- الكتلة يستخدم حساب خدمة خاص مع الدور و "ربط الدور".
لقد قمنا بتأمين الكتلة بشكل ملحوظ ، لكن قال شخص ذكي:
"يمكن أن يكون هناك حل واحد آمن تمامًا - جهاز كمبيوتر مغلق ، وموجود في صندوق خرساني ويخضع لحراسة الجنود".
هناك طرق مختلفة لمعالجة البيانات والعثور على نواقل هجوم جديدة. ومع ذلك ، أنا واثق من أن هذه التوصيات ستسمح لك بتنفيذ معيار الصناعة الأساسي للأمان.
علاوة
لا يرتبط هذا الجزء بالأمان بشكل مباشر ، ولكنه سيكون مفيدًا أيضًا. سأريكم بعض الأشياء الشيقة التي يعرف عنها القليل من الناس. على سبيل المثال ، كيفية البحث عن الرسوم البيانية - الرسمية وغير الرسمية.
في المستودع يوجد الآن حوالي 300 مخطط ودفقان: مستقر وحاضنة. يعرف أي شخص يساهم جيدًا مدى صعوبة الانتقال من حاضنة إلى مستقرة ، ومدى سهولة الخروج من المستقرة. ومع ذلك ، فهي ليست أفضل أداة للبحث في الرسوم البيانية لـ Prometheus وأي شيء آخر تريده ، لسبب واحد بسيط - إنها ليست بوابة ملائمة للبحث عن الحزم.
لكن هناك خدمة ، حيث يكون العثور على المخططات أكثر ملاءمة. الأهم من ذلك ، هناك العديد من المستودعات الخارجية وحوالي 800 تعويذة متوفرة. بالإضافة إلى ذلك ، يمكنك توصيل المستودع الخاص بك إذا كنت لا ترغب في إرسال المخططات الخاصة بك إلى مستقر لسبب ما.
جرب hub.helm.sh ودعنا نطوره معًا. هذه الخدمة ضمن مشروع Helm ويمكنك حتى المساهمة في واجهة المستخدم الخاصة بها إذا كنت واجهة أمامية وتريد فقط تحسين المظهر.
أود أيضًا أن ألفت انتباهك إلى افتح تكامل API Service Broker. يبدو الأمر مرهقًا وغير مفهوم ، لكنه يحل المشكلات التي يواجهها الجميع. اسمحوا لي أن أشرح بمثال بسيط.
لدينا مجموعة Kubernetes حيث نريد تشغيل تطبيق WordPress كلاسيكي. كقاعدة عامة ، هناك حاجة إلى قاعدة بيانات للوظائف الكاملة. هناك العديد من الحلول المختلفة ، على سبيل المثال ، يمكنك تشغيل خدمة الدولة الخاصة بك. هذا ليس مريحًا للغاية ، لكن الكثير من الناس يفعلون ذلك.
يستخدم آخرون ، مثلنا في Chainstack ، قواعد البيانات المدارة مثل MySQL أو PostgreSQL للخوادم. لذلك ، توجد قواعد بياناتنا في مكان ما في السحابة.
ولكن تظهر مشكلة: نحتاج إلى ربط خدمتنا بقاعدة البيانات ، وإنشاء نكهة لقاعدة البيانات ، وتمرير بيانات الاعتماد وإدارتها بطريقة ما. عادة ما يتم كل هذا يدويًا بواسطة مسؤول النظام أو المطور. ولا توجد مشكلة عندما يكون هناك عدد قليل من التطبيقات. عندما يكون هناك الكثير منهم ، فأنت بحاجة إلى الجمع. هناك مثل هذا الجمع - وسيط الخدمة. يسمح لك باستخدام مكون إضافي خاص لمجموعة سحابية عامة وطلب الموارد من مزود عبر وسيط ، كما لو كانت واجهة برمجة تطبيقات. للقيام بذلك ، يمكنك استخدام أدوات Kubernetes الأصلية.
انه بسيط جدا. يمكنك طلب ، على سبيل المثال ، Managed MySQL على Azure بطبقة أساسية (يمكن تكوين ذلك). باستخدام Azure API ، سيتم إنشاء قاعدة البيانات وتصبح جاهزة للاستخدام. لست بحاجة إلى التدخل في هذا الأمر ، فالمكوِّن الإضافي مسؤول عن ذلك. على سبيل المثال ، سيعيد OSBA (المكون الإضافي Azure) بيانات الاعتماد إلى الخدمة ، ويمررها إلى Helm. ستكون قادرًا على استخدام WordPress مع Cloud MySQL ، ولن تتعامل مع قواعد البيانات المُدارة على الإطلاق ، ولا تقلق بشأن الخدمات الكاملة في الداخل.
يمكننا القول أن Helm يعمل كلصق يسمح لك ، من ناحية ، بنشر الخدمات ، ومن ناحية أخرى ، يستهلك موارد مزودي الخدمات السحابية.
يمكنك كتابة المكون الإضافي الخاص بك واستخدام كل هذا السجل في مكان العمل. بعد ذلك سيكون لديك ببساطة المكون الإضافي الخاص بك لمزود خدمة السحابة للشركة. أنصحك بتجربة هذا النهج ، خاصةً إذا كان لديك نطاق واسع وترغب في النشر السريع للتطوير أو التدريج أو البنية التحتية الكاملة لميزة ما. هذا سيجعل الحياة أسهل لعملياتك أو DevOps.
اكتشاف آخر أشرت إليه بالفعل هو المساعد helm-gcs، والذي يسمح لك باستخدام دلاء Google (تخزين الكائنات) لتخزين مخططات Helm.
ما عليك سوى أربعة أوامر لبدء استخدامه:
- تثبيت البرنامج المساعد
- الشروع فيه
- اضبط المسار إلى الدلو الموجود في gcp ؛
- نشر الرسوم البيانية بالطريقة القياسية.
الجميل هو أنه سيتم استخدام طريقة gcp الأصلية للترخيص. يمكنك استخدام حساب خدمة ، حساب مطور ، أيا كان. إنه مريح للغاية ولا يكلف أي شيء لتشغيله. إذا كنت ، مثلي ، تروج لفلسفة opsless ، فسيكون هذا مناسبًا جدًا ، خاصة للفرق الصغيرة.
البدائل
حلم ليس الحل الوحيد لإدارة الخدمات. هناك الكثير من الأسئلة له ، وهذا على الأرجح سبب ظهور النسخة الثالثة بهذه السرعة. بالطبع هناك بدائل.
يمكن أن تكون هذه إما حلولًا متخصصة مثل Ksonnet أو Metaparticle. يمكنك استخدام أدوات إدارة البنية التحتية الكلاسيكية (Ansible ، Terraform ، Chef ، إلخ) لنفس الأغراض التي ذكرتها.
أخيرا هناك حل التي تزداد شعبيتها.
إطار عمل المشغل هو البديل الرئيسي لبرنامج Helm الذي يجب البحث عنه.
إنه أصلي أكثر لـ CNCF و Kubernetes ، لكن حاجز الدخول أعلى من ذلك بكثير، تحتاج إلى المزيد من التعليمات البرمجية ووصف البيانات بشكل أقل.
هناك العديد من الإضافات ، مثل مشروع ، سقالة. إنها تجعل الحياة أسهل كثيرًا ، على سبيل المثال ، تبسط الدورة للمطورين لإرسال وتشغيل Helm لنشر بيئة اختبار. أود أن أسميهم مفوضين.
هذا رسم بياني مرئي لمكان كل شيء.
الإحداثي السيني هو مستوى تحكمك الشخصي فيما يحدث ، والإحداثيات هي مستوى موطن Kubernetes. الإصدار 2 من Helm يقع في مكان ما بينهما. في الإصدار 3 ، ليس ضخمًا ، ولكن تم تحسين كل من التحكم ومستوى الولادة. لا تزال الحلول على مستوى Ksonnet أقل شأنا حتى من Helm 2. ومع ذلك ، فهي تستحق نظرة لمعرفة ما هو موجود في هذا العالم. بالطبع ، سيكون مدير التكوين الخاص بك تحت سيطرتك ، لكنه ليس أصليًا على الإطلاق لـ Kubernetes.
يعد Operator Framework أصليًا تمامًا لـ Kubernetes ويسمح لك بإدارته بشكل أكثر أناقة ودقة (ولكن ضع في اعتبارك مستوى الدخول). بدلاً من ذلك ، فهو مناسب لتطبيق متخصص وإنشاء إدارة له ، بدلاً من الجمع الشامل لتعبئة عدد كبير من التطبيقات باستخدام Helm.
تعمل الموسعات على تحسين التحكم بشكل طفيف أو استكمال سير العمل أو قطع الزوايا على خطوط أنابيب CI / CD.
هيلمز المستقبل
النبأ السار هو أن Helm 3 قادم ، وقد تم بالفعل إطلاق الإصدار ألفا من Helm 3.0.0-alpha.2 ، يمكنك تجربته. إنه مستقر تمامًا ، لكن الوظيفة لا تزال محدودة.
لماذا تحتاج هيلم 3؟ بادئ ذي بدء ، هذه قصة عن اختفاء تيلر، كعنصر. هذا ، كما فهمت بالفعل ، يعد خطوة كبيرة إلى الأمام ، لأنه من وجهة نظر أمان العمارة ، يتم تبسيط كل شيء.
عندما تم إنشاء Helm 2 ، خلال فترة Kubernetes 1.8 يومًا أو حتى قبل ذلك ، كانت العديد من المفاهيم غير ناضجة. على سبيل المثال ، يتم الآن تنفيذ مفهوم CRD بشكل فعال ، وسوف يقوم Helm بذلك استخدم CRDلتخزين الهياكل. سيكون من الممكن استخدام العميل فقط وعدم الاحتفاظ بجزء الخادم. وفقًا لذلك ، استخدم أوامر Kubernetes الأصلية للعمل مع الهياكل والموارد. هذه خطوة كبيرة إلى الأمام.
سوف تظهر دعم مستودعات OCI الأصلية (مبادرة الحاويات المفتوحة). هذه مبادرة ضخمة ، ويهتم هيلم في المقام الأول بنشر الرسوم البيانية الخاصة بهم. يتعلق الأمر ، على سبيل المثال ، بأن Docker Hub يدعم العديد من معايير OCI. أنا لا أخمن ، ولكن ربما يبدأ موفرو مستودع Docker الكلاسيكيين في السماح لك باستضافة مخططات Helm الخاصة بهم.
قصة مثيرة للجدل بالنسبة لي دعم Lua، كمحرك قوالب لكتابة النصوص. لست من أشد المعجبين بـ Lua ، لكنها ستكون اختيارية تمامًا. لقد تحققت منه 3 مرات - لن يكون استخدام Lua ضروريًا. لذا ، من يريد أن يكون قادرًا على استخدام Lua ، ومن يحب Go ، انضم إلى معسكرنا الضخم واستخدم go-tmpl لذلك.
أخيرًا ، ما كنت أفتقده بالتأكيد هو ظهور المخطط والتحقق من صحة أنواع البيانات. لن يكون هناك المزيد من المشاكل مع int أو سلسلة ، لا داعي لالتفاف الصفر بين علامتي اقتباس. سيظهر مخطط JSONS والذي سيتيح لك وصف هذا بوضوح للقيم.
سيتم إعادة صياغة بشكل كبير نموذج يحركها الحدث. لقد تم بالفعل تصورها. انظر إلى فرع Helm 3 وسترى عدد الأحداث والخطافات والأشياء الأخرى التي تمت إضافتها ، مما يبسط إلى حد كبير ، ومن ناحية أخرى ، يضيف تحكمًا في عمليات النشر وردود الفعل عليها.
سيكون Helm 3 أسهل وأكثر أمانًا وإثارة للاهتمام ، ليس لأننا لا نحب Helm 2 ، ولكن لأن Kubernetes أصبح أكثر تقدمًا. وفقًا لذلك ، يمكن لشركة Helm استخدام تطويرات Kubernetes وإنشاء مديرين ممتازين لـ Kubernetes عليها.
آخر الأخبار الجيدة هو أن الكسندر خيوروف سيقول أذكر أن المؤتمر على تكامل عمليات التطوير والاختبار والتشغيل سيعقد في موسكو 30 سبتمبر و 1 أكتوبر. لا يزال بإمكانك حتى 20 أغسطس وأخبرنا عن تجربتك مهام نهج DevOps.
تابع نقاط التفتيش الخاصة بالمؤتمر والأخبار في и .
المصدر: www.habr.com