🥇 ہیلم 3 کا تعارف

نوٹ. ترجمہ: اس سال کا 16 مئی کوبرنیٹس - ہیلم کے پیکیج مینیجر کی ترقی میں ایک اہم سنگ میل ہے۔ اس دن، منصوبے کے مستقبل کے بڑے ورژن کا پہلا الفا ریلیز - 3.0 - پیش کیا گیا تھا۔ اس کی ریلیز ہیلم میں اہم اور طویل انتظار کی تبدیلیاں لائے گی، جس کے لیے کوبرنیٹس کمیونٹی میں بہت سے لوگوں کو بہت امیدیں ہیں۔ ہم خود بھی ان میں سے ایک ہیں، چونکہ ہم ایپلیکیشن کی تعیناتی کے لیے ہیلم کو فعال طور پر استعمال کرتے ہیں: ہم نے اسے CI/CD کو لاگو کرنے کے لیے اپنے ٹول میں ضم کر لیا ہے۔ werf اور وقتا فوقتا ہم اپ اسٹریم کی ترقی میں اپنا حصہ ڈالتے ہیں۔ یہ ترجمہ سرکاری ہیلم بلاگ کے 7 نوٹوں کو یکجا کرتا ہے، جو ہیلم 3 کے پہلے الفا ریلیز کے لیے وقف ہیں اور پروجیکٹ کی تاریخ اور ہیلم 3 کی اہم خصوصیات کے بارے میں بات کرتے ہیں۔ ان کے مصنف Matt "bacongobbler" Fisher ہیں، جو مائیکرو سافٹ کا ملازم ہے۔ اور ہیلم کے کلیدی دیکھ بھال کرنے والوں میں سے ایک۔

15 اکتوبر 2015 کو، اب ہیلم کے نام سے جانا جانے والا پروجیکٹ پیدا ہوا۔ اس کے قیام کے صرف ایک سال بعد، ہیلم کمیونٹی نے Kubernetes میں شمولیت اختیار کی، جبکہ Helm 2 پر فعال طور پر کام کیا۔ جون 2018 میں، Helm CNCF میں شمولیت اختیار کی۔ ایک ترقی پذیر (انکیوبٹنگ) پروجیکٹ کے طور پر۔ موجودہ کی طرف تیزی سے آگے بڑھیں، اور نئے ہیلم 3 کا پہلا الفا ریلیز اپنے راستے پر ہے۔ (یہ ریلیز پہلے ہی ہوا ہے مئی کے وسط میں - تقریبا. ترجمہ).

اس حصے میں، میں اس کے بارے میں بات کروں گا کہ یہ سب کہاں سے شروع ہوا، ہم آج جہاں ہیں وہاں تک کیسے پہنچے، ہیلم 3 کے پہلے الفا ریلیز میں دستیاب کچھ منفرد خصوصیات کا تعارف کروائیں گے، اور بتاؤں گا کہ ہم آگے بڑھنے کا منصوبہ کیسے بناتے ہیں۔

خلاصہ:

ہیلم کی تخلیق کی تاریخ؛
ٹلر کو ایک ٹینڈر الوداع؛
چارٹ کے ذخیرے؛
رہائی کا انتظام؛
چارٹ انحصار میں تبدیلی؛
لائبریری چارٹس؛
اس کے بعد کیا ہے؟

ہیلم کی تاریخ

پیدائش

ہیلم 1 کا آغاز ایک اوپن سورس پروجیکٹ کے طور پر ہوا جسے ڈیس نے تخلیق کیا تھا۔ ہم ایک چھوٹا سا آغاز تھا۔ جذب مائیکروسافٹ موسم بہار 2017 میں۔ ہمارے دوسرے اوپن سورس پروجیکٹ، جس کا نام ڈیس بھی ہے، میں ایک ٹول تھا۔ deisctl، جو (دوسری چیزوں کے علاوہ) میں Deis پلیٹ فارم کو انسٹال کرنے اور چلانے کے لیے استعمال کیا گیا تھا۔ فلیٹ کلسٹر. اس وقت، فلیٹ پہلے کنٹینر آرکیسٹریشن پلیٹ فارمز میں سے ایک تھا۔

2015 کے وسط میں، ہم نے کورس تبدیل کرنے کا فیصلہ کیا اور Deis (اس وقت Deis Workflow کا نام تبدیل کر کے) Fleet سے Kubernetes میں منتقل کر دیا۔ دوبارہ ڈیزائن کیے جانے والے پہلے میں سے ایک انسٹالیشن ٹول تھا۔ deisctl. ہم نے اسے Fleet کلسٹر میں Deis Workflow کو انسٹال اور منظم کرنے کے لیے استعمال کیا۔

ہیلم 1 مشہور پیکیج مینیجرز جیسے ہومبریو، آپٹ اور یم کی تصویر میں بنایا گیا تھا۔ اس کا بنیادی مقصد Kubernetes پر پیکیجنگ اور ایپلی کیشنز کو انسٹال کرنے جیسے کاموں کو آسان بنانا تھا۔ ہیلم کو باضابطہ طور پر 2015 میں سان فرانسسکو میں کیوبیکون کانفرنس میں متعارف کرایا گیا تھا۔

ہیلم کے ساتھ ہماری پہلی کوشش نے کام کیا، لیکن یہ کچھ سنگین حدود کے بغیر نہیں تھا۔ اس نے Kubernetes مینی فیسٹس کا ایک سیٹ لیا، جس کا ذائقہ جنریٹرز کے ساتھ تعارفی YAML بلاکس کے طور پر تھا۔ (سامنے معاملہ)*، اور نتائج کوبرنیٹس میں لوڈ کیا۔

* نوٹ. ترجمہ: ہیلم کے پہلے ورژن سے، YAML نحو کو Kubernetes کے وسائل کو بیان کرنے کے لیے منتخب کیا گیا تھا، اور کنفیگریشن لکھتے وقت جنجا ٹیمپلیٹس اور Python اسکرپٹس کو سپورٹ کیا گیا تھا۔ ہم نے اس کے بارے میں اور عام طور پر ہیلم کے پہلے ورژن کی ساخت کے بارے میں باب "ہیلم کی مختصر تاریخ" میں لکھا ہے۔ یہ مواد.

مثال کے طور پر، YAML فائل میں کسی فیلڈ کو تبدیل کرنے کے لیے، آپ کو مینی فیسٹ میں درج ذیل کنسٹرکٹ کو شامل کرنا ہوگا۔

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

یہ بہت اچھی بات ہے کہ آج ٹیمپلیٹ انجن موجود ہیں، ہے نا؟

بہت سی وجوہات کی بناء پر، اس ابتدائی Kubernetes انسٹالر کو مینی فیسٹ فائلوں کی ہارڈ کوڈ شدہ فہرست کی ضرورت تھی اور اس نے صرف واقعات کی ایک چھوٹی، مقررہ ترتیب کو انجام دیا تھا۔ اسے استعمال کرنا اتنا مشکل تھا کہ Deis Workflow R&D ٹیم کو اس پلیٹ فارم پر اپنے پروڈکٹ کو منتقل کرنے کی کوشش کرتے وقت بہت مشکل پیش آئی - تاہم، خیال کے بیج بوئے جا چکے تھے۔ ہماری پہلی کوشش سیکھنے کا ایک بہترین موقع تھا: ہمیں احساس ہوا کہ ہم اپنے صارفین کے لیے روزمرہ کے مسائل کو حل کرنے والے عملی ٹولز بنانے کے لیے واقعی پرجوش تھے۔

ماضی کی غلطیوں کے تجربے کی بنیاد پر، ہم نے ہیلم 2 تیار کرنا شروع کیا۔

ہیلم بنانا 2

2015 کے آخر میں، گوگل ٹیم نے ہم سے رابطہ کیا۔ وہ Kubernetes کے لیے اسی طرح کے ٹول پر کام کر رہے تھے۔ Kubernetes کے لیے تعیناتی مینیجر ایک موجودہ ٹول کا ایک پورٹ تھا جسے Google Cloud Platform کے لیے استعمال کیا جاتا تھا۔ "کیا ہم پسند کریں گے،" انہوں نے پوچھا، "مماثلتوں اور فرقوں پر گفتگو کرتے ہوئے کچھ دن گزاریں؟"

جنوری 2016 میں، ہیلم اور تعیناتی مینیجر کی ٹیمیں خیالات کے تبادلے کے لیے سیئٹل میں ملیں۔ مذاکرات ایک پرجوش منصوبے کے ساتھ ختم ہوئے: ہیلم 2 بنانے کے لیے دونوں منصوبوں کو یکجا کرنے کے لیے۔ ڈیس اور گوگل کے ساتھ ساتھ، کے لوگ سکپ باکس (اب بٹ نامی کا حصہ - تقریباً ترجمہ)، اور ہم نے ہیلم 2 پر کام کرنا شروع کیا۔

ہم ہیلم کے استعمال میں آسانی کو برقرار رکھنا چاہتے تھے، لیکن درج ذیل شامل کریں:

حسب ضرورت کے لیے چارٹ ٹیمپلیٹس؛
ٹیموں کے لیے انٹرا کلسٹر مینجمنٹ؛
عالمی معیار کا چارٹ ذخیرہ؛
دستخط کے اختیارات کے ساتھ مستحکم پیکیج کی شکل؛
سیمنٹک ورژننگ اور ورژن کے درمیان پسماندہ مطابقت کو برقرار رکھنے کے لیے ایک مضبوط عزم۔

ان اہداف کو حاصل کرنے کے لیے، ہیلم ماحولیاتی نظام میں ایک دوسرا عنصر شامل کیا گیا ہے۔ اس انٹرا کلسٹر جزو کو ٹلر کہا جاتا تھا اور وہ ہیلم چارٹس کو انسٹال کرنے اور ان کا انتظام کرنے کا ذمہ دار تھا۔

2 میں Helm 2016 کی ریلیز کے بعد سے، Kubernetes نے کئی بڑی اختراعات شامل کی ہیں۔ رول پر مبنی رسائی کنٹرول شامل کیا گیا (آر بی اے سی۔)، جس نے بالآخر انتساب پر مبنی رسائی کنٹرول (ABAC) کی جگہ لے لی۔ وسائل کی نئی اقسام متعارف کرائی گئیں (تعینات اس وقت بیٹا میں تھیں)۔ حسب ضرورت وسائل کی تعریفیں (اصل میں تھرڈ پارٹی ریسورسز یا TPRs کہلاتی ہیں) ایجاد کی گئیں۔ اور سب سے اہم بات یہ ہے کہ بہترین طریقوں کا ایک مجموعہ سامنے آیا ہے۔

ان تمام تبدیلیوں کے درمیان، Helm نے Kubernetes کے صارفین کو وفاداری سے خدمت جاری رکھی۔ تین سال اور بہت سے نئے اضافے کے بعد، یہ واضح تھا کہ یہ کوڈ بیس میں اہم تبدیلیاں کرنے کا وقت ہے تاکہ یہ یقینی بنایا جا سکے کہ ہیلم ایک ابھرتے ہوئے ماحولیاتی نظام کی بڑھتی ہوئی ضروریات کو پورا کرتا رہے۔

ٹلر کو ایک ٹینڈر الوداع

Helm 2 کی ترقی کے دوران، ہم نے Tiller کو Google کے تعیناتی مینیجر کے ساتھ اپنے انضمام کے حصے کے طور پر متعارف کرایا۔ ٹلر نے ایک مشترکہ کلسٹر میں کام کرنے والی ٹیموں کے لیے ایک اہم کردار ادا کیا: اس نے بنیادی ڈھانچے کو چلانے والے مختلف ماہرین کو ریلیز کے ایک ہی سیٹ کے ساتھ بات چیت کرنے کی اجازت دی۔

چونکہ رول بیسڈ ایکسیس کنٹرول (RBAC) کو بطور ڈیفالٹ Kubernetes 1.6 میں فعال کیا گیا تھا، اس لیے پیداوار میں Tiller کے ساتھ کام کرنا زیادہ مشکل ہو گیا۔ ممکنہ سیکورٹی پالیسیوں کی سراسر تعداد کی وجہ سے، ہمارا موقف یہ رہا ہے کہ بطور ڈیفالٹ اجازت دینے والی ترتیب پیش کی جائے۔ اس سے نوزائیدہوں کو پہلے سیکیورٹی کی ترتیبات میں غوطہ لگائے بغیر ہیلم اور کبرنیٹس کے ساتھ تجربہ کرنے کا موقع ملا۔ بدقسمتی سے، یہ اجازت کنفیگریشن صارف کو بہت زیادہ وسیع اجازتیں دے سکتی ہے جس کی انہیں ضرورت نہیں تھی۔ ڈی او اوپس اور ایس آر ای انجینئرز کو ملٹی ٹیننٹ کلسٹر میں ٹلر انسٹال کرتے وقت اضافی آپریشنل اقدامات سیکھنے پڑتے تھے۔

یہ جاننے کے بعد کہ کمیونٹی نے مخصوص حالات میں ہیلم کو کس طرح استعمال کیا، ہم نے محسوس کیا کہ ٹلر کے ریلیز مینجمنٹ سسٹم کو ریاست کو برقرار رکھنے یا ریلیز کی معلومات کے مرکزی مرکز کے طور پر کام کرنے کے لیے انٹرا کلسٹر جزو پر انحصار کرنے کی ضرورت نہیں ہے۔ اس کے بجائے، ہم آسانی سے Kubernetes API سرور سے معلومات حاصل کر سکتے ہیں، کلائنٹ سائیڈ پر ایک چارٹ بنا سکتے ہیں، اور Kubernetes میں انسٹالیشن کا ریکارڈ محفوظ کر سکتے ہیں۔

ٹلر کا بنیادی مقصد ٹِلر کے بغیر حاصل کیا جا سکتا تھا، لہٰذا ہیلم 3 کے حوالے سے ہمارے پہلے فیصلوں میں سے ایک ٹِلر کو مکمل طور پر ترک کرنا تھا۔

ٹلر کے جانے کے بعد، ہیلم کے سیکورٹی ماڈل کو یکسر آسان کر دیا گیا ہے۔ Helm 3 اب موجودہ Kubernetes کے تمام جدید سیکورٹی، شناخت اور اجازت کے طریقوں کی حمایت کرتا ہے۔ ہیلم کی اجازتوں کا استعمال کرتے ہوئے تعین کیا جاتا ہے۔ kubeconfig فائل. کلسٹر ایڈمنسٹریٹر صارف کے حقوق کو کسی بھی سطح کی گرانولریٹی تک محدود کر سکتے ہیں۔ ریلیز اب بھی کلسٹر کے اندر محفوظ ہیں، اور ہیلم کی بقیہ فعالیت برقرار ہے۔

چارٹ کے ذخیرے

اعلی سطح پر، چارٹ کا ذخیرہ ایک ایسی جگہ ہے جہاں چارٹس کو ذخیرہ اور شیئر کیا جا سکتا ہے۔ ہیلم کلائنٹ پیکج کرتا ہے اور چارٹس کو ریپوزٹری کو بھیجتا ہے۔ سیدھے الفاظ میں، چارٹس ریپوزٹری ایک قدیم HTTP سرور ہے جس میں ایک index.yaml فائل اور کچھ پیکڈ چارٹس ہیں۔

اگرچہ چارٹس ریپوزٹری API کے کچھ فوائد ہیں جو زیادہ تر بنیادی اسٹوریج کی ضروریات کو پورا کرتے ہیں، لیکن کچھ نقصانات بھی ہیں:

چارٹ کے ذخیرے پیداواری ماحول میں درکار زیادہ تر حفاظتی نفاذ کے ساتھ مطابقت نہیں رکھتے۔ تصدیق اور اجازت کے لیے معیاری API کا ہونا پیداواری منظرناموں میں انتہائی اہم ہے۔
ہیلم کے چارٹ پرووینس ٹولز، جو چارٹ کی سالمیت اور اصلیت پر دستخط کرنے، تصدیق کرنے کے لیے استعمال ہوتے ہیں، چارٹ کی اشاعت کے عمل کا ایک اختیاری حصہ ہیں۔
کثیر صارف کے منظرناموں میں، ایک ہی چارٹ کو دوسرے صارف کے ذریعے اپ لوڈ کیا جا سکتا ہے، اسی مواد کو ذخیرہ کرنے کے لیے درکار جگہ کی مقدار کو دوگنا کر کے۔ اس مسئلے کو حل کرنے کے لیے ذہین ذخیرے تیار کیے گئے ہیں، لیکن وہ رسمی تفصیلات کا حصہ نہیں ہیں۔
تلاش کرنے، میٹا ڈیٹا کو ذخیرہ کرنے، اور چارٹس کو بازیافت کرنے کے لیے سنگل انڈیکس فائل کا استعمال کرنے سے محفوظ کثیر صارف کے نفاذ کو تیار کرنا مشکل ہو گیا ہے۔

پروجیکٹ ڈاکر کی تقسیم (جسے Docker Registry v2 بھی کہا جاتا ہے) Docker Registry کا جانشین ہے اور بنیادی طور پر Docker امیجز کی پیکیجنگ، شپنگ، اسٹور کرنے اور ڈیلیور کرنے کے لیے ٹولز کے ایک سیٹ کے طور پر کام کرتا ہے۔ بہت سی بڑی کلاؤڈ سروسز تقسیم پر مبنی مصنوعات پیش کرتی ہیں۔ اس بڑھتی ہوئی توجہ کی بدولت، ڈسٹری بیوشن پروجیکٹ کو برسوں کی بہتری، سیکیورٹی کے بہترین طریقوں، اور فیلڈ ٹیسٹنگ سے فائدہ ہوا ہے جس نے اسے اوپن سورس کی دنیا کے سب سے کامیاب گمنام ہیروز میں سے ایک بنا دیا ہے۔

لیکن کیا آپ جانتے ہیں کہ ڈسٹری بیوشن پروجیکٹ کو کسی بھی قسم کے مواد کو تقسیم کرنے کے لیے ڈیزائن کیا گیا تھا، نہ کہ صرف کنٹینر کی تصاویر؟

کوششوں کا شکریہ اوپن کنٹینر انیشی ایٹو (یا OCI)، ہیلم چارٹ کسی بھی ڈسٹری بیوشن مثال پر رکھا جا سکتا ہے۔ فی الحال، یہ عمل تجرباتی ہے۔ لاگ ان سپورٹ اور مکمل ہیلم 3 کے لیے درکار دیگر فیچرز پر کام جاری ہے، لیکن ہم OCI اور ڈسٹری بیوشن ٹیموں کی جانب سے گزشتہ برسوں میں کی گئی دریافتوں سے سیکھنے کے لیے پرجوش ہیں۔ اور ان کی رہنمائی اور رہنمائی کے ذریعے، ہم یہ سیکھتے ہیں کہ بڑے پیمانے پر ایک انتہائی دستیاب سروس کو چلانا کیسا ہوتا ہے۔

ہیلم چارٹ کے ذخیروں میں آنے والی کچھ تبدیلیوں کی مزید تفصیلی وضاحت دستیاب ہے۔ ссылке по.

رہائی کا انتظام

ہیلم 3 میں، درخواست کی حالت کو کلسٹر کے اندر اشیاء کے جوڑے کے ذریعے ٹریک کیا جاتا ہے:

ریلیز آبجیکٹ - ایک ایپلیکیشن مثال کی نمائندگی کرتا ہے۔
ریلیز ورژن سیکرٹ - وقت کے ایک خاص نقطہ پر ایپلیکیشن کی مطلوبہ حالت کی نمائندگی کرتا ہے (مثال کے طور پر، ایک نئے ورژن کی ریلیز)۔

چیلینج۔ helm install ایک ریلیز آبجیکٹ اور ریلیز ورژن سیکریٹ بناتا ہے۔ کال کریں۔ helm upgrade ایک ریلیز آبجیکٹ کی ضرورت ہوتی ہے (جسے یہ تبدیل کر سکتا ہے) اور ایک نیا ریلیز ورژن سیکریٹ تخلیق کرتا ہے جس میں نئی اقدار اور ایک تیار شدہ مینی فیسٹ ہوتا ہے۔

ریلیز آبجیکٹ ریلیز کے بارے میں معلومات پر مشتمل ہے، جہاں ریلیز ایک نامزد چارٹ اور اقدار کی مخصوص تنصیب ہے۔ یہ اعتراض ریلیز کے بارے میں اعلی سطحی میٹا ڈیٹا کی وضاحت کرتا ہے۔ ریلیز آبجیکٹ ایپلی کیشن کے پورے لائف سائیکل کے دوران برقرار رہتا ہے اور ریلیز ورژن کے تمام رازوں کے ساتھ ساتھ ہیلم چارٹ کے ذریعے براہ راست تخلیق کردہ تمام اشیاء کا مالک ہے۔

ریلیز ورژن سیکرٹ ایک ریلیز کو نظرثانی کی ایک سیریز کے ساتھ جوڑتا ہے (انسٹالیشن، اپ ڈیٹس، رول بیکس، ڈیلیٹ)۔

ہیلم 2 میں، نظر ثانی انتہائی مستقل تھی۔ کال کریں۔ helm install v1 بنایا، بعد میں اپ ڈیٹ (اپ گریڈ) - v2، وغیرہ۔ ریلیز اور ریلیز ورژن سیکرٹ کو ایک واحد شے میں سمٹ دیا گیا ہے جسے نظر ثانی کہا جاتا ہے۔ نظر ثانی کو اسی نام کی جگہ میں محفوظ کیا گیا تھا جیسا کہ ٹلر، جس کا مطلب تھا کہ ہر ریلیز نام کی جگہ کے لحاظ سے "عالمی" تھی۔ نتیجے کے طور پر، نام کی صرف ایک مثال استعمال کی جا سکتی ہے۔

ہیلم 3 میں، ہر ریلیز ایک یا زیادہ ریلیز ورژن کے راز سے وابستہ ہے۔ ریلیز آبجیکٹ ہمیشہ Kubernetes پر تعینات موجودہ ریلیز کی وضاحت کرتا ہے۔ ہر ریلیز ورژن سیکرٹ اس ریلیز کے صرف ایک ورژن کی وضاحت کرتا ہے۔ ایک اپ گریڈ، مثال کے طور پر، ایک نیا ریلیز ورژن سیکریٹ بنائے گا اور پھر اس نئے ورژن کی طرف اشارہ کرنے کے لیے ریلیز آبجیکٹ کو تبدیل کر دے گا۔ رول بیک کی صورت میں، آپ ریلیز کو پچھلی حالت میں واپس لانے کے لیے پچھلے ریلیز ورژن کے راز استعمال کر سکتے ہیں۔

ٹلر کو ترک کرنے کے بعد، ہیلم 3 ڈیٹا کو اسی نام کی جگہ پر جاری کرتا ہے جس میں ریلیز ہوتا ہے۔ یہ تبدیلی آپ کو ایک مختلف نام کی جگہ میں ایک ہی ریلیز نام کے ساتھ ایک چارٹ انسٹال کرنے کی اجازت دیتی ہے، اور ڈیٹا وغیرہ وغیرہ میں کلسٹر اپ ڈیٹس/ریبوٹس کے درمیان محفوظ کیا جاتا ہے۔ مثال کے طور پر، آپ ورڈپریس کو "foo" نام کی جگہ اور پھر "bar" نام کی جگہ میں انسٹال کر سکتے ہیں، اور دونوں ریلیز کو "wordpress" کا نام دیا جا سکتا ہے۔

چارٹ انحصار میں تبدیلیاں

چارٹس پیک (استعمال کرتے ہوئے helm package) ہیلم 2 کے ساتھ استعمال کے لیے ہیلم 3 کے ساتھ انسٹال کیا جا سکتا ہے، تاہم چارٹ ڈویلپمنٹ ورک فلو کو مکمل طور پر تبدیل کر دیا گیا ہے، لہذا ہیلم 3 کے ساتھ چارٹ کی ترقی کو جاری رکھنے کے لیے کچھ تبدیلیاں کی جانی چاہئیں۔ خاص طور پر، چارٹ پر انحصار کے انتظام کا نظام بدل گیا ہے۔

چارٹ کے انحصار کے انتظام کے نظام سے منتقل ہو گیا ہے requirements.yaml и requirements.lock پر Chart.yaml и Chart.lock. اس کا مطلب ہے کہ وہ چارٹ جو کمانڈ استعمال کرتے ہیں۔ helm dependencyہیلم 3 میں کام کرنے کے لیے کچھ سیٹ اپ درکار ہے۔

آئیے ایک مثال دیکھتے ہیں۔ آئیے ہیلم 2 میں چارٹ میں انحصار شامل کریں اور دیکھیں کہ ہیلم 3 پر جانے پر کیا تبدیلیاں آتی ہیں۔

ہیلم 2 میں requirements.yaml اس طرح دیکھا:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

ہیلم 3 میں، اسی انحصار کو آپ میں ظاہر کیا جائے گا۔ Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

چارٹس ابھی بھی ڈاؤن لوڈ اور ڈائرکٹری میں رکھے گئے ہیں۔ charts/، تو ذیلی چارٹس (سب چارٹس), کیٹلاگ میں پڑا charts/، تبدیلیوں کے بغیر کام جاری رکھے گا۔

لائبریری چارٹس کا تعارف

ہیلم 3 چارٹس کی ایک کلاس کو سپورٹ کرتا ہے جسے لائبریری چارٹس کہتے ہیں۔ (لائبریری چارٹ). یہ چارٹ دوسرے چارٹس کے ذریعہ استعمال کیا جاتا ہے، لیکن یہ خود سے کوئی ریلیز آرٹفیکٹ نہیں بناتا ہے۔ لائبریری چارٹ ٹیمپلیٹس صرف عناصر کا اعلان کر سکتے ہیں۔ define. دوسرے مواد کو محض نظر انداز کر دیا جاتا ہے۔ یہ صارفین کو کوڈ کے ٹکڑوں کو دوبارہ استعمال اور اشتراک کرنے کی اجازت دیتا ہے جو متعدد چارٹس میں استعمال کیے جاسکتے ہیں، اس طرح نقل سے بچتے ہیں اور اصول کی پابندی کرتے ہیں۔ خشک.

سیکشن میں لائبریری چارٹس کا اعلان کیا گیا ہے۔ dependencies فائل میں Chart.yaml. ان کو انسٹال کرنا اور ان کا نظم کرنا دوسرے چارٹس سے مختلف نہیں ہے۔

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

ہم استعمال کے معاملات کے بارے میں پرجوش ہیں کہ یہ جزو چارٹ ڈویلپرز کے لیے کھلے گا، نیز لائبریری کے چارٹس سے سامنے آنے والے بہترین طریقوں کے بارے میں۔

اس کے بعد کیا ہے؟

ہیلم 3.0.0-alpha.1 وہ بنیاد ہے جس پر ہم ہیلم کا ایک نیا ورژن بنانا شروع کرتے ہیں۔ مضمون میں میں نے ہیلم 3 کی کچھ دلچسپ خصوصیات بیان کی ہیں۔ ان میں سے بہت سے اب بھی ترقی کے ابتدائی مراحل میں ہیں اور یہ معمول کی بات ہے۔ الفا ریلیز کا نقطہ نظر کی جانچ کرنا، ابتدائی صارفین سے تاثرات اکٹھا کرنا، اور ہمارے مفروضوں کی تصدیق کرنا ہے۔

جیسے ہی الفا ورژن جاری ہوتا ہے۔ (یاد رکھیں کہ یہ ہے پہلے ہی ہوا ہے - تقریبا. ترجمہ)ہم کمیونٹی سے ہیلم 3 کے لیے پیچ قبول کرنا شروع کر دیں گے۔ آپ کو ایک مضبوط فاؤنڈیشن بنانے کی ضرورت ہے جو نئی فعالیت کو تیار کرنے اور اپنانے کی اجازت دے، اور صارفین ٹکٹیں کھول کر اور اصلاحات کر کے اس عمل میں شامل محسوس کر سکیں۔

میں نے ہیلم 3 میں آنے والی کچھ بڑی بہتریوں کو اجاگر کرنے کی کوشش کی ہے، لیکن یہ فہرست کسی بھی طرح مکمل نہیں ہے۔ ہیلم 3 کے مکمل روڈ میپ میں خصوصیات شامل ہیں جیسے کہ بہتر اپ ڈیٹ کی حکمت عملی، OCI رجسٹریوں کے ساتھ گہرا انضمام، اور چارٹ کی قدروں کو درست کرنے کے لیے JSON اسکیموں کا استعمال۔ ہم کوڈ بیس کو صاف کرنے اور اس کے کچھ حصوں کو اپ ڈیٹ کرنے کا بھی ارادہ رکھتے ہیں جو پچھلے تین سالوں سے نظر انداز کیے گئے ہیں۔

اگر آپ کو لگتا ہے کہ ہم نے کچھ کھو دیا ہے، تو ہم آپ کے خیالات سننا پسند کریں گے!

ہماری بحث میں شامل ہوں۔ سلیک چینلز:

#helm-users کمیونٹی کے ساتھ سوالات اور سادہ مواصلت کے لیے؛
#helm-dev پل کی درخواستوں، کوڈ اور کیڑے پر بحث کرنے کے لیے۔

آپ ہماری ہفتہ وار پبلک ڈیولپر کالز میں جمعرات کو 19:30 MSK پر بھی چیٹ کر سکتے ہیں۔ میٹنگیں ان مسائل پر بحث کرنے کے لیے وقف ہوتی ہیں جن پر کلیدی ڈویلپرز اور کمیونٹی کام کر رہے ہیں، نیز ہفتے کے لیے بحث کے موضوعات۔ میٹنگ میں کوئی بھی شامل ہو سکتا ہے اور حصہ لے سکتا ہے۔ سلیک چینل میں لنک دستیاب ہے۔ #helm-dev.

مترجم سے PS

ہمارے بلاگ پر بھی پڑھیں:

ماخذ: www.habr.com

ہیلم 3 کا تعارف