🥇هلم سکیوریتی

ماهیت داستان در مورد محبوب ترین مدیر بسته برای Kubernetes را می توان با استفاده از یک ایموجی به تصویر کشید:

جعبه Helm است (که نزدیکترین چیز به آخرین نسخه Emoji است).
قفل - امنیت؛
مرد کوچک راه حل مشکل است.

در واقع، همه چیز کمی پیچیده تر خواهد شد و داستان پر از جزئیات فنی در مورد آن است چگونه هلم را ایمن کنیم.

در صورتی که نمی دانستید یا فراموش می کردید، به طور خلاصه Helm چیست. چه مشکلاتی را حل می کند و در کجای اکوسیستم قرار دارد.
بیایید به معماری هلم نگاه کنیم. هیچ مکالمه ای در مورد امنیت و نحوه ایمن سازی ابزار یا راه حل بدون درک معماری جزء کامل نمی شود.
بیایید اجزای Helm را مورد بحث قرار دهیم.
سوزان ترین سوال آینده است - نسخه جدید Helm 3.

همه چیز در این مقاله در مورد Helm 2 صدق می کند. این نسخه در حال حاضر در حال تولید است و به احتمال زیاد همان نسخه ای است که در حال حاضر از آن استفاده می کنید و این نسخه حاوی خطرات امنیتی است.

درباره گوینده: الکساندر خایوروف (allexx) به مدت 10 سال در حال توسعه است و به بهبود محتوا کمک می کند مسکو پایتون Conf++ و به کمیته پیوست Helm Summit. اکنون او در Chainstack به عنوان یک رهبر توسعه کار می کند - این ترکیبی است بین یک مدیر توسعه و شخصی که مسئول ارائه نسخه های نهایی است. یعنی در میدان نبرد واقع شده است، جایی که همه چیز از ایجاد یک محصول تا عملکرد آن اتفاق می افتد.

Chainstack یک استارت آپ کوچک و فعال در حال رشد است که ماموریت آن این است که مشتریان را قادر سازد زیرساخت ها و پیچیدگی های اجرای برنامه های غیرمتمرکز را فراموش کنند؛ تیم توسعه در سنگاپور واقع شده است. از Chainstack برای فروش یا خرید ارز دیجیتال درخواست نکنید، بلکه پیشنهاد دهید در مورد چارچوب های بلاک چین شرکتی صحبت کنید و آنها با خوشحالی به شما پاسخ خواهند داد.

سکان

این یک بسته (نمودار) مدیر برای Kubernetes است. بصری ترین و جهانی ترین راه برای آوردن برنامه های کاربردی به یک خوشه Kubernetes.

البته ما در مورد رویکردی ساختاری و صنعتی تر از ایجاد مانیفست های YAML خود و نوشتن ابزارهای کوچک صحبت می کنیم.

هلم بهترین چیزی است که در حال حاضر موجود و محبوب است.

چرا هلم؟ در درجه اول به این دلیل که توسط CNCF پشتیبانی می شود. Cloud Native یک سازمان بزرگ است و شرکت مادر پروژه های Kubernetes، etcd، Fluentd و دیگران است.

واقعیت مهم دیگر این است که Helm یک پروژه بسیار محبوب است. وقتی در ژانویه 2019 شروع کردم به صحبت در مورد چگونگی ایمن کردن Helm، این پروژه هزاران ستاره در GitHub داشت. تا ماه مه 12 هزار نفر از آنها وجود داشت.

بسیاری از مردم به Helm علاقه مند هستند، بنابراین حتی اگر هنوز از آن استفاده نکرده اید، از اطلاع از امنیت آن سود خواهید برد. ایمنی مهم است.

تیم هسته هلم توسط Microsoft Azure پشتیبانی می شود و بنابراین برخلاف بسیاری از پروژه های دیگر نسبتاً پایدار است. انتشار Helm 3 Alpha 2 در اواسط جولای نشان می دهد که افراد بسیار زیادی روی این پروژه کار می کنند و آنها تمایل و انرژی برای توسعه و بهبود Helm دارند.

Helm چندین مشکل ریشه ای مدیریت برنامه در Kubernetes را حل می کند.

بسته بندی برنامه حتی برنامه‌ای مانند «Hello, World» در وردپرس قبلاً از چندین سرویس تشکیل شده است و شما می‌خواهید آنها را با هم بسته بندی کنید.
مدیریت پیچیدگی ناشی از مدیریت این برنامه ها.
چرخه زندگی که پس از نصب یا استقرار برنامه به پایان نمی رسد. به حیات خود ادامه می دهد، نیاز به به روز رسانی دارد، و هلم در این امر کمک می کند و سعی می کند اقدامات و سیاست های مناسبی را برای این امر ارائه دهد.

کوله بری به روشی واضح سازماندهی شده است: ابرداده مطابق با کار یک مدیر بسته معمولی برای Linux، Windows یا MacOS وجود دارد. یعنی یک مخزن، وابستگی‌ها به بسته‌های مختلف، اطلاعات متا برای برنامه‌ها، تنظیمات، ویژگی‌های پیکربندی، نمایه‌سازی اطلاعات و غیره. Helm به شما امکان می‌دهد همه اینها را برای برنامه‌ها به دست آورید و از آنها استفاده کنید.

مدیریت پیچیدگی. اگر برنامه های زیادی از یک نوع دارید، پارامترسازی لازم است. قالب‌ها از همین جا می‌آیند، اما برای اینکه مجبور نباشید راه خود را برای ایجاد قالب‌ها بیابید، می‌توانید از آنچه Helm خارج از جعبه ارائه می‌دهد استفاده کنید.

مدیریت چرخه عمر برنامه - به نظر من این جالب ترین و حل نشده ترین سوال است. به همین دلیل آن روز به هلم آمدم. ما باید چرخه عمر برنامه را زیر نظر داشته باشیم و می‌خواستیم چرخه‌های CI/CD و برنامه‌های کاربردی خود را به این پارادایم منتقل کنیم.

Helm به شما اجازه می دهد:

مدیریت استقرار، مفهوم پیکربندی و تجدید نظر را معرفی می کند.
بازگشت با موفقیت انجام شود.
استفاده از قلاب برای رویدادهای مختلف؛
بررسی های برنامه اضافی را اضافه کنید و به نتایج آنها پاسخ دهید.

علاوه بر این کلاه دارای "باتری" است - تعداد زیادی چیزهای خوشمزه که می توانند در قالب پلاگین گنجانده شوند و زندگی شما را ساده کنند. پلاگین ها را می توان به طور مستقل نوشت، آنها کاملاً ایزوله هستند و نیازی به معماری هماهنگ ندارند. اگر می‌خواهید چیزی را پیاده‌سازی کنید، توصیه می‌کنم آن را به‌عنوان یک افزونه انجام دهید و احتمالاً آن را در upstream قرار دهید.

Helm بر سه مفهوم اصلی استوار است:

نمودار نمودار - شرح و مجموعه ای از پارامترهای ممکن برای مانیفست شما.
پیکربندی - یعنی مقادیری که اعمال خواهند شد (متن، مقادیر عددی و غیره).
آزاد دو جزء بالایی را جمع آوری می کند و با هم به Release تبدیل می شوند. نسخه‌ها را می‌توان نسخه‌بندی کرد، در نتیجه به یک چرخه عمر سازمان‌یافته دست یافت: کوچک در زمان نصب و بزرگ در زمان ارتقا، کاهش یا عقب‌نشینی.

معماری هلم

این نمودار به صورت مفهومی معماری سطح بالای Helm را به تصویر می کشد.

اجازه دهید به شما یادآوری کنم که Helm چیزی مربوط به Kubernetes است. بنابراین، ما نمی توانیم بدون خوشه Kubernetes (مستطیل) کار کنیم. مؤلفه kube-apiserver روی master قرار دارد. بدون Helm ما Kubeconfig داریم. Helm یک باینری کوچک را به ارمغان می‌آورد، اگر بتوان آن را به این نام نامید، ابزار Helm CLI، که روی رایانه، لپ‌تاپ، رایانه اصلی - روی هر چیزی نصب می‌شود.

اما این کافی نیست. Helm یک جزء سرور به نام Tiller دارد. این نشان دهنده منافع Helm در داخل خوشه است؛ این یک برنامه کاربردی در خوشه Kubernetes است، درست مانند هر برنامه دیگری.

جزء بعدی Chart Repo یک مخزن با نمودار است. یک مخزن رسمی وجود دارد و ممکن است یک مخزن خصوصی یک شرکت یا پروژه وجود داشته باشد.

اثر متقابل

بیایید به نحوه تعامل اجزای معماری زمانی که می‌خواهیم برنامه‌ای را با استفاده از Helm نصب کنیم، با هم تعامل می‌کنند.

ما صحبت می کنیم Helm install، به مخزن (Chart Repo) دسترسی پیدا کنید و نمودار Helm را دریافت کنید.

ابزار Helm (Helm CLI) با Kubeconfig تعامل می کند تا بفهمد با کدام خوشه تماس بگیرید.
پس از دریافت این اطلاعات، ابزار به Tiller که در کلاستر ما قرار دارد، به عنوان یک برنامه کاربردی اشاره می کند.
تیلر Kube-apiserver را فراخوانی می کند تا اقداماتی را در Kubernetes انجام دهد، برخی از اشیاء (سرویس ها، pods، replicas، Secrets و غیره) را ایجاد کند.

در مرحله بعد، نمودار را پیچیده می کنیم تا بردار حمله را ببینیم که کل معماری Helm به عنوان یک کل می تواند در معرض آن قرار گیرد. و سپس ما سعی خواهیم کرد از او محافظت کنیم.

بردار حمله

اولین نقطه ضعف احتمالی این است API ممتاز-کاربر. به عنوان بخشی از این طرح، این یک هکر است که به Helm CLI دسترسی مدیریت پیدا کرده است.

کاربر API غیرمجاز همچنین اگر در جایی نزدیک باشد می تواند خطری ایجاد کند. چنین کاربری زمینه متفاوتی خواهد داشت، به عنوان مثال، می توان او را در یک فضای نام خوشه در تنظیمات Kubeconfig ثابت کرد.

جالب‌ترین بردار حمله ممکن است فرآیندی باشد که در یک خوشه در نزدیکی تیلر قرار دارد و می‌تواند به آن دسترسی داشته باشد. این می تواند یک وب سرور یا میکروسرویس باشد که محیط شبکه خوشه را می بیند.

یک نوع حمله عجیب و غریب، اما به طور فزاینده ای محبوب، شامل Chart Repo است. نموداری که توسط یک نویسنده بی‌وجدان ایجاد شده است ممکن است حاوی منابع ناامن باشد، و شما آن را با ایمان کامل تکمیل خواهید کرد. یا می تواند جایگزین نموداری شود که از مخزن رسمی دانلود می کنید و به عنوان مثال منبعی را در قالب سیاست ایجاد کرده و دسترسی آن را افزایش دهد.

بیایید سعی کنیم حملات از هر چهار طرف را دفع کنیم و بفهمیم که کجا در معماری Helm مشکلاتی وجود دارد و شاید در کجا وجود نداشته باشد.

بیایید نمودار را بزرگ کنیم، عناصر بیشتری اضافه کنیم، اما تمام اجزای اصلی را حفظ کنیم.

Helm CLI با Chart Repo ارتباط برقرار می کند، با Kubeconfig تعامل می کند و کار به خوشه به جزء Tiller منتقل می شود.

تیلر با دو شی نشان داده می شود:

Tiller-deploy svc که یک سرویس خاص را در معرض دید قرار می دهد.
Tiller-deploy pod (در نمودار در یک کپی در یک ماکت)، که کل بار روی آن اجرا می شود، که به خوشه دسترسی دارد.

پروتکل ها و طرح های مختلف برای تعامل استفاده می شود. از نقطه نظر امنیتی، ما بیشتر به موارد زیر علاقه داریم:

مکانیزمی که توسط آن Helm CLI به مخزن نمودار دسترسی پیدا می کند: چه پروتکلی، آیا احراز هویت وجود دارد و چه کاری می توان با آن انجام داد.
پروتکلی که Helm CLI با استفاده از kubectl با تیلر ارتباط برقرار می کند. این یک سرور RPC است که در داخل کلاستر نصب شده است.
خود تیلر برای میکروسرویس هایی که در خوشه قرار دارند و با کوبه آپی سرور تعامل دارند قابل دسترسی است.

بیایید همه این زمینه ها را به ترتیب مورد بحث قرار دهیم.

RBAC

هیچ فایده ای برای صحبت در مورد امنیت Helm یا هر سرویس دیگری در کلاستر وجود ندارد مگر اینکه RBAC فعال باشد.

به نظر می رسد این آخرین توصیه نیست، اما من مطمئن هستم که بسیاری از افراد هنوز RBAC را حتی در زمان تولید فعال نکرده اند، زیرا سر و صدا زیادی دارد و بسیاری از چیزها باید پیکربندی شوند. با این حال، من شما را به انجام این کار تشویق می کنم.

https://rbac.dev/ - وکیل وب سایت برای RBAC. این شامل مقدار زیادی از مواد جالب است که به شما در راه اندازی RBAC کمک می کند، نشان می دهد که چرا خوب است و چگونه اساساً با آن در تولید زندگی کنید.

من سعی خواهم کرد نحوه عملکرد تیلر و RBAC را توضیح دهم. تیلر در داخل خوشه تحت یک حساب سرویس خاص کار می کند. به طور معمول، اگر RBAC پیکربندی نشده باشد، این superuser خواهد بود. در پیکربندی اولیه، Tiller یک مدیر خواهد بود. به همین دلیل است که اغلب گفته می شود که Tiller یک تونل SSH به خوشه شما است. در واقع، این درست است، بنابراین شما می توانید به جای حساب پیش فرض سرویس در نمودار بالا از یک حساب سرویس اختصاصی جداگانه استفاده کنید.

هنگامی که Helm را مقداردهی اولیه می کنید و برای اولین بار آن را روی سرور نصب می کنید، می توانید حساب سرویس را با استفاده از آن تنظیم کنید --service-account. این به شما امکان می دهد از کاربری با حداقل مجموعه حقوق مورد نیاز استفاده کنید. درست است، شما باید چنین "تکلی" بسازید: Role و RoleBinding.

متأسفانه هلم این کار را برای شما انجام نخواهد داد. شما یا سرپرست خوشه Kubernetes شما باید مجموعه ای از Roles و RoleBindings را برای حساب سرویس از قبل آماده کنید تا از Helm عبور کنید.

این سوال مطرح می شود - تفاوت بین Role و ClusterRole چیست؟ تفاوت این است که ClusterRole برای همه فضاهای نام کار می کند، برخلاف Roles و RoleBindings معمولی که فقط برای یک فضای نام تخصصی کار می کنند. می‌توانید خط‌مشی‌ها را برای کل خوشه و همه فضاهای نام پیکربندی کنید یا برای هر فضای نام به‌صورت جداگانه شخصی‌سازی کنید.

لازم به ذکر است که RBAC یک مشکل بزرگ دیگر را حل می کند. بسیاری از مردم شکایت دارند که Helm، متأسفانه، چند اجاره ای نیست (از چند اجاره ای پشتیبانی نمی کند). اگر چندین تیم از یک کلاستر استفاده کنند و از Helm استفاده کنند، اساساً تنظیم خط مشی ها و محدود کردن دسترسی آنها در این خوشه غیرممکن است، زیرا یک حساب سرویس خاصی وجود دارد که Helm تحت آن اجرا می شود و تمام منابع در خوشه را از زیر آن ایجاد می کند. ، که گاهی اوقات بسیار ناخوشایند است. این درست است - مانند خود فایل باینری، مانند فرآیند، هلم تیلر مفهومی از چند اجاره ای ندارد.

با این حال، یک راه عالی وجود دارد که به شما امکان می دهد Tiller را چندین بار در یک کلاستر اجرا کنید. هیچ مشکلی با این وجود ندارد، Tiller را می توان در هر فضای نامی راه اندازی کرد. بنابراین، می توانید از RBAC، Kubeconfig به عنوان زمینه استفاده کنید و دسترسی به یک Helm ویژه را محدود کنید.

شبیه این خواهد شد.

به عنوان مثال، دو Kubeconfig با زمینه برای تیم های مختلف (دو فضای نام) وجود دارد: X Team برای تیم توسعه و خوشه مدیریت. خوشه ادمین Tiller گسترده خود را دارد که در فضای نام سیستم Kube قرار دارد، یک حساب سرویس پیشرفته مربوطه. و یک فضای نام جداگانه برای تیم توسعه، آنها می توانند خدمات خود را در یک فضای نام خاص مستقر کنند.

این یک رویکرد قابل اجرا است، تیلر آنقدر تشنه قدرت نیست که بر بودجه شما تأثیر زیادی بگذارد. این یکی از راه حل های سریع است.

با خیال راحت Tiller را به طور جداگانه پیکربندی کنید و Kubeconfig را برای تیم، یک توسعه دهنده خاص یا برای محیط ارائه دهید: Dev، Staging، Production (مشکوک است که همه چیز در یک کلاستر باشد، با این حال، این کار قابل انجام است).

در ادامه داستان، بیایید از RBAC جابجا شده و در مورد ConfigMaps صحبت کنیم.

ConfigMaps

Helm از ConfigMaps به عنوان ذخیره داده خود استفاده می کند. وقتی در مورد معماری صحبت کردیم، هیچ پایگاه داده ای وجود نداشت که اطلاعات مربوط به نسخه ها، پیکربندی ها، بازگشت ها و غیره را ذخیره کند. برای این کار از ConfigMaps استفاده می شود.

مشکل اصلی ConfigMaps شناخته شده است - آنها در اصل ناامن هستند. ذخیره اطلاعات حساس غیرممکن است. ما در مورد همه چیزهایی صحبت می کنیم که نباید از سرویس فراتر رود، به عنوان مثال، رمزهای عبور. بومی ترین راه برای Helm در حال حاضر تغییر استفاده از ConfigMaps به Secrets است.

این کار بسیار ساده انجام می شود. تنظیمات 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 - همچنین از تایید اولیه پشتیبانی می کند. اگر راحت تر و کم صداتر باشد، می توانید از احراز هویت اولیه استفاده کنید.

یک افزونه نیز وجود دارد 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 محافظت خواهید کرد.

بنابراین، ما کانال اتصال را به Tiller ایمن کرده ایم، قبلاً RBAC را مورد بحث قرار داده ایم و حقوق Apiserver Kubernetes را تنظیم کرده ایم و دامنه ای را که می تواند با آن تعامل داشته باشد کاهش می دهد.

هلم محافظت شده

بیایید به نمودار نهایی نگاه کنیم. این همان معماری با همان فلش است.

اکنون همه اتصالات را می توان با خیال راحت به رنگ سبز ترسیم کرد:

برای Chart Repo از TLS یا mTLS و auth اولیه استفاده می کنیم.
mTLS برای Tiller، و به عنوان یک سرویس gRPC با TLS در معرض دید قرار می گیرد، ما از گواهی ها استفاده می کنیم.
خوشه از یک حساب سرویس ویژه با Role و RoleBinding استفاده می کند.

ما خوشه را به میزان قابل توجهی ایمن کرده ایم، اما یک نفر باهوش گفت:

"تنها یک راه حل کاملا ایمن می تواند وجود داشته باشد - یک کامپیوتر خاموش، که در یک جعبه سیمانی قرار دارد و توسط سربازان محافظت می شود."

راه های مختلفی برای دستکاری داده ها و یافتن بردارهای حمله جدید وجود دارد. با این حال، من مطمئن هستم که این توصیه ها به یک استاندارد صنعتی اساسی برای ایمنی دست خواهند یافت.

جایزه

این قسمت ارتباط مستقیمی با امنیت ندارد، اما مفید نیز خواهد بود. من چیزهای جالبی را به شما نشان خواهم داد که کمتر کسی در مورد آنها می داند. به عنوان مثال، نحوه جستجوی نمودارها - رسمی و غیر رسمی.

در مخزن github.com/helm/charts اکنون حدود 300 نمودار و دو جریان وجود دارد: پایدار و انکوباتور. هر کسی که کمک می کند، به خوبی می داند که رسیدن از انکوباتور به اصطبل چقدر دشوار است، و چقدر آسان است که از اصطبل پرواز کنید. با این حال، این بهترین ابزار برای جستجوی نمودارهای Prometheus و هر چیز دیگری که دوست دارید نیست، به یک دلیل ساده - این پورتال نیست که بتوانید به راحتی بسته ها را در آن جستجو کنید.

اما یک سرویس وجود دارد hub.helm.sh، که یافتن نمودارها را بسیار راحت تر می کند. مهمتر از همه، مخازن خارجی بسیار بیشتر و تقریباً 800 طلسم موجود است. به علاوه، اگر به دلایلی نمی‌خواهید نمودارهای خود را به استیبل ارسال کنید، می‌توانید مخزن خود را متصل کنید.

hub.helm.sh را امتحان کنید و بیایید با هم آن را توسعه دهیم. این سرویس تحت پروژه Helm است و حتی اگر یک توسعه‌دهنده فرانت‌اند هستید و فقط می‌خواهید ظاهر را بهبود ببخشید، می‌توانید به رابط کاربری آن کمک کنید.

همچنین توجه شما را به این موضوع جلب می کنم ادغام API بروکر سرویس را باز کنید. دست و پا گیر و مبهم به نظر می رسد، اما مشکلاتی را که همه با آن مواجه هستند حل می کند. بگذارید با یک مثال ساده توضیح دهم.

یک خوشه Kubernetes وجود دارد که در آن می خواهیم یک برنامه کلاسیک - وردپرس را اجرا کنیم. به طور کلی، یک پایگاه داده برای عملکرد کامل مورد نیاز است. راه حل های مختلفی وجود دارد، به عنوان مثال، می توانید سرویس statefull خود را راه اندازی کنید. این خیلی راحت نیست، اما بسیاری از مردم آن را انجام می دهند.

دیگران، مانند ما در Chainstack، از پایگاه داده های مدیریت شده مانند MySQL یا PostgreSQL برای سرورهای خود استفاده می کنند. به همین دلیل پایگاه داده های ما در جایی در فضای ابری قرار دارند.

اما یک مشکل پیش می‌آید: ما باید سرویس خود را با یک پایگاه داده متصل کنیم، یک طعم پایگاه داده ایجاد کنیم، اعتبار را انتقال دهیم و به نحوی آن را مدیریت کنیم. همه اینها معمولاً به صورت دستی توسط مدیر یا توسعه دهنده سیستم انجام می شود. و وقتی برنامه های کمی وجود دارد مشکلی وجود ندارد. هنگامی که تعداد آنها زیاد است، به یک ترکیب نیاز دارید. چنین دروگر وجود دارد - کارگزار خدمات است. این به شما امکان می دهد از یک پلاگین ویژه برای یک خوشه ابر عمومی استفاده کنید و منابع را از طریق Broker از ارائه دهنده سفارش دهید، گویی یک API است. برای این کار می توانید از ابزارهای بومی Kubernetes استفاده کنید.

خیلی ساده است. برای مثال، می‌توانید MySQL مدیریت شده را در Azure با یک لایه پایه جستجو کنید (این را می‌توان پیکربندی کرد). با استفاده از Azure API پایگاه داده ایجاد و برای استفاده آماده می شود. شما نیازی به دخالت در این کار ندارید، افزونه مسئول این کار است. به عنوان مثال، OSBA (افزونه Azure) اعتبار را به سرویس برمی گرداند و آن را به Helm ارسال می کند. شما قادر خواهید بود از وردپرس با MySQL ابری استفاده کنید، به هیچ وجه با پایگاه داده های مدیریت شده سروکار نداشته باشید و نگران سرویس های دولتی نباشید.

می توان گفت که Helm به عنوان یک چسب عمل می کند که از یک طرف به شما امکان می دهد خدمات را مستقر کنید و از طرف دیگر منابع ارائه دهندگان ابر را مصرف کنید.

شما می توانید افزونه خود را بنویسید و از کل این داستان در محل استفاده کنید. سپس شما به سادگی پلاگین خود را برای ارائه دهنده Cloud شرکتی خواهید داشت. توصیه می کنم این روش را امتحان کنید، به خصوص اگر مقیاس بزرگی دارید و می خواهید به سرعت توسعه دهنده، مرحله بندی یا کل زیرساخت را برای یک ویژگی به کار ببرید. این کار زندگی عملیات یا DevOps شما را آسان تر می کند.

یافته دیگری که قبلاً به آن اشاره کردم این است پلاگین helm-gcs، که به شما امکان می دهد از Google-buckets (ذخیره سازی اشیا) برای ذخیره نمودارهای Helm استفاده کنید.

برای شروع استفاده از آن فقط به چهار دستور نیاز دارید:

نصب افزونه؛
آن را آغاز کنید؛
مسیر سطل را که در gcp قرار دارد تنظیم کنید.
نمودارها را به روش استاندارد منتشر کنید.

زیبایی این است که روش gcp بومی برای مجوز استفاده خواهد شد. می توانید از یک حساب سرویس، یک حساب توسعه دهنده، هر آنچه که می خواهید استفاده کنید. بسیار راحت است و هزینه ای برای کارکرد ندارد. اگر شما نیز مانند من، فلسفه opsless را ترویج می کنید، این امر به خصوص برای تیم های کوچک بسیار راحت خواهد بود.

جایگزین، گزینه ها

Helm تنها راه حل مدیریت خدمات نیست. سوالات زیادی در مورد آن وجود دارد، احتمالاً به همین دلیل است که نسخه سوم به سرعت ظاهر شد. البته جایگزین هایی وجود دارد.

اینها می توانند راه حل های تخصصی، به عنوان مثال، Ksonnet یا Metaparticle باشند. شما می توانید از ابزارهای مدیریت زیرساخت کلاسیک خود (Ansible، Terraform، Chef و غیره) برای همان اهدافی که در مورد آن صحبت کردم استفاده کنید.

بالاخره راه حلی وجود دارد چارچوب اپراتور، که محبوبیت آن در حال افزایش است.

Operator Framework بهترین جایگزین Helm است که باید در نظر گرفته شود.

این بیشتر بومی CNCF و Kubernetes است، اما مانع ورود بسیار بالاتر است، باید بیشتر برنامه ریزی کنید و مانیفست ها را کمتر توصیف کنید.

افزونه های مختلفی مانند Draft، Scaffold وجود دارد. آن‌ها زندگی را بسیار آسان‌تر می‌کنند، برای مثال، چرخه ارسال و راه‌اندازی Helm را برای توسعه‌دهندگان برای استقرار یک محیط آزمایشی ساده‌تر می‌کنند. من آنها را توانمند می نامم.

در اینجا نمودار بصری جایی است که همه چیز در آن قرار دارد.

در محور x سطح کنترل شخصی شما بر آنچه در حال رخ دادن است، در محور y سطح بومی بودن Kubernetes است. Helm نسخه 2 جایی در وسط می افتد. در نسخه 3، نه به شدت، اما هم کنترل و هم سطح بومی بودن بهبود یافته است. راه حل ها در سطح Ksonnet هنوز حتی نسبت به Helm 2 پایین تر هستند. البته، مدیر پیکربندی شما تحت کنترل شما خواهد بود، اما کاملاً بومی Kubernetes نیست.

چارچوب اپراتور کاملاً بومی Kubernetes است و به شما امکان می دهد آن را بسیار زیباتر و دقیق تر مدیریت کنید (اما سطح ورودی را به خاطر بسپارید). بلکه برای یک کاربرد تخصصی و ایجاد مدیریت برای آن مناسب است، نه یک برداشت انبوه برای بسته بندی تعداد زیادی برنامه با استفاده از Helm.

توسعه دهنده ها به سادگی کنترل را کمی بهبود می بخشند، گردش کار را تکمیل می کنند، یا گوشه های خطوط لوله CI/CD را برش می دهند.

آینده هلم

خبر خوب این است که Helm 3 در راه است نسخه آلفا Helm 3.0.0-alpha.2 قبلا منتشر شده است، می توانید آن را امتحان کنید. کاملاً پایدار است، اما عملکرد هنوز محدود است.

چرا به Helm 3 نیاز دارید؟ اول از همه، این یک داستان است ناپدید شدن تیلر، به عنوان یک جزء. همانطور که قبلاً فهمیدید، این یک گام بزرگ به جلو است، زیرا از نقطه نظر امنیت معماری، همه چیز ساده شده است.

هنگامی که Helm 2 ایجاد شد، که در حدود زمان Kubernetes 1.8 یا حتی قبل از آن بود، بسیاری از مفاهیم نابالغ بودند. به عنوان مثال، مفهوم CRD در حال حاضر به طور فعال در حال اجرا است، و Helm خواهد شد از CRD استفاده کنیدبرای ذخیره سازه ها امکان استفاده فقط از کلاینت و عدم نگهداری قسمت سرور وجود خواهد داشت. بر این اساس، از دستورات بومی Kubernetes برای کار با ساختارها و منابع استفاده کنید. این یک گام بزرگ به جلو است.

پدیدار خواهد شد پشتیبانی از مخازن بومی OCI (ابتکار کانتینر باز). این یک ابتکار بزرگ است و هلم در درجه اول به ارسال نمودارهای خود علاقه دارد. کار به جایی می رسد که به عنوان مثال، داکر هاب از بسیاری از استانداردهای OCI پشتیبانی می کند. من حدس نمی زنم، اما شاید ارائه دهندگان مخزن کلاسیک Docker به شما این فرصت را بدهند که نمودارهای Helm خود را میزبانی کنید.

داستان جنجالی برای من این است پشتیبانی لوا، به عنوان موتور قالب برای نوشتن اسکریپت. من طرفدار زیادی از Lua نیستم، اما این یک ویژگی کاملا اختیاری است. من این را 3 بار بررسی کردم - استفاده از Lua ضروری نخواهد بود. بنابراین، کسانی که می خواهند بتوانند از Lua استفاده کنند، کسانی که Go را دوست دارند، به اردوی عظیم ما ملحق می شوند و برای این کار از go-tmpl استفاده می کنند.

در نهایت، چیزی که من قطعا از دست داده بودم پیدایش طرحواره و اعتبارسنجی نوع داده. دیگر هیچ مشکلی با int یا string وجود نخواهد داشت، نیازی به قرار دادن صفر در دو گیومه نیست. یک طرح JSONS ظاهر می شود که به شما امکان می دهد به صراحت این را برای مقادیر توصیف کنید.

به شدت دوباره کار خواهد شد مدل رویداد محور. قبلاً به صورت مفهومی توضیح داده شده است. به شاخه Helm 3 نگاه کنید، خواهید دید که چند رویداد و قلاب و موارد دیگر اضافه شده است که تا حد زیادی ساده می شود و از طرف دیگر کنترل فرآیندهای استقرار و واکنش ها را به آنها اضافه می کند.

Helm 3 ساده‌تر، ایمن‌تر و سرگرم‌کننده‌تر خواهد بود، نه به این دلیل که ما Helm 2 را دوست نداریم، بلکه به این دلیل که Kubernetes در حال پیشرفته‌تر شدن است. بر این اساس، هلم می تواند از پیشرفت های کوبرنتیس استفاده کند و مدیران عالی برای کوبرنتیس روی آن ایجاد کند.

خبر خوب دیگر این است که DevOpsConf الکساندر خایوروف به شما خواهد گفت آیا ظروف می توانند ایمن باشند؟ یادآوری می کنیم که کنفرانس ادغام فرآیندهای توسعه، آزمایش و عملیات در مسکو برگزار می شود 30 سپتامبر و 1 اکتبر. هنوز هم می توانید تا 20 آگوست این کار را انجام دهید ارسال گزارش و تجربه خود را در مورد راه حل به ما بگویید یکی از بسیاری وظایف رویکرد DevOps

پست های بازرسی کنفرانس و اخبار را در لیست پستی и کانال تلگرام.

منبع: www.habr.com

امنیت هلم