اسان True Engineering تي ڪسٽمر سرورز کي اپڊيٽس جي مسلسل ترسيل لاءِ هڪ عمل قائم ڪيو آهي ۽ هن تجربي کي شيئر ڪرڻ چاهيون ٿا.
شروع ڪرڻ سان، اسان ڪسٽمر لاءِ هڪ آن لائن سسٽم تيار ڪيو ۽ ان کي اسان جي پنهنجي ڪبرنيٽس ڪلستر ۾ لڳايو. ھاڻي اسان جو ھاءِ لوڊ حل ڪسٽمر جي پليٽ فارم ڏانھن منتقل ٿي ويو آھي، جنھن لاءِ اسان ھڪ مڪمل طور تي پاڻمرادو مسلسل لڳائڻ وارو عمل قائم ڪيو آھي. انهي جي مهرباني، اسان وقت کان مارڪيٽ کي تيز ڪيو - پيداوار جي ماحول ۾ تبديلين جي ترسيل.
هن آرٽيڪل ۾ اسان مسلسل ڊيپلائيمينٽ (سي ڊي) جي عمل جي سڀني مرحلن بابت ڳالهائينداسين يا گراهڪ جي پليٽ فارم تي تازه ڪاري جي ترسيل:
- اهو عمل ڪيئن شروع ٿئي ٿو؟
- ڪسٽمر جي Git مخزن سان هم وقت سازي،
- پس منظر ۽ فرنٽ اينڊ جي گڏجاڻي،
- هڪ امتحان واري ماحول ۾ خودڪار ايپليڪيشن جي جوڙجڪ،
- پروڊڪٽ تي خودڪار لڳائڻ.
اسان رستي ۾ سيٽ اپ جا تفصيل حصيداري ڪنداسين.
1. سي ڊي شروع ڪريو
مسلسل ڊولپمينٽ شروع ٿئي ٿي ڊولپر اسان جي Git مخزن جي ڇڏڻ واري شاخ ۾ تبديلين کي زور ڏيڻ سان.
اسان جي ايپليڪيشن مائڪرو سروس آرڪيٽيڪچر تي هلندي آهي ۽ ان جا سڀئي حصا هڪ مخزن ۾ محفوظ ٿيل آهن. انهي جي مهرباني، سڀئي مائڪرو سروسز گڏ ڪيا ويا آهن ۽ نصب ٿيل آهن، جيتوڻيڪ انهن مان هڪ تبديل ٿي چڪو آهي.
اسان ڪيترن ئي سببن لاء هڪ مخزن ذريعي ڪم منظم ڪيو:
- ترقي جو آسان - ايپليڪيشن فعال طور تي ترقي ڪري رهي آهي، تنهنڪري توهان هڪ ڀيرو سڀني ڪوڊ سان ڪم ڪري سگهو ٿا.
- هڪ واحد CI / CD پائپ لائن جيڪا ضمانت ڏئي ٿي ته ايپليڪيشن هڪ واحد سسٽم جي طور تي سڀني ٽيسٽ پاس ڪري ٿي ۽ ڪسٽمر جي پيداوار واري ماحول تائين پهچائي ٿي.
- اسان نسخن ۾ مونجهارو ختم ڪريون ٿا - اسان کي مائڪرو سروس ورزن جو نقشو ذخيرو ڪرڻ جي ضرورت ناهي ۽ هيلم اسڪرپٽس ۾ هر مائڪرو سروس لاءِ ان جي تشريح کي بيان ڪرڻ جي ضرورت ناهي.
2. ڪسٽمر جي ماخذ ڪوڊ جي Git مخزن سان هم وقت سازي
ڪيل تبديليون خودڪار طور تي ڪسٽمر جي Git مخزن سان هم وقت سازي ٿينديون آهن. اتي ايپليڪيشن اسيمبلي ترتيب ڏني وئي آهي، جيڪا برانچ کي تازه ڪاري ڪرڻ کان پوء شروع ڪئي وئي آهي، ۽ تسلسل کي ترتيب ڏيڻ. ٻئي عمل انهن جي ماحول ۾ Git مخزن مان پيدا ٿين ٿا.
اسان سڌو سنئون گراهڪ جي مخزن سان ڪم نٿا ڪري سگهون ڇو ته اسان کي ترقي ۽ جانچ لاءِ اسان جي پنهنجي ماحول جي ضرورت آهي. اسان استعمال ڪندا آهيون اسان جي Git مخزن انهن مقصدن لاءِ - اهو انهن جي Git مخزن سان هم وقت سازي آهي. جيئن ئي هڪ ڊولپر پوسٽون اسان جي مخزن جي مناسب برانچ ۾ تبديل ڪري ٿو، GitLab فوري طور تي انهن تبديلين کي ڪسٽمر ڏانهن ڌڪيندو آهي.
هن کان پوء توهان کي اسيمبلي ڪرڻ جي ضرورت آهي. اهو ڪيترن ئي مرحلن تي مشتمل آهي: پس منظر ۽ فرنٽ اينڊ اسيمبلي، جانچ ۽ پيداوار تائين پهچائڻ.
3. پس منظر ۽ فرنٽ اينڊ کي گڏ ڪرڻ
پس منظر ۽ فرنٽ اينڊ جي تعمير ٻه متوازي ڪم آهن جيڪي GitLab رنر سسٽم ۾ ڪيا ويا آهن. ان جي اصل اسيمبلي جي جوڙجڪ ساڳئي مخزن ۾ واقع آهي.
.
GitLab Runner گھربل مخزن مان ڪوڊ وٺي ٿو، ان کي جاوا ايپليڪيشن بلڊ ڪمانڊ سان گڏ ڪري ٿو ۽ ان کي ڊاڪر رجسٽري ڏانھن موڪلي ٿو. هتي اسان پس منظر ۽ فرنٽ اينڊ گڏ ڪريون ٿا، ڊاڪر تصويرون حاصل ڪريو، جيڪي اسان ڪسٽمر جي پاسي تي مخزن ۾ رکون ٿا. Docker تصويرن کي منظم ڪرڻ لاءِ اسان استعمال ڪندا آهيون .
اسان اسان جي تصويرن جي ورزن کي رليز ٿيل ورزن سان هم وقت سازي ڪندا آهيون جيڪو ڊڪر ۾ شايع ڪيو ويندو. هموار آپريشن لاءِ اسان ڪيتريون ئي ترميمون ڪيون آهن:
1. امتحان واري ماحول ۽ پيداوار واري ماحول جي وچ ۾ ڪنٽينرز ٻيهر نه ٺاهيا ويا آهن. اسان parametrizations ٺاهيا آهن ته جيئن ساڳيو ڪنٽينر سڀني سيٽنگن سان ڪم ڪري سگهي، ماحول جي متغير ۽ خدمتن ٻنهي ٽيسٽ ماحول ۾ ۽ پيداوار ۾ بغير ٻيهر تعمير ڪرڻ.
2. هيلم ذريعي هڪ ايپليڪيشن کي اپڊيٽ ڪرڻ لاء، توهان کي ان جو نسخو بيان ڪرڻ گهرجي. اسان ايپليڪيشن کي پس منظر، فرنٽ اينڊ ۽ تازه ڪاري ڪندا آهيون - اهي ٽي مختلف ڪم آهن، تنهنڪري اهو ضروري آهي ته ايپليڪيشن جو ساڳيو نسخو هر جڳهه استعمال ڪيو وڃي. ھن ڪم لاءِ، اسان گٽ جي تاريخ مان ڊيٽا استعمال ڪندا آھيون، ڇو ته اسان جي K8S ڪلستر جي ٺاھ جوڙ ۽ ايپليڪيشنون ساڳي Git مخزن ۾ آھن.
اسان حاصل ڪريون ٿا ايپليڪيشن ورزن ڪمانڊ جي عمل جي نتيجن مان
git describe --tags --abbrev=7.
4. ٽيسٽ ماحول ۾ سڀني تبديلين جي خودڪار ترتيب (UAT)
هن تعمير اسڪرپٽ ۾ ايندڙ قدم خودڪار طور تي K8S ڪلستر کي اپڊيٽ ڪرڻ آهي. اهو ظاهر ٿئي ٿو ته پوري ايپليڪيشن ٺاهي وئي آهي ۽ سڀئي نمونا شايع ڪيا ويا آهن Docker رجسٽري ۾. ان کان پوء، ٽيسٽ ماحول جي تازه ڪاري شروع ٿئي ٿي.
ڪلستر اپڊيٽ استعمال ڪرڻ شروع ڪيو ويو آهي . جيڪڏهن، نتيجي طور، ڪا شيء منصوبي جي مطابق نه ٿي، هيلم خودڪار طور تي ۽ آزاديء سان ان جي سڀني تبديلين کي واپس آڻيندو. هن جي ڪم کي ڪنٽرول ڪرڻ جي ضرورت ناهي.
اسان اسيمبلي سان گڏ K8S ڪلستر جي جوڙجڪ فراهم ڪندا آهيون. تنهن ڪري، ايندڙ قدم ان کي تازه ڪاري ڪرڻ آهي: configMaps، ترتيب ڏيڻ، خدمتون، راز ۽ ٻيون ڪي 8S ترتيبون جيڪي اسان تبديل ڪيون آهن.
هيلم وري ايپليڪيشن جي رول آئوٽ اپڊيٽ پاڻ کي ٽيسٽ ماحول ۾ هلائي ٿو. ان کان اڳ جو ايپليڪيشن کي پيداوار تي لڳايو وڃي. اهو ڪيو ويو آهي انهي ڪري ته صارف دستي طور تي جانچ ڪري سگھن ٿا ڪاروباري خاصيتون جيڪي اسان ٽيسٽ ماحول ۾ رکون ٿا.
5. پروڊ ۾ سڀني تبديلين جي خودڪار ترتيب
پيداوار واري ماحول ۾ تازه ڪاري ترتيب ڏيڻ لاءِ، توهان کي صرف هڪ بٽڻ تي ڪلڪ ڪرڻ جي ضرورت آهي GitLab - ۽ ڪنٽينر فوري طور تي پيداوار واري ماحول ڏانهن پهچائي رهيا آهن.
ساڳي ايپليڪيشن مختلف ماحول ۾ ڪم ڪري سگھي ٿي - ٽيسٽ ۽ پيداوار - بغير تعمير ڪرڻ جي. اسان ايپليڪيشن ۾ ڪجھ به تبديل ڪرڻ کان سواءِ ساڳيا نمونا استعمال ڪندا آهيون، ۽ اسان پيٽرول کي خارجي طور تي مقرر ڪندا آهيون.
ايپليڪيشن سيٽنگن جي لچڪدار پيٽرولائيزيشن ان ماحول تي منحصر آهي جنهن ۾ ايپليڪيشن تي عمل ڪيو ويندو. اسان سڀني ماحوليات جي سيٽنگن کي خارجي طور تي منتقل ڪيو آهي: هر شيء کي K8S ترتيب ۽ هيلم پيٽرولر ذريعي ترتيب ڏني وئي آهي. جڏهن هيلم هڪ اسيمبليءَ کي امتحان واري ماحول ۾ ترتيب ڏئي ٿو، ٽيسٽ سيٽنگون ان تي لاڳو ٿين ٿيون، ۽ پيداوار جي سيٽنگون پيداوار جي ماحول تي لاڳو ٿين ٿيون.
سڀ کان وڌيڪ ڏکيو ڪم سڀني استعمال ٿيل خدمتن ۽ متغيرن کي ترتيب ڏيڻ هو، جيڪي ماحول تي منحصر آهن، ۽ انهن کي ماحول جي متغيرن ۾ ترجمو ڪرڻ ۽ هيلم لاء ماحول جي وضاحتن جي ترتيب ڏيڻ.
ايپليڪيشن سيٽنگون ماحولياتي متغير استعمال ڪن ٿيون. انهن جون قيمتون K8S configmap استعمال ڪندي ڪنٽينرز ۾ سيٽ ڪيون ويون آهن، جيڪو گو ٽيمپليٽس استعمال ڪندي ٺهيل آهي. مثال طور، ڊومين جي نالي تي هڪ ماحول متغير ترتيب ڏيڻ هن طرح ٿي سگهي ٿو:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
قدر.گلوبل.env - هي متغير ماحول جو نالو محفوظ ڪري ٿو (پروڊ، اسٽيج، UAT).
.values.app.properties.app_external_domain - هن متغير ۾ اسان مطلوب ڊومين کي .Values.yaml فائل ۾ سيٽ ڪيو
ايپليڪيشن کي اپڊيٽ ڪرڻ وقت، هيلم ٽيمپليٽس مان هڪ configmap.yaml فائل ٺاهي ٿو ۽ APP_EXTERNAL_DOMAIN قدر کي گهربل قدر سان ڀري ٿو ان ماحول تي منحصر آهي جنهن ۾ ايپليڪيشن اپڊيٽ شروع ٿئي ٿي. هي متغير اڳ ۾ ئي ڪنٽينر ۾ مقرر ٿيل آهي. اهو ايپليڪيشن مان رسائي سگهجي ٿو، تنهنڪري هر ايپليڪيشن ماحول ۾ هن متغير لاء مختلف قدر هوندي.
نسبتا تازو، K8S سپورٽ اسپرنگ ڪلائوڊ ۾ ظاهر ٿيو، بشمول configMaps سان ڪم ڪرڻ: . جڏهن ته پروجيڪٽ فعال طور تي ترقي ڪري رهيو آهي ۽ بنيادي طور تي تبديل ڪري رهيو آهي، اسان ان کي پيداوار ۾ استعمال نٿا ڪري سگهون. پر اسان ان جي حالت کي فعال طور تي مانيٽر ڪريون ٿا ۽ ان کي استعمال ڪريون ٿا DEV ترتيبن ۾. جيترو جلدي اهو مستحڪم ٿيندو، اسان ان کي ماحولياتي متغير استعمال ڪرڻ کان سوئچ ڪنداسين.
ڪل
تنهن ڪري، مسلسل تعیناتي ترتيب ڏني وئي آهي ۽ ڪم ڪري رهيو آهي. سڀ تازه ڪاريون هڪ keystroke سان ٿينديون آهن. پيداوار جي ماحول ۾ تبديلين جي ترسيل خودڪار آهي. ۽، اھم، تازه ڪاريون سسٽم کي روڪي نه سگھندا آھن.
مستقبل جا منصوبا: خودڪار ڊيٽابيس لڏپلاڻ
اسان ڊيٽابيس کي اپڊيٽ ڪرڻ ۽ انهن تبديلين کي واپس آڻڻ جي امڪان بابت سوچيو. سڀ کان پوء، ايپليڪيشن جا ٻه مختلف نسخا هڪ ئي وقت تي هلندا آهن: پراڻو هڪ هلندو آهي، ۽ نئون هڪ مٿي آهي. ۽ اسان پراڻي کي بند ڪنداسين تڏهن ئي جڏهن اسان کي پڪ آهي ته نئون ورزن ڪم ڪندو. ڊيٽابيس جي لڏپلاڻ کي توهان کي ايپليڪيشن جي ٻنهي نسخن سان ڪم ڪرڻ جي اجازت ڏيڻ گهرجي.
تنهن ڪري، اسان صرف ڪالمن جو نالو يا ٻيو ڊيٽا تبديل نٿا ڪري سگھون. پر اسان هڪ نئون ڪالم ٺاهي سگھون ٿا، ان ۾ پراڻي ڪالم مان ڊيٽا ڪاپي ڪري محرڪ لکي سگھون ٿا، جيڪي ڊيٽا کي اپڊيٽ ڪرڻ وقت ان کي ٻئي ڪالم ۾ نقل ڪري تازه ڪاري ڪندا. ۽ ايپليڪيشن جي نئين ورزن جي ڪامياب لڳائڻ کان پوء، پوسٽ لانچ سپورٽ جي مدت کان پوء، اسان پراڻي ڪالمن ۽ ٽرگر کي ختم ڪرڻ جي قابل ٿي سگهنداسين جيڪو غير ضروري ٿي چڪو آهي.
جيڪڏهن اپليڪيشن جو نئون ورزن صحيح ڪم نه ٿو ڪري، ته اسان ڊيٽابيس جي پوئين ورزن سميت، پوئين ورزن ڏانهن واپس هلي سگهون ٿا. مختصر ۾، اسان جون تبديليون توهان کي ايپليڪيشن جي ڪيترن ئي ورزن سان گڏ ڪم ڪرڻ جي اجازت ڏين ٿيون.
اسان K8S نوڪري ذريعي ڊيٽابيس لڏپلاڻ کي خودڪار ڪرڻ جو منصوبو ٺاهيو، ان کي سي ڊي پروسيس ۾ ضم ڪرڻ. ۽ اسان ضرور هن تجربي کي Habré تي حصيداري ڪنداسين.
جو ذريعو: www.habr.com