نوٹ. ترجمہ: Kubernetes کمیونٹی میں، GitOps نامی ایک رجحان واضح مقبولیت حاصل کر رہا ہے، جیسا کہ ہم نے ذاتی طور پر دیکھا ہے، KubeCon Europe 2019۔ یہ اصطلاح نسبتاً حالیہ تھی۔ Weaveworks کے سربراہ کی طرف سے - Alexis Richardson - اور اس کا مطلب ہے آپریشنل مسائل کو حل کرنے کے لیے ڈویلپرز (بنیادی طور پر Git، اس لیے نام) سے واقف ٹولز کا استعمال۔ خاص طور پر، ہم Kubernetes کے آپریشن کے بارے میں بات کر رہے ہیں اس کی کنفیگریشنز کو Git میں محفوظ کر کے اور خود بخود کلسٹر میں تبدیلیوں کو رول آؤٹ کر کے۔ Matthias Jg اس مضمون میں اس رول آؤٹ کے بارے میں دو طریقوں کے بارے میں بات کرتا ہے۔
گزشتہ سال، (درحقیقت، رسمی طور پر یہ اگست 2017 میں ہوا - تقریباً ترجمہ۔) Kubernetes میں ایپلی کیشنز کی تعیناتی کا ایک نیا طریقہ ہے۔ اسے GitOps کہا جاتا ہے، اور یہ اس بنیادی خیال پر مبنی ہے کہ گٹ ریپوزٹری کے محفوظ ماحول میں تعیناتی ورژن کو ٹریک کیا جاتا ہے۔
اس نقطہ نظر کے اہم فوائد درج ذیل ہیں::
- تعیناتی ورژن اور تبدیلی کی تاریخ. پورے کلسٹر کی حالت گٹ ریپوزٹری میں محفوظ ہے، اور تعیناتیوں کو صرف کمٹ کے ذریعے اپ ڈیٹ کیا جاتا ہے۔ اس کے علاوہ، تمام تبدیلیوں کو کمٹ ہسٹری کا استعمال کرتے ہوئے ٹریک کیا جا سکتا ہے۔
- واقف Git کمانڈز کا استعمال کرتے ہوئے رول بیکس. سادہ
git resetآپ کو تعیناتیوں میں تبدیلیوں کو دوبارہ ترتیب دینے کی اجازت دیتا ہے؛ ماضی کی حالتیں ہمیشہ دستیاب رہتی ہیں۔ - تیار رسائی کنٹرول. عام طور پر، گٹ سسٹم میں بہت زیادہ حساس ڈیٹا ہوتا ہے، اس لیے زیادہ تر کمپنیاں اس کی حفاظت پر خصوصی توجہ دیتی ہیں۔ اس کے مطابق، یہ تحفظ تعیناتیوں کے ساتھ آپریشنز پر بھی لاگو ہوتا ہے۔
- تعیناتیوں کے لیے پالیسیاں. زیادہ تر گٹ سسٹم مقامی طور پر شاخ در شاخ کی پالیسیوں کی حمایت کرتے ہیں — مثال کے طور پر، صرف پل کی درخواستیں ہی ماسٹر کو اپ ڈیٹ کر سکتی ہیں، اور تبدیلیوں کا جائزہ لینا چاہیے اور ٹیم کے کسی دوسرے رکن کو قبول کرنا چاہیے۔ رسائی کنٹرول کے ساتھ، وہی پالیسیاں تعیناتی اپ ڈیٹس پر لاگو ہوتی ہیں۔
جیسا کہ آپ دیکھ سکتے ہیں، GitOps طریقہ کے بہت سے فوائد ہیں۔ پچھلے سال کے دوران، دو طریقوں نے خاص مقبولیت حاصل کی ہے۔ ایک پش بیسڈ ہے، دوسرا پل بیسڈ ہے۔ اس سے پہلے کہ ہم ان کو دیکھیں، آئیے پہلے دیکھتے ہیں کہ کبرنیٹس کی مخصوص تعیناتیاں کیسی نظر آتی ہیں۔
تعیناتی کے طریقے
حالیہ برسوں میں، Kubernetes نے تعیناتیوں کے لیے مختلف طریقے اور ٹولز قائم کیے ہیں:
- مقامی کبرنیٹس/کسٹمائز ٹیمپلیٹس پر مبنی. Kubernetes پر ایپلیکیشنز کو تعینات کرنے کا یہ سب سے آسان طریقہ ہے۔ ڈویلپر بنیادی YAML فائلیں بناتا ہے اور ان کا اطلاق کرتا ہے۔ ایک ہی ٹیمپلیٹس کو مسلسل دوبارہ لکھنے سے چھٹکارا پانے کے لیے، کسٹمائز تیار کیا گیا تھا (یہ کبرنیٹس ٹیمپلیٹس کو ماڈیولز میں بدل دیتا ہے)۔ نوٹ. ترجمہ: Kustomize کو kubectl کے ساتھ ضم کر دیا گیا ہے۔ .
- ہیلم چارٹس. ہیلم چارٹس آپ کو ٹیمپلیٹس کے سیٹ، انیٹ کنٹینرز، سائڈ کارز وغیرہ بنانے کی اجازت دیتے ہیں، جو ٹیمپلیٹ پر مبنی اپروچ کے مقابلے میں زیادہ لچکدار حسب ضرورت اختیارات کے ساتھ ایپلی کیشنز کو تعینات کرنے کے لیے استعمال ہوتے ہیں۔ یہ طریقہ ٹیمپلیٹڈ YAML فائلوں پر مبنی ہے۔ ہیلم انہیں مختلف پیرامیٹرز سے بھرتا ہے اور پھر انہیں ٹلر کو بھیجتا ہے، ایک کلسٹر جزو جو انہیں کلسٹر میں تعینات کرتا ہے اور اپ ڈیٹس اور رول بیکس کی اجازت دیتا ہے۔ اہم بات یہ ہے کہ ہیلم بنیادی طور پر صرف مطلوبہ اقدار کو ٹیمپلیٹس میں داخل کرتا ہے اور پھر انہیں اسی طرح لاگو کرتا ہے جیسا کہ روایتی انداز میں کیا جاتا ہے۔ (یہ سب کیسے کام کرتا ہے اور آپ اسے ہمارے میں کیسے استعمال کرسکتے ہیں اس کے بارے میں مزید پڑھیں - تقریبا. ترجمہ). مختلف قسم کے ریڈی میڈ ہیلم چارٹس ہیں جن میں کاموں کی ایک وسیع رینج شامل ہے۔
- متبادل ٹولز. بہت سے متبادل اوزار ہیں. ان سب میں جو چیز مشترک ہے وہ یہ ہے کہ وہ کچھ ٹیمپلیٹ فائلوں کو Kubernetes پڑھنے کے قابل YAML فائلوں میں تبدیل کرتے ہیں اور پھر انہیں استعمال کرتے ہیں۔
اپنے کام میں، ہم مسلسل ہیلم چارٹس کو اہم ٹولز کے لیے استعمال کرتے ہیں (چونکہ ان کے پاس بہت سی چیزیں پہلے سے ہی تیار ہیں، جو زندگی کو بہت آسان بناتی ہیں) اور "خالص" Kubernetes YAML فائلوں کو اپنی ایپلی کیشنز کی تعیناتی کے لیے استعمال کرتے ہیں۔
پل اینڈ پش
اپنی حالیہ بلاگ پوسٹس میں سے ایک میں، میں نے ٹول متعارف کرایا ، جو آپ کو گٹ ریپوزٹری میں ٹیمپلیٹس کا ارتکاب کرنے اور کنٹینر کے ہر کمٹ یا پش کے بعد تعیناتی کو اپ ڈیٹ کرنے کی اجازت دیتا ہے۔ میرا تجربہ بتاتا ہے کہ یہ ٹول پل اپروچ کو فروغ دینے میں ایک اہم چیز ہے، اس لیے میں اکثر اس کا حوالہ دوں گا۔ اگر آپ اسے استعمال کرنے کے طریقے کے بارے میں مزید جاننا چاہتے ہیں تو، یہاں .
این بی! GitOps استعمال کرنے کے تمام فوائد دونوں طریقوں کے لیے یکساں ہیں۔
ھیںچو پر مبنی نقطہ نظر
پل اپروچ اس حقیقت پر مبنی ہے کہ تمام تبدیلیاں کلسٹر کے اندر سے لاگو ہوتی ہیں۔ کلسٹر کے اندر ایک آپریٹر ہے جو متعلقہ گٹ اور ڈوکر رجسٹری ریپوزٹری کو باقاعدگی سے چیک کرتا ہے۔ اگر ان میں کوئی تبدیلی آتی ہے تو، کلسٹر کی حالت اندرونی طور پر اپ ڈیٹ ہوجاتی ہے۔ یہ عمل عام طور پر بہت محفوظ سمجھا جاتا ہے، کیونکہ کسی بھی بیرونی کلائنٹ کو کلسٹر ایڈمنسٹریٹر کے حقوق تک رسائی حاصل نہیں ہے۔
پیشہ:
- کسی بھی بیرونی کلائنٹ کے پاس کلسٹر میں تبدیلیاں کرنے کا حق نہیں ہے؛ تمام اپ ڈیٹس اندر سے رول آؤٹ کر دیے جاتے ہیں۔
- کچھ ٹولز آپ کو ہیلم چارٹ اپ ڈیٹس کو سنکرونائز کرنے اور انہیں کلسٹر سے لنک کرنے کی بھی اجازت دیتے ہیں۔
- ڈوکر رجسٹری کو نئے ورژن کے لیے اسکین کیا جا سکتا ہے۔ اگر کوئی نئی تصویر دستیاب ہے تو، گٹ ریپوزٹری اور تعیناتی کو نئے ورژن میں اپ ڈیٹ کر دیا جاتا ہے۔
- پل ٹولز کو مختلف گٹ ریپوزٹریز اور اجازتوں کے ساتھ مختلف نام کی جگہوں پر تقسیم کیا جا سکتا ہے۔ اس کا شکریہ، ایک ملٹیٹیننٹ ماڈل استعمال کیا جا سکتا ہے. مثال کے طور پر، ٹیم A نام کی جگہ A استعمال کر سکتی ہے، ٹیم B نام کی جگہ B استعمال کر سکتی ہے، اور بنیادی ڈھانچے کی ٹیم عالمی جگہ استعمال کر سکتی ہے۔
- ایک اصول کے طور پر، اوزار بہت ہلکے ہیں.
- آپریٹر جیسے ٹولز کے ساتھ مل کر ، رازوں کو گٹ ریپوزٹری میں انکرپٹڈ اسٹور کیا جاسکتا ہے اور کلسٹر کے اندر بازیافت کیا جاسکتا ہے۔
- CD پائپ لائنوں سے کوئی تعلق نہیں ہے کیونکہ تعیناتیاں کلسٹر کے اندر ہوتی ہیں۔
Cons:
- ہیلم چارٹس سے تعیناتی کے رازوں کو منظم کرنا معمول کے مقابلے میں زیادہ مشکل ہے، کیونکہ انہیں پہلے سیل شدہ رازوں کی شکل میں پیدا کرنا ہوتا ہے، پھر ایک اندرونی آپریٹر کے ذریعے ڈکرپٹ کیا جاتا ہے، اور اس کے بعد ہی وہ پل ٹول کے لیے دستیاب ہوتے ہیں۔ پھر آپ ریلیز کو ہیلم میں پہلے سے تعینات رازوں میں اقدار کے ساتھ چلا سکتے ہیں۔ سب سے آسان طریقہ یہ ہے کہ تعیناتی کے لیے استعمال ہونے والی تمام ہیلم ویلیوز کے ساتھ ایک راز بنائیں، اسے ڈکرپٹ کریں اور اسے گِٹ کے ساتھ کمٹ کریں۔
- جب آپ پل اپروچ لیتے ہیں، تو آپ ٹولز سے بندھے ہو جاتے ہیں۔ یہ ایک کلسٹر میں تعیناتی کے عمل کو اپنی مرضی کے مطابق کرنے کی صلاحیت کو محدود کرتا ہے۔ مثال کے طور پر، Kustomize اس حقیقت سے پیچیدہ ہے کہ اسے آخری ٹیمپلیٹس کے Git کے لیے پرعزم ہونے سے پہلے چلنا چاہیے۔ میں یہ نہیں کہہ رہا ہوں کہ آپ اسٹینڈ لون ٹولز استعمال نہیں کر سکتے، لیکن ان کو آپ کی تعیناتی کے عمل میں ضم کرنا زیادہ مشکل ہے۔
پش پر مبنی نقطہ نظر
پش اپروچ میں، ایک بیرونی سسٹم (بنیادی طور پر سی ڈی پائپ لائنز) گٹ ریپوزٹری سے وابستگی کے بعد یا پچھلی CI پائپ لائن کامیاب ہونے کے بعد کلسٹر میں تعیناتیاں شروع کرتا ہے۔ اس نقطہ نظر میں، نظام کو کلسٹر تک رسائی حاصل ہے۔
پیشہ:
- سیکیورٹی کا تعین گٹ ریپوزٹری اور پائپ لائن کے ذریعے کیا جاتا ہے۔
- ہیلم چارٹس کو تعینات کرنا آسان ہے اور ہیلم پلگ ان کو سپورٹ کرتا ہے۔
- رازوں کا انتظام کرنا آسان ہے کیونکہ رازوں کو پائپ لائنوں میں استعمال کیا جا سکتا ہے اور گٹ میں انکرپٹڈ بھی ذخیرہ کیا جا سکتا ہے (صارف کی ترجیحات پر منحصر ہے)۔
- کسی مخصوص ٹول سے کوئی تعلق نہیں ہے، کیونکہ کسی بھی قسم کا استعمال کیا جا سکتا ہے۔
- کنٹینر ورژن اپ ڈیٹس کو بلڈ پائپ لائن کے ذریعے شروع کیا جا سکتا ہے۔
Cons:
- کلسٹر تک رسائی کا ڈیٹا بلڈ سسٹم کے اندر ہے۔
- پل کے عمل کے ساتھ تعیناتی کنٹینرز کو اپ ڈیٹ کرنا اب بھی آسان ہے۔
- CD سسٹم پر بہت زیادہ انحصار، چونکہ ہمیں جن پائپ لائنوں کی ضرورت ہے وہ اصل میں Gitlab Runners کے لیے لکھی گئی ہیں، اور پھر ٹیم Azure DevOps یا Jenkins میں جانے کا فیصلہ کرتی ہے... اور اسے بڑی تعداد میں تعمیراتی پائپ لائنوں کو منتقل کرنا پڑے گا۔
نتائج: دھکا یا ھیںچو؟
جیسا کہ عام طور پر ہوتا ہے، ہر نقطہ نظر کے اپنے فوائد اور نقصانات ہوتے ہیں۔ کچھ کام ایک کے ساتھ آسان اور دوسرے کے ساتھ زیادہ مشکل ہوتے ہیں۔ پہلے تو میں دستی طور پر تعیناتیاں کر رہا تھا، لیکن جب مجھے ویو فلکس کے بارے میں کچھ مضامین ملے، میں نے تمام منصوبوں کے لیے GitOps کے عمل کو نافذ کرنے کا فیصلہ کیا۔ بنیادی ٹیمپلیٹس کے لیے یہ آسان تھا، لیکن پھر میں نے ہیلم چارٹس کے ساتھ مشکلات کا سامنا کرنا شروع کیا۔ اس وقت، Weave Flux نے ہیلم چارٹ آپریٹر کا صرف ایک ابتدائی ورژن پیش کیا تھا، لیکن اب بھی کچھ کام دستی طور پر راز بنانے اور انہیں لاگو کرنے کی ضرورت کی وجہ سے زیادہ مشکل ہیں۔ آپ بحث کر سکتے ہیں کہ پل اپروچ بہت زیادہ محفوظ ہے کیونکہ کلسٹر کی اسناد کلسٹر سے باہر قابل رسائی نہیں ہیں، جس سے یہ اتنا زیادہ محفوظ ہو جاتا ہے کہ یہ اضافی کوشش کے قابل ہے۔
کچھ سوچنے کے بعد میں غیر متوقع طور پر اس نتیجے پر پہنچا کہ ایسا نہیں ہے۔ اگر ہم ان اجزاء کے بارے میں بات کرتے ہیں جن کو زیادہ سے زیادہ تحفظ کی ضرورت ہوتی ہے، تو اس فہرست میں خفیہ اسٹوریج، CI/CD سسٹمز، اور Git repositories شامل ہوں گی۔ ان کے اندر کی معلومات بہت کمزور ہیں اور انہیں زیادہ سے زیادہ تحفظ کی ضرورت ہے۔ مزید برآں، اگر کوئی آپ کے گٹ ریپوزٹری میں داخل ہوتا ہے اور وہاں کوڈ کو آگے بڑھا سکتا ہے، تو وہ جو چاہیں تعینات کر سکتے ہیں (چاہے وہ پل یا پش ہو) اور کلسٹر کے سسٹمز میں گھس سکتے ہیں۔ اس طرح، سب سے اہم اجزاء جن کو محفوظ کرنے کی ضرورت ہے وہ ہیں گٹ ریپوزٹری اور CI/CD سسٹمز، نہ کہ کلسٹر اسناد۔ اگر آپ کے پاس اس قسم کے سسٹمز کے لیے اچھی طرح سے ترتیب شدہ پالیسیاں اور سیکیورٹی کنٹرولز ہیں، اور کلسٹر اسناد کو صرف پائپ لائنوں میں راز کے طور پر نکالا جاتا ہے، تو پل اپروچ کی اضافی سیکیورٹی اتنی قیمتی نہیں ہوسکتی ہے جتنا کہ اصل میں سوچا گیا تھا۔
لہذا، اگر پل اپروچ زیادہ محنتی ہے اور حفاظتی فائدہ فراہم نہیں کرتا ہے، تو کیا صرف پش اپروچ استعمال کرنا منطقی نہیں ہے؟ لیکن کوئی یہ بحث کر سکتا ہے کہ پش اپروچ میں آپ سی ڈی سسٹم سے بہت زیادہ جڑے ہوئے ہیں اور، شاید، ایسا نہ کرنا ہی بہتر ہے تاکہ مستقبل میں ہجرت کرنا آسان ہو۔
میری رائے میں (ہمیشہ کی طرح)، آپ کو وہ چیز استعمال کرنی چاہیے جو کسی خاص کیس کے لیے سب سے زیادہ موزوں ہو یا جوڑیں۔ ذاتی طور پر، میں دونوں طریقوں کا استعمال کرتا ہوں: پل پر مبنی تعیناتیوں کے لیے Weave Flux جس میں زیادہ تر ہماری اپنی خدمات شامل ہیں، اور ہیلم اور پلگ انز کے ساتھ ایک پش اپروچ، جس سے ہیلم چارٹس کو کلسٹر پر لاگو کرنا آسان ہو جاتا ہے اور آپ کو بغیر کسی رکاوٹ کے راز تخلیق کرنے کی اجازت ملتی ہے۔ میرے خیال میں تمام معاملات کے لیے کبھی بھی ایک ہی حل موزوں نہیں ہوگا، کیونکہ ہمیشہ بہت سی باریکیاں ہوتی ہیں اور وہ مخصوص اطلاق پر منحصر ہوتی ہیں۔ یہ کہا جا رہا ہے، میں GitOps کی انتہائی سفارش کرتا ہوں - یہ زندگی کو بہت آسان بناتا ہے اور سیکیورٹی کو بہتر بناتا ہے۔
مجھے امید ہے کہ اس موضوع پر میرا تجربہ آپ کو یہ فیصلہ کرنے میں مدد کرے گا کہ آپ کی قسم کی تعیناتی کے لیے کون سا طریقہ زیادہ موزوں ہے، اور مجھے آپ کی رائے سن کر خوشی ہوگی۔
مترجم کی طرف سے PS نوٹ
پل ماڈل کا منفی پہلو یہ ہے کہ گٹ میں پیش کردہ مینی فیسٹس ڈالنا مشکل ہے، لیکن اس میں کوئی کمی نہیں ہے کہ پل ماڈل میں سی ڈی پائپ لائن رول آؤٹ سے الگ رہتی ہے اور بنیادی طور پر ایک زمرہ پائپ لائن بن جاتی ہے۔ لگاتار اپلائی کریں۔. لہذا، تمام تعیناتیوں سے ان کی حیثیت کو جمع کرنے اور کسی نہ کسی طرح لاگز/سٹیٹس تک رسائی فراہم کرنے کے لیے اور بھی زیادہ کوشش کی ضرورت ہوگی، ترجیحا سی ڈی سسٹم کے حوالے سے۔
اس لحاظ سے، پش ماڈل ہمیں رول آؤٹ کی کم از کم کچھ ضمانتیں فراہم کرنے کی اجازت دیتا ہے، کیونکہ پائپ لائن کی زندگی کو رول آؤٹ کی زندگی کے برابر بنایا جا سکتا ہے۔
ہم نے دونوں ماڈلز کو آزمایا اور مضمون کے مصنف کے طور پر اسی نتیجے پر پہنچے:
- پل ماڈل ہمارے لیے بڑی تعداد میں کلسٹرز پر سسٹم کے اجزاء کی اپ ڈیٹس کو منظم کرنے کے لیے موزوں ہے (دیکھیں۔ ).
- GitLab CI پر مبنی پش ماڈل ہیلم چارٹس کا استعمال کرتے ہوئے ایپلی کیشنز کو رول آؤٹ کرنے کے لیے موزوں ہے۔ ایک ہی وقت میں، پائپ لائنوں کے اندر تعیناتیوں کے رول آؤٹ کو ٹول کا استعمال کرتے ہوئے مانیٹر کیا جاتا ہے۔ . ویسے، ہمارے اس پروجیکٹ کے تناظر میں، جب ہم نے KubeCon Europe'19 میں اپنے اسٹینڈ پر DevOps انجینئرز کے اہم مسائل پر بات کی تو ہم نے مسلسل "GitOps" کو سنا۔
مترجم سے پی پی ایس
ہمارے بلاگ پر بھی پڑھیں:
- «؛ "
- «؛ "
- «؛ "
- «'.
سروے میں صرف رجسٹرڈ صارفین ہی حصہ لے سکتے ہیں۔ ، برائے مہربانی.
کیا آپ GitOps استعمال کر رہے ہیں؟
-
جی ہاں، نقطہ نظر ھیںچو
-
جی ہاں، دھکا
-
ہاں، پل + پش
-
ہاں، کچھ اور
-
کوئی
30 صارفین نے ووٹ دیا۔ 10 صارفین غیر حاضر رہے۔
ماخذ: www.habr.com