🥇3-طريقه ضم ڪرڻ لاءِ ويرف: ڪبرنيٽس کي هيلم سان ڊيپلائيمينٽ “آن اسٽيرائڊز”

جيڪو اسان (۽ نه رڳو اسان) ڊگهي عرصي کان انتظار ڪري رهيا هئاسين: werf, اسان جي اوپن سورس يوٽيليٽي ايپليڪيشنون ٺاهڻ ۽ انهن کي ڪبرنيٽس تائين پهچائڻ لاءِ، هاڻي 3-واٽ مرج پيچس استعمال ڪندي تبديلين کي لاڳو ڪرڻ جي حمايت ڪري ٿي! ان کان علاوه، اهو ممڪن آهي ته موجوده K8s وسيلن کي هيلم رليز ۾ اپنائڻ کان سواء انهن وسيلن کي ٻيهر تعمير ڪرڻ.

جيڪڏهن اهو تمام ننڍو آهي، پوء اسان رکون ٿا WERF_THREE_WAY_MERGE=enabled - اسان کي تعیناتي ملي ٿي "جيئن اندر kubectl apply"، موجوده هيلم 2 تنصيب سان مطابقت ۽ اڃا به ٿورو وڌيڪ.

پر اچو ته ان نظريي سان شروع ڪريون: 3-طريقه ضم ٿيل پيچ اصل ۾ ڇا آهن، ماڻهو انهن کي پيدا ڪرڻ جي طريقي سان ڪيئن آيا، ۽ اهي ڪبرنيٽس تي ٻڌل انفراسٽرڪچر سان CI/CD پروسيس ۾ اهم ڇو آهن؟ ۽ ان کان پوء، اچو ته ڏسو ته ڇا 3-طريقه ضم آهي werf ۾، ڪهڙا طريقا ڊفالٽ طور استعمال ڪيا ويا آهن ۽ ان کي ڪيئن منظم ڪجي.

هڪ 3-طريقه ضم پيچ ڇا آهي؟

تنهن ڪري، اچو ته شروع ڪريون ڪم سان گڏ بيان ڪيل وسيلن کي ختم ڪرڻ جي YAML ۾ بيان ڪيل ڪبرنيٽس ۾.

وسيلن سان ڪم ڪرڻ لاء، Kubernetes API پيش ڪري ٿو ھيٺيون بنيادي عمل: ٺاھيو، پيچ، تبديل ڪريو ۽ حذف ڪريو. اهو فرض ڪيو ويو آهي ته انهن جي مدد سان اهو ضروري آهي ته ڪلستر تائين وسيلن جي هڪ آسان مسلسل رول آئوٽ ٺاهي. ڪيئن؟

kubectl ضروري حڪم

Kubernetes ۾ شيون منظم ڪرڻ جو پهريون طريقو آهي kubectl لازمي حڪمن کي استعمال ڪرڻ لاءِ انهن شين کي ٺاهڻ، تبديل ڪرڻ ۽ حذف ڪرڻ. آسان لفظ:

ٽيم kubectl run توهان هلائي سگهو ٿا تعیناتي يا نوڪري:
```
kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE
```
ٽيم kubectl scale - نقلن جو تعداد تبديل ڪريو:
```
kubectl scale --replicas=3 deployment/mysql
```
۽ وغيره تي.

اهو طريقو پهرين نظر ۾ آسان لڳي سگهي ٿو. تنهن هوندي به، اتي مسئلا آهن:

اهو ڏکيو آهي پاڻمرادو.
ڪيئن عڪاسي تشڪيل گٽ ۾؟ ڪلستر ۾ ٿيندڙ تبديلين جو جائزو ڪيئن وٺجي؟
ڪيئن مهيا ڪرڻ پيداواري صلاحيت ٻيهر شروع ڪرڻ تي ٺاھ جوڙ؟
...

اهو واضح آهي ته اهو طريقو ايپليڪيشن ۽ انفراسٽرڪچر کي ڪوڊ جي طور تي محفوظ ڪرڻ سان مناسب ناهي (IaC؛ يا اڃا به GitOps وڌيڪ جديد اختيار جي طور تي، ڪبرنيٽس ايڪو سسٽم ۾ مقبوليت حاصل ڪرڻ). تنهن ڪري، انهن حڪمن کي ڪبيڪٽل ۾ وڌيڪ ترقي حاصل نه ڪيو.

ٺاهيو، حاصل ڪريو، تبديل ڪريو ۽ ختم ڪريو آپريشن

پرائمري سان تخليق اهو سادو آهي: آپريشن ڏانهن منشور موڪليو create kube api ۽ وسيلا ٺاهي وئي آهي. ظاهر جي YAML نمائندگي Git ۾ ذخيرو ٿي سگھي ٿو ۽ حڪم استعمال ڪندي ٺاھيو ويو kubectl create -f manifest.yaml.

С ختم ڪرڻ پڻ سادو: ساڳيو متبادل manifest.yaml گٽ کان ٽيم تائين kubectl delete -f manifest.yaml.

آپريشن replace توهان کي اجازت ڏئي ٿو ته وسيلن جي ترتيب کي مڪمل طور تي هڪ نئين سان تبديل ڪرڻ جي، بغير وسيلن کي ٻيهر ٺاهڻ جي. هن جو مطلب اهو آهي ته هڪ وسيلن ۾ تبديلي ڪرڻ کان اڳ، اهو منطقي آهي ته موجوده ورزن کي آپريشن سان سوال ڪيو وڃي get، ان کي تبديل ڪريو ۽ ان کي آپريشن سان تازه ڪاري ڪريو replace. kube apiserver ۾ ٺهيل آهي پراميد تالا ۽، جيڪڏهن سرجري کان پوء get اعتراض تبديل ٿي چڪو آهي، پوء آپريشن replace اهو ڪم نه ڪندو.

Git ۾ ٺاھ جوڙ کي ذخيرو ڪرڻ ۽ ان کي تبديل ڪندي تازه ڪاري ڪرڻ لاء، توھان کي عمل ڪرڻو پوندو get، گيٽ مان ترتيب کي ضم ڪريو جيڪو اسان حاصل ڪيو، ۽ عمل ڪريو replace. ڊفالٽ طور، kubectl صرف توهان کي حڪم استعمال ڪرڻ جي اجازت ڏئي ٿو kubectl replace -f manifest.yamlڪٿي manifest.yaml - اڳ ۾ ئي مڪمل طور تي تيار ڪيل (اسان جي صورت ۾، ضم ٿيل) پڌرو جيڪو نصب ٿيڻ جي ضرورت آهي. اهو ظاهر ٿئي ٿو ته صارف کي ضمير جي منشور تي عمل ڪرڻ جي ضرورت آهي، ۽ اهو هڪ معمولي معاملو ناهي ...

اهو پڻ قابل ذڪر آهي ته جيتوڻيڪ manifest.yaml ۽ Git ۾ ذخيرو ٿيل آهي، اسان اڳ ۾ نه ٿا ڄاڻون ته اهو هڪ اعتراض ٺاهڻ يا ان کي اپڊيٽ ڪرڻ ضروري آهي - اهو صارف سافٽ ويئر طرفان ڪيو وڃي.

Total: ڇا اسان هڪ مسلسل رول آئوٽ ٺاهي سگهون ٿا صرف استعمال ڪندي ٺاهيو، تبديل ڪريو ۽ حذف ڪريو، انهي کي يقيني بڻائڻ ته انفراسٽرڪچر جي جوڙجڪ Git ۾ ڪوڊ ۽ آسان CI/CD سان گڏ محفوظ ٿيل آهي؟

اصول ۾، اسان ڪري سگھون ٿا... هن لاءِ توهان کي ملائڻ واري عمل کي لاڳو ڪرڻ جي ضرورت پوندي منشور ۽ ڪجهه قسم جو پابند آهي ته:

ڪلستر ۾ اعتراض جي موجودگي کي چيڪ ڪري ٿو،
شروعاتي وسيلن جي تخليق کي انجام ڏئي ٿو،
تازه ڪاري يا ختم ڪري ٿو.

جڏهن تازه ڪاري ڪريو، مهرباني ڪري نوٽ ڪريو ته ذريعو تبديل ٿي سگھي ٿو آخري کان وٺي get ۽ خود بخود آپٽيمسٽڪ لاڪنگ جي صورت کي سنڀاليو - بار بار اپڊيٽ ڪرڻ جي ڪوشش ڪريو.

تنهن هوندي، ڇو ته ڦيٿي کي ٻيهر ٺاهيو جڏهن kube-apiserver وسيلن کي اپڊيٽ ڪرڻ لاء هڪ ٻيو طريقو پيش ڪري ٿو: آپريشن patch، جيڪو صارف کي ڪجھ بيان ڪيل مسئلن کان رليف ڏئي ٿو؟

پيوند

هاڻي اسان پيچ ڏانهن وڃو.

پيچس Kubernetes ۾ موجود شيون ۾ تبديليون لاڳو ڪرڻ جو بنيادي طريقو آھي. آپريشن patch اهو هن طرح ڪم ڪري ٿو:

kube-apiserver استعمال ڪندڙ کي JSON فارم ۾ پيچ موڪلڻ ۽ اعتراض جي وضاحت ڪرڻ جي ضرورت آهي،
۽ apiserver پاڻ کي اعتراض جي موجوده حالت سان ڊيل ڪندو ۽ ان کي گهربل شڪل ۾ آڻيندو.

هن معاملي ۾ Optimistic لاڪنگ جي ضرورت نه آهي. هي آپريشن بدلائڻ کان وڌيڪ بياني آهي، جيتوڻيڪ پهرين ۾ اهو شايد ٻئي طريقي سان لڳي سگهي ٿو.

هن طريقي سان:

هڪ آپريشن استعمال ڪندي create اسان گٽ مان ظاهر ڪيل مطابق هڪ اعتراض ٺاهي،
مدد سان delete - حذف ڪريو جيڪڏهن اعتراض وڌيڪ گهربل ناهي،
مدد سان patch - اسان اعتراض کي تبديل ڪريون ٿا، ان کي Git ۾ بيان ڪيل فارم ۾ آڻيندي.

بهرحال، هن کي ڪرڻ لاء، توهان کي ٺاهڻ جي ضرورت آهي صحيح پيچ!

هيلم 2 ۾ پيچ ڪيئن ڪم ڪن ٿا: 2-طريقه-ضم

جڏهن توهان پهريون ڀيرو هڪ رليز نصب ڪيو، هيلم آپريشن کي انجام ڏئي ٿو create چارٽ وسيلن لاء.

جڏهن هر وسيلن لاء هيلم رليز کي اپڊيٽ ڪيو وڃي:

پوئين چارٽ ۽ موجوده چارٽ ورزن جي وسيلن واري ورزن جي وچ ۾ پيچ کي سمجهي ٿو،
هن پيچ کي لاڳو ڪري ٿو.

اسان هن پيچ کي سڏينداسين 2-واٽ ملائي پيچ، ڇاڪاڻ ته ان جي تخليق ۾ 2 منشور شامل آهن:

پوئين رليز مان وسيلا ظاهر،
موجوده وسيلن مان ظاهر ڪيل وسيلا.

جڏهن آپريشن کي هٽائڻ delete kube apiserver ۾ وسيلن لاء سڏيو ويندو آهي جيڪي اڳئين رليز ۾ اعلان ڪيا ويا، پر موجوده ۾ اعلان نه ڪيا ويا.

2 رستو ضم ڪرڻ واري پيچ جي طريقي سان هڪ مسئلو آهي: اهو وڃي ٿو ڪلسٽر ۾ وسيلن جي حقيقي حالت سان مطابقت کان ٻاهر ۽ Git ۾ ظاهر.

هڪ مثال سان مسئلو جي وضاحت

Git ۾، هڪ چارٽ هڪ پڌرو ذخيرو ڪري ٿو جنهن ۾ فيلڊ image مقرري جو معاملو ubuntu:18.04.
استعمال ڪندڙ جي ذريعي kubectl edit هن فيلڊ جي قيمت کي تبديل ڪيو ubuntu:19.04.
جڏهن هيلم چارٽ کي ٻيهر ترتيب ڏيو پيچ پيدا نٿو ڪري، ڇاڪاڻ ته ميدان image رليز جي پوئين ورزن ۾ ۽ موجوده چارٽ ۾ ساڳيا آهن.
ٻيهر لڳائڻ کان پوء image رهي ٿو ubuntu:19.04، جيتوڻيڪ چارٽ چوي ٿو ubuntu:18.04.

اسان کي غير هم وقت سازي ملي ۽ اعلانيت وڃائي ڇڏيو.

هڪ هم وقت سازي وسيلن ڇا آهي؟

عام طور تي ڳالهائڻ، پورو اهو حاصل ڪرڻ ناممڪن آهي وسيلن جي ظاهر جي وچ ۾ هلندڙ ڪلستر ۽ Git مان ظاهر ڪيل. ڇاڪاڻ ته هڪ حقيقي پڌرنامي ۾ ٿي سگهي ٿي خدمت تشريح/ليبل، اضافي ڪنٽينر ۽ ٻيون ڊيٽا جيڪي شامل ڪيا ويا آهن ۽ وسيلن مان متحرڪ طور تي ڪجهه ڪنٽرولرز طرفان هٽايو ويو آهي. اسان نٿا ڪري سگهون ۽ نه ٿا چاهيون ته هن ڊيٽا کي Git ۾ رکو. بهرحال، اسان چاهيون ٿا ته اهي شعبا جيڪي اسان واضح طور تي Git ۾ بيان ڪيا آهن رول آئوٽ تي مناسب قدر کڻڻ لاءِ.

اهو ٻاهر ڦرندو ايترو عام هم وقت سازي وسيلن جو ضابطو: جڏهن هڪ وسيلو کي رول آئوٽ ڪيو، توهان صرف انهن شعبن کي تبديل يا حذف ڪري سگهو ٿا جيڪي واضح طور تي Git جي منشور ۾ بيان ڪيا ويا آهن (يا اڳئين ورزن ۾ بيان ڪيا ويا آهن ۽ هاڻي ڊهي ويا آهن).

3-واٽ ملائي پيچ

مکيه خيال 3-واٽ ملائي پيچ: اسان Git مان منشور جي آخري لاڳو ٿيل ورزن ۽ Git مان منشور جي ھدف واري ورزن جي وچ ۾ ھڪڙو پيچ ٺاھيون ٿا، ھلندڙ ڪلستر مان منشور جي موجوده ورزن کي حساب ۾ رکندي. نتيجو ڪندڙ پيچ کي هم وقت سازي وسيلن جي قاعدي سان عمل ڪرڻ گهرجي:

ھدف واري ورزن ۾ شامل ڪيل نوان شعبا پيچ استعمال ڪندي شامل ڪيا ويا آھن؛
پوئين لاڳو ٿيل ورزن ۾ اڳ ۾ موجود فيلڊز ۽ ٽارگيٽ ورجن ۾ موجود نه آھن، پيچ استعمال ڪندي ري سيٽ ڪيا ويا آھن؛
اعتراض جي موجوده ورزن ۾ فيلڊ جيڪي منشور جي ٽارگيٽ ورزن کان مختلف آهن پيچ استعمال ڪندي اپڊيٽ ڪيا ويا آهن.

اهو هن اصول تي آهي ته اهو پيچ ٺاهي ٿو kubectl apply:

منشور جو آخري لاڳو ٿيل نسخو پاڻ کي اعتراض جي تشريح ۾ محفوظ ڪيو ويو آهي،
ٽارگيٽ - مخصوص YAML فائل مان ورتو،
موجوده هڪ هلندڙ ڪلستر مان آهي.

هاڻي ته اسان نظريي کي ترتيب ڏنو آهي، اهو توهان کي ٻڌائڻ جو وقت آهي جيڪو اسان werf ۾ ڪيو.

werf ۾ تبديليون لاڳو ڪرڻ

اڳي، werf، Helm 2 وانگر، استعمال ڪيو ويو 2-طريقه-مرج پيچ.

مرمت جي پيچ

ھڪڙي نئين قسم جي پيچ کي تبديل ڪرڻ لاء - 3-طريقو-ضم - پھريون قدم جيڪو اسان متعارف ڪرايو آھي اھو آھي مرمت جي پيچ.

جڏهن ترتيب ڏيڻ، هڪ معياري 2-واٽ-مرج پيچ استعمال ڪيو ويندو آهي، پر werf اضافي طور تي هڪ پيچ ٺاهي ٿو جيڪو وسيلن جي حقيقي حالت کي هم وقت سازي ڪري ٿو جيڪو Git ۾ لکيل آهي (اهڙو پيچ مٿي بيان ڪيل ساڳئي هم وقت سازي وسيلن جي اصول کي استعمال ڪندي ٺاهيو ويو آهي) .

جيڪڏهن هڪ غير هم وقت سازي ٿئي ٿي، ترتيب ڏيڻ جي آخر ۾ صارف هڪ لاڳاپيل پيغام ۽ هڪ پيچ سان گڏ هڪ خبرداري حاصل ڪري ٿو جيڪو وسيلن کي هم وقت سازي فارم ۾ آڻڻ لاء لاڳو ڪيو وڃي. هي پيچ پڻ هڪ خاص تشريح ۾ رڪارڊ ٿيل آهي werf.io/repair-patch. اهو فرض ڪيو ويو آهي ته صارف جي هٿن ۾ сам هن پيچ کي لاڳو ڪندو: werf ان کي لاڳو نه ڪندو.

مرمت جي پيچ کي پيدا ڪرڻ هڪ عارضي ماپ آهي جيڪو توهان کي اصل ۾ 3-طريقه ضم اصول جي بنياد تي پيچ ٺاهڻ جي جانچ ڪرڻ جي اجازت ڏئي ٿو، پر خودڪار طور تي انهن پيچ کي لاڳو نه ڪريو. هن وقت، هي آپريٽنگ موڊ ڊفالٽ طور تي فعال آهي.

3-طريقه-مضمون پيچ صرف نئين رليز لاءِ

ڊسمبر 1، 2019 کان شروع ٿي، بيٽا ۽ الفا ورزن جي ورف شروع ٿيندي ڊفالٽ طرفان تبديلين کي لاڳو ڪرڻ لاءِ مڪمل 3-واٽ ضم ٿيل پيچ استعمال ڪريو صرف نئين هيلم رليزز تي werf ذريعي رول آئوٽ. موجوده رليز جاري رهنديون استعمال ڪرڻ لاءِ 2-way-merge + مرمت جي پيچ جو طريقو.

هي آپريٽنگ موڊ واضح طور تي سيٽنگ ذريعي فعال ٿي سگهي ٿو WERF_THREE_WAY_MERGE_MODE=onlyNewReleases هاڻي.

ويچاري: مضمون ڪيترن ئي رليز تي werf ۾ ظاهر ٿيو: الفا چينل ۾ اهو نسخو سان تيار ٿي ويو v1.0.5-alpha.19، ۽ بيٽا چينل ۾ - سان v1.0.4-beta.20.

سڀني رليز لاءِ 3-طريقه-مرج پيچ

ڊسمبر 15، 2019 کان شروع ٿي، werf جا بيٽا ۽ الفا ورزن مڪمل 3-واٽ-مرج پيچ استعمال ڪرڻ شروع ڪن ٿا ڊفالٽ طور سڀني رليز ۾ تبديليون لاڳو ڪرڻ لاءِ.

هي آپريٽنگ موڊ واضح طور تي سيٽنگ ذريعي فعال ٿي سگهي ٿو WERF_THREE_WAY_MERGE_MODE=enabled هاڻي.

وسيلن جي خودڪار اسڪيلنگ سان ڇا ڪجي؟

ڪبرنيٽس ۾ آٽو اسڪيلنگ جا 2 قسم آهن: HPA (افقي) ۽ VPA (عمودي).

افقي خودڪار طريقي سان replicas جو تعداد چونڊيندو، عمودي - وسيلن جو تعداد. ٻئي replicas جو تعداد ۽ وسيلن جي گهرج وسيلن جي منشور ۾ بيان ڪيو ويو آهي (ڏسو ريسورس مينيفيسٽ). spec.replicas يا spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory и другие).

مسئلو: جيڪڏهن هڪ صارف هڪ چارٽ ۾ هڪ وسيلن کي ترتيب ڏئي ٿو ته جيئن اهو وسيلن لاء ڪجهه قدر بيان ڪري يا ريپليڪس ۽ آٽو اسڪيلرز هن وسيلن لاء فعال ڪيا وڃن، پوء هر ترتيب سان werf انهن قدرن کي ري سيٽ ڪندو جيڪو چارٽ مينيفيسٽ ۾ لکيل آهي. .

مسئلي جا ٻه حل آهن. شروع ڪرڻ لاءِ، اھو بھتر آھي ته واضح طور تي چارٽ پڌر ۾ خودڪار اسڪيل ويل ويلز کي بيان ڪرڻ کان پاسو ڪيو وڃي. جيڪڏهن هي اختيار ڪنهن سبب لاءِ موزون نه آهي (مثال طور، ڇاڪاڻ ته اهو آسان آهي ته ابتدائي وسيلن جي حدن ۽ چارٽ ۾ نقلن جو تعداد مقرر ڪرڻ لاءِ)، پوءِ werf هيٺيون تشريحون پيش ڪري ٿو:

werf.io/set-replicas-only-on-creation=true
werf.io/set-resources-only-on-creation=true

جيڪڏهن اهڙي تشريح موجود آهي، werf هر مقرري تي لاڳاپيل قيمتن کي ريٽ نه ڪندو، پر صرف انهن کي سيٽ ڪندو جڏهن وسيلا شروعاتي طور تي ٺاهي ويندي.

وڌيڪ تفصيل لاءِ، ڏسو پروجيڪٽ جي دستاويز لاءِ هاء и وي پي اي.

3-طريقه ملائي پيچ جي استعمال کي روڪيو

صارف في الحال ماحول جي متغير استعمال ڪندي werf ۾ نئين پيچ جي استعمال کي منع ڪري سگھي ٿو WERF_THREE_WAY_MERGE_MODE=disabled. بهرحال، شروع 1 مارچ 2020 کان، هي پابندي هاڻي لاڳو نه ٿيندي. ۽ اهو صرف استعمال ڪرڻ ممڪن ٿيندو 3-طريقه ضم ٿيل پيچ.

ورف ۾ وسيلن جي اپنائڻ

3-طريقه ضم ٿيل پيچس سان تبديلين کي لاڳو ڪرڻ جي طريقي ۾ مهارت حاصل ڪرڻ اسان کي فوري طور تي اهڙي خصوصيت کي لاڳو ڪرڻ جي اجازت ڏني آهي جيئن ڪلستر ۾ موجود وسيلن کي هيلم رليز ۾ اپنائڻ.

هيلم 2 ۾ هڪ مسئلو آهي: توهان چارٽ ظاهر ڪرڻ لاءِ ڪو وسيلو شامل نٿا ڪري سگهو جيڪو اڳ ۾ ئي موجود آهي ڪلستر ۾ بغير هن وسيلن کي شروع کان ٻيهر ٺاهڻ (ڏسو. #6031, #3275). اسان ورف کي سيکاريو ته موجوده وسيلن کي ڇڏڻ لاءِ قبول ڪيو. هن کي ڪرڻ لاء، توهان کي هلندڙ ڪلستر مان وسيلن جي موجوده ورزن تي هڪ تشريح نصب ڪرڻ جي ضرورت آهي (مثال طور، استعمال ڪندي kubectl edit):

"werf.io/allow-adoption-by-release": RELEASE_NAME

هاڻي وسيلن کي چارٽ ۾ بيان ڪرڻ جي ضرورت آهي ۽ ايندڙ وقت werf مناسب نالي سان هڪ رليز کي ترتيب ڏئي ٿو، موجوده وسيلن کي هن رليز ۾ قبول ڪيو ويندو ۽ ان جي ڪنٽرول هيٺ رهندو. ان کان علاوه، جاري ڪرڻ لاء هڪ وسيلن کي قبول ڪرڻ جي عمل ۾، werf وسيلن جي موجوده حالت کي هلائيندڙ ڪلستر کان رياست ڏانهن آڻيندو جيڪو چارٽ ۾ بيان ڪيو ويو آهي، ساڳئي 3-رستي-ضمي پيچ ۽ هم وقت سازي وسيلن جي ضابطي کي استعمال ڪندي.

ويچاري: سيٽنگ WERF_THREE_WAY_MERGE_MODE وسيلن جي اپنائڻ تي اثر انداز نه ڪندو آهي - اپنائڻ جي صورت ۾، هڪ 3-واٽ-ضميمه پيچ هميشه استعمال ڪيو ويندو آهي.

تفصيل - ۾ دستاويز.

نتيجو ۽ مستقبل جو منصوبو

مون کي اميد آهي ته هن آرٽيڪل کان پوءِ اهو واضح ٿي ويو آهي ته ڇا 3-طريقه ضم ٿيل پيچ آهن ۽ اهي انهن وٽ ڇو آيا آهن. ويرف پروجيڪٽ جي ترقي جي عملي نقطي نظر کان، انهن تي عمل درآمد هيلم جهڙو ڪم بهتر ڪرڻ جي طرف هڪ ٻيو قدم هو. ھاڻي توھان وساري سگھوٿا ڪنفيگريشن سنڪرونائيزيشن جي مسئلن جي باري ۾، جيڪي اڪثر پيدا ٿينديون ھيم 2 استعمال ڪندي. ساڳي ئي وقت، ھيلم رليز ۾ شامل ڪيو ويو اڳ ۾ ئي ڊائون لوڊ ڪيل Kubernetes وسيلن کي اپنائڻ جي ھڪ نئين مفيد خصوصيت.

هيلم جهڙيون نوڪريون، جيئن گو ٽيمپليٽس جو استعمال، اڃا به ڪجهه مسئلا ۽ چيلينجز آهن، جن کي اسين حل ڪندا رهنداسين.

وسيلن جي تازه ڪاري جي طريقن ۽ اپنائڻ بابت معلومات پڻ ملي سگھن ٿا هي دستاويز صفحو.

هيلم 3

خاص نوٽ جي لائق جاري ڪيو ويو صرف ٻئي ڏينهن هيلم - v3 جو هڪ نئون وڏو نسخو - جيڪو پڻ استعمال ڪري ٿو 3-واٽ-مرج پيچس ۽ ٽيلر کان نجات حاصل ڪري ٿو. هيلم جي نئين نسخي جي ضرورت آهي لڏپلاڻ موجوده تنصيب انهن کي نئين رليز اسٽوريج فارميٽ ۾ تبديل ڪرڻ لاء.

Werf، ان جي حصي لاء، في الحال ٽيلر استعمال ڪرڻ کان نجات حاصل ڪري چڪو آهي، 3-طريقه ضم ڪرڻ ۽ شامل ڪيو ويو آهي گهڻو وڌيڪ، جڏهن ته موجوده هيلم 2 تنصيبن سان مطابقت رکي ٿي (ڪي به لڏپلاڻ اسڪرپٽ کي عمل ڪرڻ جي ضرورت ناهي). تنهن ڪري، جيستائين werf سوئچ ڪري ٿو Helm 3 تي، werf استعمال ڪندڙ Helm 3 جي مٿان Helm 2 جا بنيادي فائدا نه وڃائيندا آهن (werf پڻ انهن وٽ آهي).

بهرحال، هيلم 3 ڪوڊ بيس ڏانهن ويرف جو سوئچ ناگزير آهي ۽ ويجهي مستقبل ۾ ٿيندو. غالباً هي werf 1.1 يا werf 1.2 هوندو (هن وقت، werf جو مکيه نسخو 1.0 آهي؛ وڌيڪ معلومات لاءِ werf ورزننگ ڊيوائس، ڏسو هتي). هن وقت دوران، هيلم 3 کي مستحڪم ڪرڻ جو وقت هوندو.

پي ايس

اسان جي بلاگ تي پڻ پڙهو:

جو ذريعو: www.habr.com

3-طريقو ضم ڪرڻ لاءِ ورف: ڪبرنيٽس کي اسٽيرائڊس تي هيلم سان گڏ ڪرڻ