GitOps: ایک اور بز ورڈ یا آٹومیشن میں پیش رفت؟

ہم میں سے اکثر، آئی ٹی بلاگ اسفیئر یا کانفرنس میں ایک اور نئی اصطلاح کو دیکھتے ہوئے، جلد یا بدیر اسی طرح کا سوال پوچھتے ہیں: "یہ کیا ہے؟ صرف ایک اور بز ورڈ، ایک "buzzword" یا کوئی ایسی چیز جو واقعی قریب سے توجہ دینے، مطالعہ کرنے اور نئے افق کے وعدے کے لائق ہے؟ اصطلاح کے ساتھ میرے ساتھ بھی ایسا ہی ہوا۔ GitOps کچھ عرصہ پہلے. کچھ وقت پہلے. بہت سے موجودہ مضامین کے ساتھ ساتھ کمپنی کے ساتھیوں کے علم سے لیس GitLabمیں نے یہ جاننے کی کوشش کی کہ یہ کس قسم کا حیوان ہے، اور عملی طور پر اس کا استعمال کیسا لگتا ہے۔

ویسے، اصطلاح کی نیاپن کے بارے میں GitOps ہمارا حالیہ سروے یہ بھی کہتا ہے: سروے میں شامل نصف سے زیادہ نے ابھی تک اس کے اصولوں کے ساتھ کام کرنا شروع نہیں کیا۔

لہذا، بنیادی ڈھانچے کے انتظام کا مسئلہ نیا نہیں ہے. بہت سے کلاؤڈ فراہم کرنے والے ایک درجن سالوں سے عام لوگوں کے لیے دستیاب ہیں اور ایسا لگتا ہے کہ بنیادی ڈھانچے کے لیے ذمہ دار ٹیموں کے کام کو آسان اور سیدھا بنانا چاہیے تھا۔ تاہم، جب ایپلی کیشن ڈویلپمنٹ کے عمل سے موازنہ کیا جائے (جہاں آٹومیشن نئی سطحوں پر پہنچ رہا ہے)، بنیادی ڈھانچے کے منصوبوں میں اب بھی اکثر بہت سے دستی کام شامل ہوتے ہیں اور خاص علم اور مہارت کی ضرورت ہوتی ہے، خاص طور پر آج کی غلطیوں کو برداشت کرنے، لچک، اسکیل ایبلٹی اور لچک کی ضروریات کے پیش نظر۔

کلاؤڈ سروسز نے ان تقاضوں کو بہت کامیابی کے ساتھ پورا کیا اور یہی وہ تھے جنہوں نے نقطہ نظر کی ترقی کو ایک اہم تحریک دی۔ IAC. یہ بات سمجھ میں آتی ہے۔ سب کے بعد، انہوں نے ایک مکمل طور پر مجازی ڈیٹا سینٹر کو ترتیب دینا ممکن بنایا: کوئی جسمانی سرور، ریک، یا نیٹ ورک کے اجزاء نہیں ہیں؛ پورے بنیادی ڈھانچے کو سکرپٹ اور ترتیب فائلوں کا استعمال کرتے ہوئے بیان کیا جا سکتا ہے.

تو بالکل کیا فرق ہے؟ GitOps سے IAC? اس سوال کے ساتھ ہی میں نے اپنی تحقیقات کا آغاز کیا۔ ساتھیوں کے ساتھ بات کرنے کے بعد، میں مندرجہ ذیل موازنہ کے ساتھ آنے کے قابل تھا:

GitOps

IAC

تمام کوڈ گٹ ریپوزٹری میں محفوظ ہیں۔

کوڈ ورژن اختیاری ہے۔

اعلانیہ کوڈ کی تفصیل / Idempotency

اعلانیہ اور لازمی وضاحتیں دونوں قابل قبول ہیں۔

تبدیلیاں ضم کرنے کی درخواست / پل کی درخواست کے طریقہ کار کا استعمال کرتے ہوئے اثر انداز ہوتی ہیں۔

معاہدہ، منظوری اور تعاون اختیاری ہیں۔

اپ ڈیٹ رول آؤٹ کا عمل خودکار ہے۔

اپ ڈیٹ رول آؤٹ کا عمل معیاری نہیں ہے (خودکار، دستی، فائلوں کو کاپی کرنا، کمانڈ لائن کا استعمال کرتے ہوئے، وغیرہ)

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

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

تجسس GitOpsیقیناً، اس حقیقت میں بھی کہ یہ کسی بھی وینڈر سے وابستہ پروڈکٹ، پلگ ان یا پلیٹ فارم نہیں ہے۔ یہ ایک نمونہ اور اصولوں کا ایک مجموعہ ہے، جیسا کہ ایک اور اصطلاح جس سے ہم واقف ہیں: DevOps۔

کمپنی GitLab ہم نے اس نئی اصطلاح کی دو تعریفیں تیار کی ہیں: نظریاتی اور عملی۔ آئیے نظریاتی کے ساتھ شروع کریں:

GitOps ایک طریقہ کار ہے جو ایپلی کیشن کی ترقی کے لیے استعمال ہونے والے بہترین DevOps اصولوں کو لیتا ہے، جیسے کہ ورژن کنٹرول، تعاون، آرکیسٹریشن، CI/CD، اور ان کا اطلاق خودکار بنیادی ڈھانچے کے انتظام کے چیلنجوں پر ہوتا ہے۔

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

ایک عملی نقطہ نظر سے، ہم بیان کرتے ہیں GitOps مندرجہ ذیل

ہم پہلے ہی اس فارمولے کے کلیدی اجزاء میں سے ایک کے طور پر بنیادی ڈھانچے پر بطور کوڈ بحث کر چکے ہیں۔ آئیے باقی شرکاء کا تعارف کراتے ہیں۔

ضم کرنے کی درخواست (متبادل نام پل کی درخواست)۔ عمل کی شرائط میں، MR کوڈ میں تبدیلیاں لاگو کرنے اور پھر شاخوں کو ضم کرنے کی درخواست ہے۔ لیکن ان ٹولز کے لحاظ سے جو ہم استعمال کرتے ہیں، یہ تمام تبدیلیوں کی مکمل تصویر حاصل کرنے کا ایک موقع ہے: نہ صرف کمٹ کی ایک خاص تعداد سے جمع کردہ کوڈ میں فرق، بلکہ سیاق و سباق، ٹیسٹ کے نتائج، اور حتمی متوقع نتیجہ. اگر ہم انفراسٹرکچر کوڈ کے بارے میں بات کر رہے ہیں، تو ہمیں اس بات میں دلچسپی ہے کہ بنیادی ڈھانچہ کس طرح بدلے گا، کتنے نئے وسائل شامل کیے جائیں گے یا ہٹائے جائیں گے، تبدیل کیے جائیں گے۔ ترجیحا کچھ زیادہ آسان اور پڑھنے میں آسان فارمیٹ میں۔ کلاؤڈ فراہم کرنے والوں کے لیے، یہ جاننا اچھا خیال ہے کہ اس تبدیلی کے مالی اثرات کیا ہوں گے۔

لیکن MR تعاون، تعامل اور مواصلات کا ایک ذریعہ بھی ہے۔ وہ جگہ جہاں چیک اینڈ بیلنس کا نظام چلتا ہے۔ سادہ تبصروں سے رسمی منظوریوں اور منظوریوں تک۔

ٹھیک ہے، آخری جزو: CI/CD، جیسا کہ ہم پہلے ہی جانتے ہیں، بنیادی ڈھانچے کی تبدیلیوں اور جانچ کے عمل کو خودکار بنانا ممکن بناتا ہے (سادہ نحو کی جانچ سے لے کر زیادہ پیچیدہ جامد کوڈ تجزیہ تک)۔ اور بعد میں بڑھے ہوئے پتہ لگانے میں بھی: نظام کی حقیقی اور مطلوبہ حالت کے درمیان فرق۔ مثال کے طور پر، غیر مجاز دستی تبدیلیوں یا نظام کی ناکامی کے نتیجے میں۔

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

اور اگر آپ اچانک اس میں دلچسپی لیتے ہیں کہ یہ سب عملی طور پر کیسے نظر آتا ہے، تو میں آپ کو دعوت دیتا ہوں کہ ہمارے ماسٹر کلاس، جس میں میں آپ کو مرحلہ وار بتاتا ہوں کہ گٹ لیب کو کیسے استعمال کیا جائے:

• GitOps کے بنیادی اصولوں کو نافذ کریں۔

• کلاؤڈ انفراسٹرکچر بنائیں اور اس میں تبدیلیاں کریں (Yandex Cloud کی مثال کا استعمال کرتے ہوئے)

• فعال نگرانی کا استعمال کرتے ہوئے مطلوبہ حالت سے سسٹم کے بڑھنے کا خودکار پتہ لگانا

https://bit.ly/34tRpwZ

ماخذ: www.habr.com