نوٽ. ترجمو: هن سال جي 16 مئي Kubernetes - Helm لاءِ پيڪيج مينيجر جي ترقي ۾ هڪ اهم سنگ ميل جي نشاندهي ڪري ٿي. هن ڏينهن تي، منصوبي جي مستقبل جي وڏي ورزن جو پهريون الفا رليز - 3.0 - پيش ڪيو ويو. ان جي رليز سان هيلم ۾ اهم ۽ ڊگهي انتظار جون تبديليون اينديون، جن لاءِ ڪبرنيٽس ڪميونٽي ۾ وڏيون اميدون آهن. اسان پاڻ انهن مان هڪ آهيون، ڇاڪاڻ ته اسان فعال طور تي هيلم استعمال ڪريون ٿا ايپليڪيشن ڊيپلائيمينٽ لاءِ: اسان ان کي CI/CD لاڳو ڪرڻ لاءِ پنهنجي ٽول ۾ ضم ڪيو آهي. ۽ وقت بوقت اسان اپ اسٽريم جي ترقي ۾ پنهنجو حصو ڏيندا رهيا آهيون. هي ترجمو سرڪاري هيلم بلاگ جي 7 نوٽس کي گڏ ڪري ٿو، جيڪي هيلم 3 جي پهرين الفا رليز لاءِ وقف ڪيا ويا آهن ۽ پروجيڪٽ جي تاريخ ۽ هيلم 3 جي اهم خصوصيتن بابت ڳالهائي رهيا آهن. انهن جو ليکڪ آهي Matt “bacongobbler” Fisher، Microsoft ملازم ۽ هيلم جي اهم سنڀاليندڙن مان هڪ آهي.
15 آڪٽوبر، 2015 تي، پروجيڪٽ هاڻي هيلم طور سڃاتو وڃي ٿو پيدا ٿيو. ان جي باني کان صرف هڪ سال بعد، هيلم ڪميونٽي ڪبرنيٽس ۾ شامل ٿي، جڏهن ته فعال طور تي هيلم 2 تي ڪم ڪري رهيو آهي. جون 2018 ۾، هيلم هڪ ترقي پذير (انڪيوبيٽنگ) منصوبي جي طور تي. فاسٽ اڳتي وڌو موجوده، ۽ نئين هيلم 3 جو پهريون الفا رليز ان جي رستي تي آهي. (هي رليز مئي جي وچ ۾ - تقريبن. ترجمو.).
هن ٽڪري ۾، مان ڳالهائيندس ته اهو سڀ ڪٿان شروع ٿيو، اسان ڪيئن پهتاسين جتي اسان اڄ آهيون، هيلم 3 جي پهرين الفا رليز ۾ موجود ڪجهه منفرد خصوصيتن کي متعارف ڪرايو، ۽ وضاحت ڪريو ته اسان ڪيئن اڳتي وڌڻ جو منصوبو ٺاهيو.
خلاصو:
- هيلم جي پيدائش جي تاريخ؛
- Tiller لاء هڪ ٽيلر الوداعي؛
- چارٽ مخزن؛
- ڇڏڻ جو انتظام؛
- چارٽ انحصار ۾ تبديليون؛
- لائبريري چارٽس؛
- اڳتي ڇا آهي؟
هيلم جي تاريخ
ڄمڻ
هيلم 1 هڪ اوپن سورس پروجيڪٽ جي طور تي شروع ڪيو ڊيس پاران ٺاهيل. اسان هڪ ننڍڙو شروعاتي هئاسين Microsoft بهار 2017 ۾. اسان جو ٻيو اوپن سورس پروجيڪٽ، جنهن جو نالو پڻ Deis آهي، هڪ اوزار هو deisctl، جيڪو استعمال ڪيو ويو (ٻين شين جي وچ ۾) ڊيس پليٽ فارم کي انسٽال ڪرڻ ۽ هلائڻ لاءِ . ان وقت، فليٽ پهرين ڪنٽينر آرڪيسٽريشن پليٽ فارمن مان هڪ هو.
2015 جي وچ ۾، اسان ڪورس تبديل ڪرڻ جو فيصلو ڪيو ۽ ڊيس (ان وقت ڊيس ورڪ فلو جو نالو تبديل ڪيو ويو) فليٽ کان ڪبرنيٽس ڏانهن منتقل ڪيو ويو. انهن مان هڪ پهريون ڀيرو ٻيهر ڊزائين ڪيو ويو تنصيب وارو اوزار. deisctl. اسان ان کي انسٽال ڪرڻ ۽ منظم ڪرڻ لاءِ استعمال ڪيو ڊيس ورڪ فلو فليٽ ڪلستر ۾.
هيلم 1 مشهور پيڪيج مينيجرز جي تصوير ۾ ٺاهيو ويو آهي جهڙوڪ هومبرو، اپٽ ۽ يوم. ان جو بنيادي مقصد ڪمن کي آسان ڪرڻ هو جيئن ته پيڪنگنگ ۽ ايپليڪيشنن کي انسٽال ڪرڻ ڪبرنيٽس تي. هيلم کي سرڪاري طور تي متعارف ڪرايو ويو 2015 ۾ سان فرانسسڪو ۾ KubeCon ڪانفرنس ۾.
هيلم سان اسان جي پهرين ڪوشش ڪم ڪيو، پر اهو ڪجهه سنگين حدن کان سواء نه هو. هن Kubernetes manifests جو هڪ سيٽ ورتو، جنريٽر سان ذائقو ڪيو جيئن تعارفي YAML بلاڪ (اڳوڻي ڳالهه)*، ۽ نتيجن کي ڪبرنيٽس ۾ لوڊ ڪيو.
* نوٽ. ترجمو: Helm جي پهرئين ورزن کان، YAML نحو چونڊيو ويو ڪبرنيٽس وسيلن کي بيان ڪرڻ لاءِ، ۽ جنجا ٽيمپليٽس ۽ پٿون اسڪرپٽ کي سپورٽ ڪيو ويو جڏھن ترتيب لکڻ ۾. اسان هن بابت وڌيڪ لکيو آهي ۽ هيلم جي پهرين نسخي جي جوڙجڪ بابت عام طور تي باب ”هيلم جي مختصر تاريخ“ ۾. .
مثال طور، YAML فائل ۾ فيلڊ کي تبديل ڪرڻ لاء، توھان کي ھيٺ ڏنل ٺاھڻ کي منشور ۾ شامل ڪرڻو پوندو:
#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yamlاهو عظيم آهي ته ٽيمپليٽ انجڻ اڄ موجود آهي، ڇا اهو ناهي؟
ڪيترن ئي سببن جي ڪري، هن شروعاتي ڪبرنيٽس انسٽالر کي گهربل فائلن جي سخت ڪوڊ ٿيل لسٽ جي ضرورت آهي ۽ صرف واقعن جي هڪ ننڍڙي، مقرر ڪيل ترتيب تي عمل ڪيو. اهو استعمال ڪرڻ ڏاڍو ڏکيو هو ته ڊيس ورڪ فلو آر اينڊ ڊي ٽيم کي سخت وقت هو جڏهن انهن پنهنجي پروڊڪٽ کي هن پليٽ فارم تي منتقل ڪرڻ جي ڪوشش ڪئي - جڏهن ته، خيال جو ٻج اڳ ۾ ئي پوکي چڪو هو. اسان جي پهرين ڪوشش هڪ بهترين سکيا جو موقعو هو: اسان محسوس ڪيو ته اسان واقعي پرجوش آهيون عملي اوزار ٺاهڻ جي باري ۾ جيڪي اسان جي استعمال ڪندڙن لاءِ روزمره جي مسئلن کي حل ڪن ٿا.
ماضي جي غلطين جي تجربي جي بنياد تي، اسان هيلم 2 کي ترقي ڪرڻ شروع ڪيو.
هيلم ٺاهڻ 2
2015 جي آخر ۾، گوگل ٽيم اسان سان رابطو ڪيو. اهي Kubernetes لاءِ ساڳي اوزار تي ڪم ڪري رهيا هئا. ڪبرنيٽس لاءِ ڊيپلائيمينٽ مئنيجر هڪ موجوده اوزار جو هڪ بندرگاهه هو جيڪو گوگل ڪلائوڊ پليٽ فارم لاءِ استعمال ڪيو ويو هو. ”ڇا اسان چاهيون ٿا،“ هنن پڇيو، ”ڪجهه ڏينهن هڪجهڙائي ۽ اختلافن تي بحث ڪندي گذاريون؟
جنوري 2016 ۾، هيلم ۽ ڊيپلائيمينٽ مئنيجر ٽيمون سيٽل ۾ خيالن جي تبادلي لاء ملاقات ڪئي. ڳالهين هڪ امڪاني منصوبي سان ختم ٿي وئي: هيلم 2 ٺاهڻ لاءِ ٻنهي منصوبن کي گڏ ڪرڻ لاءِ. ڊيس ۽ گوگل سان گڏ، دوست (هاڻي Bitnami جو حصو - تقريبن ترجمو.)، ۽ اسان هيلم 2 تي ڪم ڪرڻ شروع ڪيو.
اسان هيلم جي استعمال کي آسان رکڻ چاهيون ٿا، پر هيٺيون شامل ڪريو:
- حسب ضرورت لاء چارٽ ٽيمپليٽ؛
- ٽيمن لاءِ اندروني ڪلستر انتظام؛
- عالمي-طبقاتي چارٽ مخزن؛
- دستخط جي اختيار سان مستحڪم پيڪيج فارميٽ؛
- ورجن جي وچ ۾ پسمانده مطابقت کي برقرار رکڻ ۽ سيمينٽڪ ورزننگ لاءِ مضبوط عزم.
انهن مقصدن کي حاصل ڪرڻ لاء، هيلم ايڪو سسٽم ۾ هڪ ٻيو عنصر شامل ڪيو ويو آهي. هي انٽرا-ڪلسٽر جزو کي ٽيلر سڏيو ويندو هو ۽ هيلم چارٽس کي نصب ڪرڻ ۽ انهن کي منظم ڪرڻ جو ذميوار هو.
2 ۾ هيلم 2016 جي ڇڏڻ کان وٺي، ڪبرنيٽس ڪيترن ئي وڏن جدت کي شامل ڪيو آهي. شامل ڪيو ويو ڪردار جي بنياد تي رسائي ڪنٽرول ()، جنهن آخرڪار ايٽريبيوٽ بيسڊ رسائي ڪنٽرول (ABAC) کي تبديل ڪيو. نوان وسيلن جا قسم متعارف ڪرايا ويا (تعميرات اڃا تائين بيٽا ۾ هئي). ڪسٽم ريسورس وصفون (اصل ۾ ٽئين پارٽي وسيلا يا ٽي پي آرز) ايجاد ڪيا ويا. ۽ سڀ کان اهم، بهترين عملن جو هڪ سيٽ سامهون آيو آهي.
انهن سڀني تبديلين جي وچ ۾، هيلم ڪبرنيٽس صارفين جي وفاداري سان خدمت ڪرڻ جاري رکي. ٽن سالن کان پوءِ ۽ ڪيترن ئي نون اضافون کان پوءِ، اهو واضح ٿي ويو ته اهو وقت آهي ڪوڊ بيس ۾ اهم تبديليون ڪرڻ جو ته جيئن هيلم هڪ ترقي پذير ماحولياتي نظام جي وڌندڙ ضرورتن کي پورو ڪرڻ جاري رکي.
ٽيلر کي هڪ نرم الوداعي
Helm 2 جي ترقيءَ دوران، اسان Tiller کي متعارف ڪرايو گوگل جي ڊيپلائيمينٽ مئنيجر سان اسان جي انضمام جي حصي طور. ٽيلر هڪ عام ڪلستر جي اندر ڪم ڪندڙ ٽيمن لاءِ اهم ڪردار ادا ڪيو: هن مختلف ماهرن کي اجازت ڏني ته انفراسٽرڪچر کي هلائيندڙ رليز جي ساڳئي سيٽ سان لهه وچڙ ۾ اچي.
جيئن ته ڪردار تي ٻڌل رسائي ڪنٽرول (RBAC) کي ڊفالٽ طور Kubernetes 1.6 ۾ فعال ڪيو ويو، پيداوار ۾ ٽيلر سان ڪم ڪرڻ وڌيڪ ڏکيو ٿي ويو. ممڪن حفاظتي پاليسين جي وڏي تعداد جي ڪري، اسان جي پوزيشن ڊفالٽ طرفان اجازت ڏيڻ واري ترتيب پيش ڪرڻ جي ڪئي وئي آهي. هي اجازت ڏني وئي نوان نوان هيلم ۽ ڪبرنيٽس سان تجربا ڪرڻ کان سواءِ پهرين حفاظتي سيٽنگن ۾ ٻڏڻ جي. بدقسمتي سان، هي اجازت جي ترتيب صارف کي اجازت ڏئي سگهي ٿي تمام گهڻي حد تائين اجازتون جيڪي انهن جي ضرورت نه هئي. DevOps ۽ SRE انجنيئرن کي اضافي آپريشنل مرحلا سکڻا پوندا هئا جڏهن ٽيلر کي ملٽي ٽيننٽ ڪلسٽر ۾ انسٽال ڪيو ويندو هو.
اهو سکڻ سان ته ڪميونٽي خاص حالتن ۾ هيلم کي ڪيئن استعمال ڪيو، اسان اهو محسوس ڪيو ته ٽيلر جي رليز مئنيجمينٽ سسٽم کي رياستن کي برقرار رکڻ لاءِ انٽرا-ڪلسٽر جزو تي ڀروسو ڪرڻ جي ضرورت نه هئي يا جاري ڪيل معلومات لاءِ مرڪزي مرڪز طور ڪم ڪيو وڃي. ان جي بدران، اسان صرف Kubernetes API سرور کان معلومات حاصل ڪري سگهون ٿا، ڪلائنٽ جي پاسي تي هڪ چارٽ ٺاهي، ۽ Kubernetes ۾ انسٽاليشن جو رڪارڊ محفوظ ڪري سگهون ٿا.
ٽلر جو بنيادي ڪم ٽلر کان سواءِ پورو ٿي سگھي ٿو، تنھنڪري ھيلم 3 جي حوالي سان اسان جو پھريون فيصلو ٽلر کي مڪمل طور تي ڇڏڻ ھو.
ٽيلر جي وڃڻ سان، هيلم جي سيڪيورٽي ماڊل کي بنيادي طور تي آسان ڪيو ويو آهي. Helm 3 ھاڻي سپورٽ ڪري ٿو سڀني جديد سيڪيورٽي، سڃاڻپ، ۽ اختيار ڏيڻ جي طريقن جي موجوده ڪبرنيٽس جي. هيلم اجازتون استعمال ڪندي طئي ٿيل آهن . ڪلسٽر ايڊمنسٽريٽر استعمال ڪندڙ جي حقن کي ڪنهن به سطح جي گرينولرٽي تائين محدود ڪري سگهن ٿا. ريليز اڃا تائين ڪلستر ۾ محفوظ ٿيل آهن، ۽ هيلم جي باقي ڪارڪردگي برقرار رهي ٿي.
چارٽ مخزن
هڪ اعلي سطح تي، هڪ چارٽ مخزن هڪ جڳهه آهي جتي چارٽ محفوظ ۽ حصيداري ڪري سگهجي ٿو. هيلم ڪلائنٽ پيڪيجز ۽ چارٽ موڪلي ٿو مخزن ڏانهن. سادي لفظ ۾، هڪ چارٽس مخزن هڪ ابتدائي HTTP سرور آهي جيڪو هڪ index.yaml فائل ۽ ڪجهه پيڪيج ٿيل چارٽس سان.
جڏهن ته چارٽس ريپوزٽري API جا ڪجهه فائدا آهن تمام گهڻيون بنيادي اسٽوريج گهرجن کي پورا ڪرڻ، اتي پڻ ڪجھ نقصان آهن:
- چارٽ جا ذخيرا پيداواري ماحول ۾ گھربل اڪثر حفاظتي عملن سان مطابقت نٿا رکن. پيداوار جي منظرنامي ۾ تصديق ۽ اختيار ڏيڻ لاءِ معياري API هجڻ انتهائي اهم آهي.
- هيلم جا چارٽ ثابت ڪرڻ جا اوزار، جيڪي چارٽ جي ڇپائيءَ جي عمل جو هڪ اختياري حصو آهن، دستخط ڪرڻ، تصديق ڪرڻ ۽ ان جي صداقت جي تصديق ڪرڻ لاءِ استعمال ٿيندا آهن.
- گھڻن استعمال ڪندڙن جي منظرنامي ۾، ساڳيو چارٽ ٻئي صارف طرفان اپلوڊ ڪري سگھجي ٿو، ساڳئي مواد کي ذخيرو ڪرڻ لاءِ گھربل جاءِ جي مقدار کي ٻيڻو ڪري. هن مسئلي کي حل ڪرڻ لاءِ سمارٽ ذخيرا ٺاهيا ويا آهن، پر اهي رسمي وضاحتن جو حصو نه آهن.
- هڪ واحد انڊيڪس فائل استعمال ڪرڻ لاءِ ڳولها، ذخيرو ڪرڻ، ميٽاڊيٽا ۽ چارٽ حاصل ڪرڻ ان کي ڏکيو بڻائي ڇڏيو آهي محفوظ ملٽي يوزر تي عمل درآمد ڪرڻ.
پروجيڪٽ (ڊاڪر رجسٽري v2 جي نالي سان پڻ سڃاتو وڃي ٿو) ڊاڪر رجسٽري جو جانشين آهي ۽ بنيادي طور تي ڪم ڪري ٿو اوزار جي هڪ سيٽ جي طور تي پيڪنگنگ، شپنگ، اسٽوريج ۽ پهچائڻ لاءِ ڊڪر تصويرون. ڪيتريون ئي وڏيون بادل خدمتون پيش ڪن ٿيون تقسيم تي ٻڌل پراڊڪٽس. هن وڌايل توجه جي مهرباني، ڊسٽريبيوشن پروجيڪٽ سالن جي بهتري، حفاظتي بهترين عملن، ۽ فيلڊ ٽيسٽنگ مان فائدو ورتو آهي جنهن ان کي اوپن سورس جي دنيا جي سڀ کان ڪامياب اڻڄاتل هيرو بڻائي ڇڏيو آهي.
پر ڇا توهان کي خبر آهي ته ڊسٽريبيوشن پروجيڪٽ ڪنهن به قسم جي مواد کي ورهائڻ لاءِ ٺاهيو ويو هو، نه صرف ڪنٽينر جون تصويرون؟
ڪوششن جي مهرباني (يا OCI)، هيلم چارٽ رکي سگھجن ٿا ڪنهن به تقسيم مثال تي. في الحال، اهو عمل تجرباتي آهي. مڪمل هيلم 3 لاءِ لاگ ان سپورٽ ۽ ٻيون خاصيتون گھربل ڪم جاري آھن، پر اسان انھن دريافتن مان سکڻ لاءِ پرجوش آھيون جيڪي OCI ۽ تقسيم ٽيمن سالن کان ڪيون آھن. ۽ انھن جي مشوري ۽ ھدايت جي ذريعي، اسان ڄاڻون ٿا ته اھو ڇا آھي جيڪو وڏي پيماني تي دستياب خدمت کي هلائڻ جھڙو آھي.
هيلم چارٽ جي مخزنن ۾ ايندڙ ڪجهه تبديلين جو وڌيڪ تفصيلي بيان موجود آهي .
ڇڏڻ جو انتظام
هيلم 3 ۾، ايپليڪيشن اسٽيٽ ڪلستر جي اندر شين جي هڪ جوڙي ذريعي ٽريڪ ڪئي وئي آهي:
- ڇڏڻ جو اعتراض - هڪ ايپليڪيشن مثال جي نمائندگي ڪري ٿو؛
- جاري ٿيل نسخو راز - وقت جي مخصوص نقطي تي ايپليڪيشن جي گهربل حالت جي نمائندگي ڪري ٿو (مثال طور، نئين ورزن جي ڇڏڻ).
چيلنج helm install هڪ رليز اعتراض ٺاهي ٿو ۽ ورزن راز جاري ڪري ٿو. سڏ helm upgrade هڪ رليز اعتراض جي ضرورت آهي (جيڪو اهو تبديل ڪري سگهي ٿو) ۽ هڪ نئون رليز ورزن راز ٺاهي ٿو جنهن ۾ نوان قدر ۽ هڪ تيار ڪيل منشور شامل آهي.
ريليز اعتراض تي مشتمل آهي رليز بابت معلومات، جتي رليز نالي چارٽ ۽ قدر جي مخصوص تنصيب آهي. هي اعتراض بيان ڪري ٿو مٿين سطح جي ميٽا ڊيٽا کي ڇڏڻ بابت. رليز ٿيل اعتراض ايپليڪيشن جي پوري زندگي جي چڪر دوران جاري رهي ٿو ۽ سڀني رليز ورزن جي رازن جي مالڪ جي طور تي ڪم ڪري ٿو، انهي سان گڏ اهي سڀئي شيون جيڪي سڌو سنئون هيلم چارٽ ذريعي ٺاهيا ويا آهن.
رليز ورزن رازن کي ورجائي ٿو هڪ رليز جي نظرثانين جي سيريز سان (تنصيب، تازه ڪاري، رول بيڪ، حذف ڪرڻ).
هيلم 2 ۾، ترميمون انتهائي لاڳيتو هيون. سڏ helm install ٺاهي وئي v1، بعد ۾ تازه ڪاري (اپ گريڊ) - v2، وغيره. رليز ۽ رليز ورجن راز کي هڪ واحد شئي ۾ ختم ڪيو ويو آهي جنهن کي نظر ثاني طور سڃاتو وڃي ٿو. نظرثانيون ساڳئي نالي جي جاءِ ۾ محفوظ ڪيون ويون جيئن ٽلر، جنهن جو مطلب هو ته هر رليز نالي جي جاءِ جي لحاظ کان ”عالمي“ هئي. نتيجي طور، نالو جو صرف ھڪڙو مثال استعمال ٿي سگھي ٿو.
هيلم 3 ۾، هر رليز هڪ يا وڌيڪ رليز ورزن رازن سان لاڳاپيل آهي. رليز اعتراض هميشه بيان ڪري ٿو موجوده رليز کي مقرر ڪيو ويو ڪبرنيٽس ڏانهن. هر رليز ورزن راز بيان ڪري ٿو صرف هڪ نسخو انهي رليز جو. هڪ اپ گريڊ، مثال طور، هڪ نئون رليز ورزن راز ٺاهيندو ۽ پوءِ رليز اعتراض کي تبديل ڪندو انهي نئين ورزن ڏانهن اشارو ڪرڻ لاءِ. رول بيڪ جي صورت ۾، توهان استعمال ڪري سگهو ٿا پوئين رليز ورزن رازن کي واپس رول ڪرڻ لاءِ رليز کي پوئين حالت ۾.
ٽيلر ڇڏڻ کان پوءِ، هيلم 3 اسٽورز ڊيٽا کي ساڳي نالي واري جاءِ ۾ جاري ڪري ٿو جيئن رليز. هي تبديلي توهان کي هڪ چارٽ انسٽال ڪرڻ جي اجازت ڏئي ٿي هڪ ئي رليز نالي سان مختلف نالي واري جاءِ ۾، ۽ ڊيٽا محفوظ ڪئي ويندي آهي ڪلسٽر اپڊيٽس/ريبوٽس وغيره جي وچ ۾. مثال طور، توهان ورڈپریس انسٽال ڪري سگهو ٿا "foo" نالي جي جاءِ ۽ پوءِ "bar" نالي جي جاءِ ۾، ۽ ٻنهي رليز کي "wordpress" جو نالو ڏئي سگهجي ٿو.
چارٽ انحصار ۾ تبديليون
چارٽ ڀريل (استعمال ڪندي helm package) Helm 2 سان استعمال ڪرڻ لاءِ Helm 3 سان انسٽال ڪري سگھجي ٿو، جڏهن ته چارٽ ڊولپمينٽ ورڪ فلو کي مڪمل طور تي تبديل ڪيو ويو آھي، تنھنڪري ھيلم 3 سان چارٽ ڊولپمينٽ کي جاري رکڻ لاءِ ڪجھ تبديليون ڪرڻ گھرجن. خاص طور تي، چارٽ ڊولپمينٽ مينيجمينٽ سسٽم تبديل ٿي ويو آھي.
چارٽ جي انحصار جي انتظام واري نظام مان منتقل ٿي چڪو آهي requirements.yaml и requirements.lock تي Chart.yaml и Chart.lock. هن جو مطلب اهو آهي ته چارٽ جيڪي ڪمانڊ استعمال ڪيا آهن helm dependency, Helm 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/, so subcharts (ذيلي چارٽس), فهرست ۾ ڪوڙ charts/, تبديلين کان سواء ڪم جاري رهندو.
لائبريري چارٽس متعارف ڪرايو
هيلم 3 چارٽس جي هڪ طبقي کي سپورٽ ڪري ٿو جنهن کي لائبريري چارٽس سڏيو ويندو آهي (لائبريري چارٽ). هي چارٽ ٻين چارٽس پاران استعمال ڪيو ويو آهي، پر پنهنجو پاڻ تي ڪا به ريليز آرٽيڪل ٺاهي نه ٿو. لائبريري چارٽ ٽيمپليٽ صرف عناصر جو اعلان ڪري سگھن ٿا define. ٻيو مواد صرف نظر انداز ڪيو ويو آهي. هي صارفين کي ٻيهر استعمال ڪرڻ جي اجازت ڏئي ٿو ۽ ڪوڊ اسپيٽس کي حصيداري ڪري ٿو جيڪي ڪيترن ئي چارٽس ۾ استعمال ڪري سگھجن ٿيون، انهي سان گڏ نقل کان بچڻ ۽ اصول تي عمل ڪرڻ. .
لائبريري چارٽس سيڪشن ۾ بيان ڪيا ويا آهن dependencies فائل ۾ Chart.yaml. انهن کي انسٽال ڪرڻ ۽ منظم ڪرڻ ٻين چارٽس کان مختلف ناهي.
dependencies:
- name: mylib
version: 1.x.x
repository: quay.ioاسان استعمال جي ڪيسن جي باري ۾ پرجوش آهيون ته هي جزو چارٽ ڊولپرز لاءِ کليل هوندو، انهي سان گڏ بهترين طريقا جيڪي لائبريري چارٽس مان نڪرندا هوندا.
ايندڙ ڇا آهي؟
Helm 3.0.0-alpha.1 اهو بنياد آهي جنهن تي اسان هيلم جو نئون ورزن ٺاهڻ شروع ڪريون ٿا. مضمون ۾ مون هيلم 3 جون ڪجهه دلچسپ خصوصيتون بيان ڪيون آهن. انهن مان گهڻا اڃا ترقي جي شروعاتي مرحلن ۾ آهن ۽ اهو عام آهي؛ الفا رليز جو نقطو خيال کي جانچڻ، شروعاتي استعمال ڪندڙن کان موٽ گڏ ڪرڻ، ۽ اسان جي مفروضن جي تصديق ڪرڻ آهي.
جيترو جلد الفا ورجن جاري ڪيو ويو آهي (ياد رکو ته هي آهي - لڳ ڀڳ ترجمو.)، اسان ڪميونٽي کان هيلم 3 لاءِ پيچ قبول ڪرڻ شروع ڪنداسين. توهان کي هڪ مضبوط بنياد ٺاهڻ جي ضرورت آهي جيڪا نئين ڪارڪردگي کي ترقي ۽ اپنائڻ جي اجازت ڏئي ٿي، ۽ صارفين کي ٽڪيٽن کي کولڻ ۽ درست ڪرڻ سان عمل ۾ شامل ٿيڻ جو احساس ڏي.
مون هيلم 3 ۾ ايندڙ ڪجهه اهم سڌارن کي اجاگر ڪرڻ جي ڪوشش ڪئي آهي، پر هي فهرست ڪنهن به طرح مڪمل ناهي. هيلم 3 لاءِ مڪمل روڊ ميپ ۾ خاصيتون شامل آهن جيئن ته بهتر اپ ڊيٽ حڪمت عمليون، او سي آءِ رجسٽرين سان وڌيڪ گہرے انضمام، ۽ چارٽ جي قدرن کي درست ڪرڻ لاءِ JSON اسڪيمن جو استعمال. اسان ڪوڊ بيس کي صاف ڪرڻ ۽ ان جي حصن کي اپڊيٽ ڪرڻ جو منصوبو پڻ ڪيو آهي جيڪي گذريل ٽن سالن کان نظرانداز ڪيا ويا آهن.
جيڪڏهن توهان محسوس ڪيو آهي ته اسان ڪجهه وڃايو آهي، اسان توهان جي خيالن کي ٻڌڻ چاهيندا!
اسان جي بحث ۾ شامل ٿيو :
-
#helm-usersڪميونٽي سان سوالن ۽ سادي رابطي لاء؛ -
#helm-devڇڪڻ جي درخواستن، ڪوڊ ۽ بگ تي بحث ڪرڻ لاءِ.
توھان پڻ چيٽ ڪري سگھو ٿا اسان جي ھفتيوار پبلڪ ڊولپر ڪالن ۾ خميس تي 19:30 MSK تي. گڏجاڻيون انهن مسئلن تي بحث ڪرڻ لاءِ وقف آهن جن تي اهم ڊولپر ۽ ڪميونٽي ڪم ڪري رهيا آهن، انهي سان گڏ هفتي لاءِ بحث جا موضوع. ڪو به شريڪ ٿي سگهي ٿو ۽ گڏجاڻي ۾ حصو وٺي سگھي ٿو. لنڪ موجود آهي Slack چينل ۾ #helm-dev.
پي ايس مترجم کان
اسان جي بلاگ تي پڻ پڙهو:
- «"؛
- «"؛
- «"؛
- «"؛
- «».
جو ذريعو: www.habr.com