هيلم الأمن

يمكن تمثيل جوهر القصة عن مدير الحزم الأكثر شعبية في Kubernetes بمساعدة الرموز التعبيرية:

• المربع هو Helm (هذا هو الأنسب الموجود في الإصدار الأخير من Emoji) ؛
• قفل أمان
• الرجل هو الحل للمشكلة.

في الواقع ، سيكون كل شيء أكثر تعقيدًا قليلاً ، والقصة مليئة بالتفاصيل التقنية حول كيفية جعل هيلم آمنًا .

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

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


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

تعد Chainstack شركة ناشئة صغيرة ومتنامية ، وتتمثل مهمتها في تزويد العملاء بفرصة لنسيان البنية التحتية وصعوبات تشغيل التطبيقات اللامركزية ، ويقع فريق التطوير في سنغافورة. لا تطالب Chainstack ببيع أو شراء عملة مشفرة ، ولكن عليك أن تتحدث عن أطر عمل blockchain الخاصة بالمؤسسة ، وسوف يسعدهم الرد عليك.

خوذة

هذا هو مدير الحزم (الرسوم البيانية) ل Kubernetes. الطريقة الأكثر سهولة وتنوعا لإحضار التطبيقات إلى نظام Kubernetes.



هذا ، بالطبع ، يتعلق بنهج هيكلي وصناعي أكثر من إنشاء بيانات YAML الخاصة بك وكتابة أدوات مساعدة صغيرة.

هيلم هو أفضل ما هو متاح وشعبية الآن.

لماذا دفة؟ في المقام الأول لأنه مدعوم من قبل CNCF. Cloud Native - مؤسسة كبيرة ، هي الشركة الأم لمشاريع Kubernetes ، etcd ، Fluentd وغيرها.

حقيقة أخرى مهمة ، هيلم هو مشروع شعبي جدا. عندما كنت أخطط للتو في يناير 2019 للحديث عن كيفية جعل هيلم آمنًا ، كان للمشروع ألف نجمة على جيثب. بحلول شهر مايو كان هناك 12 ألف منهم.

كثير من الناس مهتمون بـ "هلم" ، لذلك ، حتى إذا كنت لا تزال لا تستخدمه ، فستحتاج إلى معرفة سلامته. السلامة مهمة.

يدعم Microsoft Azure الفريق الأساسي لـ Helm ، وبالتالي فهو مشروع مستقر إلى حد ما على عكس العديد من المشاريع الأخرى. يشير إصدار Helm 3 Alpha 2 في منتصف يوليو إلى أن الكثير من الأشخاص يعملون في المشروع ، ولديهم الرغبة والقوة لتطوير وتحسين Helm.



حل يحل العديد من قضايا إدارة تطبيق الجذر في Kubernetes.

• التعبئة والتغليف التطبيق. حتى تطبيق مثل "Hello، World" على WordPress يتكون بالفعل من عدة خدمات ، وأريد أن أحزمها معًا.
• إدارة التعقيد الذي ينشأ مع إدارة هذه التطبيقات.
• دورة حياة لا تنتهي بعد تثبيت التطبيق أو نشره. لا يزال يعيش ، يحتاج إلى تحديث ، ويساعد Helm في هذا ويحاول وضع التدابير والسياسات الصحيحة لذلك.

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

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

إدارة دورة حياة التطبيق - في رأيي ، هذه هي القضية الأكثر إثارة للاهتمام والتي لم تحل بعد. لهذا السبب جئت إلى هيلم في الوقت المناسب. كنا في حاجة إلى مراقبة دورة حياة التطبيق ، أردنا نقل CI / CD ودورات التطبيق لدينا إلى هذا النموذج.

هلم يسمح لك:

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

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

يعتمد Helm على ثلاثة مفاهيم أساسية:

• الرسم البياني الريبو - وصف ومجموعة من المعلمات ممكن لبيانك.
• التكوين - أي القيم التي سيتم تطبيقها (النص ، القيم العددية ، إلخ).
• يجمع الإصدار بين المكونين العلويين ، ويتحولان معًا إلى الإصدار. يمكن إصدار الإصدارات ، وبالتالي تحقيق تنظيم دورة الحياة: صغير في وقت التثبيت وكبير في وقت الترقية أو الرجوع إلى الإصدار السابق أو التراجع.

هيلم العمارة

الرسم البياني يعكس من الناحية النظرية الهندسة رفيعة المستوى في هيلم.



اسمح لي أن أذكرك بأن Helm شيء مرتبط بـ Kubernetes. لذلك ، لا يمكننا الاستغناء عن Kubernetes- العنقودية (المستطيل). مكون kube-apiserver موجود على المعالج. بدون هيلم ، لدينا Kubeconfig. يجلب Helm واحدة صغيرة ثنائية ، إذا جاز التعبير ، الأداة المساعدة Helm CLI ، والتي تم تثبيتها على جهاز كمبيوتر أو كمبيوتر محمول أو جهاز رئيسي - لأي شيء.

لكن هذا لا يكفي. هيلم لديه مكون خادم تيلر. يمثل اهتمامات هلم داخل المجموعة ؛ إنه نفس التطبيق داخل مجموعة Kubernetes مثل أي تطبيق آخر.

المكون التالي لـ Chart Repo هو مستودع المخطط. يوجد مستودع رسمي ، وقد يكون هناك مستودع خاص لشركة أو مشروع.

تفاعل

دعونا نرى كيف تتفاعل مكونات الهندسة المعمارية عندما نريد تثبيت تطبيق باستخدام Helm.

• نقول Helm install ، انتقل إلى المستودع (Chart Repo) واحصل على مخطط Helm.

• تتفاعل الأداة المساعدة Helm (Helm CLI) مع Kubeconfig لمعرفة أي مجموعة يمكن الاتصال بها.
• بعد تلقي هذه المعلومات ، تتحول الأداة المساعدة إلى Tiller ، الموجود في نظامنا ، بالفعل كتطبيق.
• يدعو Tiller Kube-apiserver إلى تنفيذ إجراءات في Kubernetes ، لإنشاء بعض الكائنات (الخدمات ، القرون ، النسخ المتماثلة ، الأسرار ، إلخ).

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

هجوم المتجهات

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

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

قد يكون متجه الهجوم الأكثر إثارة هو العملية التي تقع داخل الكتلة في مكان ما بالقرب من تيلر ويمكن الوصول إليها. يمكن أن يكون خادم ويب أو خدمة ميكروية ترى بيئة شبكة المجموعة.

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



دعنا نحاول محاربة الهجمات من جميع هذه الجوانب الأربعة ومعرفة أين توجد مشاكل في بنية هيلم ، وأين ، ربما ، ليست كذلك.

دعنا نوسع المخطط ، أضف المزيد من العناصر ، لكن احتفظ بجميع المكونات الأساسية.



يتصل Helm CLI بـ Chart Repo ، ويتفاعل مع Kubeconfig ، ويتم نقل العمل إلى الكتلة في مكون Tiller.

يمثل تيلر كائنين:

• Tiller-الانتشار svc ، الذي يعرض خدمة معينة ؛
• جراب Tiller- نشر (على الرسم التخطيطي في نسخة واحدة في نسخة متماثلة واحدة) ، الذي يقوم بتشغيل الحمل بأكمله الذي يصل إلى الكتلة.

للتفاعل ، يتم استخدام البروتوكولات والمخططات المختلفة. من وجهة نظر الأمان ، نحن مهتمون أكثر بما يلي:

• الآلية التي يصل بها Helm CLI إلى المخطط repo: ما هو البروتوكول ، وما إذا كان هناك مصادقة وما يمكن القيام به حيال ذلك.
• البروتوكول الذي يتصل به Helm CLI باستخدام kubectl مع Tiller. هذا خادم RPC مثبت داخل الكتلة.
• يتوفر Tiller نفسه للخدمات المصغرة الموجودة في كتلة ويتفاعل مع Kube-apiserver.

سنناقش كل هذه الاتجاهات بالترتيب.

RBAC

من غير المجدي التحدث عن أي أمان لـ Helm أو خدمة أخرى داخل الكتلة إذا لم يتم تمكين RBAC.

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



https://rbac.dev/ هو موقع محام لـ RBAC. لقد جمعت كمية كبيرة من المواد المثيرة للاهتمام التي ستساعد في إعداد RBAC ، وتظهر سبب كونها جيدة وكيفية التعايش معها من حيث المبدأ في الإنتاج.

سأحاول شرح كيفية عمل Tiller و RBAC. يعمل Tiller داخل كتلة تحت حساب خدمة معين. عادة ، إذا لم يتم تكوين RBAC ، سيكون هذا هو المستخدم الخارق. في التكوين الأساسي ، سيكون تيلر هو المشرف. هذا هو السبب في كثير من الأحيان يقال أن تيلر هو نفق SSH إلى الكتلة الخاصة بك. هذا هو الحال بالفعل ، لذلك يمكنك استخدام حساب خدمة مخصص منفصل بدلاً من حساب الخدمة الافتراضية في الرسم البياني أعلاه.

عند تهيئة Helm ، قم أولاً بتثبيته على الخادم ، يمكنك تعيين حساب الخدمة باستخدام --service-account . سيتيح لك ذلك استخدام المستخدم مع الحد الأدنى الضروري من الحقوق. صحيح ، عليك إنشاء مثل "إكليل": الدور وتجليد الأدوار.



لسوء الحظ ، لن يقوم Helm بهذا من أجلك. تحتاج أنت أو مسؤول الكتلة Kubernetes إلى إعداد مجموعة من الأدوار ، RoleBinding لحساب الخدمة مسبقًا لنقل Helm.

السؤال هو - ما هو الفرق بين الدور و ClusterRole؟ الفرق هو أن ClusterRole صالح لجميع مساحات الأسماء ، على عكس Role و RoleBinding العادية ، والتي تعمل فقط على مساحة الاسم المتخصصة. يمكنك تكوين سياسات للكتلة بأكملها وجميع مساحات الأسماء ، بالإضافة إلى تخصيصها لكل مساحة اسم على حدة.

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

ومع ذلك ، هناك طريقة رائعة يمكنك تشغيل Tiller في كتلة عدة مرات. لا توجد مشكلة في هذا ؛ يمكن تشغيل Tiller في كل مساحة اسم. وبالتالي ، يمكنك استخدام RBAC ، Kubeconfig كسياق ، وتقييد الوصول إلى Helm الخاص.

سوف تبدو على النحو التالي.



على سبيل المثال ، هناك نوعان من Kubeconfig مع سياق لفرق مختلفة (اثنين من مساحة الاسم): فريق X لفريق التطوير ومجموعة نظام الإدارة. تحتوي مجموعة الإدارة على Tiller الخاص بها ، والذي يقع في مساحة اسم نظام Kube ، على التوالي حساب خدمة متقدم. ومساحة اسم منفصلة لفريق التطوير ، سيتمكنون من نشر خدماتهم في مساحة اسم خاصة.

هذا أسلوب عملي ، حيث أن Tiller ليس شديد الشراهة بحيث يمكن أن يؤثر بشكل كبير على ميزانيتك. هذا هو واحد من الحلول السريعة.

لا تتردد في تكوين Tiller بشكل منفصل وتزويد Kubeconfig بسياق للفريق أو لمطور محدد أو للبيئة: Dev ، Staging ، Production (من المشكوك فيه أن كل شيء سيكون على نفس المجموعة ، ومع ذلك ، يمكن القيام به).

متابعة قصتنا ، التبديل من RBAC والتحدث عن ConfigMaps.

ConfigMaps

يستخدم Helm ConfigMaps كمستودع بيانات. عندما تحدثنا عن الهندسة المعمارية ، لم يكن هناك مكان في قاعدة البيانات التي تم تخزين المعلومات حول الإصدارات ، التكوينات ، العودة إلى الحالة السابقة ، لذلك ، يتم استخدام ConfigMaps.

المشكلة الرئيسية في ConfigMaps معروفة - فهي غير آمنة من حيث المبدأ ، ومن المستحيل تخزين البيانات الحساسة فيها. نحن نتحدث عن كل شيء لا ينبغي أن يتجاوز الخدمة ، على سبيل المثال ، كلمات المرور. أكثر الطرق الأصلية لـ Helm الآن هي الانتقال من استخدام ConfigMaps إلى الأسرار.

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



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

التخزين هلم من الأفضل أن تترجم إلى أسرار ، وأنها بدورها آمنة مركزيا.

بالطبع ، سيبقى هناك حد لتخزين البيانات من 1 ميغابايت . يستخدم Helm هنا etcd كمستودع موزع لـ ConfigMaps. وهناك اعتقدوا أنه كان قطعة بيانات مناسبة للنسخ المتماثل ، إلخ. هناك مناقشة مثيرة للاهتمام حول رديت حول هذا ، أوصي بالعثور على هذه المسألة متعة القراءة لعطلة نهاية الأسبوع أو قراءة الضغط هنا .

الرسم البياني repos

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

بالتأكيد ، تحتاج إلى كشف Helm Repo عبر HTTPS - هذا هو الخيار الأفضل وغير المكلف.

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

بالإضافة إلى ذلك ، يدعم عميل Helm TLS (ليس بمعنى HTTP من جانب الخادم ، ولكن TLS المتبادل). يمكنك استخدام مفاتيح الخادم والعميل من أجل التواصل. بصراحة ، أنا لا أستخدم مثل هذه الآلية بسبب كره الشهادات المتبادلة. من حيث المبدأ ، يدعم chartmuseum - الأداة الرئيسية لتعرض Helm Repo لـ Helm 2 - المصادقة الأساسية. يمكنك استخدام المصادقة الأساسية إذا كان أكثر ملاءمة وأكثر هدوءًا.

يوجد أيضًا مكون إضافي helm-gcs يسمح لك باستضافة Chart Repos على Google Cloud Storage. هذا مناسب تمامًا ويعمل بشكل رائع وآمن تمامًا ، لأنه يتم استخدام جميع الآليات الموصوفة.



إذا قمت بتمكين HTTPS أو TLS ، استخدم mTLS ، وقم بتوصيل المصادقة الأساسية لتقليل المخاطر بشكل أكبر ، فستحصل على قناة اتصال آمنة Helm CLI و Chart Repo.

gRPC API

الخطوة التالية هي مسؤولية كبيرة - لتأمين Tiller ، الموجود في المجموعة ، وهو ، من ناحية ، الخادم ، من ناحية أخرى ، يمكنه الوصول إلى المكونات الأخرى ويحاول تقديم نفسه كشخص.

كما قلت ، Tiller هي خدمة تكشف gRPC ، يأتي عميل Helm إليها عبر gRPC. بشكل افتراضي ، بالطبع ، يتم إيقاف تشغيل TLS. لماذا يتم ذلك هو سؤال قابل للنقاش ، يبدو لي أن أبسط الإعداد في البداية.

للإنتاج وحتى للإعداد ، أوصي بتمكين TLS على gRPC.

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



وبالتالي ، سوف تحمي نفسك من جميع الطلبات إلى تيلر من خارج الكتلة.

لذا ، قمنا بتأمين قناة الاتصال بـ Tiller ، وناقشنا بالفعل RBAC وعدلنا حقوق Kubernetes apiserver ، وقللنا من النطاق الذي يمكن أن تتفاعل به.

هيلم المحمية

لنلقِ نظرة على المخطط النهائي. هذا هو نفس الهيكل مع نفس الأسهم.



يمكن الآن ربط جميع الوصلات بأمان باللون الأخضر:

• بالنسبة لـ Chart Repo ، نستخدم TLS أو mTLS والمصادقة الأساسية ؛
• mTLS for Tiller ، ويتم كشفها كخدمة gRPC مع TLS ، نستخدم الشهادات ؛
• يستخدم نظام المجموعة حساب خدمة خاص مع الدور و RoleBinding.

لقد أمّننا المجموعة بشكل ملحوظ ، لكن قال شخص ذكي:

"لا يمكن أن يكون هناك سوى حل واحد آمن تمامًا - يتم إيقاف تشغيل الكمبيوتر ، وهو في صندوق خرساني ويحرسه الجنود".

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

علاوة

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

يحتوي مستودع github.com/helm/charts الآن على حوالي 300 مخطط وتجريان: ثابت وحاضن. يعرف المساهم مدى صعوبة الانتقال من الحاضنة إلى المستقرة ، ومدى سهولة الخروج من الإسطبل. ومع ذلك ، ليست هذه هي أفضل أداة للبحث عن المخططات لـ Prometheus وكل ما تريده لسبب بسيط واحد ليس بوابة حيث يكون من المناسب البحث عن الحزم.

ولكن هناك خدمة hub.helm.sh والتي من الملائم أكثر العثور على المخططات. الأهم من ذلك ، هناك العديد من المستودعات الخارجية وأكثر من 800 المخططات المتاحة. بالإضافة إلى ذلك ، يمكنك توصيل مستودعك إذا كنت لا ترغب في إرسال مخططاتك لسبب ما لسبب ما.

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

أرغب أيضًا في لفت انتباهك إلى تكامل Open Service Broker API . هذا يبدو مرهقًا وغير مفهوم ، لكنه يحل المشكلات التي يواجهها الجميع. ساوضح مثال بسيط.



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

يستخدم الآخرون ، مثلنا في Chainstack ، قواعد البيانات المدارة ، مثل MySQL أو PostgreSQL ، للخوادم. لذلك ، توجد قواعد البيانات الخاصة بنا في مكان ما في السحابة.

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

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

يمكننا القول أن Helm بمثابة مادة لاصقة ، والتي تتيح لك من ناحية نشر الخدمات ، ومن ناحية أخرى ، فإنها تستهلك موارد موفري الخدمات السحابية.

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

اكتشاف آخر ذكرته بالفعل هو المكون الإضافي helm-gcs ، والذي يسمح لك باستخدام مجموعات Google (تخزين الكائنات) لتخزين مخططات Helm.



يستغرق الأمر أربعة أوامر فقط لبدء استخدامه:

1. تثبيت البرنامج المساعد ؛
2. استهله
3. تعيين المسار إلى دلو ، والذي يقع في gcp ؛
4. نشر الرسوم البيانية بطريقة قياسية.

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

البدائل

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

يمكن أن يكون كحلول متخصصة ، على سبيل المثال ، Ksonnet أو Metaparticle. يمكنك استخدام أدوات إدارة البنية الأساسية الكلاسيكية (Ansible ، و Terraform ، و Chef ، وما إلى ذلك) لنفس الأغراض التي تحدثت عنها.

أخيرًا ، يوجد حل المشغل الذي تتزايد شعبيته.

إطار المشغل هو البديل الرئيسي لـ Helm الذي يجب عليك الانتباه إليه.

إنه أصلي بالنسبة لـ CNCF و Kubernetes ، لكن عتبة الدخول أعلى بكثير ، تحتاج إلى برمجة أكثر ووصف البيانات الظاهرة بشكل أقل.

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

فيما يلي رسم بياني بصري للمكان الذي يوجد فيه.



على المحور السيني ، مستوى التحكم الشخصي في ما يحدث ، على المحور ص ، مستوى المولد Kubernetes. هيلم الإصدار 2 هو في مكان ما في الوسط. في الإصدار 3 ، فإنه ليس هائلاً ، ولكن تم تحسين كل من التحكم ومستوى المهد. لا تزال الحلول على مستوى Ksonnet أقل شأنا حتى بالنسبة لـ Helm 2. ومع ذلك ، فهي تستحق نظرة لمعرفة ما يوجد في هذا العالم. بطبيعة الحال ، سيكون مدير التهيئة تحت سيطرتك ، ولكن ليس على الإطلاق Kubernetes.

إن إطار المشغل هو موطن أصلي لـ 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 الخاصة بك نيابة عنك.

قصة مثيرة للجدل بالنسبة لي هو دعم لوا كمحرك templating لكتابة النصوص. لست معجبًا كبيرًا بـ Lua ، لكنها ستكون ميزة اختيارية تمامًا. راجعت 3 مرات - باستخدام لوا لن يكون ضروريا. لذلك ، أي شخص يريد أن يكون قادرًا على استخدام Lua ، شخص يحب Go ، ينضم إلى معسكرنا الضخم ويستخدم go-tmpl لهذا الغرض.

, — . int string, . JSONS-, values.

event-driven model . . Helm 3, , , , , .

Helm 3 , , Helm 2, Kubernetes . , Helm Kubernetes Kubernetes.

آخر الأخبار الجيدة هي أن DevOpsConf الكسندر Haorov أقول ما إذا كانت الحاويات يمكن أن تكون آمنة؟ أذكر ، سيعقد مؤتمر حول دمج عمليات التطوير والاختبار والتشغيل في موسكو يومي 30 سبتمبر و 1 أكتوبر . حتى 20 أغسطس ، لا يزال بإمكانك إرسال تقرير والتحدث عن تجربتك في حل إحدى المهام العديدة لنهج DevOps.

للمؤتمر نقطة تفتيش ومتابعة الأخبار في إرسال و قناة برقية .