ابتدائی افراد کے لیے پانچ مراحل میں اپنی پہلی DevOps چین بنانا۔
ڈی او اوپس بہت سست، منقطع اور بصورت دیگر مسائل پیدا کرنے والے ترقیاتی عمل کے لیے ایک علاج بن گیا ہے۔ لیکن آپ کو DevOps میں کم سے کم علم کی ضرورت ہے۔ یہ تصورات کا احاطہ کرے گا جیسے DevOps چین اور پانچ مراحل میں سے ایک کیسے بنایا جائے۔ یہ مکمل گائیڈ نہیں ہے، بلکہ صرف ایک "مچھلی" ہے جسے بڑھایا جا سکتا ہے۔ آئیے تاریخ سے آغاز کرتے ہیں۔
DevOps سے میرا تعارف
میں Citi گروپ میں کلاؤڈز کے ساتھ کام کرتا تھا اور Citi کے کلاؤڈ انفراسٹرکچر کو منظم کرنے کے لیے ایک IaaS ویب ایپلیکیشن تیار کرتا تھا، لیکن میں ہمیشہ سے اس بات میں دلچسپی رکھتا ہوں کہ ڈویلپمنٹ چین کو کس طرح بہتر بنایا جائے اور ڈویلپرز کے درمیان ثقافت کو بہتر بنایا جائے۔ گریگ لیوینڈر، ہمارے CTO برائے کلاؤڈ آرکیٹیکچر اور انفراسٹرکچر نے مجھے اس کتاب کی سفارش کی۔ . یہ DevOps اصولوں کی خوبصورتی سے وضاحت کرتا ہے اور ایک ناول کی طرح پڑھتا ہے۔
پیچھے کی میز سے پتہ چلتا ہے کہ کمپنیاں کتنی بار نئے ورژن تیار کرتی ہیں:
ایمیزون، گوگل اور نیٹ فلکس اتنا رول آؤٹ کیسے کرتے ہیں؟ اور یہ آسان ہے: انہوں نے اندازہ لگایا کہ تقریباً کامل DevOps چین کیسے بنایا جائے۔
Citi میں ہمارے لیے حالات بہت مختلف تھے جب تک کہ ہم نے DevOps پر سوئچ نہیں کیا۔ تب میری ٹیم کا ماحول مختلف تھا، لیکن ہم نے ڈویلپمنٹ سرور کو دستی طور پر ڈیلیوری کی۔ تمام ڈویلپرز کو IBM WebSphere Application Server Community Edition پر مبنی صرف ایک ڈویلپمنٹ سرور تک رسائی حاصل تھی۔ فراہم کرنے کی بیک وقت کوشش کے ساتھ، سرور "گر گیا"، اور ہر بار ہمیں آپس میں "تکلیف کے ساتھ" گفت و شنید کرنی پڑی۔ ہمارے پاس ٹیسٹوں کے ساتھ کوڈ کی ناکافی کوریج بھی تھی، دستی ڈیلیوری کا وقت لگتا تھا، اور کسی کام یا کلائنٹ کی ضرورت کی مدد سے کوڈ کی ترسیل کو ٹریک کرنے کا کوئی طریقہ نہیں تھا۔
یہ واضح تھا کہ فوری طور پر کچھ کرنے کی ضرورت ہے، اور مجھے ایک ہم خیال ساتھی ملا۔ ہم نے مل کر پہلا DevOps سلسلہ بنانے کا فیصلہ کیا - اس نے ایک ورچوئل مشین اور ایک Tomcat ایپلیکیشن سرور قائم کیا، اور میں نے Jenkins، Atlassian Jira اور BitBucket کے ساتھ انضمام کے ساتھ ساتھ ٹیسٹ کے ساتھ کوڈ کوریج کا خیال رکھا۔ پروجیکٹ کامیاب رہا: ہم نے ڈیولپمنٹ چین کو مکمل طور پر خودکار بنایا، ڈیولپمنٹ سرور پر تقریباً 100% اپ ٹائم حاصل کیا، ٹیسٹ کے ساتھ کوڈ کوریج کی نگرانی اور اسے بہتر بنانے کے قابل تھے، اور Git برانچ کو جیرا کی ترسیل اور ایشو سے جوڑا جا سکتا ہے۔ اور تقریباً تمام ٹولز جو ہم DevOps چین بنانے کے لیے استعمال کرتے تھے وہ اوپن سورس تھے۔
درحقیقت، زنجیر کو آسان بنایا گیا تھا، کیونکہ ہم نے جینکنز یا انسیبل کا استعمال کرتے ہوئے ایڈوانس کنفیگریشنز کا اطلاق بھی نہیں کیا۔ لیکن ہم کامیاب ہو گئے۔ شاید یہ اصول کا نتیجہ ہے۔ (عرف 80/20 اصول)۔
DevOps اور CI/CD سلسلہ کی مختصر تفصیل
DevOps کی مختلف تعریفیں ہیں۔ DevOps، Agile کی طرح، مختلف مضامین شامل ہیں۔ لیکن زیادہ تر لوگ درج ذیل تعریف سے متفق ہوں گے: DevOps سافٹ ویئر ڈویلپمنٹ کا ایک طریقہ، یا لائف سائیکل ہے، جس کا بنیادی اصول ایک ایسا کلچر بنانا ہے جہاں ڈویلپرز اور دیگر ملازمین "ایک ہی طول موج پر" ہوں، دستی مزدوری خودکار ہو، ہر کوئی وہی کرتا ہے جس میں وہ بہترین ہوتا ہے، ترسیل کی فریکوئنسی بڑھتی ہے، کام کی پیداواری صلاحیت بڑھتی ہے، لچک بڑھتی ہے۔
اگرچہ DevOps ماحول بنانے کے لیے اکیلے ٹولز کافی نہیں ہیں، لیکن وہ ناگزیر ہیں۔ ان میں سب سے اہم مسلسل انضمام اور مسلسل ترسیل (CI/CD) ہے۔ ہر ماحول کے سلسلے میں مختلف مراحل ہوتے ہیں (جیسے DEV (ترقی)، INT (انضمام)، TST (ٹیسٹنگ)، QA (معیار کی یقین دہانی)، UAT (صارف کی قبولیت کی جانچ)، STG (تیاری)، PROD (استعمال) ، دستی کام خودکار ہوتے ہیں، ڈویلپرز کوالٹی کوڈ تیار کر سکتے ہیں، ڈیلیور کر سکتے ہیں، اور آسانی سے دوبارہ تعمیر کر سکتے ہیں۔
یہ نوٹ بیان کرتا ہے کہ کس طرح پانچ مراحل میں DevOps چین بنایا جائے، جیسا کہ نیچے دی گئی تصویر میں اوپن سورس ٹولز کا استعمال کرتے ہوئے دکھایا گیا ہے۔
اب کام کی طرف آ جائو.
مرحلہ 1: CI/CD پلیٹ فارم
سب سے پہلے، آپ کو CI/CD ٹول کی ضرورت ہے۔ جینکنز ایک MIT کا لائسنس یافتہ، اوپن سورس CI/CD ٹول ہے جو جاوا میں لکھا گیا ہے جس نے DevOps تحریک کو مقبول بنایا اور CICD کے لیے ڈی فیکٹو سٹینڈرڈ بن گیا ہے۔
جینکنز کیا ہے؟ تصور کریں کہ آپ کے پاس متعدد خدمات اور ٹولز کے لیے جادوئی کنٹرول پینل ہے۔ اپنے طور پر، جینکنز جیسا CI/CD ٹول بیکار ہے، لیکن مختلف ٹولز اور سروسز کے ساتھ، یہ تمام طاقتور ہو جاتا ہے۔
جینکنز کے علاوہ، بہت سے دوسرے اوپن سورس ٹولز ہیں، کوئی بھی منتخب کریں۔
CI/CD ٹول کے ساتھ DevOps کا عمل کیسا لگتا ہے۔
آپ کے پاس لوکل ہوسٹ میں CI/CD ٹول ہے، لیکن ابھی بہت کچھ کرنا باقی نہیں ہے۔ آئیے اگلے مرحلے پر چلتے ہیں۔
مرحلہ 2: ورژن کنٹرول
CI/CD ٹول کے جادو کو جانچنے کا بہترین (اور معقول حد تک آسان) طریقہ اسے سورس کنٹرول مینجمنٹ (SCM) ٹول کے ساتھ مربوط کرنا ہے۔ آپ کو ورژن کنٹرول کی ضرورت کیوں ہے؟ مان لیں کہ آپ درخواست دے رہے ہیں۔ آپ اسے جاوا، ازگر، C++، Go، Ruby، JavaScript، یا کسی دوسری زبان میں لکھتے ہیں جو ایک ویگن اور چھوٹی کارٹ ہے۔ آپ جو لکھتے ہیں اسے سورس کوڈ کہتے ہیں۔ سب سے پہلے، خاص طور پر اگر آپ اکیلے کام کر رہے ہیں، تو آپ ہر چیز کو مقامی ڈائریکٹری میں محفوظ کر سکتے ہیں۔ لیکن جیسے جیسے پروجیکٹ بڑھتا ہے اور زیادہ لوگ شامل ہوتے ہیں، آپ کو کوڈ کی تبدیلیوں کا اشتراک کرنے کا طریقہ درکار ہوتا ہے لیکن تبدیلیوں کو ضم کرتے وقت تنازعات سے بچتے ہیں۔ اور آپ کو بیک اپ استعمال کیے بغیر اور کوڈ فائلوں کے لیے کاپی پیسٹ کا طریقہ استعمال کیے بغیر کسی نہ کسی طرح پچھلے ورژن کو بحال کرنے کی ضرورت ہے۔
اور یہاں کہیں بھی SCM کے بغیر۔ SCM ریپوزٹریز میں کوڈ کو اسٹور کرتا ہے، اس کے ورژن کا انتظام کرتا ہے، اور اسے ڈویلپرز کے درمیان ہم آہنگ کرتا ہے۔
بہت سارے SCM ٹولز ہیں، لیکن Git مستحق طور پر ڈی فیکٹو سٹینڈرڈ بن گیا ہے۔ میں آپ کو اسے استعمال کرنے کا مشورہ دیتا ہوں، لیکن اس کے علاوہ اور بھی اختیارات ہیں۔
SCM کو شامل کرنے کے بعد DevOps پائپ لائن کیسی دکھتی ہے۔
CI/CD ٹول ماخذ کوڈ اپ لوڈ اور ڈاؤن لوڈ اور ٹیم کے تعاون کو خودکار کر سکتا ہے۔ برا نہیں ہے؟ لیکن اب اس سے ایک ورکنگ ایپلی کیشن کیسے بنائی جائے، جسے اربوں صارفین پسند کرتے ہیں؟
مرحلہ 3: آٹومیشن ٹول بنائیں
سب کچھ ویسا ہی ہو رہا ہے جیسا کہ ہونا چاہیے۔ آپ کوڈ اپ لوڈ کر سکتے ہیں اور سورس کنٹرول میں تبدیلیاں کر سکتے ہیں، اور دوستوں کو اپنے ساتھ کام کرنے کی دعوت دے سکتے ہیں۔ لیکن آپ کے پاس ابھی تک کوئی ایپ نہیں ہے۔ اس کے لیے ایک ویب ایپلیکیشن بننے کے لیے، اسے تقسیم کے لیے مرتب اور پیک کیا جانا چاہیے یا بطور ایگزیکیوٹیبل چلایا جانا چاہیے۔ (جاوا اسکرپٹ یا پی ایچ پی جیسی تشریح شدہ پروگرامنگ زبان کو مرتب کرنے کی ضرورت نہیں ہے۔)
بلڈ آٹومیشن ٹول استعمال کریں۔ آپ جو بھی ٹول منتخب کرتے ہیں، یہ کوڈ کو صحیح فارمیٹ میں جمع کرے گا اور خودکار صفائی، تالیف، جانچ، اور ترسیل کو خودکار بنائے گا۔ بلڈ ٹولز زبان کے لحاظ سے مختلف ہوتے ہیں، لیکن درج ذیل اوپن سورس آپشنز عام طور پر استعمال ہوتے ہیں۔
کامل! اب آئیے بلڈ آٹومیشن ٹول کنفیگریشن فائلوں کو سورس کنٹرول میں داخل کریں تاکہ CI/CD ٹول انہیں بنا سکے۔
یہ اچھا لگتا ہے۔ لیکن اب یہ سب کچھ کہاں ہے؟
مرحلہ 4: ویب ایپلیکیشن سرور
لہذا، آپ کے پاس ایک پیکڈ فائل ہے جسے عمل میں لایا جا سکتا ہے یا رول آؤٹ کیا جا سکتا ہے۔ کسی ایپلیکیشن کے واقعی کارآمد ہونے کے لیے، اس میں کسی نہ کسی قسم کی سروس یا انٹرفیس ہونا ضروری ہے، لیکن آپ کو یہ سب کہیں رکھنا ہوگا۔
ویب ایپلیکیشن کو ویب ایپلیکیشن سرور پر ہوسٹ کیا جا سکتا ہے۔ ایپلیکیشن سرور ایک ایسا ماحول فراہم کرتا ہے جہاں آپ پیکیجڈ منطق کو انجام دے سکتے ہیں، انٹرفیس پیش کر سکتے ہیں، اور ویب سروسز کو ساکٹ پر بے نقاب کر سکتے ہیں۔ ایپلیکیشن سرور کو انسٹال کرنے کے لیے آپ کو ایک HTTP سرور اور کچھ دوسرے ماحول (مثال کے طور پر ایک ورچوئل مشین) کی ضرورت ہے۔ ابھی کے لیے، آئیے دکھاوا کرتے ہیں کہ آپ جاتے وقت ان سب سے نمٹ رہے ہیں (حالانکہ میں نیچے کنٹینرز کے بارے میں بات کروں گا)۔
کئی اوپن ویب ایپلیکیشن سرورز ہیں۔
ہمارے پاس پہلے سے ہی تقریباً کام کرنے والی DevOps چین ہے۔ بہت اچھا کام!
اصولی طور پر، آپ یہاں روک سکتے ہیں، پھر آپ اسے خود سنبھال سکتے ہیں، لیکن یہ کوڈ کے معیار کے بارے میں بات کرنے کے قابل ہے۔
مرحلہ 5: ٹیسٹ کوریج
جانچ میں کافی وقت اور محنت درکار ہوتی ہے، لیکن بہتر ہے کہ فوراً کیڑے تلاش کریں اور آخری صارفین کو خوش کرنے کے لیے کوڈ کو بہتر بنائیں۔ اس مقصد کے لیے بہت سے اوپن ٹولز موجود ہیں جو نہ صرف کوڈ کی جانچ کریں گے بلکہ اس کو بہتر بنانے کے بارے میں بھی مشورہ دیں گے۔ زیادہ تر CI/CD ٹولز ان ٹولز میں پلگ ان کر سکتے ہیں اور عمل کو خودکار کر سکتے ہیں۔
ٹیسٹنگ کو دو حصوں میں تقسیم کیا گیا ہے: ٹیسٹ لکھنے اور انجام دینے کے لیے ٹیسٹنگ فریم ورک، اور کوڈ کے معیار کو بہتر بنانے کے لیے اشارے والے ٹولز۔
جانچ کے فریم ورک
کوالٹی ٹپس کے ساتھ ٹولز
ان میں سے زیادہ تر ٹولز اور فریم ورک Java، Python اور JavaScript کے لیے لکھے گئے ہیں کیونکہ C++ اور C# ملکیتی ہیں (حالانکہ GCC اوپن سورس ہے)۔
ہم نے ٹیسٹ کوریج ٹولز کا اطلاق کر دیا ہے، اور اب DevOps پائپ لائن کو ٹیوٹوریل کے شروع میں تصویر کی طرح نظر آنا چاہیے۔
اضافی اقدامات
کنٹینرز
جیسا کہ میں نے پہلے کہا، ایک ایپلیکیشن سرور کو ورچوئل مشین یا سرور میں ہوسٹ کیا جا سکتا ہے، لیکن کنٹینرز زیادہ مقبول ہیں۔
? مختصراً، ایک ورچوئل مشین میں، آپریٹنگ سسٹم اکثر ایپلی کیشن سے زیادہ جگہ لیتا ہے، اور ایک کنٹینر عام طور پر چند لائبریریوں اور کنفیگریشن کے ساتھ کافی ہوتا ہے۔ کچھ معاملات میں، ورچوئل مشینیں ناگزیر ہوتی ہیں، لیکن کنٹینر بغیر کسی اضافی قیمت کے سرور کے ساتھ ایپلی کیشن کو ایڈجسٹ کر سکتا ہے۔
کنٹینرز کے لیے، Docker اور Kubernetes عام طور پر لیے جاتے ہیں، حالانکہ دیگر اختیارات موجود ہیں۔
پر ڈاکر اور کبرنیٹس کے بارے میں مضامین پڑھیں :
مڈل ویئر آٹومیشن ٹولز
ہمارا DevOps سلسلہ باہمی تعاون پر مبنی تعمیر اور ایپلیکیشن کی ترسیل پر مرکوز ہے، لیکن دیگر دلچسپ چیزیں ہیں جو آپ DevOps ٹولز کے ساتھ کر سکتے ہیں۔ مثال کے طور پر، انفراسٹرکچر کو کوڈ (IaC) ٹولز کے طور پر استعمال کریں، جسے مڈل ویئر آٹومیشن ٹولز بھی کہا جاتا ہے۔ یہ ٹولز مڈل ویئر کے لیے خودکار تنصیب، انتظام اور دیگر کاموں میں مدد کرتے ہیں۔ مثال کے طور پر، ایک آٹومیشن ٹول ایپلی کیشنز (ویب ایپلیکیشن سرور، ڈیٹا بیس، مانیٹرنگ ٹولز) کو درست کنفیگریشن کے ساتھ لے سکتا ہے اور انہیں ایپلیکیشن سرور پر دھکیل سکتا ہے۔
اوپن مڈل ویئر آٹومیشن ٹولز کے لیے یہاں کچھ اختیارات ہیں:
مضامین میں تفصیلات :
اب کیا؟
یہ آئس برگ کا صرف ایک سرہ ہے۔ DevOps سلسلہ بہت کچھ کر سکتا ہے۔ ایک CI/CD ٹول کے ساتھ شروع کریں اور دیکھیں کہ آپ اپنے کام کو آسان بنانے کے لیے اور کیا خودکار کر سکتے ہیں۔ کے بارے میں مت بھولنا مؤثر تعاون کے لیے۔
ابتدائیوں کے لیے یہاں کچھ اور اچھے DevOps مضامین ہیں:
آپ کھلے فرتیلی ٹولز کے ساتھ DevOps کو بھی ضم کر سکتے ہیں:
ماخذ: www.habr.com