گاہک کے پلیٹ فارم پر مسلسل تعیناتی کا ہمارا نفاذ

ٹرو انجینئرنگ میں ہم نے کسٹمر سرورز کو اپ ڈیٹس کی مسلسل ترسیل کے لیے ایک عمل ترتیب دیا ہے اور اس تجربے کو شیئر کرنا چاہتے ہیں۔

شروع کرنے کے لیے، ہم نے گاہک کے لیے ایک آن لائن سسٹم تیار کیا اور اسے ہمارے اپنے Kubernetes کلسٹر میں تعینات کیا۔ اب ہمارا ہائی-لوڈ حل کسٹمر کے پلیٹ فارم پر چلا گیا ہے، جس کے لیے ہم نے ایک مکمل خودکار مسلسل تعیناتی کا عمل ترتیب دیا ہے۔ اس کی بدولت، ہم نے ٹائم ٹو مارکیٹ یعنی مصنوعات کے ماحول میں تبدیلیوں کی ترسیل کو تیز کیا۔

اس مضمون میں ہم مسلسل تعیناتی (CD) کے عمل کے تمام مراحل یا گاہک کے پلیٹ فارم پر اپ ڈیٹس کی فراہمی کے بارے میں بات کریں گے:

1. یہ عمل کیسے شروع ہوتا ہے؟
2. گاہک کے Git ذخیرہ کے ساتھ ہم آہنگی،
3. پسدید اور فرنٹ اینڈ کی اسمبلی،
4. آزمائشی ماحول میں خودکار درخواست کی تعیناتی،
5. پروڈکٹ میں خودکار تعیناتی

ہم راستے میں سیٹ اپ کی تفصیلات کا اشتراک کریں گے۔

1. سی ڈی شروع کریں۔

مسلسل تعیناتی کا آغاز ڈویلپر کی جانب سے ہمارے Git ریپوزٹری کی ریلیز برانچ میں تبدیلیاں کرنے کے ساتھ ہوتا ہے۔

ہماری ایپلیکیشن مائیکرو سرویس فن تعمیر پر چلتی ہے اور اس کے تمام اجزاء ایک ذخیرہ میں محفوظ ہیں۔ اس کی بدولت، تمام مائیکرو سروسز کو اکٹھا اور انسٹال کیا جاتا ہے، چاہے ان میں سے کوئی ایک بدل گیا ہو۔

ہم نے کئی وجوہات کی بنا پر ایک ذخیرے کے ذریعے کام کو منظم کیا:

• ترقی میں آسانی - ایپلیکیشن فعال طور پر ترقی کر رہی ہے، لہذا آپ ایک ساتھ تمام کوڈ کے ساتھ کام کر سکتے ہیں۔
• ایک واحد CI/CD پائپ لائن جو اس بات کی ضمانت دیتی ہے کہ ایک واحد نظام کے طور پر ایپلیکیشن تمام ٹیسٹ پاس کرتی ہے اور اسے گاہک کے پیداواری ماحول میں پہنچایا جاتا ہے۔
• ہم ورژن میں الجھن کو ختم کرتے ہیں - ہمیں مائیکرو سروسز کے ورژن کا نقشہ ذخیرہ کرنے اور ہیلم اسکرپٹ میں ہر مائیکرو سروس کے لیے اس کی ترتیب کو بیان کرنے کی ضرورت نہیں ہے۔

2. گاہک کے سورس کوڈ کی گٹ ریپوزٹری کے ساتھ ہم آہنگی۔

کی گئی تبدیلیاں خود بخود گاہک کے Git ریپوزٹری کے ساتھ ہم آہنگ ہوجاتی ہیں۔ وہاں ایپلیکیشن اسمبلی کو کنفیگر کیا جاتا ہے، جو برانچ کو اپ ڈیٹ کرنے کے بعد شروع کیا جاتا ہے، اور اسے تسلسل کے لیے تعینات کیا جاتا ہے۔ دونوں عمل ان کے ماحول میں گٹ ریپوزٹری سے شروع ہوتے ہیں۔

ہم گاہک کے ذخیرے کے ساتھ براہ راست کام نہیں کر سکتے کیونکہ ہمیں ترقی اور جانچ کے لیے اپنے ماحول کی ضرورت ہے۔ ہم ان مقاصد کے لیے اپنا Git ذخیرہ استعمال کرتے ہیں - یہ ان کے Git ذخیرہ کے ساتھ ہم آہنگ ہوتا ہے۔ جیسے ہی کوئی ڈویلپر ہماری ریپوزٹری کی مناسب برانچ میں تبدیلیاں پوسٹ کرتا ہے، GitLab فوری طور پر ان تبدیلیوں کو گاہک تک پہنچاتا ہے۔

اس کے بعد آپ کو اسمبلی کرنے کی ضرورت ہے۔ یہ کئی مراحل پر مشتمل ہے: بیک اینڈ اور فرنٹ اینڈ اسمبلی، ٹیسٹنگ اور پروڈکشن کی ترسیل۔

3. پسدید اور فرنٹ اینڈ کو جمع کرنا

بیک اینڈ اور فرنٹ اینڈ بنانا دو متوازی کام ہیں جو گٹ لیب رنر سسٹم میں انجام پاتے ہیں۔ اس کی اصل اسمبلی کنفیگریشن اسی ذخیرہ میں واقع ہے۔

GitLab میں تعمیر کے لیے YAML اسکرپٹ لکھنے کا سبق.

گٹ لیب رنر مطلوبہ ذخیرے سے کوڈ لیتا ہے، اسے جاوا ایپلیکیشن بلڈ کمانڈ کے ساتھ اسمبل کرتا ہے اور اسے ڈاکر رجسٹری کو بھیجتا ہے۔ یہاں ہم بیک اینڈ اور فرنٹ اینڈ کو جمع کرتے ہیں، ڈوکر امیجز حاصل کرتے ہیں، جسے ہم گاہک کی طرف ایک ذخیرہ میں رکھتے ہیں۔ ڈوکر امیجز کو منظم کرنے کے لیے ہم استعمال کرتے ہیں۔ گریڈل پلگ ان.

ہم اپنی تصاویر کے ورژن کو ریلیز ورژن کے ساتھ ہم آہنگ کرتے ہیں جو ڈوکر میں شائع کیا جائے گا۔ ہموار آپریشن کے لیے ہم نے کئی ایڈجسٹمنٹ کی ہیں:

1. ٹیسٹ کے ماحول اور پیداواری ماحول کے درمیان کنٹینرز دوبارہ نہیں بنائے جاتے ہیں۔ ہم نے پیرامیٹرائزیشنز بنائی ہیں تاکہ ایک ہی کنٹینر تمام ترتیبات، ماحولیاتی متغیرات اور خدمات کے ساتھ ٹیسٹ کے ماحول اور پروڈکشن میں دوبارہ تعمیر کیے بغیر کام کر سکے۔

2. ہیلم کے ذریعے کسی ایپلیکیشن کو اپ ڈیٹ کرنے کے لیے، آپ کو اس کا ورژن بتانا ہوگا۔ ہم بیک اینڈ، فرنٹ اینڈ بناتے ہیں اور ایپلیکیشن کو اپ ڈیٹ کرتے ہیں - یہ تین مختلف کام ہیں، اس لیے ضروری ہے کہ ایپلیکیشن کا ایک ہی ورژن ہر جگہ استعمال کیا جائے۔ اس کام کے لیے، ہم گٹ ہسٹری سے ڈیٹا استعمال کرتے ہیں، کیونکہ ہماری K8S کلسٹر کنفیگریشن اور ایپلیکیشنز ایک ہی Git ریپوزٹری میں ہیں۔

ہمیں کمانڈ پر عمل درآمد کے نتائج سے ایپلیکیشن ورژن ملتا ہے۔
git describe --tags --abbrev=7.

4. ٹیسٹ ماحول میں تمام تبدیلیوں کی خودکار تعیناتی (UAT)

اس بلڈ اسکرپٹ کا اگلا مرحلہ K8S کلسٹر کو خود بخود اپ ڈیٹ کرنا ہے۔ یہ اس وقت ہوتا ہے بشرطیکہ پوری ایپلیکیشن بنائی گئی ہو اور تمام نمونے ڈاکر رجسٹری میں شائع کیے گئے ہوں۔ اس کے بعد، ٹیسٹ کے ماحول کی تازہ کاری شروع ہوتی ہے۔

کلسٹر اپ ڈیٹ کا استعمال شروع کر دیا گیا ہے۔ ہیلم اپڈیٹ. اگر، نتیجے کے طور پر، کچھ منصوبہ بندی کے مطابق نہیں ہوا، Helm خود بخود اور آزادانہ طور پر اپنی تمام تبدیلیوں کو واپس لے جائے گا۔ اس کے کام کو کنٹرول کرنے کی ضرورت نہیں ہے۔

ہم اسمبلی کے ساتھ K8S کلسٹر کنفیگریشن فراہم کرتے ہیں۔ اس لیے، اگلا مرحلہ اسے اپ ڈیٹ کرنا ہے: configMaps، تعیناتی، خدمات، راز اور کوئی دوسری K8S کنفیگریشن جسے ہم نے تبدیل کیا ہے۔

اس کے بعد ہیلم ٹیسٹ کے ماحول میں ایپلیکیشن کا رول آؤٹ اپ ڈیٹ چلاتا ہے۔ اس سے پہلے کہ ایپلیکیشن پروڈکشن میں لگائی جائے۔ ایسا اس لیے کیا جاتا ہے تاکہ صارف دستی طور پر ان کاروباری خصوصیات کی جانچ کر سکیں جو ہم آزمائشی ماحول میں ڈالتے ہیں۔

5. پروڈ میں تمام تبدیلیوں کی خودکار تعیناتی۔

پیداواری ماحول میں اپ ڈیٹ تعینات کرنے کے لیے، آپ کو GitLab میں صرف ایک بٹن پر کلک کرنے کی ضرورت ہے - اور کنٹینرز کو فوری طور پر پیداواری ماحول میں پہنچا دیا جاتا ہے۔

ایک ہی ایپلیکیشن مختلف ماحول میں کام کر سکتی ہے — ٹیسٹ اور پروڈکشن — بغیر دوبارہ تعمیر کیے۔ ہم ایپلیکیشن میں کچھ بھی تبدیل کیے بغیر وہی نمونے استعمال کرتے ہیں، اور ہم پیرامیٹرز کو بیرونی طور پر سیٹ کرتے ہیں۔

ایپلیکیشن سیٹنگز کی لچکدار پیرامیٹرائزیشن اس ماحول پر منحصر ہے جس میں ایپلیکیشن کو عمل میں لایا جائے گا۔ ہم نے ماحول کی تمام ترتیبات کو بیرونی طور پر منتقل کر دیا ہے: K8S کنفیگریشن اور ہیلم پیرامیٹرز کے ذریعے ہر چیز کو پیرامیٹرائز کیا گیا ہے۔ جب ہیلم ٹیسٹ کے ماحول میں اسمبلی کو تعینات کرتا ہے، تو ٹیسٹ کی ترتیبات اس پر لاگو ہوتی ہیں، اور پروڈکٹ کی ترتیبات پروڈکشن ماحول میں لاگو ہوتی ہیں۔

سب سے مشکل کام ان تمام استعمال شدہ خدمات اور متغیرات کو پیرامیٹرائز کرنا تھا جو ماحول پر منحصر ہیں، اور انہیں ماحولیاتی متغیرات اور ہیلم کے لیے ماحولیاتی پیرامیٹرز کی وضاحت کنفیگریشنز میں ترجمہ کرنا تھا۔

ایپلیکیشن کی ترتیبات ماحولیاتی متغیرات کا استعمال کرتی ہیں۔ ان کی قدریں K8S کنفیگریشن میپ کا استعمال کرتے ہوئے کنٹینرز میں سیٹ کی جاتی ہیں، جو گو ٹیمپلیٹس کا استعمال کرتے ہوئے ٹیمپلیٹ ہوتی ہے۔ مثال کے طور پر، ڈومین کے نام پر ماحولیاتی متغیر کو ترتیب دینا اس طرح کیا جا سکتا ہے:

APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

.values.global.env - یہ متغیر ماحول کے نام کو محفوظ کرتا ہے (پروڈ، اسٹیج، UAT)۔
.values.app.properties.app_external_domain - اس متغیر میں ہم مطلوبہ ڈومین کو .Values.yaml فائل میں سیٹ کرتے ہیں۔

کسی ایپلیکیشن کو اپ ڈیٹ کرتے وقت، ہیلم ٹیمپلیٹس سے ایک configmap.yaml فائل بناتا ہے اور APP_EXTERNAL_DOMAIN ویلیو کو مطلوبہ ویلیو کے ساتھ بھرتا ہے اس ماحول پر منحصر ہوتا ہے جس میں ایپلی کیشن اپ ڈیٹ شروع ہوتی ہے۔ یہ متغیر پہلے ہی کنٹینر میں سیٹ ہے۔ ایپلیکیشن سے اس تک رسائی حاصل کی جا سکتی ہے، لہذا ہر ایپلیکیشن ماحول میں اس متغیر کے لیے مختلف قدر ہوگی۔

نسبتا حال ہی میں، K8S سپورٹ اسپرنگ کلاؤڈ میں ظاہر ہوا، بشمول configMaps کے ساتھ کام کرنا: بہار کے بادل کبرنیٹس. جب کہ پروجیکٹ فعال طور پر ترقی کر رہا ہے اور یکسر تبدیل ہو رہا ہے، ہم اسے پیداوار میں استعمال نہیں کر سکتے۔ لیکن ہم فعال طور پر اس کی حالت کی نگرانی کرتے ہیں اور اسے DEV کنفیگریشن میں استعمال کرتے ہیں۔ جیسے ہی یہ مستحکم ہوتا ہے، ہم ماحولیاتی متغیرات کو استعمال کرنے سے اس میں تبدیل ہو جائیں گے۔

مجموعی طور پر

لہذا، مسلسل تعیناتی ترتیب دی گئی ہے اور کام کر رہی ہے۔ تمام اپ ڈیٹس ایک کی اسٹروک کے ساتھ ہوتی ہیں۔ مصنوعات کے ماحول میں تبدیلیوں کی ترسیل خودکار ہے۔ اور، اہم بات، اپ ڈیٹس سسٹم کو نہیں روکتے۔

مستقبل کے منصوبے: خودکار ڈیٹا بیس کی منتقلی۔

ہم نے ڈیٹا بیس کو اپ گریڈ کرنے اور ان تبدیلیوں کو واپس لانے کے امکان کے بارے میں سوچا۔ بہر حال، ایپلیکیشن کے دو مختلف ورژن ایک ہی وقت میں چل رہے ہیں: پرانا چل رہا ہے، اور نیا چل رہا ہے۔ اور ہم پرانے کو تب ہی بند کر دیں گے جب ہمیں یقین ہو جائے کہ نیا ورژن کام کر رہا ہے۔ ڈیٹا بیس کی منتقلی آپ کو ایپلیکیشن کے دونوں ورژن کے ساتھ کام کرنے کی اجازت دیتی ہے۔

لہذا، ہم صرف کالم کا نام یا دیگر ڈیٹا تبدیل نہیں کر سکتے۔ لیکن ہم ایک نیا کالم بنا سکتے ہیں، اس میں پرانے کالم سے ڈیٹا کاپی کر سکتے ہیں اور ایسے محرکات لکھ سکتے ہیں جو ڈیٹا کو اپ ڈیٹ کرتے وقت اسے ایک ساتھ کاپی کر کے دوسرے کالم میں اپ ڈیٹ کر دیتے ہیں۔ اور ایپلیکیشن کے نئے ورژن کی کامیاب تعیناتی کے بعد، پوسٹ لانچ سپورٹ پیریڈ کے بعد، ہم پرانے کالم اور ٹرگر کو حذف کر سکیں گے جو غیر ضروری ہو گیا ہے۔

اگر ایپلیکیشن کا نیا ورژن صحیح طریقے سے کام نہیں کرتا ہے، تو ہم ڈیٹا بیس کے پچھلے ورژن سمیت پچھلے ورژن پر واپس جا سکتے ہیں۔ مختصراً، ہماری تبدیلیاں آپ کو ایپلیکیشن کے کئی ورژنز کے ساتھ بیک وقت کام کرنے کی اجازت دیں گی۔

ہم K8S جاب کے ذریعے ڈیٹا بیس کی منتقلی کو خودکار کرنے کا ارادہ رکھتے ہیں، اسے CD کے عمل میں ضم کر دیتے ہیں۔ اور ہم اس تجربے کو Habré پر ضرور شیئر کریں گے۔

ماخذ: www.habr.com