میرا مشورہ ہے کہ آپ انوینٹس سے الیگزینڈر سگاچیف کی رپورٹ کا ٹرانسکرپٹ پڑھیں "ڈوکر + گٹلاب سی آئی کے ساتھ ترقی اور جانچ کا عمل"
وہ لوگ جو ابھی ڈوکر + گٹلاب سی آئی پر مبنی ترقی اور جانچ کے عمل کو نافذ کرنا شروع کر رہے ہیں اکثر بنیادی سوالات پوچھتے ہیں۔ کہاں سے شروع کریں؟ کیسے منظم کریں؟ ٹیسٹ کیسے کریں؟
یہ رپورٹ اچھی ہے کیونکہ یہ Docker اور Gitlab CI کا استعمال کرتے ہوئے ترقی اور جانچ کے عمل کے بارے میں ایک منظم انداز میں بات کرتی ہے۔ رپورٹ خود 2017 کی ہے۔ میرا خیال ہے کہ اس رپورٹ سے آپ بنیادی باتیں، طریقہ کار، خیال اور استعمال کے تجربے کو حاصل کر سکتے ہیں۔
کسی بھی دلچسپی کے لئے، براہ کرم بلی دیکھیں۔
میرا نام الیگزینڈر سگاچیف ہے۔ میں Inventos کے لیے کام کرتا ہوں۔ میں آپ کو ڈوکر کے استعمال کے اپنے تجربے کے بارے میں بتاؤں گا اور یہ کہ ہم کمپنی میں پروجیکٹس پر اسے آہستہ آہستہ کیسے نافذ کر رہے ہیں۔
رپورٹ کا موضوع: ڈوکر اور گٹلاب سی آئی کا استعمال کرتے ہوئے ترقی کا عمل۔
ڈوکر کے بارے میں یہ میری دوسری بات ہے۔ پہلی رپورٹ کے وقت، ہم نے ڈوکر کو صرف ڈویلپر مشینوں پر ڈویلپمنٹ میں استعمال کیا۔ ڈوکر استعمال کرنے والے ملازمین کی تعداد تقریباً 2-3 افراد تھی۔ رفتہ رفتہ تجربہ حاصل ہوا اور ہم تھوڑا آگے بڑھ گئے۔ ہمارے سے لنک کریں۔ .
اس رپورٹ میں کیا ہوگا؟ ہم اپنے تجربے کا اشتراک کریں گے کہ ہم نے کون سے ریک جمع کیے، ہم نے کن مسائل کو حل کیا۔ یہ ہر جگہ خوبصورت نہیں تھا، لیکن اس نے ہمیں آگے بڑھنے دیا۔
ہمارا نعرہ: ہر چیز کو ڈوکرائز کریں جس پر ہم ہاتھ ڈالتے ہیں۔
ہم کن مسائل کو حل کر رہے ہیں؟
جب ایک کمپنی میں کئی ٹیمیں ہوتی ہیں، تو پروگرامر ایک مشترکہ وسیلہ ہوتا ہے۔ ایسے مراحل ہوتے ہیں جب ایک پروگرامر کو ایک پروجیکٹ سے نکال کر دوسرے پروجیکٹ کو کچھ وقت کے لیے دیا جاتا ہے۔
ایک پروگرامر کو تیزی سے سمجھنے کے لیے، اسے پروجیکٹ کا سورس کوڈ ڈاؤن لوڈ کرنے اور جلد از جلد ایک ایسا ماحول شروع کرنے کی ضرورت ہے، جس سے وہ اس پروجیکٹ کے مسائل کو حل کرنے میں مزید آگے بڑھ سکے۔
عام طور پر، اگر آپ شروع سے شروع کرتے ہیں، تو پروجیکٹ میں بہت کم دستاویزات موجود ہیں۔ صرف پرانے ٹائمرز کے پاس اس کو ترتیب دینے کے بارے میں معلومات ہوتی ہیں۔ ملازمین ایک یا دو دن میں اپنے کام کی جگہ خود ترتیب دیتے ہیں۔ اس کو تیز کرنے کے لیے، ہم نے Docker کا استعمال کیا۔
اگلی وجہ ڈیولپمنٹ میں سیٹنگز کا معیاری بنانا ہے۔ میرے تجربے میں، ڈویلپر ہمیشہ پہل کرتے ہیں۔ ہر پانچویں صورت میں، ایک حسب ضرورت ڈومین درج کیا جاتا ہے، مثال کے طور پر vasya.dev۔ میرے پاس میرا پڑوسی پیٹیا بیٹھا ہے، جس کا ڈومین petya.dev ہے۔ وہ اس ڈومین نام کا استعمال کرتے ہوئے ایک ویب سائٹ یا کچھ سسٹم کا جزو تیار کرتے ہیں۔
جب نظام بڑھتا ہے اور یہ ڈومین نام کنفیگریشن میں شامل ہونا شروع ہو جاتے ہیں، تو ترقیاتی ماحول میں تنازعہ پیدا ہو جاتا ہے اور سائٹ کا راستہ دوبارہ لکھا جاتا ہے۔
ڈیٹا بیس کی ترتیبات کے ساتھ بھی ایسا ہی ہوتا ہے۔ کچھ لوگ سیکیورٹی سے پریشان نہیں ہوتے ہیں اور خالی روٹ پاس ورڈ کے ساتھ کام کرتے ہیں۔ انسٹالیشن کے مرحلے پر، MySQL نے کسی سے پاس ورڈ مانگا اور پاس ورڈ 123 نکلا۔ اکثر ایسا ہوتا ہے کہ ڈیولپر کی کمٹمنٹ کے لحاظ سے ڈیٹا بیس کی تشکیل مسلسل تبدیل ہوتی رہتی ہے۔ کسی نے تصحیح کی، کسی نے ترتیب درست نہیں کی۔ جب ہم نے کچھ ٹیسٹ کنفیگریشن میں ڈالا تو چالیں تھیں۔ .gitignore اور ہر ڈویلپر کو ڈیٹا بیس انسٹال کرنا تھا۔ اس نے شروع کرنے کے عمل کو مزید مشکل بنا دیا۔ دوسری چیزوں کے علاوہ، آپ کو ڈیٹا بیس کے بارے میں یاد رکھنے کی ضرورت ہے۔ ڈیٹابیس کا آغاز ہونا چاہیے، پاس ورڈ کا اندراج ہونا چاہیے، صارف کا رجسٹر ہونا ضروری ہے، ایک نشان بنانا چاہیے، وغیرہ۔
ایک اور مسئلہ لائبریریوں کے مختلف ورژن ہیں۔ اکثر ایسا ہوتا ہے کہ ایک ڈویلپر مختلف پروجیکٹس پر کام کرتا ہے۔ ایک لیگیسی پروجیکٹ ہے، جو پانچ سال پہلے شروع ہوا تھا (2017 سے - ایڈیٹر کا نوٹ)۔ شروع میں ہم نے MySQL 5.5 کے ساتھ شروعات کی۔ ایسے جدید منصوبے بھی ہیں جہاں ہم MySQL کے مزید جدید ورژن کو نافذ کرنے کی کوشش کر رہے ہیں، مثال کے طور پر 5.7 یا اس سے زیادہ (2017 میں - ایڈیٹر کا نوٹ)
جو بھی MySQL کے ساتھ کام کرتا ہے وہ جانتا ہے کہ یہ لائبریریاں انحصار کرتی ہیں۔ 2 ڈیٹا بیس کو ایک ساتھ چلانا کافی مشکل ہے۔ کم از کم، پرانے کلائنٹس کو نئے ڈیٹا بیس سے جوڑنا مشکل ہے۔ اس کے نتیجے میں کئی مسائل جنم لیتے ہیں۔
اگلا مسئلہ یہ ہے کہ جب ایک ڈویلپر مقامی مشین پر کام کرتا ہے، وہ مقامی وسائل، مقامی فائلیں، مقامی RAM استعمال کرتا ہے۔ مسائل کا حل تیار کرنے کے وقت تمام تعامل اس حقیقت کے فریم ورک کے اندر ہوتے ہیں کہ یہ ایک مشین پر کام کرتی ہے۔ ایک مثال یہ ہوگی جب ہمارے پاس پروڈکشن 3 میں بیک اینڈ سرور ہوں، اور ڈویلپر فائلوں کو روٹ ڈائرکٹری میں محفوظ کرتا ہے اور وہاں سے nginx فائلوں کو درخواست کا جواب دینے کے لیے لے جاتا ہے۔ جب ایسا کوڈ پروڈکشن میں آتا ہے، تو پتہ چلتا ہے کہ فائل 3 سرورز میں سے ایک پر موجود ہے۔
مائیکرو سروسز کی سمت اس وقت ترقی کر رہی ہے۔ جب ہم اپنی بڑی ایپلی کیشنز کو کچھ چھوٹے اجزاء میں تقسیم کرتے ہیں جو ایک دوسرے کے ساتھ تعامل کرتے ہیں۔ یہ آپ کو مخصوص ٹاسک اسٹیک کے لیے ٹیکنالوجیز منتخب کرنے کی اجازت دیتا ہے۔ یہ آپ کو کام اور ذمہ داری کے علاقے کو ڈویلپرز کے درمیان تقسیم کرنے کی بھی اجازت دیتا ہے۔
ایک فرنٹ اینڈ ڈویلپر، جو جے ایس میں ترقی کر رہا ہے، کا بیک اینڈ پر عملی طور پر کوئی اثر نہیں ہے۔ بیک اینڈ ڈویلپر، بدلے میں، ہمارے معاملے میں، روبی آن ریلز تیار کرتا ہے اور فرونڈ اینڈ میں مداخلت نہیں کرتا ہے۔ تعامل API کا استعمال کرتے ہوئے کیا جاتا ہے۔
بونس کے طور پر، ڈوکر کا استعمال کرتے ہوئے ہم اسٹیجنگ پر وسائل کو ری سائیکل کرنے کے قابل تھے۔ ہر پروجیکٹ، اس کی تفصیلات کی وجہ سے، بعض ترتیبات کی ضرورت ہوتی ہے۔ جسمانی طور پر، یہ ضروری تھا کہ یا تو ایک ورچوئل سرور مختص کیا جائے اور انہیں الگ سے ترتیب دیا جائے، یا کسی قسم کے متغیر ماحول کو تقسیم کیا جائے اور لائبریریوں کے ورژن کے لحاظ سے پروجیکٹس ایک دوسرے پر اثر انداز ہو سکتے ہیں۔
اوزار. ہم کیا استعمال کرتے ہیں؟
- ڈوکر خود۔ ایک ڈاکر فائل ایک ہی ایپلی کیشن کے انحصار کو بیان کرتا ہے۔
- Docker-compose ایک بنڈل ہے جو ہماری کئی Docker ایپلی کیشنز کو اکٹھا کرتا ہے۔
- ہم سورس کوڈ کو ذخیرہ کرنے کے لیے GitLab استعمال کرتے ہیں۔
- ہم نظام کے انضمام کے لیے GitLab-CI استعمال کرتے ہیں۔
رپورٹ دو حصوں پر مشتمل ہے۔
پہلا حصہ آپ کو بتائے گا کہ ڈوکر کو ڈویلپرز کی مشینوں پر کیسے چلایا جائے۔
دوسرا حصہ اس بارے میں بات کرے گا کہ GitLab کے ساتھ کیسے تعامل کیا جائے، ہم کس طرح ٹیسٹ چلاتے ہیں اور ہم اسٹیجنگ تک کیسے پہنچتے ہیں۔
ڈوکر ایک ایسی ٹیکنالوجی ہے جو (اعلاناتی نقطہ نظر کا استعمال کرتے ہوئے) ضروری اجزاء کو بیان کرنے کی اجازت دیتی ہے۔ یہ ایک مثال ہے Dockerfile. یہاں ہم اعلان کرتے ہیں کہ ہمیں روبی کی آفیشل ڈوکر امیج سے وراثت مل رہی ہے: 2.3.0۔ اس میں روبی ورژن 2.3 انسٹال ہے۔ ہم ضروری اسمبلی لائبریریاں اور نوڈ جے ایس انسٹال کرتے ہیں۔ ہم بیان کرتے ہیں کہ ہم ایک ڈائریکٹری بنا رہے ہیں۔ /app. ہم ایپ ڈائرکٹری کو ورکنگ ڈائرکٹری کے طور پر تفویض کرتے ہیں۔ اس ڈائرکٹری میں ہم مطلوبہ کم از کم Gemfile اور Gemfile.lock رکھتے ہیں۔ پھر ہم ایسے پروجیکٹ بناتے ہیں جو اس انحصار کی تصویر کو انسٹال کرتے ہیں۔ ہم اشارہ کرتے ہیں کہ کنٹینر بیرونی پورٹ 3000 پر سننے کے لیے تیار ہو جائے گا۔ آخری کمانڈ وہ کمانڈ ہے جو براہ راست ہماری ایپلی کیشن کو لانچ کرتی ہے۔ اگر ہم پروجیکٹ رن کمانڈ پر عمل کرتے ہیں، تو ایپلی کیشن مخصوص کمانڈ کو چلانے اور چلانے کی کوشش کرے گی۔
یہ ڈاکر کمپوز فائل کی ایک کم سے کم مثال ہے۔ اس صورت میں، ہم یہ ظاہر کرتے ہیں کہ دو کنٹینرز کے درمیان تعلق ہے. یہ براہ راست ڈیٹا بیس سروس اور ویب سروس میں ہے۔ ہماری ویب ایپلیکیشنز کو زیادہ تر معاملات میں ڈیٹا کو ذخیرہ کرنے کے لیے بیک اینڈ کے طور پر کسی قسم کے ڈیٹا بیس کی ضرورت ہوتی ہے۔ چونکہ ہم MySQL استعمال کرتے ہیں، مثال MySQL کے ساتھ ہے - لیکن کوئی بھی چیز ہمیں کسی دوسرے ڈیٹا بیس (PostgreSQL، Redis) کو استعمال کرنے سے نہیں روکتی۔
ہم MySQL 5.7.14 تصویر کو بغیر کسی تبدیلی کے Docker Hub سے آفیشل سورس سے لیتے ہیں۔ ہم موجودہ ڈائرکٹری سے وہ تصویر جمع کرتے ہیں جو ہماری ویب ایپلیکیشن کے لیے ذمہ دار ہے۔ پہلی لانچ کے دوران، وہ ہمارے لیے ایک تصویر جمع کرتا ہے۔ پھر یہ کمانڈ چلاتا ہے جسے ہم یہاں انجام دے رہے ہیں۔ اگر ہم واپس جائیں تو ہم دیکھیں گے کہ لانچ کمانڈ کی وضاحت پوما کے ذریعے کی گئی تھی۔ پوما روبی میں لکھی ہوئی ایک خدمت ہے۔ دوسری صورت میں ہم اوور رائڈ کرتے ہیں۔ یہ حکم ہماری ضروریات یا کاموں کے لحاظ سے من مانی ہو سکتا ہے۔
ہم یہ بھی بیان کرتے ہیں کہ ہمیں اپنی ڈویلپر ہوسٹ مشین پر پورٹ کو 3000 سے 3000 کنٹینر پورٹ پر بھیجنے کی ضرورت ہے۔ یہ خود بخود iptables اور اس کے اپنے میکانزم کا استعمال کرتے ہوئے کیا جاتا ہے، جو براہ راست Docker میں سرایت کرتا ہے۔
ڈویلپر، پہلے کی طرح، کسی بھی دستیاب IP ایڈریس تک رسائی حاصل کر سکتا ہے، مثال کے طور پر، مشین کے مقامی یا بیرونی IP ایڈریس 127.0.0.1۔
آخری لائن کہتی ہے کہ ویب کنٹینر ڈی بی کنٹینر پر منحصر ہے۔ جب ہم ویب کنٹینر کو لانچ کرنے کے لیے کال کرتے ہیں، تو docker-compose سب سے پہلے ہمارے لیے ڈیٹا بیس لانچ کرے گا۔ پہلے سے ہی ڈیٹا بیس کے آغاز پر (حقیقت میں، کنٹینر کے آغاز کے بعد! یہ ڈیٹا بیس کی تیاری کی ضمانت نہیں دیتا) یہ ہماری ایپلیکیشن، ہمارا بیک اینڈ لانچ کر دے گا۔
یہ ہمیں ڈیٹا بیس کے مکمل نہ ہونے پر غلطیوں سے بچنے کی اجازت دیتا ہے اور جب ہم ڈیٹا بیس کنٹینر کو روکتے ہیں تو ہمیں وسائل کو بچانے کی اجازت دیتا ہے، اس طرح دوسرے پروجیکٹس کے لیے وسائل خالی ہوتے ہیں۔
کسی پروجیکٹ پر ڈیٹا بیس ڈاکرائزیشن کا استعمال ہمیں کیا دیتا ہے؟ ہم تمام ڈویلپرز کے لیے MySQL ورژن ریکارڈ کرتے ہیں۔ یہ آپ کو کچھ ایسی غلطیوں سے بچنے کی اجازت دیتا ہے جو اس وقت پیدا ہو سکتی ہیں جب ورژن مختلف ہو جائیں، جب نحو، ترتیب، اور ڈیفالٹ سیٹنگز تبدیل ہوں۔ یہ آپ کو ڈیٹا بیس، لاگ ان، پاس ورڈ کے لیے ایک مشترکہ میزبان نام بتانے کی اجازت دیتا ہے۔ ہم ناموں کے چڑیا گھر سے دور جا رہے ہیں اور کنفگ فائلوں میں تنازعات جو پہلے موجود تھے۔
ہمارے پاس ڈیولپمنٹ ماحول کے لیے زیادہ بہترین کنفیگریشن استعمال کرنے کا موقع ہے، جو پہلے سے طے شدہ سے مختلف ہوگا۔ MySQL کمزور مشینوں کے لیے بطور ڈیفالٹ کنفیگر ہوتا ہے اور باکس سے باہر اس کی کارکردگی بہت کم ہے۔
Docker آپ کو مطلوبہ ورژن کے Python، Ruby، NodeJS، PHP ترجمان کو استعمال کرنے کی اجازت دیتا ہے۔ ہم کسی قسم کے ورژن مینیجر کو استعمال کرنے کی ضرورت سے چھٹکارا پاتے ہیں۔ پہلے، روبی کے لیے ایک rpm پیکیج استعمال کیا جاتا تھا، جس کی مدد سے آپ پروجیکٹ کے لحاظ سے ورژن تبدیل کر سکتے تھے۔ ڈوکر کنٹینر کا شکریہ، یہ آپ کو انحصار کے ساتھ کوڈ اور ورژن کو آسانی سے منتقل کرنے کی بھی اجازت دیتا ہے۔ ہمیں مترجم اور کوڈ دونوں کے ورژن کو سمجھنے میں کوئی مسئلہ نہیں ہے۔ ورژن کو اپ ڈیٹ کرنے کے لیے، آپ کو پرانے کنٹینر کو کم کرنے اور نئے کنٹینر کو اونچا کرنے کی ضرورت ہے۔ اگر کچھ غلط ہو جاتا ہے، تو ہم نئے کنٹینر کو نیچے کر سکتے ہیں، پرانے کنٹینر کو بڑھا سکتے ہیں۔
امیج بنانے کے بعد، ڈویلپمنٹ اور پروڈکشن دونوں میں کنٹینرز ایک جیسے ہوں گے۔ یہ خاص طور پر بڑی تنصیبات کے لیے درست ہے۔
فرنٹ اینڈ پر ہم JavaScipt اور NodeJS استعمال کرتے ہیں۔
اب ہمارے پاس اپنا آخری پروجیکٹ ReacJS پر ہے۔ ڈویلپر نے ہر چیز کو کنٹینر میں لانچ کیا اور ہاٹ ری لوڈ کا استعمال کرتے ہوئے تیار کیا۔
اس کے بعد، JavaScipt کو جمع کرنے کا کام شروع کیا جاتا ہے اور statically اسمبل شدہ کوڈ کو nginx کے ذریعے بھیجا جاتا ہے، وسائل کی بچت ہوتی ہے۔
یہاں میں نے اپنے تازہ ترین پروجیکٹ کا خاکہ فراہم کیا ہے۔
آپ نے کن مسائل کو حل کیا؟ ہمیں ایک ایسا نظام بنانے کی ضرورت تھی جس کے ساتھ موبائل آلات تعامل کریں۔ وہ ڈیٹا وصول کرتے ہیں۔ امکانات میں سے ایک اس ڈیوائس پر پش اطلاعات بھیجنا ہے۔
ہم نے اس کے لیے کیا کیا ہے؟
ہم نے ایپلیکیشن کو درج ذیل اجزاء میں تقسیم کیا: JS میں ایڈمن کا حصہ، ایک بیک اینڈ جو Ruby on Rails کے تحت REST انٹرفیس کے ذریعے کام کرتا ہے۔ بیک اینڈ ڈیٹا بیس کے ساتھ تعامل کرتا ہے۔ نتیجہ جو پیدا ہوتا ہے وہ کلائنٹ کو دیا جاتا ہے۔ ایڈمن پینل ایک REST انٹرفیس کے ذریعے بیک اینڈ اور ڈیٹا بیس کے ساتھ بات چیت کرتا ہے۔
ہمیں پش اطلاعات بھیجنے کی بھی ضرورت تھی۔ اس سے پہلے، ہمارے پاس ایک پروجیکٹ تھا جس میں ایک طریقہ کار نافذ کیا گیا تھا جو موبائل پلیٹ فارم پر اطلاعات پہنچانے کا ذمہ دار تھا۔
ہم نے درج ذیل اسکیم تیار کی ہے: براؤزر سے آپریٹر ایڈمن پینل کے ساتھ بات چیت کرتا ہے، ایڈمن پینل بیک اینڈ کے ساتھ بات چیت کرتا ہے، کام پش نوٹیفیکیشن بھیجنا ہے۔
پش نوٹیفیکیشنز کسی دوسرے جزو کے ساتھ تعامل کرتی ہیں جو NodeJS میں لاگو ہوتا ہے۔
قطاریں لگائی جاتی ہیں اور ان کے اپنے طریقہ کار کے مطابق اطلاعات بھیجی جاتی ہیں۔
یہاں دو ڈیٹا بیس بنائے گئے ہیں۔ فی الحال، Docker کا استعمال کرتے ہوئے، ہم 2 آزاد ڈیٹا بیس استعمال کرتے ہیں جو کسی بھی طرح سے ایک دوسرے سے جڑے ہوئے نہیں ہیں۔ اس حقیقت کے علاوہ کہ ان کے پاس ایک مشترکہ ورچوئل نیٹ ورک ہے، اور جسمانی ڈیٹا ڈویلپر کی مشین پر مختلف ڈائریکٹریوں میں محفوظ ہے۔
ایک ہی چیز لیکن تعداد میں۔ کوڈ کا دوبارہ استعمال یہاں اہم ہے۔
اگر پہلے ہم لائبریریوں کی شکل میں کوڈ کو دوبارہ استعمال کرنے کے بارے میں بات کرتے ہیں، تو اس مثال میں ہماری سروس، جو پش نوٹیفیکیشن کا جواب دیتی ہے، ایک مکمل سرور کے طور پر دوبارہ استعمال ہوتی ہے۔ یہ ایک API فراہم کرتا ہے۔ اور ہماری نئی ترقی اس کے ساتھ تعامل کرتی ہے۔
اس وقت ہم نوڈ جے ایس کا ورژن 4 استعمال کر رہے تھے۔ اب (2017 میں - ایڈیٹر کا نوٹ) ہماری تازہ ترین پیشرفت میں ہم نوڈ جے ایس کا ورژن 7 استعمال کرتے ہیں۔ لائبریریوں کے نئے ورژن کو شامل کرنے میں نئے اجزاء میں کوئی حرج نہیں ہے۔
اگر ضروری ہو تو، آپ پش نوٹیفکیشن سروس کے نوڈ جے ایس ورژن کو ری ایکٹر اور بڑھا سکتے ہیں۔
اور اگر ہم API مطابقت کو برقرار رکھ سکتے ہیں، تو اسے دوسرے پروجیکٹس سے تبدیل کرنا ممکن ہوگا جو پہلے استعمال کیے گئے تھے۔
آپ کو ڈوکر شامل کرنے کی کیا ضرورت ہے؟ ہم اپنے ذخیرے میں ایک Dockerfile شامل کرتے ہیں، جو ضروری انحصار کو بیان کرتا ہے۔ اس مثال میں، اجزاء کو منطقی طور پر تقسیم کیا گیا ہے۔ بیک اینڈ ڈویلپر کے لیے یہ کم از کم کٹ ہے۔
ایک نیا پروجیکٹ بناتے وقت، ہم ایک Dockerfile بناتے ہیں اور مطلوبہ ماحولیاتی نظام (Python, Ruby, NodeJS) کو بیان کرتے ہیں۔ docker-compose میں، یہ ضروری انحصار کی وضاحت کرتا ہے - ڈیٹا بیس۔ ہم بیان کرتے ہیں کہ ہمیں فلاں اور فلاں ورژن کے ڈیٹا بیس کی ضرورت ہے، تاکہ ڈیٹا کو وہاں اور وہاں ذخیرہ کیا جا سکے۔
ہم جامد مواد پیش کرنے کے لیے nginx کے ساتھ ایک علیحدہ تیسرا کنٹینر استعمال کرتے ہیں۔ تصاویر اپ لوڈ کرنا ممکن ہے۔ پسدید انہیں پہلے سے تیار شدہ حجم میں رکھتا ہے، جو nginx کے ساتھ ایک کنٹینر میں بھی نصب ہوتا ہے، جو جامد ڈیٹا فراہم کرتا ہے۔
nginx اور mysql کنفیگریشن کو اسٹور کرنے کے لیے، ہم نے ایک Docker فولڈر شامل کیا جس میں ہم ضروری کنفیگریشنز کو اسٹور کرتے ہیں۔ جب کوئی ڈویلپر اپنی مشین پر کسی ریپوزٹری کا گٹ کلون بناتا ہے، تو اس کے پاس پہلے سے ہی مقامی ترقی کے لیے ایک پروجیکٹ تیار ہوتا ہے۔ اس بارے میں کوئی سوال نہیں ہے کہ کون سی پورٹ یا کون سی ترتیبات لاگو کی جائیں۔
اس کے بعد ہمارے پاس کئی اجزاء ہیں: منتظم، معلومات-API، پش اطلاعات۔
یہ سب شروع کرنے کے لیے، ہم نے ایک اور ذخیرہ بنایا جسے dockerized-app کہتے ہیں۔ ہم فی الحال ہر جزو کے لیے متعدد ذخیرے استعمال کرتے ہیں۔ وہ صرف منطقی طور پر مختلف ہیں - GitLab میں یہ ایک فولڈر کی طرح لگتا ہے، لیکن ڈویلپر کی مشین پر یہ کسی مخصوص پروجیکٹ کے فولڈر کی طرح لگتا ہے۔ ذیل میں ایک سطح وہ اجزاء ہیں جو یکجا کیے جائیں گے۔
یہ dockerized-app کے مشمولات کی ایک مثال ہے۔ ہم یہاں ایک ڈوکر ڈائرکٹری بھی رکھتے ہیں، جس میں ہم تمام اجزاء کے تعامل کے لیے درکار کنفیگریشنز کو بھرتے ہیں۔ ایک README.md ہے جو مختصراً اس منصوبے کو شروع کرنے کا طریقہ بتاتا ہے۔
یہاں ہم نے دو ڈاکر کمپوز فائلیں لگائی ہیں۔ یہ مراحل میں لانچ کرنے کے قابل ہونے کے لیے کیا جاتا ہے۔ جب ایک ڈویلپر کرنل کے ساتھ کام کرتا ہے، تو اسے پش نوٹیفیکیشن کی ضرورت نہیں ہوتی، وہ بس ڈاکر کمپوز فائل لانچ کرتا ہے اور اس کے مطابق وسائل محفوظ کیے جاتے ہیں۔
اگر پش نوٹیفیکیشن کے ساتھ انضمام کی ضرورت ہے، تو docker-compose.yaml اور docker-compose-push.yaml شروع کیے جاتے ہیں۔
چونکہ docker-compose.yaml اور docker-compose-push.yaml فولڈر میں ہیں، ایک واحد ورچوئل نیٹ ورک خود بخود بن جاتا ہے۔
اجزاء کی تفصیل۔ یہ ایک زیادہ جدید فائل ہے جو اجزاء کو جمع کرنے کی ذمہ دار ہے۔ یہاں کیا قابل ذکر ہے؟ یہاں ہم بیلنسر جزو متعارف کراتے ہیں۔
یہ ایک ریڈی میڈ ڈوکر امیج ہے جو nginx چلاتی ہے اور ایک ایپلیکیشن جو Docker ساکٹ کو سنتی ہے۔ متحرک، جیسا کہ کنٹینرز کو آن اور آف کیا جاتا ہے، nginx کنفگ دوبارہ تیار ہوتا ہے۔ ہم تیسرے درجے کے ڈومین ناموں کا استعمال کرتے ہوئے اجزاء کی ہینڈلنگ کو تقسیم کرتے ہیں۔
ترقیاتی ماحول کے لیے ہم .dev ڈومین - api.informer.dev استعمال کرتے ہیں۔ .dev ڈومین والی درخواستیں ڈویلپر کی مقامی مشین پر دستیاب ہیں۔
پھر کنفیگریشنز کو ہر پروجیکٹ میں منتقل کیا جاتا ہے اور تمام پروجیکٹس ایک ہی وقت میں شروع کیے جاتے ہیں۔
اگر ہم اس کی تصویر کشی کرتے ہیں تو پتہ چلتا ہے کہ کلائنٹ ہمارا براؤزر ہے یا کوئی ایسا ٹول ہے جس سے ہم بیلنسر سے درخواستیں کرتے ہیں۔
بیلنس ڈومین نام کی بنیاد پر طے کرتا ہے کہ کن کنٹینر تک رسائی کی ضرورت ہے۔
یہ nginx ہوسکتا ہے، جو ایڈمن پینل کو جے ایس فراہم کرتا ہے۔ یہ nginx کے ذریعہ کیا جا سکتا ہے، جو API فراہم کرتا ہے، یا جامد فائلیں، جو nginx کے ذریعہ لوڈنگ امیجز کی شکل میں فراہم کی جاتی ہیں۔
خاکہ سے پتہ چلتا ہے کہ کنٹینرز ایک ورچوئل نیٹ ورک سے جڑے ہوئے ہیں اور پراکسی کے پیچھے چھپے ہوئے ہیں۔
ڈویلپر کی مشین پر، آپ IP کو جانتے ہوئے کنٹینر تک رسائی حاصل کر سکتے ہیں، لیکن اصولی طور پر ہم اسے استعمال نہیں کرتے ہیں۔ براہ راست رابطے کی عملی طور پر کوئی ضرورت نہیں ہے۔
اپنی درخواست کو ڈاکرائز کرنے کے لیے مجھے کس مثال کو دیکھنا چاہیے؟ میری رائے میں، ایک اچھی مثال MySQL کے لیے آفیشل ڈوکر امیج ہے۔
یہ کافی پیچیدہ ہے۔ بہت سے ورژن ہیں. لیکن اس کی فعالیت آپ کو بہت سی ضروریات کو پورا کرنے کی اجازت دیتی ہے جو مزید ترقی کے عمل میں پیدا ہوسکتی ہیں۔ اگر آپ وقت نکالتے ہیں اور سمجھتے ہیں کہ یہ سب کس طرح تعامل کرتا ہے، تو مجھے لگتا ہے کہ آپ کو خود اسے نافذ کرنے میں کوئی دشواری نہیں ہوگی۔
Hub.docker.com عام طور پر github.com کے لنکس پر مشتمل ہوتا ہے، جہاں خام ڈیٹا براہ راست فراہم کیا جاتا ہے جس سے آپ خود ایک تصویر بنا سکتے ہیں۔
مزید اس ریپوزٹری میں ایک اسکرپٹ docker-endpoint.sh ہے، جو ایپلیکیشن لانچ کی ابتدائی شروعات اور مزید پروسیسنگ کے لیے ذمہ دار ہے۔
نیز اس مثال میں ماحولیاتی متغیرات کا استعمال کرتے ہوئے ترتیب کا امکان موجود ہے۔ ایک کنٹینر چلاتے وقت یا docker-compose کے ذریعے ماحول کے متغیر کی وضاحت کرتے ہوئے، ہم کہہ سکتے ہیں کہ ہمیں MySQL پر روٹ کے لیے docker کے لیے خالی پاس ورڈ سیٹ کرنے کی ضرورت ہے یا جو بھی ہم چاہتے ہیں۔
بے ترتیب پاس ورڈ بنانے کا آپشن موجود ہے۔ ہم کہتے ہیں کہ ہمیں صارف کی ضرورت ہے، ہمیں صارف کے لیے پاس ورڈ سیٹ کرنے کی ضرورت ہے، اور ہمیں ایک ڈیٹا بیس بنانے کی ضرورت ہے۔
ہمارے پروجیکٹس میں، ہم نے Dockerfile کو قدرے متحد کیا ہے، جو ابتدا کے لیے ذمہ دار ہے۔ وہاں ہم نے اسے اپنی ضروریات کے مطابق ایڈجسٹ کیا تاکہ صارف کے حقوق کو وسعت دی جا سکے جو ایپلیکیشن استعمال کرتی ہے۔ اس سے مستقبل میں ایپلیکیشن کنسول سے ڈیٹا بیس بنانا ممکن ہو گیا۔ روبی ایپلی کیشنز کے پاس ڈیٹا بیس بنانے، ترمیم کرنے اور حذف کرنے کے احکامات ہوتے ہیں۔
یہ اس کی ایک مثال ہے کہ MySQL کا مخصوص ورژن github.com پر کیسا لگتا ہے۔ آپ Dockerfile کھول سکتے ہیں اور دیکھ سکتے ہیں کہ وہاں انسٹالیشن کیسے ہوتی ہے۔
docker-endpoint.sh اسکرپٹ انٹری پوائنٹ کے لیے ذمہ دار ہے۔ ابتدائی آغاز کے دوران، کچھ تیاری کے اعمال کی ضرورت ہوتی ہے اور یہ تمام اعمال ابتدائی اسکرپٹ میں شامل ہوتے ہیں۔
آئیے دوسرے حصے کی طرف چلتے ہیں۔
ہم نے سورس کوڈز کو اسٹور کرنے کے لیے gitlab پر سوئچ کیا۔ یہ کافی طاقتور نظام ہے جس کا بصری انٹرفیس ہے۔
Gitlab اجزاء میں سے ایک Gitlab CI ہے۔ یہ آپ کو حکموں کی ایک سیریز کی وضاحت کرنے کی اجازت دیتا ہے جو بعد میں کوڈ کی ترسیل کے نظام کو منظم کرنے یا خودکار ٹیسٹنگ چلانے کے لیے استعمال کیے جائیں گے۔
Gitlab CI 2 پر رپورٹ - روبی روس کلب کی رپورٹ کافی مفصل ہے اور آپ کے لیے دلچسپی کا باعث ہو سکتی ہے۔
اب ہم دیکھیں گے کہ Gitlab CI کو چالو کرنے کے لیے کیا ضروری ہے۔ Gitlab CI کو شروع کرنے کے لیے، ہمیں صرف .gitlab-ci.yml فائل کو پروجیکٹ کے روٹ میں ڈالنے کی ضرورت ہے۔
یہاں ہم بیان کرتے ہیں کہ ہم ریاستوں کا ایک سلسلہ انجام دینا چاہتے ہیں جیسے ٹیسٹ، تعیناتی۔
ہم ایسی اسکرپٹس پر عمل کرتے ہیں جو براہ راست ہماری ایپلیکیشن کی ڈوکر کمپوز بلڈ کو کہتے ہیں۔ یہ صرف پسدید کی ایک مثال ہے۔
اگلا ہم کہتے ہیں کہ ڈیٹا بیس کو تبدیل کرنے اور ٹیسٹ چلانے کے لیے ہجرت چلانا ضروری ہے۔
اگر اسکرپٹ کو صحیح طریقے سے عمل میں لایا جاتا ہے اور غلطی کا کوڈ واپس نہیں کرتے ہیں، تو نظام تعیناتی کے دوسرے مرحلے پر جاتا ہے۔
تعیناتی کا مرحلہ فی الحال سٹیجنگ کے لیے لاگو کیا گیا ہے۔ ہم نے بغیر ڈاؤن ٹائم ری اسٹارٹ کا اہتمام نہیں کیا۔
ہم زبردستی تمام کنٹینرز کو بجھاتے ہیں، اور پھر ہم ٹیسٹ کے دوران پہلے مرحلے پر جمع کیے گئے تمام کنٹینرز کو دوبارہ اٹھاتے ہیں۔
آئیے ڈیٹا بیس کی منتقلی کو چلائیں جو موجودہ متغیر ماحول کے لیے ڈویلپرز نے لکھے تھے۔
ایک نوٹ ہے کہ اس کا اطلاق صرف ماسٹر برانچ پر ہونا چاہیے۔
دوسری شاخوں کو تبدیل کرتے وقت کام نہیں کرتا ہے۔
شاخوں کے ساتھ ساتھ رول آؤٹ کو منظم کرنا ممکن ہے۔
اسے مزید منظم کرنے کے لیے، ہمیں Gitlab Runner انسٹال کرنے کی ضرورت ہے۔
یہ افادیت گولانگ میں لکھی گئی ہے۔ یہ ایک واحد فائل ہے جیسا کہ گولانگ کی دنیا میں عام ہے، جس میں کسی انحصار کی ضرورت نہیں ہے۔
سٹارٹ اپ پر ہم Gitlab Runer کو رجسٹر کرتے ہیں۔
ہمیں Gitlab ویب انٹرفیس میں کلید موصول ہوتی ہے۔
پھر ہم کمانڈ لائن پر ابتدائی کمانڈ کو کال کرتے ہیں۔
ڈائیلاگ موڈ میں گٹلاب رنر کو ترتیب دینا (شیل، ڈوکر، ورچوئل باکس، ایس ایس ایچ)
Gitlab Runner پر موجود کوڈ .gitlab-ci.yml کی ترتیب کے لحاظ سے ہر کمٹ پر عملدرآمد کرے گا۔
یہ ویب انٹرفیس میں Gitlab میں بصری طور پر کیسا لگتا ہے۔ GItlab CI کو جوڑنے کے بعد، ہمارے پاس ایک جھنڈا ہے جو ظاہر کرتا ہے کہ اس وقت تعمیر کس حالت میں ہے۔
ہم دیکھتے ہیں کہ 4 منٹ پہلے ایک عہد کیا گیا تھا جس نے تمام ٹیسٹ پاس کیے تھے اور کسی قسم کی پریشانی پیدا نہیں کی تھی۔
ہم تعمیرات کو مزید تفصیل سے دیکھ سکتے ہیں۔ یہاں ہم دیکھتے ہیں کہ دو ریاستیں گزر چکی ہیں۔ اسٹیجنگ پر جانچ کی حیثیت اور تعیناتی کی حیثیت۔
اگر ہم کسی مخصوص بلڈ پر کلک کرتے ہیں تو وہاں ان کمانڈز کا کنسول آؤٹ پٹ ہوگا جو .gitlab-ci.yml کے مطابق عمل میں شروع کیے گئے تھے۔
ہماری پروڈکٹ کی کہانی اس طرح دکھائی دیتی ہے۔ ہم دیکھتے ہیں کہ کامیاب کوششیں ہوئی ہیں۔ جب ٹیسٹ جمع کرائے جاتے ہیں، وہ اگلے مرحلے پر نہیں جاتے اور سٹیجنگ کوڈ اپ ڈیٹ نہیں ہوتا ہے۔
جب ہم نے ڈوکر کو نافذ کیا تو ہم نے اسٹیجنگ میں کون سے مسائل حل کیے؟ ہمارا سسٹم اجزاء پر مشتمل ہے اور ہمیں صرف کچھ اجزاء کو دوبارہ شروع کرنے کی ضرورت ہے جو کہ ریپوزٹری میں اپ ڈیٹ کیے گئے تھے، نہ کہ پورے سسٹم کو۔
ایسا کرنے کے لیے ہمیں ہر چیز کو الگ الگ فولڈر میں الگ کرنا تھا۔
ایسا کرنے کے بعد، ہمیں اس حقیقت کے ساتھ ایک مسئلہ درپیش تھا کہ Docker-compose ہر فولڈر کے لیے اپنے نیٹ ورک کی جگہ بناتا ہے اور اپنے پڑوسی کے اجزاء کو نہیں دیکھتا۔
گھومنے پھرنے کے لیے، ہم نے ڈوکر میں دستی طور پر نیٹ ورک بنایا۔ Docker-compose میں لکھا تھا کہ آپ کو اس پروجیکٹ کے لیے ایسا نیٹ ورک استعمال کرنا چاہیے۔
اس طرح، اس میش سے شروع ہونے والا ہر جزو نظام کے دوسرے حصوں میں اجزاء کو دیکھتا ہے۔
اگلا مسئلہ کئی منصوبوں کے درمیان اسٹیجنگ کو تقسیم کرنا ہے۔
چونکہ یہ سب کچھ خوبصورت نظر آنے کے لیے اور پروڈکشن کے جتنا ممکن ہوسکے قریب ہے، اس لیے پورٹ 80 یا 443 استعمال کرنا اچھا ہے، جو WEB میں ہر جگہ استعمال ہوتا ہے۔
ہم نے اسے کیسے حل کیا؟ ہم نے تمام بڑے منصوبوں کے لیے ایک Gitlab رنر تفویض کیا ہے۔
Gitlab آپ کو کئی تقسیم شدہ Gitlab رنرز کو لانچ کرنے کی اجازت دیتا ہے، جو تمام کاموں کو ایک ایک کر کے انتشار کی ترتیب میں لے کر چلائیں گے۔
گھر کے مسائل سے بچنے کے لیے، ہم نے اپنے پراجیکٹس کے گروپ کو ایک Gitlab Runner تک محدود کر دیا، جو بغیر کسی پریشانی کے ہمارے حجم کا مقابلہ کرتا ہے۔
ہم نے nginx-proxy کو ایک علیحدہ لانچ اسکرپٹ میں منتقل کیا اور اس میں تمام پروجیکٹس کے گرڈ لکھے۔
ہمارے پروجیکٹ میں ایک گرڈ ہے، اور بیلنسر میں پروجیکٹ کے ناموں پر مبنی کئی گرڈ ہیں۔ یہ ڈومین ناموں سے مزید پراکسی کر سکتا ہے۔
ہماری درخواستیں پورٹ 80 پر ڈومین کے ذریعے آتی ہیں اور ان کا حل کنٹینرز کے ایک گروپ میں ہوتا ہے جو اس ڈومین کی خدمت کرتا ہے۔
اور کیا مسائل تھے؟ یہ وہی ہے جو تمام کنٹینرز بطور ڈیفالٹ روٹ کے طور پر چلتے ہیں۔ یہ نظام کی جڑ غیر مساوی جڑ میزبان ہے۔
تاہم، اگر آپ کنٹینر میں داخل ہوتے ہیں، تو یہ روٹ ہو جائے گا اور جو فائل ہم اس کنٹینر میں بناتے ہیں اسے روٹ کے حقوق حاصل ہوتے ہیں۔
اگر ایک ڈویلپر کنٹینر میں داخل ہوتا ہے اور وہاں کچھ کمانڈ کرتا ہے جس سے فائلیں تیار ہوتی ہیں، پھر کنٹینر کو چھوڑ دیا جاتا ہے، تو اس کی ورکنگ ڈائرکٹری میں اس کے پاس ایک فائل ہے جس تک اس کی رسائی نہیں ہے۔
یہ کیسے حل ہو سکتا ہے؟ آپ ان صارفین کو شامل کر سکتے ہیں جو کنٹینر میں ہوں گے۔
جب ہم نے صارف کو شامل کیا تو کیا مسائل پیدا ہوئے؟
صارف بناتے وقت، گروپ ID (UID) اور صارف ID (GID) اکثر مماثل نہیں ہوتے ہیں۔
کنٹینر میں اس مسئلے کو حل کرنے کے لیے ہم ID 1000 والے صارفین استعمال کرتے ہیں۔
ہمارے معاملے میں، یہ اس حقیقت کے ساتھ موافق ہے کہ تقریبا تمام ڈویلپرز Ubuntu OS استعمال کرتے ہیں. اور Ubuntu OS میں پہلے صارف کے پاس ID 1000 ہے۔
کیا ہمارے پاس کوئی منصوبہ ہے؟
Docker دستاویزات کو دوبارہ پڑھیں۔ پروجیکٹ فعال طور پر ترقی کر رہا ہے، دستاویزات بدل رہی ہیں۔ دو تین ماہ قبل حاصل ہونے والا ڈیٹا آہستہ آہستہ پرانا ہوتا جا رہا ہے۔
کچھ مسائل جو ہم نے حل کیے ہیں وہ معیاری ذرائع سے پہلے ہی حل ہو چکے ہیں۔
میں واقعی میں آگے بڑھنا چاہتا ہوں اور براہ راست آرکیسٹریشن میں جانا چاہتا ہوں۔
ایک مثال Docker کا بلٹ ان میکانزم ہے جسے Docker Swarm کہتے ہیں، جو باکس سے باہر آتا ہے۔ میں ڈوکر سوارم ٹیکنالوجی پر مبنی پروڈکشن میں کچھ لانچ کرنا چاہوں گا۔
کنٹینرز کو اسپن کرنے سے لاگز کے ساتھ کام کرنا تکلیف دہ ہو جاتا ہے۔ اب نوشتہ جات الگ تھلگ ہیں۔ وہ کنٹینرز میں بکھرے ہوئے ہیں۔ کاموں میں سے ایک ویب انٹرفیس کے ذریعے لاگ تک آسان رسائی بنانا ہے۔
ماخذ: www.habr.com