27 مئي DevOpsConf 2019 ڪانفرنس جي مکيه هال ۾، ميلو جي حصي طور منعقد "مسلسل ترسيل" سيڪشن جي حصي جي طور تي، هڪ رپورٽ ڏني وئي "werf - اسان جو اوزار CI/CD لاءِ ڪبرنيٽس ۾". اهو انهن بابت ڳالهائيندو آهي مسئلا ۽ چيلينج جيڪي هر ڪنهن کي منهن ڏيڻو پوي ٿو جڏهن ڪبرنيٽس کي ترتيب ڏيڻ، انهي سان گڏ nuances بابت جيڪي شايد فوري طور تي قابل ذڪر نه هوندا. ممڪن حلن جو تجزيو ڪندي، اسان ڏيکاريون ٿا ته اهو ڪيئن لاڳو ٿئي ٿو اوپن سورس ٽول ۾ .
پريزنٽيشن کان وٺي، اسان جي افاديت (اڳوڻي ڊيپ جي نالي سان مشهور آهي) جي هڪ تاريخي سنگ ميل تي پهچي چڪو آهي GitHub تي 1000 تارا - اسان کي اميد آهي ته صارفين جي ان جي وڌندڙ برادري ڪيترن ئي DevOps انجنيئرن لاءِ زندگي آسان بڻائي ڇڏيندي.
تنهن ڪري، اچو ته متعارف ڪرايو (~ 47 منٽ، مضمون کان گهڻو وڌيڪ معلوماتي) ۽ ان مان مکيه اقتباس متن جي صورت ۾. وڃ!
ڪبرنيٽس تائين ڪوڊ پهچائڻ
ڳالهه هاڻي werf بابت نه هوندي، پر ڪبرنيٽس ۾ CI/CD بابت، انهي جو مطلب آهي ته اسان جو سافٽ ويئر ڊاکر ڪنٽينرز ۾ پيڪيج ٿيل آهي. (مون ان بابت ڳالهايو )، ۽ K8s استعمال ڪيو ويندو ان کي پيداوار ۾ هلائڻ لاء (ان بابت وڌيڪ اصطلاح ۾ ).
ڪبرنيٽس ۾ ترسيل ڇا نظر اچي ٿي؟
- ڪوڊ ۽ ان جي تعمير لاء هدايتون سان گڏ هڪ Git مخزن آهي. اپليڪيشن ڊاکر تصوير ۾ ٺهيل آهي ۽ ڊاکر رجسٽري ۾ شايع ٿيل آهي.
- ساڳئي مخزن ۾ پڻ ايپليڪيشن کي ترتيب ڏيڻ ۽ هلائڻ تي هدايتون شامل آهن. مقرري واري مرحلي ۾، اهي هدايتون ڪبرنيٽس ڏانهن موڪليا ويا آهن، جيڪي رجسٽري مان گهربل تصوير وصول ڪري ٿو ۽ ان کي لانچ ڪري ٿو.
- ان سان گڏ، عام طور تي ٽيسٽ آهن. انهن مان ڪجهه ڪري سگهجي ٿو جڏهن هڪ تصوير شايع ڪرڻ. توهان پڻ ڪري سگهو ٿا (ساڳين هدايتن تي عمل ڪندي) ايپليڪيشن جي هڪ ڪاپي (هڪ الڳ K8s نالي جي جڳهه يا هڪ الڳ ڪلستر ۾) ۽ اتي ٽيسٽ هلائي سگهو ٿا.
- آخرڪار، توهان کي هڪ CI سسٽم جي ضرورت آهي جيڪا Git (يا بٽڻ ڪلڪ) کان واقعا وصول ڪري ٿي ۽ سڀني نامزد ٿيل مرحلن کي ڪال ڪري ٿو: تعمير، شايع، ترتيب، ٽيسٽ.
هتي ڪجھ اهم نوٽس آهن:
- ڇاڪاڻ ته اسان وٽ هڪ ناقابل بدل انفراسٹرڪچر آهي (غير تبديل ٿيندڙ انفراسٽرڪچر), ايپليڪيشن تصوير جيڪا سڀني مرحلن تي استعمال ٿئي ٿي (اسٽيجنگ، پيداوار، وغيره)، اتي هڪ هجڻ گهرجي. مون ان بابت وڌيڪ تفصيل سان ۽ مثالن سان ڳالهايو. .
- ڇو ته اسان بنيادي ڍانچي جي پيروي ڪندا آهيون جيئن ڪوڊ اپروچ (IaC), ايپليڪيشن ڪوڊ، گڏ ڪرڻ لاء هدايتون ۽ ان کي لانچ ڪرڻ گهرجي بلڪل هڪ مخزن ۾. ان بابت وڌيڪ معلومات لاءِ، ڏسو .
- پهچائڻ جو سلسلو (ترسيل) اسان عام طور تي ان کي ڏسندا آهيون: ايپليڪيشن گڏ ڪئي وئي، آزمائشي، جاري ڪئي وئي (ڇڏيل اسٽيج) ۽ اهو ئي آهي - پهچائڻ ٿي چڪو آهي. پر حقيقت ۾، صارف حاصل ڪري ٿو جيڪو توهان رول ڪيو، نه پوءِ جڏهن توهان ان کي پيداوار ڏانهن پهچايو، ۽ جڏهن هو اتي وڃڻ جي قابل ٿي ويو ۽ هن پيداوار ڪم ڪيو. تنهن ڪري مان سمجهان ٿو ته ترسيل سلسلو ختم ٿئي ٿو صرف آپريشنل اسٽيج تي (هلڻ)، يا وڌيڪ صحيح طور تي، ان وقت به جڏهن ڪوڊ پيداوار مان هٽايو ويو (ان کي نئين سان تبديل ڪرڻ).
اچو ته Kubernetes ۾ مٿين ترسيل اسڪيم ڏانهن موٽون: اهو نه رڳو اسان جي طرفان ايجاد ڪيو ويو، پر لفظي طور تي هر ڪنهن طرفان جيڪو هن مسئلي سان معاملو ڪيو. حقيقت ۾، هي نمونو هاڻي سڏيو ويندو آهي GitOps (توهان اصطلاح ۽ ان جي پويان خيالن بابت وڌيڪ پڙهي سگهو ٿا ). اچو ته اسڪيم جي مرحلن کي ڏسو.
اسٽيج تعمير ڪريو
اهو لڳي ٿو ته توهان 2019 ۾ ڊاکر تصويرون ٺاهڻ جي باري ۾ ڳالهائي سگهو ٿا، جڏهن هرڪو ڄاڻي ٿو ته ڊڪر فائلون ڪيئن لکڻ ۽ هلائڻ docker build؟.. هتي اهي نزاڪت آهن جن تي مان ڌيان ڏيڻ چاهيان ٿو:
- تصوير جو وزن ضروري آهي، تنهنڪري استعمال ڪريو تصوير ۾ ڇڏڻ لاءِ صرف اها درخواست جيڪا واقعي آپريشن لاءِ ضروري آهي.
- تہن جو تعداد جي زنجيرن کي گڏ ڪندي گھٽ ۾ گھٽ ڪيو وڃي
RUN- معنيٰ مطابق حڪم. - بهرحال، هي مسئلا وڌائي ٿو ڊيبگنگ، ڇاڪاڻ ته جڏهن اسيمبلي حادثو ٿئي ٿي، توهان کي زنجير مان صحيح حڪم ڳولڻو پوندو جيڪو مسئلو پيدا ڪيو.
- اسيمبلي جي رفتار ضروري آهي ڇاڪاڻ ته اسان چاهيون ٿا جلدي تبديلين کي رول آئوٽ ڪرڻ ۽ نتيجا ڏسڻ. مثال طور، توھان نٿا چاھيو ته ٻوليءَ جي لئبرريءَ ۾ انحصار کي بحال ڪرڻ گھرجي ھر وقت توھان ايپليڪيشن ٺاھيو.
- گهڻو ڪري هڪ Git مخزن مان توهان کي ضرورت آهي ڪيتريون ئي تصويرون، جيڪو Dockerfiles جي هڪ سيٽ (يا هڪ فائل ۾ نامزد ٿيل مرحلو) ۽ هڪ بش اسڪرپٽ انهن جي ترتيب واري اسيمبلي سان حل ڪري سگهجي ٿو.
هي صرف برفاني چوٽي جو ٽپ هو جنهن کي هرڪو منهن ڏئي ٿو. پر ٻيا مسئلا آهن، خاص طور تي:
- اڪثر اسيمبلي اسٽيج تي اسان کي ڪجهه جي ضرورت آهي جبل (مثال طور، هڪ حڪم جو نتيجو ڪيش ڪريو جهڙوڪ apt ٽئين پارٽي ڊاريڪٽري ۾).
- اسان چاهيون ٿا ناھي شيل ۾ لکڻ جي بدران.
- اسان چاهيون ٿا Docker کان سواء تعمير (اسان کي هڪ اضافي ورچوئل مشين جي ضرورت ڇو آهي جنهن ۾ اسان کي ان لاءِ هر شي کي ترتيب ڏيڻ جي ضرورت آهي، جڏهن اسان وٽ اڳ ۾ ئي ڪوبرنيٽس ڪلستر آهي جنهن ۾ اسان ڪنٽينر هلائي سگهون ٿا؟).
- متوازي اسيمبلي، جنهن کي مختلف طريقن سان سمجهي سگهجي ٿو: Dockerfile کان مختلف حڪم (جيڪڏهن ملٽي اسٽيج استعمال ڪيو ويندو آهي)، ساڳئي مخزن جا ڪيترائي ڪم، ڪيترائي Dockerfiles.
- ورهايل اسيمبلي: اسان پوڊز ۾ شيون گڏ ڪرڻ چاهيون ٿا جيڪي "اعتدال" آهن ڇاڪاڻ ته انهن جي ڪيش غائب ٿي وڃي ٿي، جنهن جو مطلب آهي ته ان کي الڳ الڳ جاءِ رکڻ جي ضرورت آهي.
- آخر ۾، مون خواهشن جي چوٽي جو نالو رکيو خودڪار: اهو مثالي هوندو ته مخزن ڏانهن وڃو، ڪجهه حڪم ٽائيپ ڪريو ۽ هڪ تيار ٿيل تصوير حاصل ڪريو، انهي کي سمجهڻ سان گڏ گڏ ڪيو ويو ته ڪيئن ۽ ڇا صحيح طريقي سان ڪيو وڃي. تنهن هوندي، مون کي ذاتي طور تي پڪ ناهي ته سڀ nuances هن طرح پيش ڪري سگهجي ٿو.
۽ هتي منصوبا آهن:
- - Docker Inc کان هڪ بلڊر (اڳ ۾ ئي ڊڪر جي موجوده ورزن ۾ ضم ٿيل)، جيڪو انهن سڀني مسئلن کي حل ڪرڻ جي ڪوشش ڪري رهيو آهي؛
- - گوگل کان هڪ بلڊر جيڪو توهان کي اجازت ڏئي ٿو بغير ڊڪر جي تعمير ڪرڻ؛
- - CNCF جي ڪوشش پاڻمرادو جادو ڪرڻ جي ۽، خاص طور تي، تہن جي بحالي سان گڏ ھڪڙو دلچسپ حل؛
- ۽ ٻين افاديت جو هڪ گروپ، جهڙوڪ , ...
... ۽ ڏسو ته ڪيترا تارا آھن اھي GitHub تي. يعني هڪ طرف، docker build موجود آهي ۽ ڪجهه ڪري سگهي ٿو، پر حقيقت ۾ مسئلو مڪمل طور تي حل نه ڪيو ويو آهي - هن جو ثبوت متبادل جمع ڪندڙ جي متوازي ترقي آهي، جن مان هر هڪ مسئلن جو ڪجهه حصو حل ڪري ٿو.
ورف ۾ اسيمبلي
تنهنڪري اسان کي ملي (اڳ ڊيپ وانگر) - فلانٽ ڪمپني مان هڪ اوپن سورس يوٽيليٽي، جنهن کي اسان ڪيترن سالن کان ٺاهي رهيا آهيون. اهو سڀ 5 سال اڳ بش اسڪرپٽس سان شروع ٿيو جنهن ڊاڪرفائلس جي اسيمبلي کي بهتر ڪيو، ۽ گذريل 3 سالن کان مڪمل ترقي ڪئي وئي آهي هڪ منصوبي جي فريم ورڪ جي اندر ان جي پنهنجي Git مخزن سان. (پهرين روبي ۾، ۽ پوءِ وڃڻ لاء، ۽ ساڳئي وقت نالو تبديل ڪيو ويو). ڪهڙي اسيمبليءَ جا مسئلا وارف ۾ حل ٿين ٿا؟
نيري ۾ ڇانيل مسئلا اڳ ۾ ئي لاڳو ڪيا ويا آهن، متوازي تعمير ساڳئي ميزبان جي اندر ڪئي وئي، ۽ پيلي ۾ نمايان ٿيل مسئلن کي اونهاري جي آخر تائين مڪمل ڪرڻ جي منصوبابندي ڪئي وئي آهي.
رجسٽري ۾ اشاعت جو مرحلو (شايع)
اسان ڊائل ڪيو docker push... - رجسٽري ۾ تصوير اپلوڊ ڪرڻ بابت ڇا ڏکيو ٿي سگهي ٿو؟ ۽ پوء سوال پيدا ٿئي ٿو: "مون کي تصوير تي ڪهڙي ٽيگ رکڻ گهرجي؟" اهو ان ڪري پيدا ٿئي ٿو جو اسان وٽ آهي گيٽ فلو (يا ٻي گٽ حڪمت عملي) ۽ ڪبرنيٽس، ۽ صنعت کي يقيني بڻائڻ جي ڪوشش ڪري رهي آهي ته ڪبرنيٽس ۾ ڇا ٿئي ٿو پٺيان گيٽ ۾ ڇا ٿئي ٿو. آخرڪار، گيت اسان جي سچائي جو واحد ذريعو آهي.
ان ۾ ڪهڙي ڏکيائي آهي؟ reproducibility کي يقيني بڻائي: گٽ ۾ هڪ وابستگي کان، جيڪو فطرت ۾ ناقابل قبول آهي (مٽڻ لائق)، هڪ Docker تصوير ڏانهن، جنهن کي ساڳيو رکيو وڃي.
اهو پڻ اسان لاء اهم آهي اصل جو تعين ڪرڻ، ڇاڪاڻ ته اسان اهو سمجهڻ چاهيون ٿا ته ڪبرنيٽس ۾ هلندڙ ايپليڪيشن ڪهڙي ڪمٽ تان ٺاهي وئي هئي (پوءِ اسان اختلاف ۽ ساڳي شيون ڪري سگهون ٿا).
ٽيگنگ حڪمت عمليون
پهريون سادو آهي git ٽيگ. اسان وٽ هڪ رجسٽري آهي جنهن ۾ هڪ تصوير سان ٽيگ ٿيل آهي 1.0. ڪبرنيٽس وٽ اسٽيج ۽ پيداوار آهي، جتي هي تصوير اپلوڊ ڪئي وئي آهي. گٽ ۾ اسان ڪميون ڪيون ٿا ۽ ڪجهه نقطي تي اسان ٽيگ ڪريون ٿا 2.0. اسان ان کي گڏ ڪريون ٿا مخزن جي هدايتن مطابق ۽ ان کي رجسٽري ۾ ٽيگ سان رکون ٿا 2.0. اسان ان کي اسٽيج تي پهچايو ۽، جيڪڏهن سڀ ڪجهه ٺيڪ آهي، پوء پيداوار ڏانهن.
هن طريقي سان مسئلو اهو آهي ته اسان پهريون ڀيرو ٽيگ لڳايو، ۽ صرف پوء ان کي جانچيو ۽ ان کي رول ڪيو. ڇو؟ پهرين، اهو صرف غير منطقي آهي: اسان سافٽ ويئر جو هڪ نسخو جاري ڪري رهيا آهيون جيڪو اسان اڃا تائين آزمائي نه ڪيو آهي (اسان ٻي صورت ۾ نٿا ڪري سگهون، ڇاڪاڻ ته چيڪ ڪرڻ لاء، اسان کي ٽيگ لڳائڻ جي ضرورت آهي). ٻيو، هي رستو Gitflow سان مطابقت ناهي.
ٻيو اختيار آهي git انجام + ٽيگ. ماسٽر برانچ هڪ ٽيگ آهي 1.0؛ ان لاءِ رجسٽري ۾ - هڪ تصوير جيڪا پيداوار تي لڳايو ويو آهي. ان کان سواء، ڪبرنيٽس ڪلستر جو ڏيک ۽ اسٽيجنگ جي شڪل آهي. اڳيون اسان Gitflow جي پيروي ڪندا آهيون: ترقي لاءِ مکيه شاخ ۾ (develop) اسان نئين خاصيتون ٺاهيندا آهيون، جنهن جي نتيجي ۾ سڃاڻپ ڪندڙ سان هڪ عزم #c1. اسان ان کي گڏ ڪريون ٿا ۽ ان کي رجسٽري ۾ شايع ڪريون ٿا هن سڃاڻپ ڪندڙ (#c1). ساڳي سڃاڻپ ڪندڙ سان اسان ڏيک ڏينداسين. اسان ڪمن سان پڻ ائين ڪندا آهيون #c2 и #c3.
جڏهن اسان محسوس ڪيو ته ڪافي خاصيتون آهن، اسان هر شيء کي مستحڪم ڪرڻ شروع ڪيو. Git ۾ هڪ شاخ ٺاهيو release_1.1 (بنياد تي #c3 کان develop). هن رليز کي گڏ ڪرڻ جي ڪا ضرورت ناهي، ڇاڪاڻ ته ... اهو اڳئين قدم ۾ ڪيو ويو. تنهن ڪري، اسان صرف ان کي اسٽيجنگ ڪرڻ لاء ٻاهر ڪڍي سگهون ٿا. اسان ان ۾ غلطيون درست ڪريون ٿا #c4 ۽ ساڳيءَ طرح اسٽيج ڪرڻ لاءِ. ساڳئي وقت ۾، ترقي جاري آهي develop، جتي تبديليون وقتي طور تي ورتيون وينديون آهن release_1.1. ڪجهه نقطي تي، اسان هڪ ڪمٽ مرتب ڪيو ۽ اسٽيجنگ تي اپ لوڊ ڪيو، جنهن سان اسان خوش آهيون (#c25).
پوءِ اسان ملائي (فاسٽ فارورڊ سان) ڇڏڻ واري شاخ (release_1.1) ماسٽر ۾. اسان هن ڪمٽ تي نئين ورزن سان ٽيگ لڳايو (1.1). پر هي تصوير اڳ ۾ ئي رجسٽري ۾ گڏ ڪئي وئي آهي، تنهنڪري ان کي ٻيهر گڏ نه ڪرڻ لاء، اسان صرف موجوده تصوير ۾ هڪ ٻيو ٽيگ شامل ڪندا آهيون (هاڻي اهو رجسٽري ۾ ٽيگ آهي. #c25 и 1.1). ان کان پوء، اسان ان کي پيداوار ڏانهن وڌايو.
اتي هڪ خرابي آهي ته اسٽيجنگ تي صرف هڪ تصوير اپلوڊ ڪئي وئي آهي (#c25)، ۽ پيداوار ۾ اهو مختلف قسم جو آهي (1.1)، پر اسان ڄاڻون ٿا ته "جسماني طور تي" اهي ساڳيا تصوير آهن رجسٽري مان.
اصل نقصان اهو آهي ته ضم ڪرڻ جي ڪمن لاءِ ڪو به سهارو نه آهي، توهان کي ڪرڻو پوندو فاسٽ فارورڊ.
اسان اڳتي وڌي سگھون ٿا ۽ هڪ چال ڪري سگهون ٿا... اچو ته هڪ سادي Dockerfile جو مثال ڏسون:
FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb
FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/publicاچو ته ان مان فائل ٺاھيون ھيٺ ڏنل اصول موجب:
- SHA256 استعمال ٿيل تصويرن جي سڃاڻپ ڪندڙ کان (
ruby:2.3иnginx:alpine)، جيڪي انهن جي مواد جي چڪاس آهن؛ - سڀ ٽيمون (
RUN,CMD۽ ايئن.)؛ - SHA256 فائلن مان جيڪي شامل ڪيا ويا.
... ۽ اهڙي فائل مان چيڪسم (ٻيهر SHA256) وٺو. هي دستخط هر شي جيڪا وضاحت ڪري ٿي Docker تصوير جي مواد کي.
اچو ته واپس ڊراگرام ڏانهن وڃو ۽ واعدو ڪرڻ بدران اسين اهڙيون نشانيون استعمال ڪنداسين، i.e. نشانين سان تصويرون ٽيگ ڪريو.
ھاڻي، جڏھن ضروري آھي، مثال طور، ھڪڙي رليز کان ماسٽر تائين تبديلين کي ضم ڪرڻ لاءِ، اسان ڪري سگھون ٿا حقيقي ضم ڪرڻ جو ڪم: ان ۾ ھڪ مختلف سڃاڻپ ڪندڙ ھوندو، پر ساڳي دستخط. ساڳي سڃاڻپ ڪندڙ سان اسان تصوير کي پيداوار ۾ آڻينداسين.
نقصان اهو آهي ته هاڻي اهو طئي ڪرڻ ممڪن نه ٿيندو ته ڪهڙي قسم جي عزم کي پيداوار ڏانهن ڌڪيو ويو آهي - چيڪسم صرف هڪ طرفي ڪم ڪن ٿا. اهو مسئلو ميٽاداٽا سان گڏ هڪ اضافي پرت ذريعي حل ڪيو ويو آهي - مان توهان کي وڌيڪ بعد ۾ ٻڌائيندس.
ورف ۾ ٽيگنگ
werf ۾ اسان اڃا به اڳتي وڌيا آهيون ۽ تيار ڪري رهيا آهيون ورهايل تعمير هڪ ڪيش سان جيڪا هڪ مشين تي محفوظ نه آهي... تنهن ڪري، اسان ٻه قسم جون تصويرون ٺاهي رهيا آهيون، اسان انهن کي سڏين ٿا. اسٽيج и تصوير.
werf Git مخزن اسٽورن جي تعمير لاءِ مخصوص هدايتون جيڪي بيان ڪن ٿيون تعمير جي مختلف مرحلن (انسٽال ڪرڻ کان اڳ, انسٽال ڪريو, سيٽ اپ کان اڳ, سيٽ اپ ڪريو). اسان پهرين اسٽيج جي تصوير گڏ ڪريون ٿا هڪ دستخط سان جيڪو بيان ڪيو ويو آهي پهرين مرحلن جي چيڪسم. پوءِ اسان سورس ڪوڊ شامل ڪريون ٿا، نئين اسٽيج جي تصوير لاءِ اسان ان جي چيڪسم کي ڳڻون ٿا... اهي عمل سڀني مرحلن لاءِ ورجائجن ٿا، جنهن جي نتيجي ۾ اسان کي اسٽيج تصويرن جو هڪ سيٽ ملي ٿو. ان کان پوء اسان حتمي تصوير ٺاهيندا آهيون، جنهن ۾ ان جي اصليت بابت ميٽاداٽا پڻ شامل آهي. ۽ اسان هن تصوير کي مختلف طريقن سان ٽيگ ڪندا آهيون (تفصيل بعد ۾).
فرض ڪريو ان کان پوءِ هڪ نئون ڪمٽ ظاهر ٿئي ٿو جنهن ۾ صرف ايپليڪيشن ڪوڊ تبديل ڪيو ويو آهي. ڇا ٿيندو؟ ڪوڊ تبديلين لاء، هڪ پيچ ٺاهي ويندي ۽ هڪ نئين اسٽيج تصوير تيار ڪئي ويندي. ان جي دستخط کي پراڻي اسٽيج جي تصوير جي چيڪسم ۽ نئين پيچ جي طور تي طئي ڪيو ويندو. هن تصوير مان هڪ نئين فائنل تصوير ٺاهي ويندي. ساڳيو رويو ٻين مرحلن ۾ تبديلين سان ٿيندو.
اهڙيء طرح، اسٽيج تصويرون هڪ ڪيش آهن جيڪي ورهائي سگهجن ٿيون، ۽ اڳ ۾ ئي ٺاهيل تصويرون ڊاکر رجسٽري تي اپ لوڊ ڪيون ويون آهن.
رجسٽري جي صفائي
اسان انهن تہن کي ختم ڪرڻ جي باري ۾ نه ڳالهائي رهيا آهيون جيڪي ختم ٿيل ٽيگ کان پوءِ لٽڪي رهيون آهن - اهو خود ڊڪر رجسٽري جي هڪ معياري خصوصيت آهي. اسان هڪ اهڙي صورتحال جي باري ۾ ڳالهائي رهيا آهيون جڏهن ڪيترائي ڊاکر ٽيگ گڏ ٿين ٿا ۽ اسان سمجهون ٿا ته اسان کي هاڻي انهن مان ڪجهه جي ضرورت ناهي، پر اهي جڳهه وٺندا آهن (۽ / يا اسان ان لاءِ ادا ڪندا آهيون).
صفائي جون حڪمت عمليون ڇا آهن؟
- توهان صرف ڪجهه نه ٿا ڪري سگهو صاف نه ڪريو. ڪڏهن ڪڏهن اهو واقعي آسان هوندو آهي ٿورو ادا ڪرڻ بجاءِ اضافي جاءِ لاءِ ٽيگ جي وڏي پيچيدگي کي ختم ڪرڻ جي. پر اهو صرف هڪ خاص نقطي تائين ڪم ڪري ٿو.
- مڪمل ري سيٽ. جيڪڏهن توهان سڀني تصويرن کي حذف ڪريو ۽ صرف موجوده تصويرون کي CI سسٽم ۾ ٻيهر ٺاهي، هڪ مسئلو پيدا ٿي سگهي ٿي. جيڪڏهن ڪنٽينر کي پيداوار ۾ ٻيهر شروع ڪيو ويو آهي، هڪ نئين تصوير ان لاء لوڊ ڪئي ويندي - هڪ جيڪا اڃا تائين ڪنهن به آزمائشي نه ڪئي وئي آهي. هي ناقابل برداشت انفراسٽرڪچر جي خيال کي ماريندو آهي.
- نيري گرين. ھڪڙي رجسٽري اوور فلو ٿيڻ شروع ٿي - اسان تصويرن کي ٻئي ڏانھن اپلوڊ ڪيو. ساڳيو مسئلو جيئن پوئين طريقي ۾: توهان ڪهڙي نقطي تي رجسٽري کي صاف ڪري سگهو ٿا جيڪو اوور فلو ٿيڻ شروع ڪيو آهي؟
- وقت سان. 1 مهيني کان پراڻيون سڀ تصويرون ڊليٽ ڪريو؟ پر اتي ضرور هڪ خدمت هوندي جيڪا هڪ مهيني تائين اپڊيٽ نه ڪئي وئي آهي ...
- دستي طور تي اهو طئي ڪيو ته ڇا اڳ ۾ ئي ختم ڪري سگهجي ٿو.
اتي ٻه واقعي قابل عمل اختيار آھن: صاف نه ڪريو يا نيري-سائي + دستي طور تي ميلاپ. پوئين صورت ۾، اسان هيٺين بابت ڳالهائي رهيا آهيون: جڏهن توهان سمجهي رهيا آهيو ته اهو رجسٽري کي صاف ڪرڻ جو وقت آهي، توهان هڪ نئون ٺاهيو ۽ ان ۾ سڀني نئين تصويرون شامل ڪريو، مثال طور، هڪ مهيني. ۽ هڪ مهيني کان پوء، ڏسو ڪبرنيٽس ۾ ڪهڙا پوڊ اڃا تائين پراڻي رجسٽري استعمال ڪري رهيا آهن، ۽ انهن کي پڻ نئين رجسٽري ڏانهن منتقل ڪريو.
اسان ڇا ڪري آيا آهيون werf؟ اسان گڏ ڪريون ٿا:
- گٽ سر: سڀ ٽيگ، سڀ شاخون - فرض ڪيو ته اسان کي هر شيء جي ضرورت آهي جيڪا تصويرن ۾ گٽ ۾ ٽيگ ٿيل آهي (۽ جيڪڏهن نه، پوء اسان کي ان کي گٽ ۾ ئي ختم ڪرڻ جي ضرورت آهي)؛
- سڀئي پوڊ جيڪي هن وقت ڪبرنيٽس ڏانهن پمپ ڪيا ويا آهن؛
- پراڻي ReplicaSets (جيڪو تازو جاري ڪيو ويو هو)، ۽ اسان پڻ هيلم رليز کي اسڪين ڪرڻ ۽ اتي تازيون تصويرون چونڊڻ جو ارادو رکون ٿا.
... ۽ هن سيٽ مان هڪ وائيٽ لسٽ ٺاهيو - تصويرن جي هڪ فهرست جيڪا اسان حذف نه ڪنداسين. اسان باقي سڀ شيون صاف ڪريون ٿا، جنهن کان پوءِ اسين يتيم اسٽيج جون تصويرون ڳوليون ٿا ۽ انهن کي به حذف ڪريون ٿا.
اسٽيج کي ترتيب ڏيو
قابل اعتماد بيان
پهريون نقطو جنهن تي آئون ڌيان ڏيڻ چاهيان ٿو تعیناتي ۾ تازه ڪاري وسيلن جي ترتيب جو رول آئوٽ، اعلان ڪيو ويو آهي. اصل YAML دستاويز بيان ڪري ٿو Kubernetes وسيلن کي هميشه ڪلستر ۾ هلندڙ نتيجن کان بلڪل مختلف آهي. ڇاڪاڻ ته Kubernetes ترتيب ۾ شامل ڪري ٿو:
- سڃاڻپ ڪندڙ؛
- خدمت جي معلومات؛
- ڪيترائي ڊفالٽ قدر؛
- موجوده حيثيت سان سيڪشن؛
- داخلا ويب هِڪ جي حصي جي طور تي ڪيل تبديليون؛
- مختلف ڪنٽرولرز جي ڪم جو نتيجو (۽ شيڊولر).
تنهن ڪري، جڏهن هڪ نئين وسيلن جي جوڙجڪ ظاهر ٿئي ٿي (نئون(رهن ٿا). هن کي ڪرڻ لاء اسان کي مقابلو ڪرڻو پوندو نئون آخري لاڳو ڪيل ترتيب سان (آخري لاڳو) ۽ رول تي رهن ٿا حاصل ڪيل پيچ.
اهو طريقو سڏيو ويندو آهي 2-واٽ ملائڻ. اهو استعمال ڪيو ويندو آهي، مثال طور، هيلم ۾.
پڻ آهي 3-واٽ ملائڻ، جنهن ۾ فرق آهي:
- موازنہ ڪرڻ آخري لاڳو и نئون، اسان ڏسون ٿا ته ڇا ختم ڪيو ويو؛
- موازنہ ڪرڻ نئون и رهن ٿا، اسان ڏسون ٿا ته ڇا شامل ڪيو ويو آهي يا تبديل ڪيو ويو آهي؛
- مجموعو پيچ تي لاڳو ٿئي ٿو رهن ٿا.
اسان هيلم سان گڏ 1000+ ايپليڪيشنون ترتيب ڏيون ٿا، تنهنڪري اسان اصل ۾ 2-طريقه ضم سان گڏ رهندا آهيون. بهرحال، ان ۾ ڪيترائي مسئلا آهن جيڪي اسان اسان جي پيچ سان حل ڪيا آهن، جيڪي هيلم کي عام طور تي ڪم ڪرڻ ۾ مدد ڪن ٿيون.
حقيقي رول آئوٽ جي حالت
اسان جي سي آءِ سسٽم کان پوءِ ايندڙ واقعي جي بنياد تي ڪبرنيٽس لاءِ هڪ نئين ترتيب ٺاهي ٿي ، اهو ان کي استعمال لاءِ منتقل ڪري ٿو (لاڳو) هڪ ڪلستر ڏانهن - هيلم يا استعمال ڪندي kubectl apply. اڳيون، اڳ ۾ ئي بيان ڪيل N-way ضم ٿئي ٿو، جنهن تي Kubernetes API CI سسٽم جي منظوري سان جواب ڏئي ٿو، ۽ اهو ان جي استعمال ڪندڙ کي.
بهرحال، اتي هڪ وڏو مسئلو آهي: سڀ کان پوء ڪامياب ايپليڪيشن جو مطلب اهو ناهي ته ڪامياب رول آئوٽ. جيڪڏھن ڪبرنيٽس سمجھي ٿو ته ڪھڙين تبديلين کي لاڳو ڪرڻ جي ضرورت آھي ۽ ان کي لاڳو ڪيو وڃي، اسان اڃا تائين نه ٿا ڄاڻون ته نتيجو ڇا ٿيندو. مثال طور، فرنٽ اينڊ ۾ پوڊس کي اپڊيٽ ڪرڻ ۽ ٻيهر شروع ڪرڻ ڪامياب ٿي سگھي ٿو، پر پس منظر ۾ نه، ۽ اسان کي هلندڙ ايپليڪيشن تصويرن جا مختلف ورجن ملندا.
هر شي کي صحيح طريقي سان ڪرڻ لاءِ، هن اسڪيم کي هڪ اضافي لنڪ جي ضرورت آهي - هڪ خاص ٽريڪر جيڪو حاصل ڪندو اسٽيٽس جي معلومات Kubernetes API کان ۽ ان کي منتقل ڪري وڌيڪ تجزيي لاءِ شين جي حقيقي حالت جي. اسان گو ۾ هڪ اوپن سورس لائبريري ٺاهي. (ڏسو ان جو اعلان )، جيڪو هن مسئلي کي حل ڪري ٿو ۽ ورف ۾ ٺهيل آهي.
werf سطح تي هن ٽريڪٽر جي رويي کي تشريح استعمال ڪندي ترتيب ڏني وئي آهي جيڪي ترتيب ڏيڻ يا StatefulSets تي رکيل آهن. مکيه تشريح - fail-mode - سمجھي ٿو ھيٺين معنيٰ:
-
IgnoreAndContinueDeployProcess- اسان هن جزو کي رول آئوٽ ڪرڻ جي مسئلن کي نظر انداز ڪريون ٿا ۽ تعیناتي کي جاري رکون ٿا؛ -
FailWholeDeployProcessImmediately- هن جزو ۾ هڪ نقص تعیناتي جي عمل کي روڪي ٿو؛ -
HopeUntilEndOfDeployProcess- اسان کي اميد آهي ته هي جزو ڪم ڪرڻ جي آخر تائين ڪم ڪندو.
مثال طور، وسيلن ۽ تشريح جي قدرن جو هي ميلاپ fail-mode:
جڏهن اسان پهريون ڀيرو ڊيپلائي ڪيو ٿا، ڊيٽابيس (MongoDB) اڃا تائين تيار نه ٿي سگهي ٿي - ڊيپلائيمينٽ ناڪام ٿي وينديون. پر توھان انتظار ڪري سگھوٿا ان وقت لاءِ ان جي شروع ٿيڻ لاءِ، ۽ مقرري اڃا ٿيندي.
werf ۾ kubedog لاءِ ٻه وڌيڪ تشريحون آهن:
-
failures-allowed-per-replica- هر نقل لاءِ اجازت ڏنل فال جو تعداد؛ -
show-logs-until- ان لمحي کي منظم ڪري ٿو جيستائين werf ڏيکاري ٿو (stdout ۾) لاگز سڀني رول آئوٽ پوڊس مان. ڊفالٽ آهيPodIsReady(پيغام کي نظرانداز ڪرڻ لاءِ جيڪي شايد اسان نٿا چاهيون جڏهن ٽرئفڪ پوڊ تي اچڻ شروع ٿئي) پر قدر پڻ صحيح آهن:ControllerIsReadyиEndOfDeploy.
اسان کي مقرري کان ٻيو ڇا گهرجي؟
اڳ ۾ بيان ڪيل ٻن نقطن کان علاوه، اسان چاهيون ٿا:
- ڏسڻ لاگز - ۽ صرف ضروري آهن، ۽ هر شيء هڪ قطار ۾ نه؛
- ٽريڪ ترقي, ڇاڪاڻ ته جيڪڏهن نوڪري "خاموشيء سان" ڪيترن ئي منٽن لاء لڪي رهي آهي، اهو سمجهڻ ضروري آهي ته اتي ڇا ٿي رهيو آهي؛
- иметь خودڪار rollback صورت ۾ ڪجهه غلط ٿي ويو (۽ ان ڪري اهو ضروري آهي ته ڊيپلائيشن جي حقيقي صورتحال کي ڄاڻڻ لاء). رول آئوٽ ايٽمي هجڻ گهرجي: يا ته اهو آخر تائين وڃي ٿو، يا هر شي پنهنجي پوئين حالت ڏانهن موٽائي ٿي.
نتيجو
اسان لاءِ هڪ ڪمپني جي طور تي، ترسيل جي مختلف مرحلن تي سڀني بيان ڪيل نونسن کي لاڳو ڪرڻ (تعمير، شايع ڪرڻ، ترتيب ڏيڻ)، هڪ CI سسٽم ۽ افاديت ڪافي آهي. .
ھڪڙي نتيجي جي بدران:
werf جي مدد سان، اسان DevOps انجنيئرن لاءِ وڏي تعداد ۾ مسئلن کي حل ڪرڻ ۾ سٺي ترقي ڪئي آهي ۽ خوشي ٿيندي ته جيڪڏهن وسيع برادري گهٽ ۾ گهٽ هن افاديت کي عمل ۾ آزمائي. ان سان گڏ سٺو نتيجو حاصل ڪرڻ آسان ٿيندو.
وڊيوز ۽ سلائڊ
ڪارڪردگي کان وڊيو (~ 47 منٽ):
رپورٽ جي پيشڪش:
پي ايس
اسان جي بلاگ تي Kubernetes بابت ٻيون رپورٽون:
- «» (دمتري اسٽوليروف؛ 27 اپريل 2019 تي ”هڙتال“);
- «» (ايندري پولوفوف؛ 8 اپريل 2019 سينٽ هاءِ لوڊ++ تي);
- «» (دمتري اسٽوليروف؛ نومبر 8، 2018 HighLoad++ تي);
- «» (دمتري اسٽولياروف؛ 28 مئي 2018 تي RootConf);
- «» (دمتري اسٽوليروف؛ نومبر 7، 2017 HighLoad++ تي);
- «» (دمتري اسٽولياروف؛ 6 جون، 2017 تي RootConf).
جو ذريعو: www.habr.com