پهريون، هڪ ننڍڙو نظريو. ڇا ٿيو آهي ?
سادي لفظن ۾، هي دستاويز SaaS ايپليڪيشنن جي ترقي کي آسان ڪرڻ لاءِ ٺاهيو ويو آهي، ڊولپرز ۽ DevOps انجنيئرن کي انهن مسئلن ۽ طريقن بابت آگاهي ڏيڻ ۾ مدد ڪندي جيڪي اڪثر ڪري جديد ايپليڪيشنن جي ترقي ۾ پيش اچن ٿا.
دستاويز ٺاهي وئي هيروڪو پليٽ فارم جي ڊولپرز پاران.
Twelve-Factor ايپ ڪنهن به پروگرامنگ ٻولي ۾ لکيل ايپليڪيشنن تي لاڳو ٿي سگهي ٿي ۽ ڪنهن به ميلاپ کي استعمال ڪندي بيڪنگ سروسز (ڊيٽابيس، پيغام جي قطار، ڪيش وغيره).
مختصر طور تي انهن عنصرن جي باري ۾ جن تي هي طريقو مبني آهي:
- ڪوڊ بيس - ورزن ڪنٽرول ۾ ٽريڪ ٿيل ھڪڙو ڪوڊ بيس - گھڻن ڊيپلائيشن
- انحصار - واضح طور تي بيان ڪريو ۽ انحصار کي الڳ ڪريو
- ڪنفگريشن - رن ٽائم ۾ ترتيب محفوظ ڪريو
- پوئتي خدمتون - پلگ ان وسيلن جي طور تي پٺتي پيل خدمتن تي غور ڪريو
- ٺاھڻ ، ڇڏڻ ، ھلائڻ - سختي سان اسيمبلي ۽ عمل جي مرحلن کي الڳ ڪريو
- پروسيس - ايپليڪيشن کي هلايو هڪ يا وڌيڪ رياستي عملن جي طور تي
- پورٽ پابند - پورٽ بائنڊنگ ذريعي خدمتون برآمد ڪريو
- سموري - پروسيس استعمال ڪندي توهان جي ايپليڪيشن کي ماپ ڪريو
- نيڪال ڪرڻ - تيز شروعات ۽ صاف شٽ ڊائون سان اعتماد کي وڌايو
- ايپليڪيشن ڊولپمينٽ / آپريشن برابري - پنهنجي ترقي، اسٽيجنگ، ۽ پيداوار جي ماحول کي ممڪن طور تي ساڳيو رکو
- لاگنگ - واقعن جي هڪ وهڪرو طور لاگ ڏسو
- انتظاميه جي انتظاميه - ايڊهاڪ عملن کي استعمال ڪندي انتظامي / انتظامي ڪمن کي انجام ڏيو
توھان ھيٺ ڏنل وسيلن مان 12 عنصرن بابت وڌيڪ معلومات حاصل ڪري سگھو ٿا:
- - پڙهڻ لازمي آهي
- - سرڪاري ترجمو
- - 12 عنصرن تي هڪ تازي نظر انهن کي بهتر ڪرڻ جي مقصد سان.
بليو-گرين ڊيپلائيشن ڇا آهي؟
بليو گرين ڊيپلائيشن هڪ طريقه ڪار آهي جنهن کي ايپليڪيشن پهچائڻ لاءِ پيداوار اهڙي طرح ته آخر ڪلائنٽ پنهنجي حصي ۾ ڪا به تبديلي نه ڏسي. ٻين لفظن ۾، صفر سان ايپليڪيشن کي ترتيب ڏيڻ دير جو وقت.
کلاسک بي جي ڊيپلائي اسڪيم هيٺ ڏنل تصوير ۾ ڏيکاريل هڪ وانگر ڏسڻ ۾ اچي ٿي.
- شروع ۾ 2 فزيڪل سرور آهن بلڪل ساڳي ڪوڊ، ايپليڪيشن، پروجيڪٽ، ۽ اتي هڪ روٽر (بيلنسر) آهي.
- روٽر شروعاتي طور تي سڀني درخواستن کي سڌو سنئون سرورز (سائو).
- هن وقت جڏهن توهان کي ٻيهر ڇڏڻ جي ضرورت آهي، سڄو پروجيڪٽ ٻئي سرور تي اپڊيٽ ڪيو ويندو آهي (نيرو)، جيڪو في الحال ڪنهن به درخواست تي عمل نه ڪري رهيو آهي.
- ڪوڊ آن ٿيڻ کان پوءِ نيرو سرور مڪمل طور تي اپڊيٽ ٿيل آهي، روٽر کي سوئچ ڪرڻ لاء هڪ حڪم ڏنو ويو آهي سائو تي نيرو سرور
- ھاڻي سڀ ڪلائنٽ ڏسندا آھن ڪوڊ جو نتيجو ھلندڙ سان نيري سرور
- ڪجهه وقت لاءِ، سائو سرور هڪ بيڪ اپ ڪاپي جي طور تي ڪم ڪندو آهي جڏهن ته ناڪامي جي ترتيب جي صورت ۾ نيرو سرور ۽ ناڪامي ۽ ڪيچ جي صورت ۾، روٽر صارف جي وهڪري کي واپس ڏانهن تبديل ڪري ٿو سائو پراڻي مستحڪم ورزن سان سرور، ۽ نئون ڪوڊ نظر ثاني ۽ جاچ لاءِ موڪليو ويو آهي.
- ۽ عمل جي آخر ۾، اهو ساڳيو طريقي سان اپڊيٽ ڪيو ويو آهي سائو سرور ۽ ان کي تازه ڪاري ڪرڻ کان پوء، روٽر واپسي جي درخواست جي وهڪري کي تبديل ڪري ٿو سائو سرور
اهو سڀ ڪجهه تمام سٺو لڳندو آهي ۽ پهرين نظر ۾ ان سان ڪو به مسئلو نه هجڻ گهرجي.
پر جيئن ته اسان جديد دنيا ۾ رهون ٿا، فزيڪل سوئچنگ جو اختيار جيئن ته ڪلاسيڪل اسڪيم ۾ ڏيکاريل آهي اسان کي مناسب نه آهي. ھاڻي معلومات کي رڪارڊ ڪريو، اسان ان کي بعد ۾ واپس ڪنداسين.
خراب ۽ سٺي صلاح
اعلان: هيٺ ڏنل مثال ڏيکارين ٿا افاديت/طريقه ڪار جيڪي آئون استعمال ڪريان ٿو، توهان استعمال ڪري سگهو ٿا بلڪل ڪي به متبادل ساڳين ڪمن سان.
گھڻا مثال ھڪڙي طريقي سان يا ٻئي طريقي سان ويب ڊولپمينٽ سان (ھي ھڪڙو تعجب آھي) پي ايڇ پي ۽ ڊڪر سان گڏ.
هيٺ ڏنل پيراگراف مخصوص مثالن کي استعمال ڪندي عامل جي استعمال جي سادي عملي وضاحت مهيا ڪن ٿا؛ جيڪڏهن توهان هن موضوع تي وڌيڪ نظريو حاصل ڪرڻ چاهيو ٿا، ته مٿي ڏنل لنڪ جي پيروي ڪريو اصل ماخذ ڏانهن.
1. ڪوڊ بيس
استعمال ڪريو FTP ۽ FileZilla فائلن کي سرور تي اپلوڊ ڪرڻ لاءِ هڪ وقت ۾، ڪوڊ کي ذخيرو نه ڪريو پروڊڪشن سرور کان سواءِ ڪٿي به.
پروجيڪٽ کي هميشه هڪ واحد ڪوڊ بنيادي هجڻ گهرجي، اهو آهي، سڀ ڪوڊ هڪ کان اچي ٿو Git مخزن. سرورز (پيداوار، اسٽيجنگ، ٽيسٽ 1، ٽيسٽ 2...) ڪوڊ استعمال ڪن ٿا شاخن مان ھڪڙي عام مخزن جي. هن طريقي سان اسان ڪوڊ جي استحڪام حاصل ڪندا آهيون.
2. انحصار
فولڊر ۾ سڀئي لائبريريون ڊائون لوڊ ڪريو سڌو پروجيڪٽ جي روٽ تائين. تازه ڪاري ڪريو صرف نئين ڪوڊ کي فولڊر ۾ منتقل ڪندي لائبريري جي موجوده ورزن سان. انسٽال ڪريو سڀ ضروري افاديت سڌو سنئون ھوسٽ سرور تي جتي 20 وڌيڪ خدمتون ھلائي رھيون آھن.
ھڪڙي منصوبي کي ھميشه ھڪڙي واضح طور تي سمجھڻ واري فهرست ھجڻ گھرجي انحصار جي (انحصار مان، مان پڻ ماحول جو مطلب آھي). سڀني انحصار کي واضح طور تي بيان ڪيو وڃي ۽ الڳ ڪيو وڃي.
اچو ته هڪ مثال طور وٺون موسيقار и Docker.
موسيقار - هڪ پيڪيج مئنيجر جيڪو توهان کي PHP ۾ لائبريريون نصب ڪرڻ جي اجازت ڏئي ٿو. ڪمپوزر توهان کي نسخن جي وضاحت ڪرڻ جي اجازت ڏئي ٿو سختي سان يا لوز، ۽ واضح طور تي وضاحت ڪريو. سرور تي 20 مختلف منصوبا ٿي سگھن ٿا ۽ ھر ھڪ وٽ ھڪڙي ذاتي فهرست ھوندي جيڪا پيڪيجز ۽ لائبريرين جي ٻئي کان آزاد ھوندي.
Docker - هڪ افاديت جيڪا توهان کي ماحول جي وضاحت ۽ الڳ ڪرڻ جي اجازت ڏئي ٿي جنهن ۾ ايپليڪيشن هلندي. ان جي مطابق، موسيقار وانگر، پر وڌيڪ چڱي طرح، اسان اهو طئي ڪري سگهون ٿا ته ايپليڪيشن ڪهڙي ڪم سان ڪم ڪري ٿي. PHP جو هڪ مخصوص ورزن چونڊيو، صرف انسٽال ڪريو جيڪي پيڪيجز ضروري آهن پراجيڪٽ جي ڪم ڪرڻ لاءِ، بغير ڪنهن اضافي جي. ۽ سڀ کان اهم، ميزبان مشين ۽ ٻين منصوبن جي پيڪيجز ۽ ماحول سان مداخلت ڪرڻ کان سواء. اهو آهي، ڊڪر ذريعي هلندڙ سرور تي سڀئي منصوبا مڪمل طور تي پيڪيجز جي ڪنهن به سيٽ ۽ مڪمل طور تي مختلف ماحول استعمال ڪري سگهن ٿا.
3. ترتيب
اسٽور ڪنفيگرن کي مستقل طور تي ڪوڊ ۾ سڌو سنئون. ٽيسٽ سرور لاءِ الڳ مستقل، پيداوار لاءِ الڳ. ايپليڪيشن جي آپريشن کي ڳنڍيو ماحول جي بنياد تي سڌو سنئون منصوبي جي ڪاروباري منطق ۾ استعمال ڪندي if else constructs.
ترتيبون - اهو واحد طريقو آهي جنهن ۾ پروجيڪٽ جي ترتيبن ۾ فرق هجڻ گهرجي. مثالي طور تي، ترتيبن کي ماحولياتي متغيرن (env vars) ذريعي گذريو وڃي.
اھو آھي، جيتوڻيڪ توھان ڪيترن ئي ڪنفيگريشن فائلن کي ذخيرو ڪريو .config.prod .config.local ۽ انھن جو نالو تبديل ڪرڻ وقت .config (اھو مکيه config جنھن مان ايپليڪيشن ڊيٽا پڙھي ٿي) - اھو صحيح طريقو نه ھوندو، ڇو ته انهي صورت ۾ ترتيبن مان معلومات عام طور تي سڀني ايپليڪيشن ڊولپرز لاءِ دستياب هوندي ۽ پيداوار جي سرور مان ڊيٽا سمجھوتي ڪئي ويندي. سڀني ترتيبن کي سڌو سنئون ڊيپلائيمينٽ سسٽم (CI/CD) ۾ ذخيرو ڪيو وڃي ۽ مختلف ماحولن لاءِ تيار ڪيو وڃي مختلف قدرن سان گڏ جيڪي مقرر ڪرڻ وقت مخصوص ماحول لاءِ ضروري آهن.
4. ٽئين پارٽي جون خدمتون
ماحول سان سختي سان جڙيل رهو، مخصوص ماحول ۾ ساڳين خدمتن لاءِ مختلف ڪنيڪشن استعمال ڪريو.
حقيقت ۾، هي نقطو مضبوطيء سان ترتيبن جي باري ۾ نقطي سان اوورليپ ڪري ٿو، ڇاڪاڻ ته هن نقطي کان سواء، عام ترتيب واري ڊيٽا نه ٿي سگهي ٿي، ۽ عام طور تي، ترتيب ڏيڻ جي صلاحيت ڪجهه به نه ٿي ويندي.
خارجي خدمتن سان سڀ ڪنيڪشن، جهڙوڪ قطار سرور، ڊيٽابيس، ڪيشنگ سروسز، لازمي طور تي مقامي ماحول ۽ ٽئين پارٽي/پيداوار ماحول ٻنهي لاءِ هڪجهڙا هجن. ٻين لفظن ۾، ڪنهن به وقت، ڪنيڪشن اسٽرنگ کي تبديل ڪرڻ سان، مان ايپليڪيشن ڪوڊ کي تبديل ڪرڻ کان سواءِ بيس # 1 سان بيس # 2 تي ڪالون تبديل ڪري سگھان ٿو. يا، اڳتي ڏسندي، مثال طور، خدمت کي اسڪيل ڪرڻ وقت، توهان کي اضافي ڪيش سرور لاءِ ڪنهن خاص طريقي سان ڪنيڪشن بيان ڪرڻ جي ضرورت نه پوندي.
5. ٺاھڻ، ڇڏڻ، عمل ڪرڻ
سرور تي ڪوڊ جو صرف آخري نسخو آهي، ڇڏڻ جو ڪو به موقعو نه آهي واپس موٽڻ جو. ڊسڪ اسپيس ڀرڻ جي ڪا ضرورت ناهي. ڪو به ماڻهو جيڪو سوچي ٿو ته اهي ڪوڊ جاري ڪري سگهن ٿا پيداوار ۾ غلطي سان هڪ خراب پروگرامر آهي!
مقرري جي سڀني مرحلن کي هڪ ٻئي کان الڳ ٿيڻ گهرجي.
واپس رول ڪرڻ جو هڪ موقعو آهي. ايپليڪيشن جي پراڻين ڪاپين سان رليز ڪريو (اڳ ۾ ئي گڏ ٿيل ۽ جنگ لاءِ تيار) جلدي رسائي ۾ محفوظ ڪيو ويو، انهي ڪري ته غلطي جي صورت ۾ توهان پراڻي ورزن کي بحال ڪري سگهو ٿا. اهو آهي، شرطي طور تي هڪ فولڊر آهي رسيد ۽ فولڊر موجوده، ۽ فولڊر کي ڪامياب لڳائڻ ۽ اسيمبليءَ کان پوءِ موجوده نئين رليز سان علامتي لنڪ سان ڳنڍيل آهي جيڪو اندر آهي رسيد رليز نمبر جي روايتي نالي سان.
هي اهو آهي جتي اسان کي ياد آهي Blue-Green deployment، جيڪا توهان کي نه رڳو ڪوڊ جي وچ ۾ سوئچ ڪرڻ جي اجازت ڏئي ٿي، پر سڀني وسيلن ۽ حتي ماحول جي وچ ۾ تبديل ڪرڻ جي صلاحيت سان هر شيء کي واپس آڻڻ جي صلاحيت سان.
6. عمل
اسٽور ايپليڪيشن اسٽيٽ ڊيٽا سڌو سنئون ايپليڪيشن جي اندر اندر. پاڻ ايپليڪيشن جي رام ۾ سيشن استعمال ڪريو. ممڪن طور تي ٽئين پارٽي جي خدمتن جي وچ ۾ وڌ کان وڌ شيئرنگ استعمال ڪريو. حقيقت تي يقين رکو ته ايپليڪيشن صرف هڪ عمل ڪري سگهي ٿي ۽ اسڪيلنگ جي اجازت نه ڏيو.
سيشن جي حوالي سان، ڊيٽا کي صرف ٽئين پارٽي سروسز (memcached، redis) پاران ڪنٽرول ڪيل ڪيش ۾ ذخيرو ڪريو، تنهن ڪري جيتوڻيڪ توهان وٽ 20 ايپليڪيشن پروسيس هلندڙ آهن، انهن مان ڪو به، ڪيش تائين رسائي حاصل ڪري، ڪلائنٽ سان ڪم جاري رکڻ جي قابل هوندو. ساڳي حالت جنهن ۾ صارف ٻئي عمل ۾ ايپليڪيشن سان ڪم ڪري رهيو هو. هن طريقي سان، اهو ظاهر ٿئي ٿو ته توهان ڪيترين ئي ٽئين پارٽي جي خدمتن جون ڪاپيون استعمال ڪندا آهيو، هر شيء عام طور تي ڪم ڪندو ۽ ڊيٽا تائين رسائي جي مسئلن کان سواء.
7. پورٽ بائنڊنگ
صرف ويب سرور کي ڄاڻڻ گهرجي ته ٽئين پارٽي جي خدمتن سان ڪيئن ڪم ڪجي. يا اڃا بهتر، ٽئين پارٽي جي خدمتن کي انسٽال ڪريو سڌو ويب سرور جي اندر. مثال طور، Apache ۾ PHP ماڊل جي طور تي.
توھان جون سڀئي خدمتون ھڪ ٻئي تائين پھچڻ جي ھجڻ گهرجن ڪجھ ائڊريس ۽ پورٽ تائين پھچڻ جي ذريعي (localgost:5432, localhost:3000, nginx:80, php-fpm:9000)، يعني nginx مان مان php-fpm ۽ to ٻنهي تائين رسائي ڪري سگھان ٿو. postgres، ۽ php-fpm کان postgres ۽ nginx تائين ۽ اصل ۾ هر خدمت مان مان ٻي خدمت تائين رسائي ڪري سگهان ٿو. هن طريقي سان، هڪ خدمت جي استحڪام ٻي خدمت جي استحڪام سان ڳنڍيل ناهي.
8. متوازي
هڪ عمل سان ڪم ڪريو، ٻي صورت ۾ ڪيترائي عمل هڪ ٻئي سان گڏ نه ٿي سگهندا!
اسڪيلنگ لاء ڪمرو ڇڏي ڏيو. Docker swarm هن لاء وڏو آهي.
Docker Swarm هڪ اوزار آهي ڪنٽينرز جا ڪلسٽر ٺاهڻ ۽ انتظام ڪرڻ لاءِ ٻنهي مختلف مشينن جي وچ ۾ ۽ هڪ ئي مشين تي ڪنٽينرز جو هڪ گروپ.
swarm استعمال ڪندي، مان اندازو لڳائي سگهان ٿو ته مان هر پروسيس لاءِ ڪيترا وسيلا مختص ڪندس ۽ ساڳئي خدمت جا ڪيترا عمل آئون لانچ ڪندس، ۽ اندروني بيلنس ڪندڙ، ڏنل بندرگاهه تي ڊيٽا حاصل ڪري، خودڪار طريقي سان ان کي پروسيس تي پراکسي ڪندو. اهڙيءَ طرح، اهو ڏسي ته سرور تي لوڊ وڌي ويو آهي، مان وڌيڪ پروسيس شامل ڪري سگهان ٿو، ان ڪري ڪجهه پروسيس تي لوڊ گهٽائي.
9. نيڪال
عمل ۽ ڊيٽا سان ڪم ڪرڻ لاء قطار استعمال نه ڪريو. ھڪڙي عمل کي مارڻ سڄي ايپليڪيشن کي متاثر ڪرڻ گھرجي. جيڪڏهن هڪ خدمت گهٽجي وڃي ٿي، هر شيء ختم ٿي ويندي آهي.
هر عمل ۽ خدمت کي ڪنهن به وقت بند ڪري سگهجي ٿو ۽ اهو ٻين خدمتن کي متاثر نه ڪرڻ گهرجي (يقيناً، هن جو مطلب اهو ناهي ته اها خدمت ڪنهن ٻئي خدمت لاءِ دستياب نه هوندي، پر اها ٻي خدمت هن کان پوءِ بند نه ٿيندي). سڀني عملن کي شاندار طور تي ختم ڪيو وڃي، انهي ڪري ته جڏهن اهي ختم ڪيا وڃن، ڪو به ڊيٽا خراب نه ٿيندو ۽ سسٽم صحيح طريقي سان ڪم ڪندو جڏهن توهان ان کي آن ڪيو. اهو آهي، ايمرجنسي ختم ٿيڻ جي صورت ۾ به، ڊيٽا کي نقصان نه پهچايو وڃي (هتي ٽرانزيڪشن ميڪانيزم مناسب آهي، ڊيٽابيس ۾ سوال صرف گروپن ۾ ڪم ڪن ٿا، ۽ جيڪڏهن گروپ کان گهٽ ۾ گهٽ هڪ سوال ناڪام ٿي وڃي يا ان تي عمل ڪيو وڃي. error، پوءِ گروپ مان ڪو ٻيو سوال آخرڪار حقيقت ۾ ناڪام ٿيندو).
10. ايپليڪيشن ڊولپمينٽ/آپريشن برابري
ايپليڪيشن جي پيداوار، اسٽيجنگ ۽ مقامي ورزن مختلف هجڻ گهرجي. پيداوار ۾ اسان استعمال ڪندا آهيون Yii Lite فريم ورڪ، ۽ مقامي طور تي Yii، انهي ڪري ته اهو پيداوار ۾ تيزيء سان ڪم ڪري ٿو!
حقيقت ۾، ڪوڊ سان گڏ سڀئي نوڪريون ۽ ڪم تقريبا هڪجهڙائي واري ماحول ۾ هجڻ گهرجي (اسان جسماني هارڊويئر بابت نه ڳالهائي رهيا آهيون). انهي سان گڏ، ڪنهن به ترقياتي ملازم کي ڪوڊ کي ترتيب ڏيڻ جي قابل هوندو جيڪڏهن ضروري هجي ته پيداوار لاء، ۽ نه ڪجهه خاص طور تي تربيت يافته ڊپارٽمينٽ ڊپارٽمينٽ، جيڪو صرف خاص طاقت جي مهرباني، ايپليڪيشن کي پيداوار ۾ آڻي سگهي ٿو.
ڊڪر پڻ اسان جي مدد ڪري ٿو. جيڪڏهن سڀني پوئين پوائنٽن کي مشاهدو ڪيو وڃي، ڊڪر استعمال ڪندي ماحول کي ترتيب ڏيڻ جي عمل کي ٻنهي پيداوار تي ۽ مقامي مشين تي هڪ يا ٻه حڪم داخل ڪرڻ لاء آڻيندو.
11. لاگ
اسان فائلن ۽ ڊيٽابيس ۾ لاگ لکندا آهيون! اسان لاگن مان فائلون ۽ ڊيٽابيس کي صاف نه ڪندا آهيون. اچو ته صرف 9000 پيٽا بائيٽس سان هارڊ ڊرائيو خريد ڪريون ۽ اهو ٺيڪ آهي.
سڀني لاگن کي واقعن جو سلسلو سمجھڻ گھرجي. اپليڪيشن پاڻ کي پروسيسنگ لاگز ۾ شامل نه ٿيڻ گهرجي. لاگز کي ٻاھر نڪرڻ گھرجي يا ته stdout ڏانھن يا پروٽوڪول ذريعي موڪليو وڃي جيئن udp، ته جيئن لاگز سان ڪم ڪرڻ سان ايپليڪيشن لاءِ ڪو مسئلو پيدا نه ٿئي. graylog هن لاء سٺو آهي. گريلاگ udp ذريعي سڀ لاگ وصول ڪري رهيو آهي (هن پروٽوڪول کي پيڪيٽ جي ڪامياب استقبال بابت جواب جو انتظار ڪرڻ جي ضرورت ناهي) ڪنهن به طريقي سان ايپليڪيشن ۾ مداخلت نه ڪندو آهي ۽ صرف لاگ ان جي جوڙجڪ ۽ پروسيسنگ سان معاملو ڪندو آهي. ايپليڪيشن جي منطق اهڙي طريقن سان ڪم ڪرڻ لاء تبديل نٿو ڪري.
12. انتظامي ڪم
ڊيٽا، ڊيٽابيسس، وغيره کي اپڊيٽ ڪرڻ لاءِ، API ۾ الڳ الڳ ٺاهيل پوائنٽ استعمال ڪريو، ان کي 2 ڀيرا لڳاتار عمل ۾ آڻڻ جي نتيجي ۾ سڀڪنھن شيءِ کي نقل ڪيو ويندو. پر توهان بيوقوف نه آهيو، توهان ٻه ڀيرا ڪلڪ نه ڪندا، ۽ اسان کي لڏپلاڻ جي ضرورت ناهي.
سڀني انتظامي ڪمن کي ساڳيو ماحول ۾ ڪيو وڃي جيئن سڀني ڪوڊ، ڇڏڻ جي سطح تي. اهو آهي، جيڪڏهن اسان کي ڊيٽابيس جي جوڙجڪ کي تبديل ڪرڻ جي ضرورت آهي، ته پوء اسان اهو دستي طور تي نه ڪنداسين ڪالمن جا نالا تبديل ڪندي ۽ ڪجهه بصري ڊيٽابيس مينيجمينٽ ٽولز ذريعي نوان شامل ڪندي. اهڙين شين لاءِ، اسان الڳ الڳ اسڪرپٽ ٺاهيندا آهيون - لڏپلاڻ، جيڪي هر هنڌ ۽ سڀني ماحول ۾ هڪ ئي طرح سان هڪ عام ۽ سمجھڻ واري نتيجي سان هلنديون آهن. ٻين سڀني ڪمن لاءِ، جيئن ڊيٽا سان پروجيڪٽ ڀرڻ، ساڳيا طريقا استعمال ڪيا وڃن.
PHP، Laravel، Laradock، Docker-Compose ۾ مثال لاڳو ڪرڻ
PS سڀ مثال MacOS تي ڪيا ويا. انهن مان گهڻا لينڪس لاءِ به موزون آهن. ونڊوز استعمال ڪندڙ، مون کي معاف ڪجو، پر مون ونڊوز سان گهڻي وقت کان ڪم نه ڪيو آهي.
اچو ته هڪ اهڙي صورتحال جو تصور ڪريون جتي اسان وٽ PHP جو ڪو به نسخو اسان جي PC تي نصب نه آهي ۽ ڪجهه به ناهي.
ڊاڪر ۽ ڊاڪر-ڪپوز جا جديد ورجن انسٽال ڪريو. (اهو انٽرنيٽ تي ڳولهي سگهجي ٿو)
docker -v &&
docker-compose -v
1. اسان لڳايو
git clone https://github.com/Laradock/laradock.git &&
ls
Laradock جي حوالي سان، مان چوندس ته اها هڪ تمام سٺي شيء آهي، جنهن ۾ تمام گهڻو ڪنٽينر ۽ معاون شيون شامل آهن. پر مان Laradock استعمال ڪرڻ جي سفارش نه ڪندس جيئن ته پيداوار ۾ تبديلين جي بغير ان جي بيڪارگي جي ڪري. اهو بهتر آهي ته توهان پنهنجا ڪنٽينر ٺاهي وٺو لاراڊڪ ۾ مثالن جي بنياد تي، اهو تمام گهڻو بهتر ٿيندو، ڇاڪاڻ ته ڪنهن کي به هر شيءِ جي ضرورت ناهي جيڪا هڪ ئي وقت ۾ هجي.
2. اسان جي ايپليڪيشن کي هلائڻ لاء Laradock کي ترتيب ڏيو.
cd laradock &&
cp env-example .env
2.1. ڪجھ ايڊيٽر ۾ habr ڊاريڪٽري (پيرنٽ فولڊر جنھن ۾ لارڊاڪ ڪلون ٿيل آھي) کوليو. (منهنجي PHPStorm صورت ۾)
هن مرحلي تي اسان صرف پروجيڪٽ جو نالو ڏيو.
2.2. ڪم اسپيس تصوير لانچ ڪريو. (توهان جي صورت ۾، تصويرون ٺاهڻ ۾ ڪجهه وقت لڳندا)
Workspace ڊولپر جي طرفان فريم ورڪ سان ڪم ڪرڻ لاء خاص طور تي تيار ڪيل تصوير آهي.
اسان استعمال ڪندي ڪنٽينر اندر وڃو
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 فائل ۾ اسان جي laravel ايپليڪيشن لاء صحيح رستو مقرر ڪريو.
3. Git ۾ سڀ ڪوڊ شامل ڪريو.
هن کي ڪرڻ لاء، اسان Github (يا ڪنهن ٻئي هنڌ) تي هڪ مخزن ٺاهي سگهنداسين. اچو ته ٽرمينل ۾ 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 - ويب سرور کان درخواستون حاصل ڪرڻ لاءِ php
- ڪم اسپيس - ڊولپرز لاءِ php
هن وقت، اسان حاصل ڪيو آهي ته اسان هڪ ايپليڪيشن ٺاهي آهي جيڪا 4 مان 12 پوائنٽن کي پورا ڪري ٿي، يعني:
1. ڪوڊ بيس - سڀ ڪوڊ ھڪڙي مخزن ۾ آھي (ننڍو نوٽ: اھو صحيح ٿي سگھي ٿو ڊڪر کي لاراول پروجيڪٽ جي اندر شامل ڪرڻ، پر اھو ضروري نه آھي).
2. انحصار - اسان جا سڀ انحصار واضح طور تي لکيل آهن application/composer.json ۽ هر ڪنٽينر جي هر Dockerfile ۾.
3. پوئتي خدمتون - هر هڪ خدمتون (php-fom، nignx، workspace) پنهنجي زندگي گذاري ٿي ۽ ٻاهران ڳنڍيل آهي ۽ جڏهن هڪ خدمت سان ڪم ڪندي، ٻي متاثر نه ٿيندي.
4. پروسيس - هر خدمت هڪ عمل آهي. خدمتن مان هر هڪ اندروني حالت برقرار نه رکندو آھي.
5. پورٽ پابند
docker ps
جيئن اسان ڏسي سگهون ٿا، هر خدمت پنهنجي پورٽ تي هلندو آهي ۽ ٻين سڀني خدمتن تائين رسائي آهي.
6. سموري
Docker اسان کي اجازت ڏئي ٿو ته انهن جي وچ ۾ خودڪار لوڊ بيلنس سان ساڳئي خدمتن جي ڪيترن ئي عملن کي.
اچو ته ڪنٽينرز کي روڪيو ۽ انهن کي پرچم ذريعي هلون --پيماني تي
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
جيئن اسان ڏسي سگهون ٿا، ڪاپيون ٺاهيا ويا آهن php-fpm ڪنٽينر مان. اسان کي هن ڪنٽينر سان ڪم ڪرڻ ۾ ڪجهه به تبديل ڪرڻ جي ضرورت ناهي. اسان ان کي بندرگاهن 9000 تي پڻ رسائي جاري رکون ٿا، ۽ ڊاکر اسان لاءِ ڪنٽينرز جي وچ ۾ لوڊ کي منظم ڪري ٿو.
7. نيڪال ڪرڻ - هر ڪنٽينر ٻئي کي نقصان پهچائڻ کان سواء قتل ڪري سگهجي ٿو. ڪنٽينر کي روڪڻ يا ٻيهر شروع ڪرڻ بعد ۾ ٿيندڙ لانچن دوران ايپليڪيشن جي آپريشن کي متاثر نه ڪندو. هر ڪنٽينر به ڪنهن به وقت کڻي سگهجي ٿو.
8. ايپليڪيشن ڊولپمينٽ / آپريشن برابري - اسان جا سڀئي ماحول ساڳيا آهن. پيداوار ۾ سرور تي سسٽم کي هلائڻ سان، توهان کي توهان جي حڪمن ۾ ڪجهه به تبديل ڪرڻ جي ضرورت نه هوندي. سڀڪنھن شيء کي ساڳيء طرح Docker جي بنياد تي ڪيو ويندو.
9. لاگنگ - انهن ڪنٽينرز ۾ سڀئي لاگ اسٽريم ڏانهن ويندا آهن ۽ ڊاکر ڪنسول ۾ نظر اچن ٿا. (هن صورت ۾، حقيقت ۾، ٻين گهر جي ڪنٽينرز سان، اهو ٿي سگهي ٿو اهو معاملو نه هجي جيڪڏهن توهان ان جو خيال نه رکو)
docker-compose logs -f
پر اتي هڪ پڪ آهي ته PHP ۽ Nginx ۾ Default قدر پڻ هڪ فائل تي لاگ لکندا آهن. 12 عنصرن کي پورا ڪرڻ لاء، ضروري آهي ناڪاري هر ڪنٽينر جي ترتيبن ۾ هڪ فائل ڏانهن لاگ لکڻ الڳ الڳ.
ڊاڪر لاگ موڪلڻ جي صلاحيت پڻ فراهم ڪري ٿو نه صرف اسٽڊ آئوٽ ڏانهن، پر اهڙين شين کي پڻ گريلوگ، جنهن جو مون مٿي ذڪر ڪيو آهي. ۽ گريلاگ جي اندر، اسان لاگز کي هلائي سگھون ٿا جيئن اسان چاهيون ٿا ۽ اسان جي ايپليڪيشن ڪنهن به طريقي سان نوٽيس نه ڪندي.
10. انتظاميه جي انتظاميه - سڀني انتظامي ڪمن کي حل ڪيو ويو آهي laravel جي مهرباني، ڪاريگر ٽول جي مهرباني بلڪل جيئن 12 فيڪٽر ايپليڪيشن جي تخليق ڪندڙ چاهيندا آهن.
مثال طور، مان ڏيکاريندس ته ڪيئن ڪجهه حڪمن تي عمل ڪيو وڃي ٿو.
اسان ڪنٽينر ۾ وڃون ٿا.
docker-compose exec workspace bash
php artisan list
هاڻي اسان ڪنهن به حڪم کي استعمال ڪري سگهون ٿا. (مهرباني ڪري نوٽ ڪريو ته اسان ڊيٽابيس ۽ ڪيش کي ترتيب نه ڏنو آهي، تنهنڪري اڌ حڪمن تي عمل نه ڪيو ويندو، ڇاڪاڻ ته اهي ڪيش ۽ ڊيٽابيس سان ڪم ڪرڻ لاء ٺهيل آهن).
11. ترتيبون ۽ 12. ٺاھڻ ، ڇڏڻ ، ھلائڻ
مون هن حصي کي بليو-گرين ڊيپلائيمينٽ لاءِ وقف ڪرڻ چاهيو، پر اهو نڪتو ته هن مضمون لاءِ تمام گهڻو وسيع آهي. ان بابت هڪ الڳ مضمون لکندس.
مختصر ۾، تصور CI/CD سسٽم تي ٻڌل آهي جهڙوڪ جينکن и Gitlab CI. ٻنهي ۾، توهان هڪ مخصوص ماحول سان لاڳاپيل ماحولياتي متغير مقرر ڪري سگهو ٿا. ان جي مطابق، هن صورتحال ۾، پوائنٽ سي پورو ڪيو ويندو ترتيبون.
۽ نقطي بابت ٺاھڻ ، ڇڏڻ ، ھلائڻ نالي سان ٺهيل فنڪشن ذريعي حل ڪيو ويو آهي پائپ لائن.
پائپ لائن توهان کي ترتيب ڏيڻ واري عمل کي ڪيترن ئي مرحلن ۾ ورهائڻ جي اجازت ڏئي ٿي، اسيمبلي، ڇڏڻ ۽ عمل جي مرحلن کي نمايان ڪندي. پڻ پائپ لائن ۾، توهان ٺاهي سگهو ٿا بيڪ اپ، ۽ حقيقت ۾ ڪجھ به. هي هڪ اوزار آهي لامحدود صلاحيت سان.
اپليڪيشن ڪوڊ تي آهي .
هن مخزن کي ڪلون ڪرڻ دوران ذيلي ماڊل کي شروع ڪرڻ نه وساريو.
پي ايس: اهي سڀئي طريقا استعمال ڪري سگھجن ٿيون ڪنهن ٻئي افاديت ۽ پروگرامنگ ٻولين سان. بنيادي شيء اها آهي ته جوهر مختلف ناهي.
جو ذريعو: www.habr.com