نوٽ. ترجمو: تازو اشاعت کان پوء GitOps ۾ پل ۽ پش طريقن بابت، اسان عام طور تي ھن ماڊل ۾ دلچسپي ڏٺو، پر ھن موضوع تي تمام گھٽ روسي ٻوليءَ جون اشاعتون ھيون (ھتي ھبري تي ڪو به نه آھي). تنهن ڪري، اسان توهان جي توجه لاء هڪ ٻئي مضمون جو ترجمو پيش ڪرڻ تي راضي آهيون - جيتوڻيڪ تقريبا هڪ سال اڳ! - Weaveworks مان، جنهن جي سر "GitOps" اصطلاح ٺاهي. متن بيان ڪري ٿو نقطه نظر جي جوهر ۽ موجوده کان اهم فرق.
هڪ سال اڳ اسان شايع ڪيو . ان کان پوءِ، اسان شيئر ڪيو ته ڪيئن Weaveworks ٽيم هڪ SaaS کي مڪمل طور تي ڪبرنيٽس جي بنياد تي شروع ڪيو ۽ ڪلائوڊ جي مقامي ماحول ۾ ترتيب ڏيڻ، انتظام ڪرڻ ۽ نگراني ڪرڻ لاءِ نسخي جي بهترين طريقن جو هڪ سيٽ تيار ڪيو.
مضمون مشهور ٿيو. ٻين ماڻهن GitOps بابت ڳالهائڻ شروع ڪيو ۽ نئين اوزار شايع ڪرڻ شروع ڪيو , , , , ۽ ايئن. اسان جي ويب سائيٽ تي ظاهر ٿيو اشاعت ۽ GitOps ڪيس استعمال ڪن ٿا. پر ڪجهه ماڻهو اڃا تائين سوال آهن. ڪيئن ماڊل روايتي هڪ کان مختلف آهي؟ ۽ مسلسل پهچائڻ ()؟ ان کي استعمال ڪرڻ ضروري آهي Kubernetes؟
اسان جلد ئي محسوس ڪيو ته هڪ نئين وضاحت جي ضرورت هئي، پيش ڪندي:
- مثالن ۽ ڪهاڻيون جو هڪ وڏو تعداد؛
- GitOps جي مخصوص وصف؛
- روايتي مسلسل پهچائڻ سان مقابلو.
هن مضمون ۾ اسان انهن سڀني موضوعن کي ڍڪڻ جي ڪوشش ڪئي آهي. اهو GitOps ۽ هڪ ڊولپر ۽ CI/CD نقطه نظر جو هڪ تازه ترين تعارف مهيا ڪري ٿو. اسان بنيادي طور تي ڪبرنيٽس تي ڌيان ڏيون ٿا، جيتوڻيڪ ماڊل کي عام ڪري سگهجي ٿو.
GitOps سان ملو
تصور ڪريو ايلس. هوءَ فيملي انشورنس هلائي ٿي، جيڪا پيش ڪري ٿي صحت، آٽو، گهر، ۽ سفري بيمه انهن ماڻهن لاءِ جيڪي پاڻ ۾ معاهدن جي اندر ۽ ٻاهر نڪرڻ ۾ مصروف آهن. هن جو ڪاروبار هڪ پاسي واري منصوبي جي طور تي شروع ٿيو جڏهن ايلس هڪ بينڪ ۾ ڊيٽا سائنسدان جي حيثيت سان ڪم ڪري رهي هئي. هڪ ڏينهن هن محسوس ڪيو ته هوءَ ڊيٽا کي وڌيڪ موثر انداز ۾ تجزيو ڪرڻ ۽ انشورنس پيڪيجز ٺاهڻ لاءِ جديد ڪمپيوٽر الگورٿم استعمال ڪري سگهي ٿي. سيڙپڪارن منصوبي جي مالي مدد ڪئي، ۽ هاڻي هن جي ڪمپني هڪ سال ۾ 20 ملين ڊالر کان وڌيڪ آڻيندي آهي ۽ تيزيء سان وڌي رهي آهي. هن وقت، اهو 180 ماڻهن کي مختلف عهدن تي ملازمت ڪري ٿو. ھن ۾ ھڪڙي ٽيڪنالاجي ٽيم شامل آھي جيڪا ترقي ڪري ٿي، ويب سائيٽ، ڊيٽابيس کي برقرار رکي ٿي، ۽ ڪسٽمر بنياد جو تجزيو ڪري ٿي. 60 ماڻهن جي ٽيم باب جي اڳواڻي ۾ آهي، ڪمپني جي ٽيڪنيڪل ڊائريڪٽر.
باب جي ٽيم بادل ۾ پيداوار سسٽم کي ترتيب ڏئي ٿي. انهن جون بنيادي ايپليڪيشنون GKE تي هلن ٿيون، گوگل ڪلائوڊ تي ڪبرنيٽس جو فائدو وٺي. ان کان سواء، اهي مختلف ڊيٽا ۽ تجزياتي اوزار استعمال ڪندا آهن انهن جي ڪم ۾.
خانداني انشورنس ڪنٽينر استعمال ڪرڻ لاءِ تيار نه ڪيو، پر ڊاڪر جوش ۾ پڪڙيو ويو. ڪمپني جلد ئي دريافت ڪئي ته GKE نئين خاصيتن کي جانچڻ لاءِ ڪلسٽرز کي ترتيب ڏيڻ آسان بڻائي ڇڏيو. جينڪنز CI ۽ Quay لاءِ شامل ڪيا ويا ڪنٽينر رجسٽري کي منظم ڪرڻ لاءِ، جينڪنز لاءِ لکتون لکيون ويون جيڪي نئين ڪنٽينرز ۽ ترتيبن کي GKE ڏانهن ڌڪي ڇڏيون.
ڪجهه وقت گذري ويو. ايلس ۽ باب پنهنجي چونڊيل طريقي جي ڪارڪردگي ۽ ڪاروبار تي ان جي اثر کان مايوس ٿي ويا. ڪنٽينرز جي تعارف سان پيداواري صلاحيت ايتري بهتر نه ٿي جيتري ٽيم کي اميد هئي. ڪڏهن ڪڏهن نوڪريون ٽوڙي وينديون هيون، ۽ اهو واضح ناهي ته ڪوڊ تبديلين جو الزام هو. اهو پڻ ثابت ٿيو ته ترتيب جي تبديلين کي ٽريڪ ڪرڻ ڏکيو آهي. گهڻو ڪري اهو ضروري هو ته هڪ نئون ڪلستر ٺاهي ۽ ايپليڪيشنن کي ان ڏانهن منتقل ڪيو وڃي، ڇاڪاڻ ته اهو سسٽم جي گندگي کي ختم ڪرڻ جو آسان طريقو هو. ايلس کي ڊپ هو ته صورتحال خراب ٿي ويندي جيئن ايپليڪيشن ترقي ڪئي (ان کان علاوه، مشين سکيا تي ٻڌل هڪ نئون منصوبو ٺاهي رهيو هو). باب اڪثر ڪم کي خودڪار ڪري چڪو هو ۽ سمجھي نه سگهيو ڇو ته پائپ لائن اڃا تائين غير مستحڪم آهي، چڱي طرح ماپ نه ڪيو، ۽ وقتي طور تي دستي مداخلت جي ضرورت آهي؟
پوءِ اھي سکيو GitOps بابت. اهو فيصلو اهو نڪتو ته انهن کي اعتماد سان اڳتي وڌڻ جي ضرورت آهي.
ايلس ۽ باب Git، DevOps، ۽ انفراسٽرڪچر بابت ٻڌي رهيا آهن جيئن ڪوڊ ورڪ فلوز سالن تائين. GitOps جي باري ۾ جيڪا منفرد ڳالهه آهي اها اها آهي ته اهو ڪبرنيٽس جي حوالي سان انهن خيالن کي لاڳو ڪرڻ لاءِ بهترين طريقن جو هڪ سيٽ آڻيندو آهي - ٻنهي حتمي ۽ معياري. هي موضوع ۾ شامل آهن .
خانداني انشورنس GitOps کي لاڳو ڪرڻ جو فيصلو ڪري ٿو. ڪمپني وٽ هاڻي هڪ خودڪار آپريشن ماڊل آهي جيڪو ڪبرنيٽس ۽ گڏ ڪرڻ سان مطابقت رکي ٿو رفتار سان گڏ استحڪامڇاڪاڻ ته اهي:
- ڏٺائين ته ٽيم جي پيداوار ٻيڻو ٿي وئي بغير ڪنهن چريو ٿيڻ جي؛
- اسڪرپٽ پيش ڪرڻ بند ڪيو. ان جي بدران، اهي هاڻي نئين خاصيتن تي ڌيان ڏئي سگهن ٿا ۽ انجنيئرنگ طريقن کي بهتر بڻائي سگهن ٿا - مثال طور، ڪينري رول آئوٽ متعارف ڪرائڻ ۽ جانچ کي بهتر ڪرڻ؛
- اسان ترتيب ڏيڻ واري عمل کي بهتر ڪيو آهي ته جيئن اهو گهٽ ۾ گهٽ خراب ٿئي؛
- دستي مداخلت کان سواء جزوي ناڪامي کان پوء تعیناتي بحال ڪرڻ جو موقعو مليو؛
- خريد ڪيل استعمالоترسيل نظام ۾ وڌيڪ اعتماد. ايلس ۽ باب دريافت ڪيو ته اهي ٽيم کي ورهائي سگهن ٿيون microservice ٽيمن ۾ متوازي ڪم ڪندي؛
- هر گروپ جي ڪوششن ذريعي هر روز پروجيڪٽ ۾ 30-50 تبديليون ڪري سگهن ٿا ۽ نئين ٽيڪنالاجي جي ڪوشش ڪري سگهن ٿا؛
- پروجيڪٽ ڏانهن نون ڊولپرز کي راغب ڪرڻ آسان آهي، جن کي ڪجهه ڪلاڪن اندر پل درخواستون استعمال ڪندي پيداوار ۾ تازه ڪاريون آڻڻ جو موقعو آهي؛
- آساني سان آڊٽ پاس ڪريو SOC2 جي فريم ورڪ اندر (محفوظ ڊيٽا جي انتظام جي ضرورتن سان خدمت فراهم ڪندڙن جي تعميل لاءِ؛ وڌيڪ پڙهو، مثال طور، - لڳ ڀڳ ترجمو.).
ڇا ٿيو؟
GitOps ٻه شيون آهن:
- ڪبرنيٽس ۽ بادل جي اصلي لاءِ آپريشنل ماڊل. اهو ڪنٽينر ٿيل ڪلسٽرز ۽ ايپليڪيشنن کي ترتيب ڏيڻ، انتظام ڪرڻ ۽ نگراني ڪرڻ لاءِ بهترين طريقن جو هڪ سيٽ مهيا ڪري ٿو. شڪل ۾ خوبصورت تعريف от :
- ڊولپر-سينٽرڪ ايپليڪيشن مئنيجمينٽ ماحول ٺاهڻ جو رستو. اسان Git ورڪ فلو ٻنهي عملن ۽ ترقي تي لاڳو ڪريون ٿا. مهرباني ڪري نوٽ ڪريو ته اهو صرف Git push بابت ناهي، پر CI/CD ۽ UI/UX ٽولز جي پوري سيٽ کي منظم ڪرڻ بابت.
Git جي باري ۾ چند لفظ
جيڪڏهن توهان ورزن ڪنٽرول سسٽم ۽ Git-based ورڪ فلو کان واقف نه آهيو، اسان انهن جي باري ۾ سکڻ جي سفارش ڪريون ٿا. شاخن سان ڪم ڪرڻ ۽ درخواستن کي ڇڪڻ لڳي سگھي ٿو ڪارو جادو وانگر، پر فائدا ڪوشش جي قابل آھن. هتي شروع ڪرڻ.
ڪبرنيٽس ڪيئن ڪم ڪري ٿو
اسان جي ڪهاڻي ۾، ايلس ۽ باب ڪجهه دير تائين ڪبرنيٽس سان ڪم ڪرڻ کانپوءِ GitOps ڏانهن رخ ڪيو. درحقيقت، GitOps ڪبرنيٽس سان ويجھو لاڳاپيل آهي - اهو هڪ آپريشنل ماڊل آهي انفراسٽرڪچر ۽ ايپليڪيشنن لاءِ ڪبرنيٽس جي بنياد تي.
Kubernetes صارفين کي ڇا ڏئي ٿو؟
هتي ڪجهه اهم خاصيتون آهن:
- Kubernetes ماڊل ۾، سڀڪنھن شيء کي declarative صورت ۾ بيان ڪري سگهجي ٿو.
- Kubernetes API سرور هن اعلان کي ان پٽ طور وٺي ٿو ۽ پوءِ مسلسل ڪوشش ڪري ٿو ڪلستر کي بيان ۾ بيان ڪيل رياست ۾.
- بيانن کي بيان ڪرڻ ۽ منظم ڪرڻ لاء ڪافي آهن مختلف قسم جي ڪم لوڊ - "ايپليڪيشنون."
- نتيجي طور، ايپليڪيشن ۽ ڪلستر ۾ تبديلين جي ڪري ٿي سگھي ٿي:
- ڪنٽينر تصويرن ۾ تبديليون؛
- بيان ڪيل وضاحتن ۾ تبديليون؛
- ماحول ۾ غلطيون - مثال طور، ڪنٽينر حادثا.
ڪبرنيٽس جي عظيم ڪنورجنسي صلاحيتون
جڏهن ڪو ايڊمنسٽريٽر ڪنفيگريشن ۾ تبديليون ڪندو ته ڪبرنيٽس آرڪيسٽرٽر ان کي ڪلسٽر تي لاڳو ڪندو جيستائين ان جي حالت آهي نئين ترتيب جي ويجهو نه ايندي. هي ماڊل ڪنهن به ڪبرنيٽس ريسورس لاءِ ڪم ڪري ٿو ۽ ڪسٽم ريسورس ڊيفينشنز (CRDs) سان وسعت وارو آهي. تنهن ڪري، ڪبرنيٽس جي جوڙجڪ هيٺ ڏنل شاندار ملڪيت آهن:
- خودڪار: Kubernetes تازه ڪاريون هڪ ميکانيزم مهيا ڪن ٿيون جيڪو خودڪار طريقي سان تبديلين کي لاڳو ڪرڻ جي عمل کي شاندار ۽ بروقت انداز ۾.
- ڪنورجينس: Kubernetes ڪامياب ٿيڻ تائين تازه ڪاري جي ڪوشش جاري رکندي.
- بي ايماني: ڪنورجينس جي بار بار ايپليڪيشنن کي ساڳيو نتيجو ڏئي ٿو.
- مقرري: جڏهن وسيلا ڪافي آهن، تازه ڪاري ڪلستر جي حالت صرف گهربل رياست تي منحصر آهي.
GitOps ڪيئن ڪم ڪري ٿو
اسان Kubernetes جي باري ۾ ڪافي سکيو آھي وضاحت ڪرڻ لاءِ ته GitOps ڪيئن ڪم ڪري ٿو.
اچو ته خانداني انشورنس جي مائڪرو سروسز ٽيمن ڏانهن موٽون. انهن کي عام طور تي ڇا ڪرڻو آهي؟ هيٺ ڏنل فهرست ڏسو (جيڪڏهن ان ۾ ڪا به شيءِ عجيب يا اڻ واقف لڳي ٿي، ته مهرباني ڪري تنقيد ڪرڻ کان پاسو ڪريو ۽ اسان سان گڏ رهو). اهي صرف مثال آهن جينکنز جي بنياد تي ڪم فلو. ٻيا ڪيترائي عمل آھن جڏھن ٻين اوزارن سان ڪم ڪري رھيا آھن.
بنيادي شيء اها آهي ته اسان ڏسون ٿا ته هر تازه ڪاري ترتيب واري فائلن ۽ Git مخزن جي تبديلين سان ختم ٿئي ٿي. Git ۾ اهي تبديليون "GitOps آپريٽر" کي ڪلستر کي اپڊيٽ ڪرڻ جو سبب بڻائين ٿا:
1. ڪم ڪرڻ جو عمل: "جينڪنز تعمير - ماسٽر برانچ».
ڪم جي فهرست:
- جينڪنز ٽيگ ٿيل تصويرن کي Quay ڏانهن ڌڪي ٿو.
- جينڪنز ترتيب ۽ هيلم چارٽس کي ماسٽر اسٽوريج بالٽ ڏانهن ڌڪي ٿو.
- ڪلائوڊ فنڪشن ڪاپي ڪري ٿو ترتيب ۽ چارٽ ماسٽر اسٽوريج بالٽ کان ماسٽر گٽ مخزن ڏانهن؛
- GitOps آپريٽر ڪلستر کي اپڊيٽ ڪري ٿو.
2. جينڪنز تعمير - ڇڏڻ يا گرم فڪس برانچ:
- جينڪنز اڻ ٽيگ ٿيل تصويرن کي Quay ڏانهن ڌڪي ٿو.
- جينڪنز ترتيب ۽ هيلم چارٽس کي اسٽيجنگ اسٽوريج بالٽ ڏانهن ڌڪي ٿو.
- ڪلائوڊ فنڪشن نقل ڪري ٿو ترتيب ۽ چارٽ کي اسٽيجنگ اسٽوريج بالٽ کان اسٽيجنگ گٽ مخزن تائين؛
- GitOps آپريٽر ڪلستر کي اپڊيٽ ڪري ٿو.
3. جينڪنز تعمير - ترقي يا خصوصيت شاخ:
- جينڪنز اڻ ٽيگ ٿيل تصويرن کي Quay ڏانهن ڌڪي ٿو.
- جينڪنز ڊولپمينٽ اسٽوريج بالٽ ۾ ترتيب ۽ هيلم چارٽس کي دٻايو؛
- ڪلائوڊ فنڪشن ڊولپمينٽ اسٽوريج بالٽ کان ڊولپمينٽ گيٽ مخزن تائين ترتيب ۽ چارٽ کي نقل ڪري ٿو.
- GitOps آپريٽر ڪلستر کي اپڊيٽ ڪري ٿو.
4. نئون ڪلائنٽ شامل ڪرڻ:
- مئنيجر يا ايڊمنسٽريٽر (LCM/ops) شروعاتي طور تي نيٽ ورڪ لوڊ بيلنسرز (NLBs) کي ترتيب ڏيڻ ۽ ترتيب ڏيڻ لاءِ Gradle کي سڏي ٿو؛
- LCM/ops تازه ڪاري لاءِ ڊيپلائيمينٽ تيار ڪرڻ لاءِ نئين ترتيب ڏئي ٿو.
- GitOps آپريٽر ڪلستر کي اپڊيٽ ڪري ٿو.
GitOps جي مختصر وضاحت
- هر ماحول لاءِ بياني وضاحتن کي استعمال ڪندي پوري سسٽم جي گهربل حالت بيان ڪريو (اسان جي ڪهاڻي ۾، باب جي ٽيم گٽ ۾ پوري سسٽم جي تشڪيل کي بيان ڪري ٿي).
- Git مخزن سڄي سسٽم جي گهربل رياست جي حوالي سان سچائي جو واحد ذريعو آهي.
- مطلوب رياست ۾ سڀ تبديليون ڪيون وينديون آهن گٽ ۾ ڪمنٽس ذريعي.
- سڀ گهربل ڪلسٽر پيٽرولر پڻ ڪلسٽر ۾ ئي قابل مشاهدو آهن. هن طريقي سان اسان اهو طئي ڪري سگهون ٿا ته ڇا اهي هڪجهڙائي رکن ٿا ٺهڪندڙ) يا اختلاف (مختلف، ڌار ٿيڻ) مطلوب ۽ مشاهدو رياستون.
- جيڪڏهن گهربل ۽ مشاهدو رياستون مختلف آهن، پوء:
- اتي هڪ ڪنورجنسي ميڪانيزم آهي جيڪو جلدي يا بعد ۾ خودڪار طريقي سان ٽارگيٽ ۽ مشاهدو رياستن کي هم وقت سازي ڪري ٿو. ڪلستر جي اندر، ڪبرنيٽس اهو ڪندو آهي.
- اهو عمل فوري طور تي شروع ٿئي ٿو "تبديلي انجام" جي خبرداري سان.
- ڪجھ وقت جي ترتيب واري عرصي کان پوء، "مختلف" الرٽ موڪلي سگھجي ٿو جيڪڏھن رياستون مختلف آھن.
- هن طريقي سان، گٽ ۾ سڀ ڪمن جو سبب ڪلستر کي تصديق ڪندڙ ۽ قابل ذڪر تازه ڪاريون.
- رولبڪ اڳئين مطلوب رياست ڏانهن ڪنورجنسي آهي.
- اتفاق حتمي آهي. ان جي موجودگي جو اشارو آهي:
- وقت جي هڪ خاص مدت لاء ڪو به مختلف الارٽس.
- "converged" خبردار (مثال طور webhook، Git writeback واقعي).
اختلاف ڇا آهي؟
اچو ته ٻيهر ورجائي: سڀ گهربل ڪلستر جا خاصيتون ڪلستر ۾ ئي مشاهدو ٿيڻ گهرجن.
اختلاف جا ڪجهه مثال:
- Git ۾ شاخن کي ضم ڪرڻ جي ڪري ترتيب واري فائل ۾ تبديلي.
- GUI ڪلائنٽ پاران ٺاهيل Git ڪمٽ جي ڪري ترتيب واري فائل ۾ تبديلي.
- Git ۾ پي آر جي ڪري گهربل رياست ۾ گھڻن تبديلين بعد ڪنٽينر جي تصوير ۽ ترتيب جي تبديلين جي تعمير ڪندي.
- ھڪڙي غلطي جي ڪري ڪلستر جي حالت ۾ تبديلي، وسيلن جي تڪرار جي نتيجي ۾ "خراب رويي"، يا صرف اصل حالت کان بي ترتيب انحراف.
convergence جو ميکانيزم ڇا آهي؟
ڪجھ مثال:
- ڪنٽينرز ۽ ڪلسٽرز لاءِ، ڪنورجنسي ميڪانيزم ڪبرنيٽس پاران مهيا ڪيل آهي.
- ساڳيو ميکانيزم ڪبرنيٽس تي ٻڌل ايپليڪيشنن ۽ ڊزائينز کي منظم ڪرڻ لاءِ استعمال ڪري سگھجي ٿو (جهڙوڪ Istio ۽ Kubeflow).
- Kubernetes، تصويري مخزن ۽ Git جي وچ ۾ آپريشنل رابطي کي منظم ڪرڻ لاء هڪ ميکانيزم مهيا ڪري ٿو ، جيڪو حصو آهي .
- بنيادي مشينن لاء، ڪنورجنسي ميڪانيزم لازمي ۽ خودمختيار هجڻ گهرجي. اسان جي پنهنجي تجربي مان اهو چئي سگهون ٿا هن تعريف جي ويجهو، پر اڃا تائين انساني ڪنٽرول جي ضرورت آهي. انهي لحاظ سان، GitOps انفراسٹرڪچر جي روايت کي ڪوڊ جي طور تي وڌايو.
GitOps Git کي ڪبرنيٽس جي شاندار ڪنورجنسي انجڻ سان گڏ ڪري ٿو استحصال لاءِ ماڊل مهيا ڪرڻ لاءِ.
GitOps اسان کي چوڻ جي اجازت ڏئي ٿو: صرف اھي سسٽم جيڪي بيان ڪري سگھجن ٿا ۽ مشاهدو ڪري سگھجن ٿا خودڪار ۽ ڪنٽرول ٿي سگھن ٿا.
GitOps جو مقصد آھي پوري بادل جي اصلي اسٽيڪ لاءِ (مثال طور، Terraform، وغيره)
GitOps صرف ڪبرنيٽس ناهي. اسان چاهيون ٿا ته سڄو نظام اعلانيه طور تي هلائي وڃي ۽ ڪنورجنس استعمال ڪيو وڃي. سڄي سسٽم مان اسان جو مطلب آهي ماحوليات جو مجموعو جيڪو ڪبرنيٽس سان ڪم ڪري ٿو - مثال طور، "dev cluster 1"، "production"، وغيره. هر ماحول ۾ مشينون، ڪلسٽر، ايپليڪيشنون، گڏوگڏ ٻاهرين خدمتن لاءِ انٽرفيس شامل آهن جيڪي ڊيٽا مهيا ڪن ٿيون، نگراني ۽ وغيره
نوٽ ڪريو ته هن معاملي ۾ بوٽ اسٽريپنگ مسئلي لاءِ Terraform ڪيترو اهم آهي. ڪبرنيٽس کي ڪنهن جاءِ تي لڳايو وڃي ٿو، ۽ Terraform استعمال ڪرڻ جو مطلب آهي ته اسان ساڳيو GitOps ورڪ فلوز لاڳو ڪري سگهون ٿا ڪنٽرول پرت ٺاهڻ لاءِ جيڪا ڪبرنيٽس ۽ ايپليڪيشنن کي هيٺ ڪري ٿي. هي هڪ مفيد بهترين مشق آهي.
ڪبرنيٽس جي چوٽي تي پرتن تي GitOps تصورات کي لاڳو ڪرڻ تي مضبوط توجه آهي. هن وقت، GitOps قسم جا حل آهن Istio، Helm، Ksonnet، OpenFaaS ۽ Kubeflow لاءِ، گڏوگڏ، مثال طور، پلومي لاءِ، جيڪي ڪلائوڊ اصلي لاءِ ايپليڪيشنون ٺاهڻ لاءِ هڪ پرت ٺاهيندا آهن.
Kubernetes CI/CD: ٻين طريقن سان GitOps جو مقابلو ڪرڻ
جيئن چيو ويو آهي، GitOps ٻه شيون آهن:
- Kubernetes ۽ ڪلائوڊ اصلي لاءِ آپريٽنگ ماڊل مٿي بيان ڪيو ويو آهي.
- ڊولپر-مرڪز ايپليڪيشن مئنيجمينٽ ماحول جو رستو.
گھڻن لاءِ، GitOps بنيادي طور تي ھڪڙو ڪم فلو آھي Git pushes تي ٻڌل آھي. اسان هن کي پڻ پسند ڪريون ٿا. پر اهو سڀ ڪجهه ناهي: اچو ته هاڻي ڏسو CI/CD پائپ لائنز.
GitOps Kubernetes لاءِ مسلسل ڊيپلائيشن (CD) کي قابل بڻائي ٿو
GitOps پيش ڪري ٿو هڪ مسلسل تعیناتي ميڪانيزم جيڪو الڳ "تعميراتي انتظاماتي نظام" جي ضرورت کي ختم ڪري ٿو. ڪبرنيٽس توهان لاءِ سڀ ڪم ڪندو آهي.
- اپليڪيشن کي اپڊيٽ ڪرڻ جي ضرورت آهي Git ۾ اپڊيٽ ڪرڻ. هي هڪ ٽرانزيڪشنل اپڊيٽ آهي مطلوب رياست ڏانهن. "تعظيم" وري ڪلستر جي اندر ڪيو ويندو آهي ڪبرنيٽس طرفان پاڻ کي اپڊيٽ ڪيل تفصيل جي بنياد تي.
- فطرت جي ڪري ڪبرنيٽس ڪيئن ڪم ڪري ٿو، اهي تازه ڪاريون متضاد آهن. هي هڪ ميکانيزم مهيا ڪري ٿو مسلسل لڳائڻ لاءِ جنهن ۾ سڀ تازه ڪاريون ايٽمي آهن.
- نوٽ: هڪ GitOps آپريٽر پيش ڪري ٿو جيڪو Git ۽ Kubernetes کي ضم ڪري ٿو ۽ CD کي ڪلستر جي گهربل ۽ موجوده حالت کي ترتيب ڏيڻ جي اجازت ڏئي ٿو.
بغير ڪيبيڪل ۽ اسڪرپٽ
توھان کي پنھنجي ڪلستر کي اپڊيٽ ڪرڻ لاءِ ڪبيڪٽل استعمال ڪرڻ کان پاسو ڪرڻ گھرجي، ۽ خاص طور تي اسڪرپٽ استعمال ڪرڻ کان پاسو ڪرڻ گھرجي گروپ ڪبيڪٽل حڪمن کي. ان جي بدران، GitOps پائپ لائن سان، هڪ صارف پنهنجي ڪبرنيٽس ڪلستر کي Git ذريعي اپڊيٽ ڪري سگهي ٿو.
فائدا شامل آهن:
- ساڄو. تازه ڪارين جو ھڪڙو گروپ لاڳو ٿي سگھي ٿو، تبديل ٿي سگھي ٿو ۽ آخرڪار تصديق ٿيل آھي، اسان کي ايٽمي ٺاھڻ جي مقصد جي ويجھو آڻيندي. ان جي ابتڙ، اسڪرپٽ استعمال ڪندي ڪنورجن جي ڪا به گارنٽي فراهم نه ڪندو آهي (هن تي وڌيڪ هيٺ ڏنل).
- حفاظت. ڪيلي هاء ٽاور: "توهان جي ڪبرنيٽس ڪلستر تائين رسائي کي محدود ڪريو آٽوميشن اوزار ۽ منتظمين جيڪي ان کي ڊيبگ ڪرڻ يا برقرار رکڻ جا ذميوار آهن." پڻ ڏسو حفاظت ۽ ٽيڪنيڪل وضاحتن جي تعميل بابت، گڏو گڏ بي پرواهه طور تي لکيل جينڪنز اسڪرپٽ مان سندون چوري ڪندي.
- استعمال ڪندڙ تجربو. Kubectl ڪبرنيٽس اعتراض جي ماڊل جي ميڪيڪل کي ظاهر ڪري ٿو، جيڪي ڪافي پيچيده آهن. مثالي طور، صارفين کي سسٽم سان رابطي جي اعلي سطح تي تجريد ڪرڻ گهرجي. هتي مان ٻيهر حوالو ڪندس ڪليسي ۽ ڏسڻ جي صلاح ڏيندس .
CI ۽ CD جي وچ ۾ فرق
GitOps موجوده CI / CD ماڊل کي بهتر بڻائي ٿو.
هڪ جديد CI سرور هڪ آرڪيسٽريشن اوزار آهي. خاص طور تي، اهو هڪ اوزار آهي آرڪيسٽريٽنگ CI پائپ لائنز لاءِ. انهن ۾ شامل آهن تعمير، ٽيسٽ، ٽرڪن ۾ ضم ڪرڻ، وغيره. CI سرورز پيچيده گھڻن قدمن واري پائپ لائنن جي انتظام کي خودڪار ڪن ٿا. هڪ عام آزمائش آهي ڪبرنيٽس اپڊيٽس جو هڪ سيٽ اسڪرپٽ ڪرڻ ۽ ان کي ڪلستر ۾ تبديلين کي زور ڏيڻ لاءِ پائپ لائن جي حصي طور هلائڻ. درحقيقت، هي اهو آهي جيڪو ڪيترن ئي ماهرن کي ڪندا آهن. بهرحال، اهو بهتر ناهي، ۽ هتي آهي ڇو.
CI کي استعمال ڪيو وڃي ٿو تازه ڪارين کي ٽرڪن ڏانهن ڌڪڻ لاءِ، ۽ ڪبرنيٽس ڪلستر کي پاڻ کي تبديل ڪرڻ گهرجي انهن تازه ڪارين جي بنياد تي سي ڊي کي اندروني طور تي منظم ڪرڻ لاءِ. اسان ان کي سڏيندا آهيون CI push ماڊل جي برعڪس. سي ڊي جو حصو آهي هلندڙ وقت آرڪيسٽريشن.
ڇو سي آءِ سرورز کي ڪبرنيٽس ۾ سڌو تازه ڪارين ذريعي سي ڊيز نه ڪرڻ گهرجي
CI نوڪرين جي سيٽ جي طور تي Kubernetes ڏانهن سڌي طرح تازه ڪاريون ترتيب ڏيڻ لاءِ CI سرور استعمال نه ڪريو. هي آهي مخالف نمونو جنهن بابت اسان ڳالهائي رهيا آهيون توهان جي بلاگ تي.
اچو ته ايلس ۽ باب ڏانهن واپس وڃو.
انهن کي ڪهڙا مسئلا درپيش هئا؟ باب جو سي آءِ سرور تبديلين کي ڪلسٽر ۾ لاڳو ڪري ٿو، پر جيڪڏهن اهو عمل ۾ حادثو ٿئي ٿو، باب کي خبر نه پوندي ته ڪلسٽر ڪهڙي حالت ۾ آهي (يا هجڻ گهرجي) يا ان کي ڪيئن درست ڪجي. اهو ئي سچ آهي ڪاميابي جي صورت ۾.
اچو ته فرض ڪريو ته باب جي ٽيم هڪ نئين تصوير ٺاهي ۽ پوء تصوير کي ترتيب ڏيڻ لاء انهن جي ترتيبن کي پيچ ڪيو (سڀني CI پائپ لائن کان).
جيڪڏهن تصوير عام طور تي ٺاهي ٿي، پر پائپ لائن ناڪام ٿئي ٿي، ٽيم کي معلوم ڪرڻو پوندو:
- ڇا اپڊيٽ ختم ٿي وئي آهي؟
- ڇا اسان نئين تعمير شروع ڪري رهيا آهيون؟ ڇا اهو غير ضروري ضمني اثرات کي ڏسندو - ساڳئي غير متحرڪ تصوير جي ٻن تعميرن جي امڪان سان؟
- ڇا اسان کي تعمير ڪرڻ کان اڳ ايندڙ اپڊيٽ جو انتظار ڪرڻ گهرجي؟
- ڇا واقعي غلط ٿيو؟ ڪهڙن قدمن کي بار بار ڪرڻ جي ضرورت آهي (۽ ڪهڙن کي ورجائڻ لاءِ محفوظ آهن)؟
Git جي بنياد تي ڪم فلو قائم ڪرڻ جي ضمانت نه آهي ته باب جي ٽيم انهن مسئلن کي منهن نه ڏيندو. اهي اڃا به غلطي ڪري سگهن ٿا ڪمٽ پش، ٽيگ، يا ڪجهه ٻيو پيٽرول؛ بهرحال، اهو طريقو اڃا به تمام گهڻو يا ڪجهه به نه هجڻ جي واضح طريقي سان آهي.
اختصار ڪرڻ لاءِ، هتي آهي ڇو سي آءِ سرورز کي سي ڊي سان ڊيل نه ڪرڻ گهرجي:
- تازه ڪاري اسڪرپٽ هميشه مقرر نه هوندا آهن؛ انهن ۾ غلطي ڪرڻ آسان آهي.
- CI سرورز بيان ڪندڙ ڪلستر ماڊل سان گڏ نه ٿا ڪن.
- اهو ڏکيو آهي idmpotency جي ضمانت. صارفين کي سسٽم جي گہرے سيمينڪ کي سمجهڻ گهرجي.
- اهو هڪ جزوي ناڪامي کان بحال ڪرڻ وڌيڪ ڏکيو آهي.
Helm بابت نوٽ: جيڪڏهن توهان Helm استعمال ڪرڻ چاهيو ٿا، اسان ان کي GitOps آپريٽر سان گڏ ڪرڻ جي صلاح ڏيون ٿا جهڙوڪ . هي همراه کي يقيني بڻائڻ ۾ مدد ڪندو. هيلم بذات خود نه تعيناتي آهي ۽ نه ايٽمي.
ڪبرنيٽس لاءِ مسلسل ترسيل کي لاڳو ڪرڻ جو بهترين طريقو GitOps
ايلس ۽ باب جي ٽيم GitOps کي لاڳو ڪري ٿي ۽ دريافت ڪري ٿو ته اهو سافٽ ويئر پروڊڪٽس سان ڪم ڪرڻ، اعلي ڪارڪردگي ۽ استحڪام کي برقرار رکڻ تمام آسان ٿي چڪو آهي. اچو ته هن مضمون کي هڪ مثال سان ختم ڪريون ته انهن جو نئون طريقو ڪهڙو نظر اچي ٿو. ذهن ۾ رکو ته اسان گهڻو ڪري ايپليڪيشنن ۽ خدمتن بابت ڳالهائي رهيا آهيون، پر GitOps استعمال ڪري سگھجن ٿيون پوري پليٽ فارم کي منظم ڪرڻ لاءِ.
Kubernetes لاء آپريٽنگ ماڊل
هيٺ ڏنل خاڪو ڏسو. اهو پيش ڪري ٿو Git ۽ ڪنٽينر تصويري مخزن کي ٻن ترتيب ڏنل لائف سائيڪلن لاءِ گڏيل وسيلن جي طور تي:
- هڪ مسلسل انضمام پائپ لائن جيڪا پڙهي ۽ لکندي فائلن کي Git ۽ تازه ڪاري ڪري سگهي ٿو ڪنٽينر تصويرن جي مخزن کي.
- هڪ رن ٽائم GitOps پائپ لائن جيڪا ترتيب ڏيڻ کي گڏ ڪري ٿي انتظام ۽ مشاهدي سان. اهو Git ڏانهن فائلون پڙهي ۽ لکي ٿو ۽ ڪنٽينر تصويرون ڊائون لوڊ ڪري سگهي ٿو.
مکيه نتيجا ڇا آهن؟
- خدشات جي جدائي: مهرباني ڪري نوٽ ڪريو ته ٻئي پائپ لائنون صرف Git يا تصويري مخزن کي تازه ڪاري ڪندي ڳالهائي سگهن ٿيون. ٻين لفظن ۾، CI ۽ رن ٽائم ماحول جي وچ ۾ هڪ فائر وال آهي. اسان ان کي سڏيندا آهيون "غير متحرڪ فائر وال" (غير متحرڪ فائر وال), ڇاڪاڻ ته سڀ مخزن تازه ڪاريون نوان ورجن ٺاهي. هن موضوع تي وڌيڪ معلومات لاءِ سلائيڊ 72-87 جو حوالو ڏيو .
- توھان استعمال ڪري سگھوٿا ڪو به CI ۽ Git سرور: GitOps ڪنهن به جزو سان ڪم ڪري ٿو. توھان جاري رکي سگھوٿا استعمال ڪرڻ لاءِ پنھنجي پسنديده CI ۽ Git سرورز، تصويري ذخيرا، ۽ ٽيسٽ سوٽ. مارڪيٽ تي لڳ ڀڳ سڀني ٻين مسلسل پهچائڻ وارا اوزار انهن جي پنهنجي سي آءِ / گٽ سرور يا تصويري مخزن جي ضرورت آهي. هي بادل جي اصليت جي ترقي ۾ هڪ محدود عنصر بڻجي سگهي ٿو. GitOps سان، توھان استعمال ڪري سگھوٿا واقف اوزار.
- هڪ انضمام اوزار طور واقعا: جيئن ئي Git ۾ ڊيٽا کي اپڊيٽ ڪيو ويندو، Weave Flux (يا Weave Cloud آپريٽر) رن ٽائم کي اطلاع ڪري ٿو. جڏهن به ڪبرنيٽس هڪ تبديلي سيٽ قبول ڪري ٿو، Git اپڊيٽ ڪيو ويو آهي. هي GitOps لاءِ ورڪ فلوز کي منظم ڪرڻ لاءِ هڪ سادي انضمام ماڊل مهيا ڪري ٿو، جيئن هيٺ ڏيکاريل آهي.
ٿڪل
GitOps ڪنهن به جديد CI / CD اوزار طرفان گهربل مضبوط تازه ڪاري جي ضمانت فراهم ڪري ٿي:
- خودڪار
- هم آهنگ
- ڪمزوري
- عزم
اهو ضروري آهي ڇاڪاڻ ته اهو پيش ڪري ٿو هڪ آپريشنل ماڊل ڪلائوڊ ڊولپرز لاءِ.
- سسٽم جي انتظام ۽ نگراني لاء روايتي اوزار هڪ رن بڪ اندر هلندڙ آپريشن ٽيمن سان لاڳاپيل آهن (معمولي طريقيڪار ۽ عملن جو هڪ سيٽ - تقريبن ترجمو.)، هڪ خاص مقرري سان ڳنڍيل آهي.
- بادل جي اصلي انتظام ۾، مشاهدي جا اوزار بهترين طريقا آهن ڊيپلائيشن جي نتيجن کي ماپڻ لاءِ ته جيئن ڊولپمينٽ ٽيم تڪڙو جواب ڏئي سگهي.
تصور ڪريو ڪيترن ئي ڪلسترن ۾ پکڙيل مختلف بادلن ۽ ڪيترن ئي خدمتن سان انهن جي پنهنجي ٽيمن ۽ مقرري جي منصوبن سان. GitOps پيش ڪري ٿو ھڪڙي پيماني تي غير معمولي ماڊل ھن تمام گھڻائي کي منظم ڪرڻ لاء.
پي ايس مترجم کان
اسان جي بلاگ تي پڻ پڙهو:
- «"؛
- «"؛
- «».
صرف رجسٽرڊ استعمال ڪندڙ سروي ۾ حصو وٺي سگهن ٿا. ، توهان جي مهرباني.
ڇا توهان GitOps بابت ڄاڻو ٿا ان کان اڳ جو اهي ٻه ترجما Habré تي ظاهر ٿيا؟
-
ها، مون کي سڀ ڪجهه خبر هئي
-
صرف سطحي طور تي
-
نه
35 صارفين ووٽ ڏنو. 10 استعمال ڪندڙن کي روڪيو ويو.
جو ذريعو: www.habr.com