نوٹ. ترجمہ: ایک حالیہ اشاعت کے بعد GitOps میں پل اور پش طریقوں کے بارے میں، ہم نے عام طور پر اس ماڈل میں دلچسپی دیکھی، لیکن اس موضوع پر روسی زبان میں بہت کم اشاعتیں تھیں (Habré پر کوئی بھی نہیں ہے)۔ لہذا، ہمیں آپ کی توجہ ایک اور مضمون کا ترجمہ پیش کرتے ہوئے خوشی ہو رہی ہے - اگرچہ تقریباً ایک سال پہلے! - Weaveworks سے، جس کے سربراہ نے "GitOps" کی اصطلاح بنائی۔ متن نقطہ نظر کے جوہر اور موجودہ لوگوں سے کلیدی اختلافات کی وضاحت کرتا ہے۔
ایک سال پہلے ہم نے شائع کیا۔ . اس وقت، ہم نے اشتراک کیا کہ کس طرح Weaveworks ٹیم نے SaaS کو مکمل طور پر Kubernetes پر مبنی شروع کیا اور کلاؤڈ مقامی ماحول میں تعیناتی، انتظام اور نگرانی کے لیے بہترین نسخے کے طریقوں کا ایک سیٹ تیار کیا۔
مضمون مشہور ہوا۔ دوسرے لوگوں نے GitOps کے بارے میں بات کرنا شروع کر دی اور اس کے لیے نئے ٹولز شائع کرنا شروع کر دیے۔ , , , , اور اسی طرح. ہماری ویب سائٹ پر ظاہر ہوا۔ اشاعتیں اور GitOps کے استعمال کے معاملات۔ لیکن کچھ لوگوں کے پاس اب بھی سوالات ہیں۔ ماڈل روایتی ماڈل سے کیسے مختلف ہے؟ اور مسلسل ترسیل ()؟ کیا Kubernetes استعمال کرنا ضروری ہے؟
ہم نے جلد ہی محسوس کیا کہ ایک نئی وضاحت کی ضرورت ہے، پیشکش:
- مثالوں اور کہانیوں کی ایک بڑی تعداد؛
- GitOps کی مخصوص تعریف;
- روایتی مسلسل ترسیل کے ساتھ موازنہ.
اس مضمون میں ہم نے ان تمام موضوعات کا احاطہ کرنے کی کوشش کی ہے۔ یہ GitOps کا ایک تازہ ترین تعارف اور ایک ڈویلپر اور CI/CD نقطہ نظر فراہم کرتا ہے۔ ہم بنیادی طور پر Kubernetes پر توجہ مرکوز کرتے ہیں، حالانکہ ماڈل کو عام کیا جا سکتا ہے۔
GitOps سے ملو
ایلس کا تصور کریں۔ وہ فیملی انشورنس چلاتی ہے، جو ان لوگوں کو صحت، آٹو، گھر، اور سفری بیمہ پیش کرتی ہے جو خود معاہدوں کے ان اور آؤٹ کا پتہ لگانے میں مصروف ہیں۔ اس کا کاروبار ایک سائیڈ پروجیکٹ کے طور پر شروع ہوا جب ایلس ایک بینک میں بطور ڈیٹا سائنسدان کام کر رہی تھی۔ ایک دن اس نے محسوس کیا کہ وہ ڈیٹا کا زیادہ مؤثر طریقے سے تجزیہ کرنے اور انشورنس پیکجز بنانے کے لیے جدید کمپیوٹر الگورتھم استعمال کر سکتی ہے۔ سرمایہ کاروں نے اس منصوبے کے لیے مالی اعانت فراہم کی، اور اب اس کی کمپنی ایک سال میں $20 ملین سے زیادہ لاتی ہے اور تیزی سے بڑھ رہی ہے۔ فی الحال، اس میں مختلف عہدوں پر 180 افراد کام کر رہے ہیں۔ اس میں ایک ٹیکنالوجی ٹیم شامل ہے جو ویب سائٹ، ڈیٹا بیس کو تیار کرتی ہے، اسے برقرار رکھتی ہے، اور کسٹمر بیس کا تجزیہ کرتی ہے۔ 60 افراد کی ٹیم کی قیادت کمپنی کے ٹیکنیکل ڈائریکٹر باب کر رہے ہیں۔
باب کی ٹیم کلاؤڈ میں پروڈکشن سسٹم تعینات کرتی ہے۔ ان کی بنیادی ایپلی کیشنز GKE پر چلتی ہیں، Google Cloud پر Kubernetes کا فائدہ اٹھاتے ہوئے۔ اس کے علاوہ، وہ اپنے کام میں مختلف ڈیٹا اور تجزیاتی ٹولز استعمال کرتے ہیں۔
فیملی انشورنس نے کنٹینرز استعمال کرنے کا ارادہ نہیں کیا، لیکن ڈوکر کے جوش و خروش میں پھنس گیا۔ کمپنی نے جلد ہی دریافت کیا کہ GKE نے نئی خصوصیات کو جانچنے کے لیے کلسٹرز کو تعینات کرنا آسان اور آسان بنا دیا ہے۔ کنٹینر رجسٹری کو منظم کرنے کے لیے CI اور Quay کے لیے جینکنز کو شامل کیا گیا، جینکنز کے لیے اسکرپٹ لکھے گئے جنہوں نے نئے کنٹینرز اور کنفیگریشنز کو GKE تک پہنچایا۔
کچھ وقت گزر گیا۔ ایلس اور باب اپنے منتخب طریقہ کار کی کارکردگی اور کاروبار پر اس کے اثرات سے مایوس تھے۔ کنٹینرز کے متعارف ہونے سے پیداواری صلاحیت میں اتنی بہتری نہیں آئی جتنی ٹیم کو امید تھی۔ بعض اوقات تعیناتی ٹوٹ جاتی تھی، اور یہ واضح نہیں تھا کہ آیا کوڈ میں تبدیلیاں اس کا ذمہ دار ہیں۔ کنفیگریشن تبدیلیوں کو ٹریک کرنا بھی مشکل ثابت ہوا۔ اکثر یہ ضروری ہوتا تھا کہ ایک نیا کلسٹر بنانا اور اس میں ایپلی کیشنز کو منتقل کیا جائے، کیونکہ سسٹم میں جو گڑبڑ ہو چکی تھی اسے ختم کرنے کا یہ سب سے آسان طریقہ تھا۔ ایلس کو ڈر تھا کہ ایپلیکیشن تیار ہونے کے ساتھ ہی صورتحال مزید خراب ہو جائے گی (اس کے علاوہ، مشین لرننگ پر مبنی ایک نیا پروجیکٹ تیار ہو رہا ہے)۔ باب نے زیادہ تر کام خودکار کر دیا تھا اور اسے سمجھ نہیں آ رہا تھا کہ پائپ لائن اب بھی غیر مستحکم کیوں ہے، اچھی طرح سے پیمانہ نہیں لگایا، اور وقتاً فوقتاً دستی مداخلت کی ضرورت ہے؟
پھر انہوں نے GitOps کے بارے میں سیکھا۔ یہ فیصلہ بالکل وہی نکلا جس کی انہیں اعتماد کے ساتھ آگے بڑھنے کی ضرورت تھی۔
ایلس اور باب برسوں سے کوڈ ورک فلو کے طور پر Git، DevOps، اور انفراسٹرکچر کے بارے میں سن رہے ہیں۔ GitOps کے بارے میں جو چیز منفرد ہے وہ یہ ہے کہ یہ Kubernetes کے تناظر میں ان خیالات کو لاگو کرنے کے لیے بہترین طریقوں کا ایک مجموعہ لاتا ہے — حتمی اور معیاری دونوں —۔ یہ تھیم بشمول میں .
فیملی انشورنس نے GitOps کو نافذ کرنے کا فیصلہ کیا ہے۔ کمپنی کے پاس اب ایک خودکار آپریشن ماڈل ہے جو Kubernetes اور کمبائنز کے ساتھ مطابقت رکھتا ہے۔ رفتار کے ساتھ استحکامکیونکہ وہ:
- پتہ چلا کہ ٹیم کی پیداواری صلاحیت بغیر کسی دیوانے کے دگنی ہو گئی۔
- سکرپٹ پیش کرنا بند کر دیا. اس کے بجائے، وہ اب نئی خصوصیات پر توجہ مرکوز کر سکتے ہیں اور انجینئرنگ کے طریقوں کو بہتر بنا سکتے ہیں - مثال کے طور پر، کینری رول آؤٹ متعارف کرانا اور ٹیسٹنگ کو بہتر بنانا؛
- ہم نے تعیناتی کے عمل کو بہتر بنایا ہے تاکہ یہ شاذ و نادر ہی ٹوٹے؛
- دستی مداخلت کے بغیر جزوی ناکامیوں کے بعد تعیناتیوں کو بحال کرنے کا موقع ملا؛
- استعمال کیا خریداоترسیل کے نظام پر زیادہ اعتماد۔ ایلس اور باب نے دریافت کیا کہ وہ ٹیم کو متوازی طور پر کام کرنے والی مائیکرو سروس ٹیموں میں تقسیم کر سکتے ہیں۔
- ہر گروپ کی کوششوں سے ہر روز پروجیکٹ میں 30-50 تبدیلیاں کر سکتے ہیں اور نئی تکنیک آزما سکتے ہیں۔
- نئے ڈویلپرز کو پراجیکٹ کی طرف راغب کرنا آسان ہے، جن کے پاس چند گھنٹوں کے اندر پل کی درخواستوں کا استعمال کرتے ہوئے پروڈکشن میں اپ ڈیٹ کرنے کا موقع ہوتا ہے۔
- آسانی سے SOC2 کے فریم ورک کے اندر آڈٹ پاس کریں۔ (محفوظ ڈیٹا مینجمنٹ کے تقاضوں کے ساتھ سروس فراہم کنندگان کی تعمیل کے لیے؛ مزید پڑھیں، مثال کے طور پر، - تقریبا. ترجمہ).
کیا ہوا؟
GitOps دو چیزیں ہیں:
- Kubernetes اور کلاؤڈ مقامی کے لیے آپریشنل ماڈل۔ یہ کنٹینرائزڈ کلسٹرز اور ایپلیکیشنز کی تعیناتی، انتظام اور نگرانی کے لیے بہترین طریقوں کا ایک سیٹ فراہم کرتا ہے۔ شکل میں خوبصورت تعریف سے :
- ایک ڈویلپر مرکوز ایپلیکیشن مینجمنٹ ماحول بنانے کا راستہ۔ ہم Git ورک فلو کو آپریشنز اور ڈیولپمنٹ دونوں پر لاگو کرتے ہیں۔ براہ کرم نوٹ کریں کہ یہ صرف Git push کے بارے میں نہیں ہے، بلکہ CI/CD اور UI/UX ٹولز کے پورے سیٹ کو منظم کرنے کے بارے میں ہے۔
گٹ کے بارے میں چند الفاظ
اگر آپ ورژن کنٹرول سسٹم اور Git پر مبنی ورک فلو سے واقف نہیں ہیں، تو ہم ان کے بارے میں جاننے کی انتہائی سفارش کرتے ہیں۔ شاخوں اور پل کی درخواستوں کے ساتھ کام کرنا پہلے تو کالے جادو کی طرح لگتا ہے، لیکن فوائد کوشش کے قابل ہیں۔ یہاں شروع کرنے کے لئے.
کبرنیٹس کیسے کام کرتا ہے۔
ہماری کہانی میں، ایلس اور باب نے کبرنیٹس کے ساتھ تھوڑی دیر کام کرنے کے بعد GitOps کا رخ کیا۔ درحقیقت، GitOps کا کبرنیٹس سے گہرا تعلق ہے - یہ Kubernetes پر مبنی انفراسٹرکچر اور ایپلیکیشنز کے لیے ایک آپریشنل ماڈل ہے۔
Kubernetes صارفین کو کیا دیتا ہے؟
یہاں کچھ اہم خصوصیات ہیں:
- Kubernetes ماڈل میں، ہر چیز کو اعلانیہ شکل میں بیان کیا جا سکتا ہے۔
- Kubernetes API سرور اس اعلان کو ان پٹ کے طور پر لیتا ہے اور پھر اعلان میں بیان کردہ ریاست میں کلسٹر کو لانے کی مسلسل کوشش کرتا ہے۔
- اعلانات کام کے بوجھ کی وسیع اقسام کو بیان کرنے اور ان کا نظم کرنے کے لیے کافی ہیں—"ایپلی کیشنز۔"
- نتیجے کے طور پر، ایپلی کیشن اور کلسٹر میں تبدیلیاں اس وجہ سے ہوتی ہیں:
- کنٹینر کی تصاویر میں تبدیلی؛
- اعلانیہ تفصیلات میں تبدیلیاں؛
- ماحول میں خرابیاں - مثال کے طور پر، کنٹینر کریش۔
Kubernetes کی عظیم کنورجنسی صلاحیتیں۔
جب کوئی منتظم کنفیگریشن میں تبدیلی کرتا ہے، تو Kubernetes آرکیسٹریٹر انہیں کلسٹر پر لاگو کرے گا جب تک کہ اس کی حالت نئی ترتیب کے قریب نہیں آئے گا۔. یہ ماڈل کسی بھی Kubernetes ریسورس کے لیے کام کرتا ہے اور کسٹم ریسورس ڈیفینیشنز (CRDs) کے ساتھ قابل توسیع ہے۔ لہذا، Kubernetes کی تعیناتیوں میں درج ذیل شاندار خصوصیات ہیں:
- آٹومیشن: Kubernetes اپ ڈیٹس تبدیلیوں کو احسن طریقے سے اور بروقت لاگو کرنے کے عمل کو خودکار کرنے کے لیے ایک طریقہ کار فراہم کرتے ہیں۔
- کنورجنس: Kubernetes کامیابی تک اپ ڈیٹس کی کوشش جاری رکھیں گے۔
- بے حسی: کنورجنس کے بار بار استعمال سے ایک ہی نتیجہ نکلتا ہے۔
- ڈیٹرمنزم: جب وسائل کافی ہوتے ہیں، اپ ڈیٹ کردہ کلسٹر کی حالت صرف مطلوبہ حالت پر منحصر ہوتی ہے۔
GitOps کیسے کام کرتا ہے۔
ہم نے Kubernetes کے بارے میں کافی سیکھا ہے کہ GitOps کیسے کام کرتا ہے۔
آئیے فیملی انشورنس کی مائیکرو سروسز ٹیموں پر واپس آتے ہیں۔ انہیں عام طور پر کیا کرنا ہے؟ نیچے دی گئی فہرست کو دیکھیں (اگر اس میں کوئی آئٹم عجیب یا ناواقف لگتا ہے تو براہ کرم تنقید کرنے سے باز رہیں اور ہمارے ساتھ رہیں)۔ یہ جینکنز پر مبنی ورک فلو کی صرف مثالیں ہیں۔ دوسرے ٹولز کے ساتھ کام کرتے وقت بہت سے دوسرے عمل ہوتے ہیں۔
اہم بات یہ ہے کہ ہم دیکھتے ہیں کہ ہر اپ ڈیٹ کنفیگریشن فائلوں اور گٹ ریپوزٹریز میں تبدیلیوں کے ساتھ ختم ہوتا ہے۔ Git میں یہ تبدیلیاں "GitOps آپریٹر" کو کلسٹر کو اپ ڈیٹ کرنے کا سبب بنتی ہیں:
1. کام کرنے کا عمل: "جینکنز بلڈ - ماسٹر برانچ'.
کاموں کی فہرست:
- جینکنز نے ٹیگ شدہ تصاویر کو کوے کی طرف دھکیل دیں۔
- جینکنز کنفیگریشن اور ہیلم چارٹس کو ماسٹر اسٹوریج بالٹی میں دھکیلتا ہے۔
- کلاؤڈ فنکشن کنفیگریشن اور چارٹس کو ماسٹر اسٹوریج بالٹی سے ماسٹر گٹ ریپوزٹری میں کاپی کرتا ہے۔
- GitOps آپریٹر کلسٹر کو اپ ڈیٹ کرتا ہے۔
2. جینکنز بلڈ - ریلیز یا ہاٹ فکس برانچ:
- جینکنز نے ٹیگ نہ کی گئی تصاویر کوے کی طرف دھکیل دیں۔
- جینکنز کنفگ اور ہیلم چارٹس کو اسٹیجنگ اسٹوریج بالٹی میں دھکیلتا ہے۔
- کلاؤڈ فنکشن اسٹیجنگ اسٹوریج بالٹی سے اسٹیجنگ گٹ ریپوزٹری میں ترتیب اور چارٹس کو کاپی کرتا ہے۔
- GitOps آپریٹر کلسٹر کو اپ ڈیٹ کرتا ہے۔
3. جینکنز کی تعمیر - ترقی یا خصوصیت کی شاخ:
- جینکنز نے ٹیگ نہ کی گئی تصاویر کوے کی طرف دھکیل دیں۔
- جینکنز کنفگ اور ہیلم چارٹس کو ڈیولپمنٹ اسٹوریج بالٹی میں دھکیلتا ہے۔
- کلاؤڈ فنکشن ڈیولپمنٹ اسٹوریج بالٹی سے ڈیویلپمنٹ گٹ ریپوزٹری تک تشکیل اور چارٹس کو کاپی کرتا ہے۔
- GitOps آپریٹر کلسٹر کو اپ ڈیٹ کرتا ہے۔
4. ایک نیا کلائنٹ شامل کرنا:
- مینیجر یا ایڈمنسٹریٹر (LCM/ops) ابتدائی طور پر نیٹ ورک لوڈ بیلنسرز (NLBs) کو تعینات اور ترتیب دینے کے لیے Gradle کو کال کرتا ہے۔
- LCM/ops اپ ڈیٹس کے لیے تعیناتی کی تیاری کے لیے ایک نئی تشکیل کا ارتکاب کرتا ہے۔
- GitOps آپریٹر کلسٹر کو اپ ڈیٹ کرتا ہے۔
GitOps کی مختصر تفصیل
- ہر ماحول کے لیے اعلانیہ تصریحات کا استعمال کرتے ہوئے پورے نظام کی مطلوبہ حالت کی وضاحت کریں (ہماری کہانی میں، باب کی ٹیم گٹ میں پورے نظام کی ترتیب کی وضاحت کرتی ہے)۔
- Git ذخیرہ پورے نظام کی مطلوبہ حالت کے حوالے سے سچائی کا واحد ذریعہ ہے۔
- مطلوبہ حالت میں تمام تبدیلیاں گٹ میں کمٹ کے ذریعے کی جاتی ہیں۔
- تمام مطلوبہ کلسٹر پیرامیٹرز بھی کلسٹر میں ہی قابل مشاہدہ ہیں۔ اس طرح ہم اس بات کا تعین کر سکتے ہیں کہ آیا وہ ایک دوسرے سے ملتے ہیں تقارب) یا مختلف (اختلاف، جدا ہونا) مطلوبہ اور مشاہدہ شدہ ریاستیں۔
- اگر مطلوبہ اور مشاہدہ شدہ حالتیں مختلف ہوں تو:
- ایک کنورجنس میکانزم ہے جو جلد یا بدیر خود بخود ہدف اور مشاہدہ شدہ حالتوں کو ہم آہنگ کرتا ہے۔ کلسٹر کے اندر، Kubernetes یہ کرتا ہے۔
- یہ عمل فوری طور پر "تبدیلی کا عہد" کے الرٹ کے ساتھ شروع ہوتا ہے۔
- کچھ قابل ترتیب مدت کے بعد، اگر ریاستیں مختلف ہوں تو "diff" الرٹ بھیجا جا سکتا ہے۔
- اس طرح، گٹ میں ہونے والے تمام وعدے کلسٹر میں قابل تصدیق اور ناقابل یقین اپڈیٹس کا سبب بنتے ہیں۔
- رول بیک پہلے سے مطلوبہ حالت میں کنورژن ہے۔
- ہم آہنگی حتمی ہے۔ اس کی موجودگی کی طرف اشارہ کیا جاتا ہے:
- ایک مخصوص مدت کے لیے کوئی مختلف انتباہات نہیں۔
- "کنورجڈ" الرٹ (جیسے ویب ہُک، گِٹ رائٹ بیک ایونٹ)۔
اختلاف کیا ہے؟
آئیے دوبارہ دہراتے ہیں: تمام مطلوبہ کلسٹر کی خصوصیات کلسٹر میں ہی قابل مشاہدہ ہونی چاہئیں.
اختلاف کی چند مثالیں:
- Git میں شاخوں کو ضم کرنے کی وجہ سے کنفیگریشن فائل میں تبدیلی۔
- GUI کلائنٹ کے ذریعہ کی گئی گٹ کمٹ کی وجہ سے کنفیگریشن فائل میں تبدیلی۔
- Git میں PR کی وجہ سے مطلوبہ حالت میں متعدد تبدیلیاں اور اس کے بعد کنٹینر امیج بنانے اور کنفیگریشن تبدیلیاں۔
- کلسٹر کی حالت میں خرابی کی وجہ سے تبدیلی، وسائل کے تنازعہ کے نتیجے میں "خراب سلوک"، یا اصل حالت سے محض بے ترتیب انحراف۔
کنورجنسی کا طریقہ کار کیا ہے؟
چند مثالیں:
- کنٹینرز اور کلسٹرز کے لیے، کنورجنس میکانزم کوبرنیٹس فراہم کرتا ہے۔
- اسی طریقہ کار کو Kubernetes پر مبنی ایپلی کیشنز اور ڈیزائنز (جیسے Istio اور Kubeflow) کو منظم کرنے کے لیے استعمال کیا جا سکتا ہے۔
- Kubernetes، تصویری ذخیرے اور Git کے درمیان آپریشنل تعامل کا انتظام کرنے کا ایک طریقہ کار فراہم کرتا ہے۔ ، جو حصہ ہے .
- بیس مشینوں کے لیے، کنورجنس میکانزم کو اعلانیہ اور خود مختار ہونا چاہیے۔ اپنے تجربے سے ہم یہ کہہ سکتے ہیں۔ اس تعریف کے قریب ترین، لیکن پھر بھی انسانی کنٹرول کی ضرورت ہے۔ اس لحاظ سے، GitOps بنیادی ڈھانچے کی روایت کو کوڈ کے طور پر بڑھاتا ہے۔
GitOps استحصال کے لیے ایک ماڈل فراہم کرنے کے لیے Git کو Kubernetes کے بہترین کنورجنس انجن کے ساتھ جوڑتا ہے۔
GitOps ہمیں یہ کہنے کی اجازت دیتا ہے: صرف وہی نظام جو بیان اور مشاہدہ کیے جاسکتے ہیں خودکار اور کنٹرول کیے جاسکتے ہیں۔.
GitOps کا مقصد پورے کلاؤڈ مقامی اسٹیک کے لیے ہے (مثال کے طور پر، Terraform، وغیرہ)
GitOps صرف Kubernetes نہیں ہے۔ ہم چاہتے ہیں کہ پورا نظام اعلانیہ طور پر چلایا جائے اور ہم آہنگی کا استعمال کیا جائے۔ پورے نظام سے ہمارا مطلب ہے Kubernetes کے ساتھ کام کرنے والے ماحول کا مجموعہ - مثال کے طور پر، "dev cluster 1"، "production"، وغیرہ۔ ہر ماحول میں مشینیں، کلسٹرز، ایپلی کیشنز، نیز بیرونی خدمات کے انٹرفیس شامل ہیں جو ڈیٹا فراہم کرتے ہیں، نگرانی اور وغیرہ
دیکھیں کہ اس معاملے میں بوٹسٹریپنگ کے مسئلے کے لیے Terraform کتنا اہم ہے۔ Kubernetes کو کہیں تعینات کرنا ہوگا، اور Terraform استعمال کرنے کا مطلب ہے کہ ہم وہی GitOps ورک فلوز کو کنٹرول لیئر بنانے کے لیے لاگو کر سکتے ہیں جو Kubernetes اور ایپلی کیشنز کو زیر کرتا ہے۔ یہ ایک مفید بہترین عمل ہے۔
Kubernetes کے اوپری حصے پر GitOps کے تصورات کو لاگو کرنے پر بھرپور توجہ دی جارہی ہے۔ اس وقت، Istio، Helm، Ksonnet، OpenFaaS اور Kubeflow کے لیے GitOps قسم کے حل موجود ہیں، نیز، مثال کے طور پر، Pulumi کے لیے، جو کلاؤڈ مقامی کے لیے ایپلی کیشنز تیار کرنے کے لیے ایک پرت بناتے ہیں۔
Kubernetes CI/CD: دوسرے طریقوں سے GitOps کا موازنہ کرنا
جیسا کہ کہا گیا ہے، GitOps دو چیزیں ہیں:
- Kubernetes اور کلاؤڈ مقامی کے لیے آپریٹنگ ماڈل اوپر بیان کیا گیا ہے۔
- ڈویلپر مرکوز ایپلیکیشن مینجمنٹ ماحول کا راستہ۔
بہت سے لوگوں کے لیے، GitOps بنیادی طور پر Git pushes پر مبنی ایک ورک فلو ہے۔ ہم بھی اسے پسند کرتے ہیں۔ لیکن یہ سب کچھ نہیں ہے: آئیے اب CI/CD پائپ لائنوں کو دیکھیں۔
GitOps Kubernetes کے لیے مسلسل تعیناتی (CD) کو قابل بناتا ہے۔
GitOps ایک مسلسل تعیناتی کا طریقہ کار پیش کرتا ہے جو علیحدہ "تعیناتی انتظامی نظام" کی ضرورت کو ختم کرتا ہے۔ Kubernetes آپ کے لیے تمام کام کرتا ہے۔
- ایپلیکیشن کو اپ ڈیٹ کرنے کے لیے گٹ میں اپ ڈیٹ کرنا ضروری ہے۔ یہ مطلوبہ حالت میں ٹرانزیکشنل اپ ڈیٹ ہے۔ "تعینات" اس کے بعد کلسٹر کے اندر خود Kubernetes کے ذریعہ اپ ڈیٹ کردہ تفصیل کی بنیاد پر کی جاتی ہے۔
- Kubernetes کے کام کرنے کے طریقے کی وجہ سے، یہ اپڈیٹس متضاد ہیں۔ یہ مسلسل تعیناتی کے لیے ایک طریقہ کار فراہم کرتا ہے جس میں تمام اپ ڈیٹس ایٹم ہیں۔
- نوٹ: ایک GitOps آپریٹر پیش کرتا ہے جو Git اور Kubernetes کو مربوط کرتا ہے اور کلسٹر کی مطلوبہ اور موجودہ حالت کو ملا کر CD کو انجام دینے کی اجازت دیتا ہے۔
کیوبیکٹل اور اسکرپٹ کے بغیر
آپ کو اپنے کلسٹر کو اپ ڈیٹ کرنے کے لیے Kubectl استعمال کرنے سے گریز کرنا چاہیے، اور خاص طور پر kubectl کمانڈز کو گروپ کرنے کے لیے اسکرپٹ کے استعمال سے گریز کرنا چاہیے۔ اس کے بجائے، GitOps پائپ لائن کے ساتھ، صارف اپنے Kubernetes کلسٹر کو Git کے ذریعے اپ ڈیٹ کر سکتا ہے۔
فوائد میں شامل ہیں:
- ٹھیک ہے۔. اپ ڈیٹس کے ایک گروپ کو لاگو کیا جا سکتا ہے، یکجا کیا جا سکتا ہے اور آخر میں توثیق کی جا سکتی ہے، جو ہمیں ایٹمی تعیناتی کے ہدف کے قریب لاتی ہے۔ اس کے برعکس، اسکرپٹ کا استعمال کنورجنسی کی کوئی گارنٹی فراہم نہیں کرتا ہے (ذیل میں اس پر مزید)۔
- سیکورٹی. Kelsey Hightower: "اپنے Kubernetes کلسٹر تک رسائی کو آٹومیشن ٹولز اور ایڈمنسٹریٹرز تک محدود کریں جو اسے ڈیبگ کرنے یا برقرار رکھنے کے ذمہ دار ہیں۔" بھی دیکھو حفاظت اور تکنیکی وضاحتوں کے ساتھ تعمیل کے بارے میں لاپرواہی سے لکھے ہوئے جینکنز اسکرپٹ سے اسناد چوری کرکے۔
- صارف کا تجربہ. Kubectl Kubernetes آبجیکٹ ماڈل کے میکانکس کو بے نقاب کرتا ہے، جو کافی پیچیدہ ہیں۔ مثالی طور پر، صارفین کو نظام کے ساتھ تجرید کی اعلی سطح پر تعامل کرنا چاہیے۔ یہاں میں دوبارہ کیلسی کا حوالہ دوں گا اور دیکھنے کی سفارش کروں گا۔ .
CI اور CD کے درمیان فرق
GitOps موجودہ CI/CD ماڈلز کو بہتر بناتا ہے۔
ایک جدید CI سرور آرکیسٹریشن ٹول ہے۔ خاص طور پر، یہ CI پائپ لائنوں کو ترتیب دینے کا ایک ٹول ہے۔ ان میں تعمیر، جانچ، ٹرنک میں ضم ہونا وغیرہ شامل ہیں۔ CI سرورز پیچیدہ ملٹی سٹیپ پائپ لائنوں کے انتظام کو خودکار بناتے ہیں۔ ایک عام فتنہ یہ ہے کہ Kubernetes اپ ڈیٹس کے ایک سیٹ کو اسکرپٹ کیا جائے اور اسے پائپ لائن کے حصے کے طور پر چلایا جائے تاکہ کلسٹر میں تبدیلیوں کو آگے بڑھایا جا سکے۔ درحقیقت، بہت سے ماہرین یہی کرتے ہیں۔ تاہم، یہ بہترین نہیں ہے، اور یہاں اس کی وجہ ہے۔
CI کو ٹرنک میں اپ ڈیٹس کو آگے بڑھانے کے لیے استعمال کیا جانا چاہیے، اور CD کو اندرونی طور پر منظم کرنے کے لیے Kubernetes کلسٹر کو ان اپ ڈیٹس کی بنیاد پر خود کو تبدیل کرنا چاہیے۔ ہم اسے کہتے ہیں۔ ، CI پش ماڈل کے برعکس۔ سی ڈی حصہ ہے۔ رن ٹائم آرکیسٹریشن.
CI سرورز کو کبرنیٹس میں براہ راست اپڈیٹس کے ذریعے سی ڈیز کیوں نہیں کرنی چاہئیں
CI جابز کے سیٹ کے طور پر Kubernetes کو براہ راست اپ ڈیٹس آرکیسٹریٹ کرنے کے لیے CI سرور کا استعمال نہ کریں۔ یہ وہ اینٹی پیٹرن ہے جس کے بارے میں ہم بات کر رہے ہیں۔ آپ کے بلاگ پر
آئیے ایلس اور باب کی طرف واپس چلتے ہیں۔
انہیں کن مسائل کا سامنا کرنا پڑا؟ باب کا CI سرور تبدیلیوں کو کلسٹر پر لاگو کرتا ہے، لیکن اگر یہ اس عمل میں کریش ہو جاتا ہے، تو باب کو نہیں معلوم ہوگا کہ کلسٹر کس حالت میں ہے (یا ہونا چاہیے) یا اسے کیسے ٹھیک کیا جائے۔ کامیابی کے معاملے میں بھی ایسا ہی ہوتا ہے۔
آئیے فرض کریں کہ باب کی ٹیم نے ایک نئی تصویر بنائی اور پھر اس تصویر کو تعینات کرنے کے لیے اپنی تعیناتیوں کو پیوند کیا (تمام CI پائپ لائن سے)۔
اگر تصویر عام طور پر بنتی ہے، لیکن پائپ لائن ناکام ہوجاتی ہے، تو ٹیم کو پتہ لگانا ہوگا:
- کیا اپ ڈیٹ شروع ہو گیا ہے؟
- کیا ہم ایک نئی تعمیر شروع کر رہے ہیں؟ کیا یہ غیر ضروری ضمنی اثرات کا باعث بنے گا - ایک ہی ناقابل تغیر تصویر کی دو ساختیں ہونے کے امکان کے ساتھ؟
- کیا ہمیں بلڈ چلانے سے پہلے اگلی اپ ڈیٹ کا انتظار کرنا چاہیے؟
- بالکل غلط کیا ہوا؟ کن مراحل کو دہرانے کی ضرورت ہے (اور کون سے اقدامات کو دہرانا محفوظ ہے)؟
گٹ پر مبنی ورک فلو قائم کرنا اس بات کی ضمانت نہیں دیتا کہ باب کی ٹیم ان مسائل کا سامنا نہیں کرے گی۔ وہ اب بھی کمٹ پش، ٹیگ، یا کسی اور پیرامیٹر سے غلطی کر سکتے ہیں۔ تاہم، یہ نقطہ نظر اب بھی ایک واضح تمام یا کچھ نہیں کے نقطہ نظر کے بہت قریب ہے۔
خلاصہ کرنے کے لیے، یہاں یہ ہے کہ CI سرورز کو CD کے ساتھ ڈیل کیوں نہیں کرنا چاہیے:
- اپ ڈیٹ اسکرپٹ ہمیشہ فیصلہ کن نہیں ہوتے ہیں۔ ان میں غلطیاں کرنا آسان ہے۔
- CI سرورز اعلانیہ کلسٹر ماڈل میں تبدیل نہیں ہوتے ہیں۔
- بے ضمیری کی ضمانت دینا مشکل ہے۔ صارفین کو سسٹم کے گہرے الفاظ کو سمجھنا چاہیے۔
- جزوی ناکامی سے صحت یاب ہونا زیادہ مشکل ہے۔
ہیلم کے بارے میں نوٹ: اگر آپ ہیلم استعمال کرنا چاہتے ہیں تو ہم اسے گٹ اوپس آپریٹر کے ساتھ جوڑنے کی تجویز کرتے ہیں جیسے . اس سے ہم آہنگی کو یقینی بنانے میں مدد ملے گی۔ ہیلم بذات خود نہ تعیین ہے اور نہ ہی جوہری۔
گٹ اوپس کوبرنیٹس کے لیے مسلسل ڈیلیوری کو نافذ کرنے کا بہترین طریقہ ہے۔
ایلس اور باب کی ٹیم نے GitOps کو لاگو کیا اور پتہ چلا کہ سافٹ ویئر پروڈکٹس کے ساتھ کام کرنا، اعلیٰ کارکردگی اور استحکام کو برقرار رکھنا بہت آسان ہو گیا ہے۔ آئیے اس مضمون کو ایک مثال کے ساتھ ختم کرتے ہیں جس میں دکھایا گیا ہے کہ ان کا نیا نقطہ نظر کیسا لگتا ہے۔ ذہن میں رکھیں کہ ہم زیادہ تر ایپلی کیشنز اور خدمات کے بارے میں بات کر رہے ہیں، لیکن GitOps کو پورے پلیٹ فارم کو منظم کرنے کے لیے استعمال کیا جا سکتا ہے۔
Kubernetes کے لیے آپریٹنگ ماڈل
درج ذیل خاکہ کو دیکھیں۔ یہ گٹ اور کنٹینر امیج ریپوزٹری کو دو آرکیسٹریٹڈ لائف سائیکلز کے لیے مشترکہ وسائل کے طور پر پیش کرتا ہے:
- ایک مسلسل انضمام پائپ لائن جو Git پر فائلوں کو پڑھتی اور لکھتی ہے اور کنٹینر امیجز کے ذخیرے کو اپ ڈیٹ کر سکتی ہے۔
- ایک رن ٹائم GitOps پائپ لائن جو انتظام اور مشاہدے کے ساتھ تعیناتی کو یکجا کرتی ہے۔ یہ گٹ پر فائلوں کو پڑھتا اور لکھتا ہے اور کنٹینر کی تصاویر ڈاؤن لوڈ کرسکتا ہے۔
اہم نتائج کیا ہیں؟
- خدشات کی علیحدگی: براہ کرم نوٹ کریں کہ دونوں پائپ لائنیں صرف گٹ یا امیج ریپوزٹری کو اپ ڈیٹ کرکے ہی بات چیت کرسکتی ہیں۔ دوسرے الفاظ میں، CI اور رن ٹائم ماحول کے درمیان ایک فائر وال ہے۔ ہم اسے "غیر متغیر فائر وال" کہتے ہیں (غیر متغیر فائر وال)، چونکہ تمام ریپوزٹری اپ ڈیٹس نئے ورژن بناتے ہیں۔ اس موضوع پر مزید معلومات کے لیے، سلائیڈز 72-87 دیکھیں .
- آپ کوئی بھی CI اور Git سرور استعمال کر سکتے ہیں۔: GitOps کسی بھی جزو کے ساتھ کام کرتا ہے۔ آپ اپنے پسندیدہ CI اور Git سرورز، امیج ریپوزٹریز، اور ٹیسٹ سویٹس کا استعمال جاری رکھ سکتے ہیں۔ مارکیٹ میں تقریباً تمام دیگر مسلسل ڈیلیوری ٹولز کو ان کے اپنے CI/Git سرور یا امیج ریپوزٹری کی ضرورت ہوتی ہے۔ یہ بادل مقامی کی ترقی میں ایک محدود عنصر بن سکتا ہے۔ GitOps کے ساتھ، آپ واقف ٹولز استعمال کر سکتے ہیں۔
- انضمام کے آلے کے طور پر واقعات: جیسے ہی گٹ میں ڈیٹا اپ ڈیٹ ہوتا ہے، ویو فلکس (یا ویو کلاؤڈ آپریٹر) رن ٹائم کو مطلع کرتا ہے۔ جب بھی Kubernetes تبدیلی کے سیٹ کو قبول کرتا ہے، Git کو اپ ڈیٹ کیا جاتا ہے۔ یہ GitOps کے لیے ورک فلو کو منظم کرنے کے لیے ایک سادہ انضمام ماڈل فراہم کرتا ہے، جیسا کہ ذیل میں دکھایا گیا ہے۔
حاصل يہ ہوا
GitOps کسی بھی جدید CI/CD ٹول کو درکار مضبوط اپ ڈیٹ کی ضمانت فراہم کرتا ہے:
- آٹومیشن
- ہم آہنگی
- کمزوری
- عزم
یہ اہم ہے کیونکہ یہ کلاؤڈ مقامی ڈویلپرز کے لیے ایک آپریشنل ماڈل پیش کرتا ہے۔
- نظام کے انتظام اور نگرانی کے روایتی ٹولز رن بک کے اندر کام کرنے والی آپریشن ٹیموں سے وابستہ ہیں۔ (معمول کے طریقہ کار اور کارروائیوں کا ایک سیٹ - تقریبا ترجمہ۔)، ایک مخصوص تعیناتی سے منسلک۔
- کلاؤڈ مقامی انتظام میں، مشاہداتی ٹولز تعیناتیوں کے نتائج کی پیمائش کرنے کا بہترین طریقہ ہیں تاکہ ترقیاتی ٹیم تیزی سے جواب دے سکے۔
ان کی اپنی ٹیموں اور تعیناتی کے منصوبوں کے ساتھ مختلف بادلوں میں بکھرے ہوئے بہت سے کلسٹرز اور بہت سی خدمات کا تصور کریں۔ GitOps اس تمام کثرت کو منظم کرنے کے لیے ایک پیمانے پر متغیر ماڈل پیش کرتا ہے۔
مترجم سے PS
ہمارے بلاگ پر بھی پڑھیں:
- «؛ "
- «؛ "
- «'.
سروے میں صرف رجسٹرڈ صارفین ہی حصہ لے سکتے ہیں۔ ، برائے مہربانی.
کیا آپ GitOps کے بارے میں جانتے تھے کہ یہ دونوں ترجمے Habré پر ظاہر ہونے سے پہلے؟
-
ہاں، میں سب کچھ جانتا تھا۔
-
صرف سطحی طور پر
-
کوئی
35 صارفین نے ووٹ دیا۔ 10 صارفین غیر حاضر رہے۔
ماخذ: www.habr.com