سب سے پہلے، ایک چھوٹا سا نظریہ. کیا ہوا ?
سادہ الفاظ میں، اس دستاویز کو SaaS ایپلیکیشنز کی ترقی کو آسان بنانے کے لیے ڈیزائن کیا گیا ہے، جس سے ڈویلپرز اور DevOps انجینئرز کو ان مسائل اور طریقوں کے بارے میں مطلع کرنے میں مدد ملتی ہے جن کا اکثر جدید ایپلی کیشنز کی ترقی میں سامنا ہوتا ہے۔
دستاویز کو ہیروکو پلیٹ فارم کے ڈویلپرز نے بنایا تھا۔
بارہ فیکٹر ایپ کو کسی بھی پروگرامنگ زبان میں لکھی گئی ایپلی کیشنز پر لاگو کیا جا سکتا ہے اور بیکنگ سروسز (ڈیٹا بیس، میسج کیو، کیچز وغیرہ) کے کسی بھی مجموعہ کا استعمال کرتے ہوئے کیا جا سکتا ہے۔
مختصراً ان عوامل کے بارے میں جن پر یہ طریقہ کار مبنی ہے:
- کوڈ بیس - ورژن کنٹرول میں ٹریک کردہ ایک کوڈ بیس - متعدد تعیناتیاں
- انحصار - واضح طور پر انحصار کا اعلان اور الگ تھلگ کریں۔
- تشکیل - رن ٹائم میں کنفیگریشن کو محفوظ کریں۔
- بیکنگ سروسز - بیکنگ سروسز کو پلگ ان وسائل کے طور پر سمجھیں۔
- بنائیں، جاری کریں، چلائیں - اسمبلی اور عمل کے مراحل کو سختی سے الگ کریں۔
- پروسیسنگ - ایپلیکیشن کو ایک یا زیادہ سٹیٹ لیس پروسیس کے طور پر چلائیں۔
- پورٹ بائنڈنگ - پورٹ بائنڈنگ کے ذریعے خدمات برآمد کریں۔
- ہم آہنگی - عمل کا استعمال کرتے ہوئے اپنی درخواست کی پیمائش کریں۔
- ڈسپوزایبلٹی - تیز رفتار آغاز اور کلین شٹ ڈاؤن کے ساتھ زیادہ سے زیادہ قابل اعتماد
- ایپلیکیشن ڈویلپمنٹ/آپریشن برابری۔ - اپنی نشوونما، اسٹیجنگ اور پیداواری ماحول کو ہر ممکن حد تک یکساں رکھیں
- لاگنگ - لاگ کو واقعات کے سلسلے کے طور پر دیکھیں
- انتظامیہ کے کام - ایڈہاک عمل کا استعمال کرتے ہوئے انتظامیہ/انتظامی کے کام انجام دیں۔
آپ درج ذیل وسائل سے 12 عوامل کے بارے میں مزید معلومات حاصل کر سکتے ہیں۔
- - ایک پڑھنا ضروری ہے
- - سرکاری ترجمہ
- - ان کو بہتر بنانے کے مقصد کے ساتھ 12 عوامل پر ایک تازہ نظر۔
بلیو گرین تعیناتی کیا ہے؟
بلیو گرین تعیناتی ایک درخواست کی فراہمی کا ایک طریقہ ہے۔ پیداوار اس طرح کہ آخری کلائنٹ کو اپنی طرف سے کوئی تبدیلی نظر نہیں آتی۔ دوسرے لفظوں میں، صفر کے ساتھ ایک ایپلیکیشن تعینات کرنا ٹائم ٹائم.
کلاسک BG تعیناتی اسکیم نیچے دی گئی تصویر میں دکھائی گئی اسکیم کی طرح دکھائی دیتی ہے۔
- شروع میں بالکل ایک جیسے کوڈ، ایپلیکیشن، پروجیکٹ کے ساتھ 2 فزیکل سرورز ہیں، اور ایک روٹر (بیلنسر) ہے۔
- روٹر ابتدائی طور پر تمام درخواستوں کو سرورز میں سے ایک کو بھیجتا ہے (سبز).
- اس وقت جب آپ کو دوبارہ ریلیز کرنے کی ضرورت ہے، پورے پروجیکٹ کو دوسرے سرور پر اپ ڈیٹ کیا جاتا ہے (نیلے رنگ)، جو فی الحال کسی درخواست پر کارروائی نہیں کر رہا ہے۔
- کوڈ آن ہونے کے بعد نیلا سرور کو مکمل طور پر اپ ڈیٹ کر دیا گیا ہے، روٹر کو سوئچ کرنے کا حکم دیا گیا ہے۔ سبز پر نیلے رنگ سرور
- اب تمام کلائنٹ اس کے ساتھ چلنے والے کوڈ کا نتیجہ دیکھتے ہیں۔ نیلے رنگ سرور
- کچھ وقت کے لئے، سبز پر ناکام تعیناتی کی صورت میں سرور بیک اپ کاپی کے طور پر کام کرتا ہے۔ نیلے رنگ سرور اور ناکامی اور کیڑے کی صورت میں، روٹر صارف کے بہاؤ کو واپس سوئچ کرتا ہے۔ سبز پرانے مستحکم ورژن کے ساتھ سرور، اور نیا کوڈ نظر ثانی اور جانچ کے لیے بھیجا جاتا ہے۔
- اور عمل کے اختتام پر اسے اسی طرح اپ ڈیٹ کیا جاتا ہے۔ سبز سرور اور اسے اپ ڈیٹ کرنے کے بعد، راؤٹر درخواست کے بہاؤ کو واپس سوئچ کرتا ہے۔ سبز سرور
یہ سب بہت اچھا لگتا ہے اور پہلی نظر میں اس میں کوئی پریشانی نہیں ہونی چاہئے۔
لیکن چونکہ ہم جدید دنیا میں رہتے ہیں، اس لیے فزیکل سوئچنگ کا آپشن جیسا کہ کلاسیکی اسکیم میں اشارہ کیا گیا ہے ہمارے لیے مناسب نہیں ہے۔ ابھی کے لئے معلومات کو ریکارڈ کریں، ہم بعد میں اس پر واپس جائیں گے۔
برا اور اچھا مشورہ
اعلانِ لاتعلقی: ذیل کی مثالیں وہ افادیت/طریقہ کار دکھاتی ہیں جو میں استعمال کرتا ہوں، آپ بالکل اسی طرح کے افعال کے ساتھ کوئی بھی متبادل استعمال کر سکتے ہیں۔
زیادہ تر مثالیں پی ایچ پی اور ڈوکر کے ساتھ ویب ڈویلپمنٹ (یہ ایک حیرت کی بات ہے) کے ساتھ کسی نہ کسی طرح سے ایک دوسرے سے ملتی ہیں۔
ذیل کے پیراگراف مخصوص مثالوں کا استعمال کرتے ہوئے عوامل کے استعمال کی ایک سادہ عملی وضاحت فراہم کرتے ہیں؛ اگر آپ اس موضوع پر مزید نظریہ حاصل کرنا چاہتے ہیں، تو اصل ماخذ کے اوپر دیے گئے لنکس پر عمل کریں۔
1. کوڈ بیس
سرورز پر ایک وقت میں فائلیں اپ لوڈ کرنے کے لیے FTP اور FileZilla کا استعمال کریں، کوڈ کو پروڈکشن سرور کے علاوہ کہیں اور اسٹور نہ کریں۔
پروجیکٹ میں ہمیشہ ایک کوڈ بیس ہونا چاہئے، یعنی تمام کوڈ ایک سے آتا ہے۔ جاؤ ذخیرہ سرورز (پروڈکشن، سٹیجنگ، ٹیسٹ 1، ٹیسٹ 2...) ایک مشترکہ ذخیرہ کی شاخوں سے کوڈ استعمال کرتے ہیں۔ اس طرح ہم کوڈ کی مستقل مزاجی حاصل کرتے ہیں۔
2. انحصار
فولڈرز میں موجود تمام لائبریریوں کو براہ راست پروجیکٹ کی جڑ تک ڈاؤن لوڈ کریں۔ نئے کوڈ کو لائبریری کے موجودہ ورژن کے ساتھ فولڈر میں منتقل کرکے صرف اپ ڈیٹ کریں۔ تمام ضروری یوٹیلیٹیز کو براہ راست میزبان سرور پر انسٹال کریں جہاں مزید 20 سروسز چل رہی ہیں۔
ایک پروجیکٹ میں ہمیشہ انحصار کی واضح طور پر قابل فہم فہرست ہونی چاہئے (انحصارات سے میرا مطلب ماحولیات بھی ہے)۔ تمام انحصار کو واضح طور پر بیان اور الگ تھلگ کیا جانا چاہیے۔
آئیے ایک مثال کے طور پر لیتے ہیں۔ تحریر и میں Docker.
تحریر - ایک پیکیج مینیجر جو آپ کو پی ایچ پی میں لائبریریاں انسٹال کرنے کی اجازت دیتا ہے۔ کمپوزر آپ کو ورژنز کو سختی سے یا ڈھیلے طریقے سے متعین کرنے اور واضح طور پر ان کی وضاحت کرنے کی اجازت دیتا ہے۔ سرور پر 20 مختلف پروجیکٹس ہوسکتے ہیں اور ہر ایک کے پاس پیکجز اور لائبریریوں کی ذاتی فہرست دوسرے سے آزاد ہوگی۔
میں Docker - ایک ایسی افادیت جو آپ کو اس ماحول کی وضاحت اور الگ تھلگ کرنے کی اجازت دیتی ہے جس میں ایپلیکیشن چلے گی۔ اس کے مطابق، بالکل کمپوزر کی طرح، لیکن زیادہ اچھی طرح سے، ہم اس بات کا تعین کر سکتے ہیں کہ ایپلیکیشن کس کے ساتھ کام کرتی ہے۔ پی ایچ پی کا ایک مخصوص ورژن منتخب کریں، صرف وہی پیکجز انسٹال کریں جو پروجیکٹ کے کام کرنے کے لیے ضروری ہیں، بغیر کسی اضافی چیز کے۔ اور سب سے اہم بات، میزبان مشین اور دیگر منصوبوں کے پیکجوں اور ماحول میں مداخلت کیے بغیر۔ یعنی، ڈوکر کے ذریعے چلنے والے سرور پر تمام پروجیکٹس بالکل پیکجوں کے کسی بھی سیٹ اور بالکل مختلف ماحول کو استعمال کر سکتے ہیں۔
3. ترتیب
کنفیگس کو بطور مستقل کوڈ میں اسٹور کریں۔ ٹیسٹ سرور کے لیے الگ مستقل، پیداوار کے لیے الگ۔ ماحول کے لحاظ سے ایپلیکیشن کے آپریشن کو براہ راست پروجیکٹ کی کاروباری منطق میں if else constructs کا استعمال کرتے ہوئے باندھیں۔
تشکیلات - یہ واحد طریقہ ہے کہ پروجیکٹ کی تعیناتیوں میں فرق ہونا چاہیے۔ مثالی طور پر، کنفیگریشنز کو ماحولیاتی متغیرات (env vars) سے گزرنا چاہیے۔
یعنی، یہاں تک کہ اگر آپ متعدد کنفیگریشن فائلز .config.prod .config.local کو اسٹور کرتے ہیں اور تعیناتی کے وقت ان کا نام تبدیل کرکے .config رکھ دیتے ہیں (اہم کنفیگریشن جس سے ایپلیکیشن ڈیٹا پڑھتی ہے) - یہ صحیح طریقہ نہیں ہوگا، کیونکہ اس صورت میں کنفیگریشنز کی معلومات تمام ایپلیکیشن ڈویلپرز کے لیے عوامی طور پر دستیاب ہوں گی اور پروڈکشن سرور کے ڈیٹا سے سمجھوتہ کیا جائے گا۔ تمام کنفیگریشنز کو براہ راست تعیناتی نظام (CI/CD) میں ذخیرہ کیا جانا چاہیے اور مختلف ماحول کے لیے تیار کیا جانا چاہیے جن کی مختلف اقدار تعیناتی کے وقت مخصوص ماحول کے لیے ضروری ہیں۔
4. فریق ثالث کی خدمات
ماحول سے سختی سے منسلک رہیں، مخصوص ماحول میں ایک ہی خدمات کے لیے مختلف کنکشن استعمال کریں۔
درحقیقت، یہ نکتہ کنفیگریشن کے بارے میں پوائنٹ کے ساتھ مضبوطی سے اوور لیپ ہوتا ہے، کیونکہ اس پوائنٹ کے بغیر، نارمل کنفیگریشن ڈیٹا نہیں بنایا جا سکتا اور، عام طور پر، کنفیگر کرنے کی صلاحیت ختم ہو جائے گی۔
بیرونی خدمات کے تمام کنکشنز، جیسے قطار سرورز، ڈیٹا بیس، کیشنگ سروسز، مقامی ماحول اور فریق ثالث/پروڈکشن ماحول دونوں کے لیے یکساں ہونا چاہیے۔ دوسرے الفاظ میں، کسی بھی وقت، کنکشن سٹرنگ کو تبدیل کر کے، میں ایپلیکیشن کوڈ کو تبدیل کیے بغیر بیس نمبر 1 پر کال کو بیس نمبر 2 سے بدل سکتا ہوں۔ یا، آگے دیکھتے ہوئے، مثال کے طور پر، سروس کو اسکیل کرتے وقت، آپ کو اضافی کیش سرور کے لیے کسی خاص طریقے سے کنکشن کی وضاحت نہیں کرنی ہوگی۔
5. تعمیر، رہائی، عملدرآمد
سرور پر کوڈ کا صرف آخری ورژن رکھیں، ریلیز کو واپس لانے کا کوئی امکان نہیں ہے۔ ڈسک کی جگہ کو بھرنے کی ضرورت نہیں ہے۔ کوئی بھی جو یہ سوچتا ہے کہ وہ غلطی کے ساتھ کوڈ کو پروڈکشن میں جاری کر سکتا ہے وہ برا پروگرامر ہے!
تعیناتی کے تمام مراحل کو ایک دوسرے سے الگ کیا جانا چاہیے۔
واپس لوٹنے کا موقع ہے۔ فوری رسائی میں محفوظ کردہ ایپلیکیشن کی پرانی کاپیاں (پہلے سے جمع اور جنگ کے لیے تیار) کے ساتھ ریلیز بنائیں، تاکہ غلطیوں کی صورت میں آپ پرانے ورژن کو بحال کر سکیں۔ یعنی مشروط طور پر ایک فولڈر ہے۔ ریلیز اور فولڈر موجودہ، اور فولڈر کی کامیاب تعیناتی اور اسمبلی کے بعد موجودہ اس کے اندر موجود نئی ریلیز سے علامتی لنک کے ذریعے منسلک ریلیز ریلیز نمبر کے روایتی نام کے ساتھ۔
یہ وہ جگہ ہے جہاں ہمیں بلیو-گرین تعیناتی یاد ہے، جو آپ کو نہ صرف کوڈ کے درمیان سوئچ کرنے کی اجازت دیتی ہے، بلکہ تمام وسائل اور یہاں تک کہ ہر چیز کو واپس لانے کی صلاحیت کے ساتھ ماحول کے درمیان بھی سوئچ کرنے کی اجازت دیتی ہے۔
6. عمل
ایپلیکیشن اسٹیٹ ڈیٹا کو براہ راست ایپلی کیشن میں ہی اسٹور کریں۔ ایپلی کیشن کی RAM میں ہی سیشن استعمال کریں۔ تیسری پارٹی کی خدمات کے درمیان زیادہ سے زیادہ اشتراک کا استعمال کریں۔ اس حقیقت پر بھروسہ کریں کہ درخواست میں صرف ایک عمل ہوسکتا ہے اور اسکیلنگ کی اجازت نہ دیں۔
سیشنز کے بارے میں، ڈیٹا کو صرف فریق ثالث کی خدمات (memcached، redis) کے زیر کنٹرول کیش میں اسٹور کریں، لہذا اگر آپ کے پاس 20 ایپلیکیشن پروسیسز چل رہے ہیں، ان میں سے کوئی بھی، کیشے تک رسائی حاصل کرنے کے بعد، کلائنٹ کے ساتھ کام جاری رکھ سکے گا۔ وہی حالت جس میں صارف کسی اور عمل میں ایپلیکیشن کے ساتھ کام کر رہا تھا۔ اس نقطہ نظر سے، یہ پتہ چلتا ہے کہ اس سے کوئی فرق نہیں پڑتا ہے کہ آپ تیسری پارٹی کی خدمات کی کتنی کاپیاں استعمال کرتے ہیں، سب کچھ عام طور پر کام کرے گا اور ڈیٹا تک رسائی کے ساتھ مسائل کے بغیر.
7. پورٹ بائنڈنگ
صرف ویب سرور کو معلوم ہونا چاہیے کہ فریق ثالث کی خدمات کے ساتھ کیسے کام کرنا ہے۔ یا ابھی تک بہتر، تیسری پارٹی کی خدمات براہ راست ویب سرور کے اندر انسٹال کریں۔ مثال کے طور پر، اپاچی میں پی ایچ پی ماڈیول کے طور پر۔
آپ کی تمام خدمات کسی نہ کسی پتے اور بندرگاہ تک رسائی کے ذریعے ایک دوسرے کے لیے قابل رسائی ہونی چاہئیں postgres، اور php-fpm سے postgres اور nginx تک اور اصل میں ہر سروس سے میں دوسری سروس تک رسائی حاصل کر سکتا ہوں۔ اس طرح، کسی سروس کی قابل عملیت دوسری سروس کی عملداری سے منسلک نہیں ہے۔
8. متوازییت
ایک عمل کے ساتھ کام کریں، ورنہ کئی عمل ایک دوسرے کے ساتھ نہیں مل سکیں گے!
اسکیلنگ کے لیے جگہ چھوڑ دیں۔ ڈاکر بھیڑ اس کے لیے بہت اچھا ہے۔
Docker Swarm مختلف مشینوں اور ایک ہی مشین پر کنٹینرز کے ایک گروپ کے درمیان کنٹینرز کے کلسٹرز بنانے اور ان کا انتظام کرنے کا ایک ٹول ہے۔
swarm کا استعمال کرتے ہوئے، میں اس بات کا تعین کر سکتا ہوں کہ میں ہر عمل کے لیے کتنے وسائل مختص کروں گا اور اسی سروس کے کتنے عمل کو میں شروع کروں گا، اور داخلی بیلنسر، جو دی گئی پورٹ پر ڈیٹا وصول کرتا ہے، خود بخود اس کو پراکسی کر دے گا۔ اس طرح، یہ دیکھ کر کہ سرور پر بوجھ بڑھ گیا ہے، میں مزید پراسیسز شامل کر سکتا ہوں، اس طرح کچھ پراسیس پر بوجھ کم ہو جاتا ہے۔
9. ڈسپوزایبلٹی
عمل اور ڈیٹا کے ساتھ کام کرنے کے لیے قطاروں کا استعمال نہ کریں۔ ایک عمل کو ختم کرنے سے پوری درخواست کو متاثر کرنا چاہیے۔ اگر ایک سروس بند ہو جاتی ہے تو سب کچھ گر جاتا ہے۔
ہر عمل اور سروس کو کسی بھی وقت بند کیا جا سکتا ہے اور اس سے دوسری سروسز کو متاثر نہیں کرنا چاہیے (یقیناً، اس کا مطلب یہ نہیں ہے کہ سروس کسی دوسری سروس کے لیے دستیاب نہیں ہوگی، لیکن یہ کہ اس کے بعد کوئی اور سروس بند نہیں ہوگی)۔ تمام عمل کو احسن طریقے سے ختم کیا جانا چاہیے، تاکہ جب ان کو ختم کیا جائے تو کوئی ڈیٹا خراب نہ ہو اور اگلی بار جب آپ اسے آن کریں تو سسٹم صحیح طریقے سے کام کرے گا۔ یعنی، ہنگامی طور پر ختم ہونے کی صورت میں بھی، ڈیٹا کو نقصان نہیں پہنچانا چاہیے (لین دین کا طریقہ کار یہاں موزوں ہے، ڈیٹا بیس میں سوالات صرف گروپس میں کام کرتے ہیں، اور اگر گروپ کی جانب سے کم از کم ایک سوال ناکام ہوجاتا ہے یا اس پر عمل درآمد کیا جاتا ہے۔ غلطی، پھر گروپ کی طرف سے کوئی اور سوال بالآخر حقیقت میں ناکام نہیں ہوتا ہے)۔
10. ایپلیکیشن ڈویلپمنٹ/آپریشن برابری۔
ایپلیکیشن کا پروڈکشن، سٹیجنگ اور مقامی ورژن مختلف ہونا چاہیے۔ پیداوار میں ہم Yii Lite فریم ورک استعمال کرتے ہیں، اور مقامی طور پر Yii، تاکہ یہ پیداوار میں تیزی سے کام کرے!
حقیقت میں، تمام تعیناتی اور کوڈ کے ساتھ کام تقریباً ایک جیسے ماحول میں ہونا چاہیے (ہم جسمانی ہارڈ ویئر کے بارے میں بات نہیں کر رہے ہیں)۔ نیز، کسی بھی ترقیاتی ملازم کو ضرورت پڑنے پر کوڈ کو پروڈکشن میں تعینات کرنے کے قابل ہونا چاہیے، نہ کہ کچھ خاص طور پر تربیت یافتہ ڈیوپس ڈیپارٹمنٹ، جو صرف خصوصی طاقت کی بدولت ہی ایپلیکیشن کو پروڈکشن میں لے سکتا ہے۔
ڈوکر بھی اس میں ہماری مدد کرتا ہے۔ اگر پچھلے تمام نکات کا مشاہدہ کیا جائے تو، ڈوکر کا استعمال ماحول کو پیداوار اور مقامی مشین پر ایک یا دو کمانڈز میں داخل کرنے کے عمل کو لے آئے گا۔
11. نوشتہ جات
ہم فائلوں اور ڈیٹا بیس پر لاگ لکھتے ہیں! ہم لاگز سے فائلوں اور ڈیٹا بیس کو صاف نہیں کرتے ہیں۔ آئیے صرف 9000 پیٹا بائٹس والی ہارڈ ڈرائیو خریدیں اور یہ ٹھیک ہے۔
تمام نوشتہ جات کو واقعات کے سلسلے کے طور پر سمجھا جانا چاہیے۔ ایپلیکیشن کو خود لاگز کی کارروائی میں شامل نہیں ہونا چاہیے۔ لاگز کو یا تو stdout میں آؤٹ پٹ ہونا چاہیے یا udp جیسے پروٹوکول کے ذریعے بھیجا جانا چاہیے، تاکہ لاگز کے ساتھ کام کرنے سے ایپلیکیشن کے لیے کوئی مسئلہ پیدا نہ ہو۔ graylog اس کے لیے اچھا ہے۔ udp کے ذریعے تمام لاگز وصول کرنے والا گرے لاگ (اس پروٹوکول کے لیے پیکٹ کے کامیاب استقبال کے بارے میں جواب کا انتظار کرنے کی ضرورت نہیں ہے) کسی بھی طرح سے ایپلی کیشن میں مداخلت نہیں کرتا ہے اور صرف لاگز کی ساخت اور پروسیسنگ سے متعلق ہے۔ درخواست کی منطق اس طرح کے طریقوں کے ساتھ کام کرنے میں تبدیل نہیں ہوتی ہے۔
12. انتظامیہ کے کام
ڈیٹا، ڈیٹا بیس وغیرہ کو اپ ڈیٹ کرنے کے لیے، API میں الگ سے بنائے گئے اینڈ پوائنٹ کا استعمال کریں، اسے لگاتار 2 بار چلانے سے ہر چیز ڈپلیکیٹ ہوجائے گی۔ لیکن آپ بیوقوف نہیں ہیں، آپ دو بار کلک نہیں کریں گے، اور ہمیں ہجرت کی ضرورت نہیں ہے۔
تمام انتظامی کاموں کو ریلیز کی سطح پر تمام کوڈ کی طرح ایک ہی ماحول میں انجام دیا جانا چاہیے۔ یعنی، اگر ہمیں ڈیٹا بیس کی ساخت کو تبدیل کرنے کی ضرورت ہے، تو ہم اسے دستی طور پر کالموں کے نام تبدیل کرکے اور کچھ بصری ڈیٹا بیس مینجمنٹ ٹولز کے ذریعے نئے شامل کرکے نہیں کریں گے۔ ایسی چیزوں کے لیے، ہم الگ الگ اسکرپٹ بناتے ہیں - ہجرت، جو ہر جگہ اور تمام ماحول میں ایک ہی طرح سے ایک مشترکہ اور قابل فہم نتیجہ کے ساتھ انجام پاتی ہیں۔ دیگر تمام کاموں کے لیے، جیسے کہ پروجیکٹ کو ڈیٹا سے بھرنا، اسی طرح کے طریقے استعمال کیے جائیں۔
PHP، Laravel، Laradock، Docker-compose میں مثال کے نفاذ
P.S تمام مثالیں MacOS پر بنائی گئی تھیں۔ ان میں سے اکثر لینکس کے لیے بھی موزوں ہیں۔ ونڈوز صارفین، مجھے معاف کر دیں، لیکن میں نے ونڈوز کے ساتھ ایک طویل عرصے سے کام نہیں کیا ہے۔
آئیے ایک ایسی صورتحال کا تصور کریں جہاں ہمارے پی سی پر پی ایچ پی کا کوئی ورژن انسٹال نہیں ہے اور کچھ بھی نہیں۔
ڈوکر اور ڈوکر کمپوز کے تازہ ترین ورژن انسٹال کریں۔ (یہ انٹرنیٹ پر پایا جا سکتا ہے)
docker -v &&
docker-compose -v
1. ڈالنا
git clone https://github.com/Laradock/laradock.git &&
ls
لاراڈاک کے بارے میں، میں یہ کہوں گا کہ یہ بہت عمدہ چیز ہے، جس میں بہت سارے کنٹینرز اور معاون چیزیں ہیں۔ لیکن میں اس کی فالتو پن کی وجہ سے پیداوار میں ترمیم کے بغیر لاراڈاک کو استعمال کرنے کی سفارش نہیں کروں گا۔ Laradock میں مثالوں کی بنیاد پر اپنے کنٹینرز بنانا بہتر ہے، یہ بہت زیادہ بہتر ہو جائے گا، کیونکہ کسی کو بھی ایک ہی وقت میں موجود ہر چیز کی ضرورت نہیں ہے۔
2. ہماری ایپلیکیشن چلانے کے لیے لاراڈاک کو کنفیگر کریں۔
cd laradock &&
cp env-example .env
2.1 کچھ ایڈیٹر میں ہیبر ڈائرکٹری (پینٹ فولڈر جس میں لارڈاک کو کلون کیا گیا ہے) کھولیں۔ (میرے پی ایچ پی اسٹورم کیس میں)
اس مرحلے پر ہم صرف اس منصوبے کو ایک نام دیتے ہیں۔
2.2 ورک اسپیس امیج لانچ کریں۔ (آپ کے معاملے میں، تصاویر بنانے میں کچھ وقت لگے گا)
ورک اسپیس ڈویلپر کی جانب سے فریم ورک کے ساتھ کام کرنے کے لیے خاص طور پر تیار کردہ تصویر ہے۔
ہم استعمال کرتے ہوئے کنٹینر کے اندر جاتے ہیں۔
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3۔ Laravel انسٹال کرنا
composer create-project --prefer-dist laravel/laravel application
2.4 انسٹالیشن کے بعد، ہم چیک کرتے ہیں کہ آیا پروجیکٹ کے ساتھ ڈائرکٹری بنائی گئی ہے اور کمپوز کو ختم کر دیا گیا ہے۔
ls
exit
docker-compose down
2.5 آئیے PHPStorm پر واپس چلتے ہیں اور .env فائل میں اپنی لاریول ایپلی کیشن کا صحیح راستہ طے کرتے ہیں۔
3. Git میں تمام کوڈ شامل کریں۔
ایسا کرنے کے لیے، ہم گیتوب (یا کہیں اور) پر ایک ذخیرہ بنائیں گے۔ آئیے ٹرمینل میں habr ڈائرکٹری پر جائیں اور درج ذیل کوڈ پر عمل کریں۔
echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status
آئیے چیک کریں کہ آیا سب کچھ ترتیب میں ہے۔
سہولت کے لیے، میں گٹ کے لیے کچھ بصری انٹرفیس استعمال کرنے کی تجویز کرتا ہوں، میرے معاملے میں یہ ہے۔ . (یہاں ایک حوالہ لنک ہے)
4. آئیے لانچ کریں!
شروع کرنے سے پہلے، یقینی بنائیں کہ پورٹ 80 اور 443 پر کچھ بھی نہیں لٹک رہا ہے۔
docker-compose up -d nginx php-fpm
اس طرح، ہمارا پروجیکٹ 3 علیحدہ خدمات پر مشتمل ہے:
- nginx - ویب سرور
- php-fpm - ویب سرور سے درخواستیں وصول کرنے کے لیے پی ایچ پی
- ورک اسپیس - ڈویلپرز کے لیے پی ایچ پی
اس وقت، ہم نے حاصل کیا ہے کہ ہم نے ایک ایسی ایپلی کیشن بنائی ہے جو 4 میں سے 12 پوائنٹس کو پورا کرتی ہے، یعنی:
1. کوڈ بیس - تمام کوڈ ایک ذخیرہ میں ہے (چھوٹا نوٹ: لاریول پروجیکٹ کے اندر ڈوکر شامل کرنا درست ہوسکتا ہے، لیکن یہ اہم نہیں ہے)۔
2. انحصار - ہمارے تمام انحصار واضح طور پر application/composer.json میں اور ہر کنٹینر کی ہر Dockerfile میں لکھے گئے ہیں۔
3. بیکنگ سروسز — ہر ایک سروس (php-fom، nignx، ورک اسپیس) اپنی زندگی گزارتی ہے اور باہر سے جڑی ہوتی ہے اور ایک سروس کے ساتھ کام کرتے وقت، دوسری متاثر نہیں ہوتی۔
4. پروسیسنگ - ہر سروس ایک عمل ہے۔ خدمات میں سے ہر ایک اندرونی حالت کو برقرار نہیں رکھتی ہے۔
5. پورٹ بائنڈنگ
docker ps
جیسا کہ ہم دیکھ سکتے ہیں، ہر سروس اپنی اپنی پورٹ پر چلتی ہے اور دوسری تمام سروسز کے لیے قابل رسائی ہے۔
6. ہم آہنگی
Docker ہمیں ان کے درمیان خودکار بوجھ توازن کے ساتھ ایک ہی خدمات کے متعدد عملوں کو پیدا کرنے کی اجازت دیتا ہے۔
آئیے کنٹینرز کو روکیں اور انہیں جھنڈے کے ذریعے چلائیں۔ --پیمانہ
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
جیسا کہ ہم دیکھ سکتے ہیں، php-fpm کنٹینر کی کاپیاں بنائی گئی ہیں۔ ہمیں اس کنٹینر کے ساتھ کام کرنے میں کچھ بھی تبدیل کرنے کی ضرورت نہیں ہے۔ ہم پورٹ 9000 پر بھی اس تک رسائی جاری رکھتے ہیں، اور Docker ہمارے لیے کنٹینرز کے درمیان بوجھ کو منظم کرتا ہے۔
7. ڈسپوزایبلٹی - ہر کنٹینر دوسرے کو نقصان پہنچائے بغیر مارا جا سکتا ہے۔ کنٹینر کو روکنے یا دوبارہ شروع کرنے سے بعد کے آغاز کے دوران ایپلیکیشن کے آپریشن پر کوئی اثر نہیں پڑے گا۔ ہر کنٹینر کو بھی کسی بھی وقت اٹھایا جا سکتا ہے۔
8. ایپلیکیشن ڈویلپمنٹ/آپریشن برابری۔ - ہمارے تمام ماحول ایک جیسے ہیں۔ پروڈکشن میں سرور پر سسٹم کو چلانے سے، آپ کو اپنے کمانڈز میں کچھ بھی تبدیل نہیں کرنا پڑے گا۔ سب کچھ اسی طرح ڈوکر پر مبنی ہوگا۔
9. لاگنگ - ان کنٹینرز میں موجود تمام لاگز اسٹریم پر جاتے ہیں اور ڈوکر کنسول میں نظر آتے ہیں۔ (اس صورت میں، درحقیقت، دیگر گھریلو کنٹینرز کے ساتھ، اگر آپ اس کا خیال نہیں رکھتے ہیں تو ایسا نہیں ہو سکتا)
docker-compose logs -f
لیکن اس میں ایک کیچ ہے کہ PHP اور Nginx میں ڈیفالٹ ویلیوز بھی فائل میں لاگ لکھتی ہیں۔ 12 عوامل کو پورا کرنے کے لئے، یہ ضروری ہے غیر فعال ہر کنٹینر کی ترتیب میں الگ الگ فائل میں لاگ لکھنا۔
ڈاکر نہ صرف stdout بلکہ گرے لاگ جیسی چیزوں کو بھی لاگ بھیجنے کی صلاحیت فراہم کرتا ہے، جس کا میں نے اوپر ذکر کیا ہے۔ اور گرے لاگ کے اندر، ہم لاگز کو اپنی مرضی کے مطابق چلا سکتے ہیں اور ہماری ایپلی کیشن کسی بھی طرح سے اس کا نوٹس نہیں لے گی۔
10. انتظامیہ کے کام - تمام انتظامی کاموں کو لاراول کے ذریعے حل کیا جاتا ہے جس طرح کاریگر ٹول کی بدولت 12 فیکٹر ایپلی کیشن کے تخلیق کار چاہتے ہیں۔
ایک مثال کے طور پر، میں دکھاؤں گا کہ کچھ کمانڈز کو کیسے عمل میں لایا جاتا ہے۔
ہم کنٹینر میں جاتے ہیں.
docker-compose exec workspace bash
php artisan list
اب ہم کوئی بھی کمانڈ استعمال کر سکتے ہیں۔ (براہ کرم نوٹ کریں کہ ہم نے ڈیٹا بیس اور کیش کو کنفیگر نہیں کیا ہے، اس لیے آدھے کمانڈز کو درست طریقے سے نہیں چلایا جائے گا، کیونکہ وہ کیشے اور ڈیٹا بیس کے ساتھ کام کرنے کے لیے ڈیزائن کیے گئے ہیں)۔
11. تشکیلات اور 12۔ بنائیں، جاری کریں، چلائیں
میں اس حصے کو بلیو گرین تعیناتی کے لیے وقف کرنا چاہتا تھا، لیکن یہ اس مضمون کے لیے بہت وسیع نکلا۔ اس بارے میں ایک الگ مضمون لکھوں گا۔
مختصراً یہ تصور CI/CD نظاموں پر مبنی ہے۔ جینکنز и Gitlab CI. دونوں میں، آپ ایک مخصوص ماحول سے وابستہ ماحولیاتی متغیرات کو ترتیب دے سکتے ہیں۔ اس کے مطابق، اس صورت حال میں، نقطہ سی پورا ہو جائے گا کنفیگریشنز.
اور نقطہ کے بارے میں بنائیں، جاری کریں، چلائیں نام کے ساتھ بلٹ ان فنکشنز کے ذریعے حل کیا جاتا ہے۔ پائپ لائن.
پائپ لائن آپ کو تعیناتی کے عمل کو کئی مراحل میں تقسیم کرنے کی اجازت دیتا ہے، اسمبلی، رہائی اور عمل درآمد کے مراحل کو نمایاں کرتا ہے۔ پائپ لائن میں بھی، آپ بیک اپ بنا سکتے ہیں، اور درحقیقت کچھ بھی۔ یہ لامحدود صلاحیت کے ساتھ ایک آلہ ہے.
درخواست کوڈ پر ہے۔ .
اس ذخیرے کی کلوننگ کرتے وقت ذیلی ماڈل کو شروع کرنا نہ بھولیں۔
PS: ان تمام طریقوں کو کسی بھی دوسری افادیت اور پروگرامنگ زبانوں کے ساتھ استعمال کیا جا سکتا ہے۔ اہم بات یہ ہے کہ جوہر مختلف نہیں ہے.
ماخذ: www.habr.com