ہم اپنے تکنیکی ڈائریکٹر کی تازہ ترین تقاریر پر مبنی اشاعتوں کے ساتھ اپنے بلاگ کا آغاز کریں گے۔ (دمتری Stolyarov). یہ سب 2016 میں مختلف پیشہ ورانہ تقریبات میں ہوئے اور ڈیو اوپس اور ڈوکر کے عنوان کے لیے وقف تھے۔ بدو آفس میں ڈاکر ماسکو میٹنگ کی ایک ویڈیو، ہمارے پاس پہلے ہی موجود ہے۔ آن لائن نئے مضامین کے ساتھ رپورٹس کے نچوڑ کو بیان کرنے والے مضامین ہوں گے۔ تو…
31 مئی کو کانفرنس میں فیسٹیول "Rusian Internet Technologies" (RIT++ 2016) کے حصے کے طور پر منعقد کیا گیا، سیکشن "مسلسل تعیناتی اور تعیناتی" رپورٹ کے ساتھ کھلا جس کا آغاز "Docker کے ساتھ مسلسل ترسیل کے بہترین طرز عمل" تھا۔ اس نے Docker اور دیگر اوپن سورس پروڈکٹس کا استعمال کرتے ہوئے مسلسل ترسیل (CD) کے عمل کی تعمیر کے لیے بہترین طریقوں کا خلاصہ اور منظم کیا ہے۔ ہم پیداوار میں ان حلوں کے ساتھ کام کرتے ہیں، جو ہمیں عملی تجربے پر انحصار کرنے کی اجازت دیتا ہے۔
اگر آپ کو ایک گھنٹہ گزارنے کا موقع ملے ، ہم اسے مکمل طور پر دیکھنے کی تجویز کرتے ہیں۔ دوسری صورت میں، ذیل میں متن کی شکل میں بنیادی خلاصہ ہے.
ڈوکر کے ساتھ مسلسل ترسیل
کے تحت مسلسل ترسیل ہم واقعات کی زنجیر کو سمجھتے ہیں جس کے نتیجے میں Git ریپوزٹری سے ایپلیکیشن کوڈ پہلے پروڈکشن میں آتا ہے، اور پھر آرکائیو میں ختم ہوتا ہے۔ ایسا لگتا ہے: گٹ → بلڈ → ٹیسٹ → ریلیز → آپریٹ.
زیادہ تر رپورٹ تعمیراتی مرحلے (ایپلی کیشن اسمبلی) کے لیے وقف ہے، اور عنوانات کی رہائی اور کام کو مختصراً چھو لیا گیا ہے۔ ہم ان مسائل اور نمونوں کے بارے میں بات کریں گے جو آپ کو ان کو حل کرنے کی اجازت دیتے ہیں، اور ان نمونوں کے مخصوص نفاذ مختلف ہو سکتے ہیں۔
یہاں ڈوکر کی ضرورت کیوں ہے؟ یہ کچھ بھی نہیں ہے کہ ہم نے اس اوپن سورس ٹول کے تناظر میں مسلسل ترسیل کے طریقوں کے بارے میں بات کرنے کا فیصلہ کیا ہے۔ اگرچہ پوری رپورٹ اس کے استعمال کے لیے وقف ہے، لیکن ایپلیکیشن کوڈ رول آؤٹ کے مرکزی نمونے پر غور کرتے وقت بہت سی وجوہات سامنے آتی ہیں۔
مرکزی رول آؤٹ پیٹرن
لہذا، جب ہم ایپلیکیشن کے نئے ورژنز کو رول آؤٹ کرتے ہیں، تو ہمیں یقینی طور پر سامنا کرنا پڑتا ہے۔ ڈاؤن ٹائم مسئلہ، پروڈکشن سرور کے سوئچنگ کے دوران پیدا ہوتا ہے۔ ایپلیکیشن کے پرانے ورژن سے نئے ورژن کی طرف ٹریفک فوری طور پر تبدیل نہیں ہو سکتی: سب سے پہلے ہمیں یہ یقینی بنانا چاہیے کہ نیا ورژن نہ صرف کامیابی کے ساتھ ڈاؤن لوڈ ہوا ہے، بلکہ "وارم اپ" (یعنی درخواستوں کو پیش کرنے کے لیے مکمل طور پر تیار ہے)۔
اس طرح کچھ عرصے تک ایپلیکیشن کے دونوں ورژن (پرانے اور نئے) بیک وقت کام کریں گے۔ جو خود بخود اس کی طرف لے جاتا ہے۔ مشترکہ وسائل کا تنازعہ: نیٹ ورک، فائل سسٹم، آئی پی سی، وغیرہ۔ ڈوکر کے ساتھ، یہ مسئلہ ایپلیکیشن کے مختلف ورژنز کو الگ الگ کنٹینرز میں چلا کر آسانی سے حل کیا جاتا ہے، جس کے لیے ایک ہی میزبان (سرور/ورچوئل مشین) کے اندر وسائل کی تنہائی کی ضمانت دی جاتی ہے۔ بلاشبہ، آپ بغیر کسی موصلیت کے کچھ چالوں کے ساتھ حاصل کر سکتے ہیں، لیکن اگر کوئی تیار شدہ اور آسان ٹول ہے، تو اس کے برعکس وجہ ہے - اسے نظرانداز نہ کرنا۔
تعینات ہونے پر کنٹینرائزیشن بہت سے دوسرے فوائد فراہم کرتی ہے۔ کسی بھی درخواست پر منحصر ہے۔ مخصوص ورژن (یا ورژن کی حد) مترجم، ماڈیولز/ ایکسٹینشنز وغیرہ کی دستیابی کے ساتھ ساتھ ان کے ورژن۔ اور اس کا اطلاق نہ صرف فوری طور پر قابل عمل ماحول پر ہوتا ہے بلکہ پورے ماحول پر بھی ہوتا ہے، بشمول سسٹم سوفٹ ویئر اور اس کا ورژن (استعمال شدہ لینکس کی تقسیم تک)۔ اس حقیقت کی وجہ سے کہ کنٹینرز میں نہ صرف ایپلیکیشن کوڈ ہوتا ہے بلکہ پہلے سے نصب شدہ سسٹم اور مطلوبہ ورژن کا ایپلیکیشن سافٹ ویئر بھی ہوتا ہے، آپ انحصار کے مسائل کو بھول سکتے ہیں۔
آئیے مختصر کرتے ہیں مرکزی رول آؤٹ پیٹرن مندرجہ ذیل عوامل کو مدنظر رکھتے ہوئے نئے ورژن:
- سب سے پہلے، درخواست کا پرانا ورژن پہلے کنٹینر میں چلتا ہے۔
- اس کے بعد نئے ورژن کو رول آؤٹ کیا جاتا ہے اور دوسرے کنٹینر میں "گرم اپ" کیا جاتا ہے۔ یہ قابل ذکر ہے کہ یہ نیا ورژن بذات خود نہ صرف اپ ڈیٹ کردہ ایپلیکیشن کوڈ، بلکہ اس کے کسی بھی انحصار کے ساتھ ساتھ سسٹم کے اجزاء (مثال کے طور پر، OpenSSL کا نیا ورژن یا پوری تقسیم) لے سکتا ہے۔
- جب نیا ورژن درخواستوں کو پیش کرنے کے لیے مکمل طور پر تیار ہو جاتا ہے، تو ٹریفک پہلے کنٹینر سے دوسرے کنٹینر میں بدل جاتا ہے۔
- پرانے ورژن کو اب روکا جا سکتا ہے۔
ایپلیکیشن کے مختلف ورژن کو علیحدہ کنٹینرز میں تعینات کرنے کا یہ طریقہ ایک اور سہولت فراہم کرتا ہے۔ فوری رول بیک پرانے ورژن میں (آخر کار، ٹریفک کو مطلوبہ کنٹینر میں تبدیل کرنے کے لیے کافی ہے)۔
آخری پہلی سفارش کچھ ایسی لگتی ہے جس میں کیپٹن بھی غلطی نہیں پا سکتا تھا: "[ڈوکر کے ساتھ مسلسل ترسیل کا اہتمام کرتے وقت] Docker استعمال کریں۔ [اور سمجھیں کہ یہ کیا دیتا ہے]" یاد رکھیں، یہ چاندی کی گولی نہیں ہے جو ہر مسئلے کو حل کرے گی، بلکہ ایک ایسا آلہ ہے جو ایک شاندار بنیاد فراہم کرتا ہے۔
تولیدی صلاحیت
"پیداواری صلاحیت" سے ہمارا مطلب ہے ایپلی کیشنز کو چلانے کے دوران درپیش مسائل کا ایک عمومی مجموعہ۔ ہم ایسے معاملات کے بارے میں بات کر رہے ہیں:
- سٹیجنگ کے لیے کوالٹی ڈپارٹمنٹ کے ذریعے چیک کیے گئے اسکرپٹس کو پروڈکشن میں درست طریقے سے دوبارہ پیش کیا جانا چاہیے۔
- ایپلی کیشنز کو سرورز پر شائع کیا جاتا ہے جو مختلف ریپوزٹری آئینے سے پیکجز وصول کر سکتے ہیں (وقت کے ساتھ ساتھ وہ اپ ڈیٹ ہوتے ہیں، اور ان کے ساتھ انسٹال کردہ ایپلیکیشنز کے ورژن)۔
- "مقامی طور پر میرے لیے سب کچھ کام کرتا ہے!" (...اور ڈویلپرز کو پیداوار کی اجازت نہیں ہے۔)
- آپ کو پرانے (محفوظ شدہ) ورژن میں کچھ چیک کرنے کی ضرورت ہے۔
- ...
ان کا عمومی جوہر اس حقیقت پر ابلتا ہے کہ استعمال شدہ ماحول کی مکمل تعمیل (نیز انسانی عنصر کی عدم موجودگی) ضروری ہے۔ ہم تولیدی صلاحیت کی ضمانت کیسے دے سکتے ہیں؟ ڈوکر کی تصاویر بنائیں Git کے کوڈ کی بنیاد پر، اور پھر انہیں کسی بھی کام کے لیے استعمال کریں: ٹیسٹ سائٹس پر، پروڈکشن میں، پروگرامرز کی مقامی مشینوں پر... ایک ہی وقت میں، یہ ضروری ہے کہ انجام پانے والے اعمال کو کم سے کم کیا جائے۔ کے بعد تصویر کو جمع کرنا: یہ جتنا آسان ہوگا، غلطیوں کا امکان اتنا ہی کم ہوگا۔
انفراسٹرکچر کوڈ ہے۔
اگر بنیادی ڈھانچے کی ضروریات (سرور سافٹ ویئر کی دستیابی، اس کا ورژن، وغیرہ) باقاعدہ اور "پروگرام شدہ" نہیں ہیں، تو کسی بھی ایپلیکیشن اپ ڈیٹ کے رول آؤٹ کے تباہ کن نتائج برآمد ہو سکتے ہیں۔ مثال کے طور پر، اسٹیجنگ میں آپ نے پہلے ہی پی ایچ پی 7.0 پر سوئچ کیا ہے اور اس کے مطابق کوڈ کو دوبارہ لکھا ہے - پھر کچھ پرانے پی ایچ پی (5.5) کے ساتھ اس کی پیداوار میں ظاہر ہونا یقینی طور پر کسی کو حیران کر دے گا۔ آپ مترجم کے ورژن میں ایک بڑی تبدیلی کے بارے میں نہیں بھول سکتے، لیکن "شیطان تفصیلات میں ہے": حیرت کسی بھی انحصار کی معمولی تازہ کاری میں ہوسکتی ہے۔
اس مسئلے کو حل کرنے کے لئے ایک نقطہ نظر کے طور پر جانا جاتا ہے IaC (بطور کوڈ، "بطور بنیادی ڈھانچہ") اور درخواست کوڈ کے ساتھ بنیادی ڈھانچے کی ضروریات کو ذخیرہ کرنا شامل ہے۔ اسے استعمال کرتے ہوئے، ڈویلپرز اور ڈی او اوپس کے ماہرین ایک ہی Git ایپلیکیشن ریپوزٹری کے ساتھ لیکن اس کے مختلف حصوں پر کام کر سکتے ہیں۔ اس کوڈ سے، گٹ میں ایک ڈوکر امیج بنتی ہے، جس میں بنیادی ڈھانچے کی تمام تفصیلات کو مدنظر رکھتے ہوئے ایپلیکیشن کو تعینات کیا جاتا ہے۔ سیدھے الفاظ میں، امیجز کو اسمبل کرنے کے لیے اسکرپٹس (قواعد) کو سورس کوڈ کے ساتھ ایک ہی ریپوزٹری میں ہونا چاہیے اور ایک ساتھ ضم ہونا چاہیے۔
ملٹی لیئر ایپلی کیشن آرکیٹیکچر کے معاملے میں - مثال کے طور پر، وہاں nginx ہے، جو پہلے سے ہی ایک Docker کنٹینر کے اندر چلنے والی ایپلیکیشن کے سامنے کھڑا ہے - Docker امیجز کو Git میں موجود کوڈ سے ہر پرت کے لیے بنایا جانا چاہیے۔ پھر پہلی تصویر میں ایک مترجم اور دیگر "قریبی" انحصار کے ساتھ ایک ایپلی کیشن ہوگی، اور دوسری تصویر میں upstream nginx ہوگا۔
ڈوکر امیجز، گٹ کے ساتھ مواصلت
ہم گٹ سے جمع کی گئی تمام ڈاکر امیجز کو دو زمروں میں تقسیم کرتے ہیں: عارضی اور ریلیز۔ عارضی تصاویر Git میں برانچ کے نام سے ٹیگ کیا گیا ہے، اگلی کمٹ کے ذریعے اوور رائٹ کیا جا سکتا ہے اور صرف پیش نظارہ کے لیے رول آؤٹ کیا جاتا ہے (پروڈکشن کے لیے نہیں)۔ یہ ریلیز والوں سے ان کا کلیدی فرق ہے: آپ کو کبھی معلوم نہیں ہوگا کہ ان میں کون سا مخصوص عہد ہے۔
عارضی امیجز میں جمع کرنا سمجھ میں آتا ہے: ماسٹر برانچ (ماسٹر کے موجودہ ورژن کو مسلسل دیکھنے کے لیے آپ اسے خود بخود ایک علیحدہ سائٹ پر رول آؤٹ کر سکتے ہیں)، ریلیز کے ساتھ شاخیں، مخصوص اختراعات کی شاخیں۔
عارضی تصاویر کے پیش نظارہ کے بعد پیداوار میں ترجمے کی ضرورت پیش آتی ہے، ڈویلپرز ایک خاص ٹیگ لگاتے ہیں۔ خود بخود ٹیگ کے ذریعے جمع کیا جاتا ہے۔ تصویر جاری کریں (اس کا ٹیگ گٹ کے ٹیگ سے مماثل ہے) اور اسے اسٹیجنگ پر لایا گیا ہے۔ اگر کوالٹی ڈپارٹمنٹ کے ذریعہ اس کی کامیابی سے تصدیق ہوجاتی ہے تو یہ پروڈکشن میں چلا جاتا ہے۔
ڈپ
بیان کردہ ہر چیز (رول آؤٹ، امیج اسمبلی، بعد میں دیکھ بھال) کو باش اسکرپٹس اور دیگر "ترتیب یافتہ" ٹولز کا استعمال کرتے ہوئے آزادانہ طور پر لاگو کیا جا سکتا ہے۔ لیکن اگر آپ ایسا کرتے ہیں، تو پھر کسی وقت عمل درآمد بڑی پیچیدگی اور ناقص کنٹرولیبلٹی کا باعث بنے گا۔ اس کو سمجھتے ہوئے، ہم CI/CD بنانے کے لیے اپنی مخصوص ورک فلو یوٹیلیٹی بنانے آئے ہیں۔ ڈپ.
اس کا سورس کوڈ روبی، اوپن سورس میں لکھا گیا ہے اور اس پر شائع کیا گیا ہے۔ . بدقسمتی سے، دستاویزات فی الحال ٹول کا سب سے کمزور نقطہ ہے، لیکن ہم اس پر کام کر رہے ہیں۔ اور ہم ڈیپ کے بارے میں ایک سے زیادہ بار لکھیں گے اور بات کریں گے، کیونکہ... ہم پوری دلچسپی رکھنے والی کمیونٹی کے ساتھ اس کی صلاحیتوں کو بانٹنے کا مخلصانہ طور پر انتظار نہیں کر سکتے، لیکن اس دوران، اپنے مسائل بھیجیں اور درخواستیں بھیجیں اور/یا GitHub پر پروجیکٹ کی ترقی کی پیروی کریں۔
13 اگست 2019 کو اپ ڈیٹ کیا گیا: فی الحال ایک منصوبہ ڈپ کا نام تبدیل کر دیا گیا۔ ، اس کے کوڈ کو مکمل طور پر گو میں دوبارہ لکھا گیا ہے، اور اس کی دستاویزات کو نمایاں طور پر بہتر کیا گیا ہے۔
Kubernetes
ایک اور ریڈی میڈ اوپن سورس ٹول جو پہلے ہی پیشہ ورانہ ماحول میں نمایاں پہچان حاصل کر چکا ہے۔ Kubernetes، ایک ڈوکر مینجمنٹ کلسٹر۔ ڈوکر پر بنائے گئے پروجیکٹس کے آپریشن میں اس کے استعمال کا موضوع رپورٹ کے دائرہ کار سے باہر ہے، اس لیے پریزنٹیشن کچھ دلچسپ خصوصیات کے جائزہ تک محدود ہے۔
رول آؤٹ کے لیے، Kubernetes پیش کرتا ہے:
- تیاری کی تحقیقات - ایپلیکیشن کے نئے ورژن کی تیاری کی جانچ کرنا (ٹریفک کو اس میں تبدیل کرنے کے لیے)؛
- رولنگ اپ ڈیٹ - کنٹینرز کے جھرمٹ میں ترتیب وار تصویری اپ ڈیٹ (شٹ ڈاؤن، اپ ڈیٹ، لانچ کی تیاری، ٹریفک سوئچنگ)؛
- ہم وقت ساز اپ ڈیٹ - ایک مختلف نقطہ نظر کے ساتھ کلسٹر میں ایک تصویر کو اپ ڈیٹ کرنا: پہلے آدھے کنٹینرز پر، پھر باقی پر؛
- کینری ریلیز - بے ضابطگیوں کی نگرانی کے لیے محدود (چھوٹے) کنٹینرز پر ایک نئی تصویر لانچ کرنا۔
چونکہ کنٹینیوئس ڈیلیوری نہ صرف ایک نئے ورژن کی ریلیز ہے، اس لیے کوبرنیٹس کے پاس بعد میں بنیادی ڈھانچے کی دیکھ بھال کے لیے بہت سے مواقع ہیں: بلٹ ان مانیٹرنگ اور تمام کنٹینرز کے لیے لاگنگ، آٹومیٹک اسکیلنگ وغیرہ۔ یہ سب پہلے سے کام کر رہا ہے اور صرف مناسب ہونے کا انتظار کر رہا ہے۔ آپ کے عمل میں عمل درآمد۔
حتمی سفارشات
- Docker استعمال کریں۔
- اپنی تمام ضروریات کے لیے ایپلی کیشنز کی ڈوکر امیجز بنائیں۔
- "انفراسٹرکچر کوڈ ہے" کے اصول پر عمل کریں۔
- گٹ کو ڈوکر سے لنک کریں۔
- رول آؤٹ کے آرڈر کو منظم کریں۔
- ایک ریڈی میڈ پلیٹ فارم (Kubernetes یا کوئی اور) استعمال کریں۔
ویڈیوز اور سلائیڈز
کارکردگی سے ویڈیو (تقریبا ایک گھنٹہ) (رپورٹ خود 5ویں منٹ سے شروع ہوتی ہے - اس لمحے سے کھیلنے کے لیے لنک پر عمل کریں).
رپورٹ کی پیشکش:
PS
ہمارے بلاگ پر اس موضوع پر دیگر رپورٹس:
- «» (Dmitry Stolyarov؛ 27 مئی 2019 DevOpsConf پر);
- «» (دمتری اسٹولیاروف؛ 8 نومبر 2018 ہائی لوڈ++ پر);
- «» (دمتری اسٹولیاروف؛ 7 نومبر 2017 ہائی لوڈ++ پر);
- «» (دمتری اسٹولیاروف؛ 6 جون، 2017 روٹ کانف میں).
ماخذ: www.habr.com