ڪنٽينر تصويرن جي "سمارٽ" صفائي جو مسئلو ۽ ان جو حل werf ۾

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

تعارف

ڪنٽينر رجسٽري ۾ تصويرن جو تعداد تيزيءَ سان وڌي سگھي ٿو، وڌيڪ اسٽوريج جي جاءِ وٺي ۽ اھڙيءَ طرح ان جي قيمت وڌائي سگھي ٿي. رجسٽري ۾ قبضي واري جاء جي قابل قبول ترقي کي ڪنٽرول ڪرڻ، محدود ڪرڻ يا برقرار رکڻ لاء، اهو قبول ڪيو ويو آهي:

1. تصويرن لاءِ مقرر تعداد ۾ ٽيگ استعمال ڪريو؛
2. تصويرن کي ڪجهه طريقي سان صاف ڪريو.

پهرين حد ڪڏهن ڪڏهن ننڍي ٽيمن لاء قابل قبول آهي. جيڪڏهن ڊولپر وٽ ڪافي مستقل ٽيگ آهن (latest, main, test, boris وغيره)، رجسٽري سائيز ۾ نه لڳندي ۽ گهڻي وقت تائين توهان کي ان کي صاف ڪرڻ بابت سوچڻ جي ضرورت نه پوندي. سڀ کان پوء، سڀ غير مناسب تصويرون ختم ٿي ويا آهن، ۽ صرف صفائي لاء ڪو به ڪم نه آهي (هر شي کي باقاعده ڪچرو جمع ڪندڙ طرفان ڪيو ويندو آهي).

بهرحال، هي طريقو ترقي کي تمام گهڻو محدود ڪري ٿو ۽ جديد CI/CD منصوبن تي تمام گهٽ لاڳو ٿئي ٿو. ترقي جو هڪ لازمي حصو هو خودڪار، جيڪو توهان کي اجازت ڏئي ٿو ٽيسٽ ڪرڻ، ترتيب ڏيڻ ۽ نئين ڪارڪردگيءَ کي صارفين تائين پهچائڻ تمام تيز. مثال طور، اسان جي سڀني منصوبن ۾، هڪ سي آء پائپ لائن خودڪار طريقي سان ٺاهي وئي آهي هر ڪم سان. ان ۾، تصوير گڏ ڪئي وئي آهي، جانچ ڪئي وئي آهي، مختلف ڪبرنيٽس سرڪٽس کي ڊيبگنگ ۽ باقي چيڪ ڪرڻ لاء، ۽ جيڪڏهن سڀ ڪجهه ٺيڪ آهي، تبديليون آخري صارف تائين پهچن ٿيون. ۽ اهو هاڻي راڪيٽ سائنس ناهي، پر ڪيترن ئي لاءِ روزمره جو واقعو آهي - گهڻو ڪري توهان لاءِ، ڇاڪاڻ ته توهان هي مضمون پڙهي رهيا آهيو.

جيئن ته بگ کي درست ڪرڻ ۽ نئين ڪارڪردگي کي ترقي ڪرڻ متوازي طور تي ڪيو ويندو آهي، ۽ رليز هڪ ڏينهن ۾ ڪيترائي ڀيرا انجام ڏئي سگھجن ٿيون، اهو واضح آهي ته ترقي جي عمل سان گڏ هڪ اهم تعداد سان گڏ آهي، جنهن جو مطلب آهي رجسٽري ۾ تصويرن جو وڏو تعداد. نتيجي طور، رجسٽري جي مؤثر صفائي کي منظم ڪرڻ جو مسئلو پيدا ٿئي ٿو، يعني. غير لاڳاپيل تصويرن کي هٽائڻ.

پر توهان اهو ڪيئن اندازو لڳايو ته ڇا هڪ تصوير لاڳاپيل آهي؟

تصوير جي مطابقت لاء معيار

ڪيسن جي وڏي اڪثريت ۾، بنيادي معيار هوندي:

1. پهرين (سڀ کان وڌيڪ واضح ۽ سڀ کان وڌيڪ نازڪ) اهي تصويرون آهن جيڪي في الحال استعمال ڪيو ويو Kubernetes ۾. انهن تصويرن کي هٽائڻ جي نتيجي ۾ اهم پيداوار جي گھٽتائي جي قيمت ٿي سگهي ٿي (مثال طور، تصويرن جي نقل لاءِ گهربل هجي) يا ڪنهن به لوپ تي ٽيم ڊيبگنگ جي ڪوششن کي رد ڪري ٿي. (انهي سبب لاء اسان هڪ خاص ٺاهيو Prometheus برآمد ڪندڙ، جيڪو ڪنهن به ڪبرنيٽس ڪلستر ۾ اهڙين تصويرن جي غير موجودگي کي ٽريڪ ڪري ٿو.)

2. ٻيو (گهٽ پڌرو، پر تمام اهم ۽ وري استحصال سان لاڳاپيل) - تصويرون جيڪي سنگين مسئلن جي سڃاڻپ جي صورت ۾ رول بيڪ لاء گهربل موجوده نسخي ۾. مثال طور، هيلم جي صورت ۾، اهي تصويرون آهن جيڪي رليز جي محفوظ ٿيل نسخن ۾ استعمال ٿيل آهن. (رستي طور، هيلم ۾ ڊفالٽ جي حد 256 ترميمن جي آهي، پر اهو ممڪن ناهي ته ڪنهن کي واقعي بچائڻ جي ضرورت آهي اهڙيون نسخن جو هڪ وڏو تعداد؟..) آخرڪار، اسان، خاص طور تي، نسخن کي ذخيرو ڪريو ته جيئن اسين انهن کي بعد ۾ استعمال ڪري سگهون، يعني. جيڪڏهن ضروري هجي ته انهن ڏانهن "رول واپس".

3. ٽيون - ڊولپر جي ضرورت آهي: سڀئي تصويرون جيڪي انهن جي موجوده ڪم سان لاڳاپيل آهن. مثال طور، جيڪڏهن اسان هڪ پي آر تي غور ڪري رهيا آهيون، پوء اهو سمجهڻ لڳي ٿو ته هڪ تصوير ڇڏڻ جي آخري عزم سان ملندڙ جلندڙ آهي ۽، چئو، پوئين انجام: هن طريقي سان ڊولپر جلدي ڪنهن به ڪم ڏانهن موٽڻ ۽ جديد تبديلين سان ڪم ڪري سگهي ٿو.

4. چوٿون - تصويرون جيڪي اسان جي اپليڪيشن جي نسخن سان ملندڙ جلندڙ، i.e. آخري پراڊڪٽ آهن: v1.0.0، 20.04.01/XNUMX/XNUMX، سيرا، وغيره.

نوٽ: هتي بيان ڪيل معيار مختلف ڪمپنين جي ڪيترن ئي ترقياتي ٽيمن سان رابطي ۾ تجربو جي بنياد تي ٺاهيا ويا آهن. بهرحال، يقينا، ترقي جي عملن جي خاصيتن تي منحصر آهي ۽ استعمال ڪيل زيربنا (مثال طور، ڪبرنيٽس استعمال نه ڪيو ويو آهي)، اهي معيار مختلف ٿي سگهن ٿيون.

قابليت ۽ موجوده حل

ڪنٽينر رجسٽري سان مشهور خدمتون، ضابطي جي طور تي، پيش ڪن ٿيون پنهنجون تصويرون صاف ڪرڻ واريون پاليسيون: انهن ۾ توهان انهن شرطن کي بيان ڪري سگهو ٿا جن جي تحت هڪ ٽيگ رجسٽري مان هٽايو ويو آهي. جڏهن ته، اهي حالتون محدود آهن پيرا ميٽرن جهڙوڪ نالا، ٺهڻ جو وقت، ۽ ٽيگ جو تعداد*.

* مخصوص ڪنٽينر رجسٽري لاڳو ڪرڻ تي منحصر آهي. اسان ھيٺين حلن جي امڪانن تي غور ڪيو: Azure CR، Docker Hub، ECR، GCR، GitHub Packages، GitLab ڪنٽينر رجسٽري، هاربر رجسٽري، JFrog Artifactory، Quay.io - سيپٽمبر 2020 تائين.

پيرا ميٽرن جو هي سيٽ چوٿين معيار کي پورو ڪرڻ لاءِ ڪافي آهي - اهو آهي، تصويرن کي چونڊڻ لاءِ جيڪي نسخن سان ملن ٿيون. بهرحال، ٻين سڀني معيارن لاءِ، ڪنهن کي ڪنهن قسم جو سمجھوتي حل چونڊڻو پوندو (هڪ سخت يا، برعڪس، وڌيڪ نرمي واري پاليسي) - اميدن ۽ مالي صلاحيتن تي منحصر.

مثال طور، ٽيون معيار - ڊولپرز جي ضرورتن سان لاڳاپيل - ٽيمن جي اندر عملن کي ترتيب ڏيڻ سان حل ڪري سگھجي ٿو: تصويرن جو مخصوص نالو، خاص اجازتن جي فهرستن ۽ اندروني معاهدي کي برقرار رکڻ. پر آخرڪار اهو اڃا تائين خودڪار ٿيڻ جي ضرورت آهي. ۽ جيڪڏهن تيار ڪيل حلن جون صلاحيتون ڪافي نه آهن، توهان کي پنهنجو پاڻ کي ڪجهه ڪرڻو پوندو.

پهرين ٻن معيارن سان صورتحال ساڳي آهي: اهي هڪ خارجي سسٽم کان ڊيٽا حاصل ڪرڻ کان سواء مطمئن نٿا ٿي سگهن - هڪ جتي ايپليڪيشنون مقرر ڪيون ويون آهن (اسان جي صورت ۾، ڪبرنيٽس).

Git ۾ ڪم فلو جو مثال

اچو ته چئو ته توھان ڪجھھ ڪم ڪري رھيا آھيو Git ۾:

آريگرام ۾ هيڊ سان آئڪن ڪنٽينر تصويرن جي نشاندهي ڪري ٿو جيڪي في الحال ڪنهن به استعمال ڪندڙ (آخر استعمال ڪندڙ، ٽيسٽرز، مينيجرز، وغيره) لاءِ ڪبرنيٽس ۾ لڳايون ويون آهن يا ڊولپرز پاران ڊيبگنگ ۽ ساڳئي مقصدن لاءِ استعمال ڪيون ويون آهن.

ڇا ٿيندو جيڪڏهن صاف ڪرڻ واريون پاليسيون صرف تصويرن کي برقرار رکڻ جي اجازت ڏين ٿيون (ڊليٽ نه ٿيل) ڏنل ٽيگ نالن سان?

ظاهر آهي، اهڙي صورتحال ڪنهن کي به خوش نه ڪندي.

ڇا تبديلي آڻيندو جيڪڏهن پاليسين تصويرن کي حذف نه ڪرڻ جي اجازت ڏين؟ ڏنل وقت جي وقفي جي مطابق / آخري ڪمن جو تعداد?

نتيجو گهڻو بهتر ٿي چڪو آهي، پر اڃا تائين مثالي کان پري آهي. سڀ کان پوء، اسان وٽ اڃا تائين ڊولپرز آهن جن کي رجسٽري ۾ تصويرن جي ضرورت آهي (يا اڃا تائين K8s ۾ مقرر ڪيل) بگ ڊيب ڪرڻ لاء ...

مارڪيٽ جي موجوده صورتحال کي مختصر ڪرڻ لاءِ: ڪنٽينر رجسٽري ۾ موجود فنڪشن ڪافي لچڪ پيش نه ڪندا آهن جڏهن صفائي، ۽ ان جو بنيادي سبب آهي. ٻاهرين دنيا سان لهه وچڙ ڪرڻ جو ڪو طريقو ناهي. اهو ظاهر ٿئي ٿو ته ٽيمون جيڪي اهڙي لچڪ جي ضرورت هونديون آهن انهن کي آزاديء سان لاڳو ڪرڻ تي مجبور ڪيو ويو آهي تصوير کي ختم ڪرڻ "ٻاهرين کان"، استعمال ڪندي Docker Registry API (يا لاڳاپيل عمل جي اصلي API).

بهرحال، اسان هڪ آفاقي حل ڳولي رهيا هئاسين جيڪو مختلف ٽيمن لاءِ تصوير صاف ڪرڻ کي خودڪار ڪندو مختلف رجسٽري استعمال ڪندي...

اسان جو رستو آفاقي تصوير جي صفائي لاءِ

اها ضرورت ڪٿان آئي؟ حقيقت اها آهي ته اسان ڊولپرز جو هڪ الڳ گروپ نه آهيون، پر هڪ ٽيم جيڪا انهن مان ڪيترن کي هڪ ئي وقت ۾ خدمت ڪري ٿي، CI/CD مسئلن کي جامع طور تي حل ڪرڻ ۾ مدد ڪري ٿي. ۽ ان لاءِ مکيه ٽيڪنيڪل اوزار اوپن سورس يوٽيلٽي آهي werf. ان جي خصوصيت اها آهي ته اهو هڪ واحد فنڪشن انجام نٿو ڏئي، پر سڀني مرحلن تي مسلسل پهچائڻ واري عمل سان گڏ آهي: اسيمبليء کان تعیناتي تائين.

رجسٽري ۾ تصويرون شايع ڪرڻ * (فوري طور تي انهن جي تعمير ٿيڻ کان پوء) اهڙي افاديت جو هڪ واضح ڪم آهي. ۽ جيئن ته تصويرون اتي رکيل آهن اسٽوريج لاءِ، پوءِ - جيڪڏهن توهان جي اسٽوريج لامحدود نه آهي - توهان کي انهن جي ايندڙ صفائي لاءِ ذميوار ٿيڻو پوندو. اسان ان ۾ ڪاميابي ڪيئن حاصل ڪئي، سڀني مخصوص معيارن کي پورو ڪندي، اڳتي هلي بحث ڪيو ويندو.

* جيتوڻيڪ رجسٽري پاڻ مختلف ٿي سگهي ٿي (ڊاڪر رجسٽري، GitLab ڪنٽينر رجسٽري، هاربر، وغيره)، انهن جا صارف ساڳيا مسئلا منهن ڏين ٿا. اسان جي معاملي ۾ آفاقي حل رجسٽري جي عمل تي منحصر نه آهي، ڇاڪاڻ ته پاڻ رجسٽري کان ٻاهر هلندو آهي ۽ هر ڪنهن لاءِ ساڳيو رويو پيش ڪري ٿو.

جيتوڻيڪ اسين werf استعمال ڪري رهيا آهيون مثال جي عمل جي طور تي، اسان اميد ٿا ڪريون ته استعمال ٿيل طريقا ٻين ٽيمن لاءِ ڪارآمد ثابت ٿيندا جيڪي ساڳي مشڪلاتن سان منهن ڏئي رهيا آهن.

سو اسان مصروف ٿي وياسين خارجي تصويرن کي صاف ڪرڻ لاء هڪ ميکانيزم تي عملدرآمد - انهن صلاحيتن جي بدران جيڪي اڳ ۾ ئي ڪنٽينرز لاء رجسٽري ۾ ٺهيل آهن. پهريون قدم استعمال ڪرڻ هو Docker Registry API استعمال ڪرڻ لاءِ ساڳيا ابتدائي پاليسيون ٺاهڻ لاءِ ٽيگ جي تعداد ۽ انهن جي تخليق جي وقت (مٿي ذڪر ڪيل). انهن ۾ شامل ڪيو ويو ترتيب ڏنل انفراسٽرڪچر ۾ استعمال ٿيل تصويرن جي بنياد تي لسٽ کي اجازت ڏيو، i.e. ڪبرنيٽس. بعد ۾، اهو ڪافي هو Kubernetes API استعمال ڪرڻ لاءِ استعمال ڪرڻ لاءِ سڀني مقرر ڪيل وسيلن جي ذريعي ۽ قدرن جي فهرست حاصل ڪرڻ لاءِ image.

هي ننڍڙو حل تمام نازڪ مسئلو حل ڪيو (معيار نمبر 1)، پر صرف صفائي جي ميڪانيزم کي بهتر ڪرڻ لاء اسان جي سفر جي شروعات هئي. ايندڙ - ۽ گهڻو وڌيڪ دلچسپ - قدم فيصلو هو شايع ٿيل تصويرن کي Git جي تاريخ سان ڳنڍيو.

ٽيگنگ اسڪيمون

شروع ڪرڻ سان، اسان ھڪڙو طريقو چونڊيو آھي جنھن ۾ حتمي تصوير کي صاف ڪرڻ لاء ضروري معلومات ذخيرو ڪرڻ گھرجي، ۽ پروسيس کي ٽيگنگ اسڪيمن تي ٺاھيو. جڏهن هڪ تصوير شايع ڪندي، صارف هڪ مخصوص ٽيگنگ اختيار چونڊيو (git-branch, git-commit يا git-tag) ۽ لاڳاپيل قدر استعمال ڪيو. CI سسٽم ۾، اهي قدر خودڪار طور تي مقرر ڪيا ويا ماحولياتي متغير جي بنياد تي. حقيقت ۾ آخري تصوير هڪ مخصوص Git primitive سان لاڳاپيل هئي، ليبل ۾ صفائي لاءِ ضروري ڊيٽا محفوظ ڪرڻ.

هن طريقي جي نتيجي ۾ پاليسين جي هڪ سيٽ جي نتيجي ۾ Git کي استعمال ڪرڻ جي اجازت ڏني وئي سچ جو واحد ذريعو:

• Git ۾ شاخ/ٽيگ کي حذف ڪرڻ وقت، رجسٽري ۾ لاڳاپيل تصويرون خودڪار طريقي سان ختم ٿي ويون.
• Git tags ۽ ڪميٽ سان لاڳاپيل تصويرن جو تعداد منتخب ٿيل اسڪيما ۾ استعمال ٿيل ٽيگ جي تعداد ۽ وقت جنھن سان لاڳاپيل ڪمٽ ٺاھيو ويو ڪنٽرول ڪري سگھجي ٿو.

مجموعي طور تي، نتيجي تي عملدرآمد اسان جي ضرورتن کي پورو ڪيو، پر جلد ئي هڪ نئون چئلينج اسان جي انتظار ۾ آهي. حقيقت اها آهي ته Git primitives جي بنياد تي ٽيگنگ اسڪيمن کي استعمال ڪندي، اسان ڪيترن ئي نقصن جو سامنا ڪيو. (جيئن ته انهن جو بيان هن مضمون جي دائري کان ٻاهر آهي، هرڪو پاڻ کي تفصيل سان واقف ڪري سگهي ٿو. هتي.) تنهن ڪري، ٽيگنگ (مواد تي ٻڌل ٽيگنگ) لاء وڌيڪ موثر طريقي سان تبديل ڪرڻ جو فيصلو ڪيو ويو، اسان کي تصوير جي صفائي جي عمل تي ٻيهر غور ڪرڻو پوندو.

نئون الگورتھم

ڇو؟ مواد تي ٻڌل ٽيگنگ سان، هر ٽيگ Git ۾ ڪيترن ئي ڪمن کي پورو ڪري سگھي ٿو. جڏهن تصويرن کي صاف ڪرڻ، توهان هاڻي فرض نٿا ڪري سگهو صرف ڪمٽ تان جتي نئون ٽيگ شامل ڪيو ويو رجسٽري ۾.

نئين صفائي جي الگورتھم لاء، اهو فيصلو ڪيو ويو ته ٽيگنگ اسڪيمن کان پري وڃڻ ۽ تعمير ڪرڻ meta-تصوير جو عمل, جن مان هر هڪ کي ذخيرو ڪري ٿو:

• اهو عزم جنهن تي پبليڪيشن ڪئي وئي هئي (اها ڳالهه ناهي ته تصوير شامل ڪئي وئي هئي، تبديل ڪئي وئي يا ڪنٽينر رجسٽري ۾ ساڳيو رهي ٿو)؛
• ۽ اسان جي اندروني سڃاڻپ ڪندڙ گڏ ڪيل تصوير سان ملندڙ جلندڙ.

ٻين لفظن ۾، اهو مهيا ڪيو ويو Git ۾ ڪميٽ سان شايع ٿيل ٽيگ کي ڳنڍڻ.

آخري ترتيب ۽ عام الگورتھم

جڏهن صفائي کي ترتيب ڏيڻ، صارفين کي هاڻي پاليسين تائين رسائي آهي جيڪي موجوده تصويرون چونڊيندا آهن. هر اهڙي پاليسي جي وضاحت ڪئي وئي آهي:

• ڪيترائي حوالا، يعني گِٽ ٽيگ يا گِٽ شاخون جيڪي اسڪيننگ دوران استعمال ٿين ٿيون؛
• ۽ سيٽ مان هر حوالن لاءِ ڳولا ڪيل تصويرن جي حد.

واضع ڪرڻ لاء، هي آهي جيڪو ڊفالٽ پاليسي ترتيب ڏيڻ شروع ڪيو جيئن نظر اچي ٿو:

cleanup:
  keepPolicies:
  - references:
      tag: /.*/
      limit:
        last: 10
  - references:
      branch: /.*/
      limit:
        last: 10
        in: 168h
        operator: And
    imagesPerReference:
      last: 2
      in: 168h
      operator: And
  - references:  
      branch: /^(main|staging|production)$/
    imagesPerReference:
      last: 10

ھن تشڪيل ۾ ٽي پاليسيون شامل آھن جيڪي ھيٺين قاعدن سان عمل ڪن ٿيون:

1. آخري 10 گٽ ٽيگ لاءِ تصوير محفوظ ڪريو (ٽيگ ٺاھڻ جي تاريخ موجب).
2. گذريل هفتي ۾ شايع ٿيل 2 تصويرون کان وڌيڪ محفوظ نه ڪريو گذريل هفتي ۾ سرگرمي سان 10 موضوعن کان وڌيڪ نه.
3. شاخن لاءِ 10 تصويرون محفوظ ڪريو main, staging и production.

آخري الورورٿم ھيٺ ڏنل قدمن تائين پھچي ٿو:

• ڪنٽينر رجسٽري مان منشور حاصل ڪرڻ.
• ڪبرنيٽس ۾ استعمال ٿيل تصويرن کان سواء، ڇاڪاڻ ته اسان اڳ ۾ ئي انهن کي چونڊيو آهي K8s API پولنگ ڪندي.
• گٽ جي تاريخ کي اسڪين ڪرڻ ۽ مخصوص پاليسين جي بنياد تي تصويرن کي خارج ڪرڻ.
• باقي تصويرون هٽائڻ.

اسان جي مثال ڏانھن موٽڻ، اھو اھو آھي جيڪو ورف سان ٿئي ٿو:

تنهن هوندي، جيتوڻيڪ جيڪڏهن توهان werf استعمال نٿا ڪريو، ترقي يافته تصوير جي صفائي لاء ساڳيو طريقو - هڪ عمل ۾ يا ٻئي (تصوير جي ٽيگنگ جي ترجيح واري طريقي جي مطابق) - ٻين سسٽم / افاديت تي لاڳو ٿي سگهي ٿو. هن کي ڪرڻ لاءِ، اهو ڪافي آهي ته انهن مسئلن کي ياد ڪرڻ لاءِ جيڪي پيدا ٿين ٿا ۽ توهان جي اسٽيڪ ۾ اهي موقعا ڳولين ٿا جيڪي توهان کي انهن جي حل کي ممڪن طور تي آساني سان ضم ڪرڻ جي اجازت ڏين ٿا. اسان کي اميد آهي ته جيڪو رستو اسان سفر ڪيو آهي اهو توهان جي خاص ڪيس کي نئين تفصيل ۽ خيالن سان ڏسڻ ۾ مدد ڪندو.

ٿڪل

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

پي ايس

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

• «werf ڪليڪٽر ۾ مواد تي ٻڌل ٽيگنگ: ڇو ۽ ڪيئن ڪم ڪندو آهي؟"؛
• «3-طريقو ضم ڪرڻ لاءِ ورف: ڪبرنيٽس کي هيلم سان گڏ ”اسٽيرائڊس تي“ مقرر ڪرڻ"؛
• «werf ۾ monorepo ۽ multirepo لاءِ سپورٽ ۽ ڊاڪر رجسٽري کي ان سان ڇا ڪرڻو آهي"؛
• «werf 1.1 رليز: اڄ بلڊر ۾ بهتري ۽ مستقبل لاءِ منصوبا».

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