مان توهان کي صلاح ڏيان ٿو ته توهان اليگزينڊر سيگاچوف پاران رپورٽ جو ٽرانسڪرپٽ پڙهو Inventos “Docker + Gitlab CI سان ترقي ۽ جانچ جو عمل”.
اهي جيڪي صرف شروع ڪري رهيا آهن ترقي ۽ جانچ جي عمل کي لاڳو ڪرڻ جي بنياد تي Docker + Gitlab CI اڪثر ڪري بنيادي سوال پڇن ٿا. ڪٿي شروع ڪرڻ لاء؟ ڪيئن منظم ڪرڻ لاء؟ ٽيسٽ ڪيئن ڪجي؟
اها رپورٽ سٺي آهي ڇاڪاڻ ته اها ڊڪر ۽ گٽلاب سي آءِ استعمال ڪندي ترقي ۽ جاچ واري عمل بابت منظم طريقي سان ڳالهائي ٿي. رپورٽ پاڻ 2017 جي آهي. مان سمجهان ٿو ته هن رپورٽ مان توهان بنياديات، طريقو، خيال، ۽ استعمال جو تجربو حاصل ڪري سگهو ٿا.
ڪير پرواهه، مهرباني ڪري ٻلي جي هيٺان.
منهنجو نالو اليگزينڊر سيگاچوف آهي. مان Inventos لاءِ ڪم ڪريان ٿو. مان توهان کي ٻڌايان ٿو منهنجي تجربي بابت ڊڪر استعمال ڪندي ۽ اسان ڪيئن تدريجي طور تي ان کي ڪمپني ۾ منصوبن تي لاڳو ڪري رهيا آهيون.
رپورٽ جو موضوع: ڊڪرر ۽ گٽلاب سي آء استعمال ڪندي ترقي جو عمل.
ڊاڪر بابت هي منهنجي ٻي ڳالهه آهي. پهرين رپورٽ جي وقت تي، اسان ڊولپر صرف ڊولپر مشينن تي ترقي ۾ استعمال ڪيو. ملازمن جو تعداد جيڪو Docker استعمال ڪيو اٽڪل 2-3 ماڻهو هو. آهستي آهستي، تجربو حاصل ڪيو ويو ۽ اسان ٿورو اڳتي وڌو. اسان جي لنڪ .
هن رپورٽ ۾ ڇا هوندو؟ اسان پنهنجو تجربو شيئر ڪنداسين ته اسان ڪهڙن ريڪن کي گڏ ڪيو، اسان ڪهڙا مسئلا حل ڪيا. اهو هر جڳهه خوبصورت نه هو، پر اهو اسان کي اڳتي وڌڻ جي اجازت ڏني.
اسان جو مقصد: هر شي کي ڊڪرائيز ڪريو جنهن تي اسين هٿ کڻون ٿا.
اسان ڪهڙا مسئلا حل ڪري رهيا آهيون؟
جڏهن هڪ ڪمپني وٽ ڪيترائي ٽيمون آهن، پروگرامر هڪ گڏيل وسيلو آهي. اهڙا مرحلا آهن جڏهن هڪ پروگرامر کي هڪ پروجيڪٽ مان ڪڍيو ويندو آهي ۽ ڪجهه وقت لاءِ ٻئي پروجيڪٽ کي ڏنو ويندو آهي.
پروگرامر کي جلدي سمجھڻ لاءِ، هن کي ضرورت آهي ته پروجيڪٽ جو سورس ڪوڊ ڊائون لوڊ ڪري ۽ جلدي ممڪن طور تي هڪ ماحول شروع ڪري، جيڪو هن کي هن منصوبي جي مسئلن کي حل ڪرڻ ۾ اڳتي وڌڻ جي اجازت ڏيندو.
عام طور تي، جيڪڏهن توهان شروع کان شروع ڪيو، اتي پروجيڪٽ ۾ ٿورو دستاويز آهي. صرف پراڻن ٽائمرز کي معلومات آهي ته ان کي ڪيئن سيٽ ڪيو وڃي. ملازم هڪ يا ٻن ڏينهن ۾ پنهنجي ڪم جي جاءِ پاڻ تي قائم ڪندا آهن. ھن کي تيز ڪرڻ لاءِ، اسان استعمال ڪيو ڊاڪر.
ايندڙ سبب ڊولپمينٽ ۾ سيٽنگن جو معيار آهي. منهنجي تجربي ۾، ڊولپرز هميشه شروعات ڪن ٿا. هر پنجين صورت ۾، هڪ ڪسٽم ڊومين داخل ڪيو ويو آهي، مثال طور vasya.dev. منهنجي ڀرسان ويٺو آهي منهنجو پاڙيسري Petya، جنهن جو ڊومين petya.dev آهي. اهي هن ڊومين جو نالو استعمال ڪندي ويب سائيٽ يا ڪجهه سسٽم جو حصو ٺاهيندا آهن.
جڏهن سسٽم وڌندو آهي ۽ اهي ڊومين جا نالا ترتيب ۾ شامل ٿيڻ شروع ڪندا آهن، ترقي جي ماحول ۾ هڪ تڪرار پيدا ٿئي ٿو ۽ سائيٽ جو رستو ٻيهر لکيو ويو آهي.
ساڳي شيء ڊيٽابيس سيٽنگن سان ٿئي ٿي. ڪجهه ماڻهو سيڪيورٽي سان پريشان نه ڪندا آهن ۽ خالي روٽ پاسورڊ سان ڪم ڪندا آهن. انسٽاليشن اسٽيج تي، MySQL ڪنهن کان پاس ورڊ پڇيو ۽ پاسورڊ 123 ٿي ويو. اڪثر ائين ٿيندو آهي ته ڊيٽابيس جي جوڙجڪ ڊولپر جي ڪمٽمينٽ جي بنياد تي مسلسل تبديل ٿيندي رهي ٿي. ڪنهن درست ڪيو، ڪنهن ترتيب درست نه ڪيو. اتي چالون هيون جڏهن اسان ڪجهه ٽيسٽ ترتيب ۾ وجهي ڇڏيو .gitignore ۽ هر ڊولپر کي ڊيٽابيس کي انسٽال ڪرڻو هو. هن شروعاتي عمل کي وڌيڪ ڏکيو بڻائي ڇڏيو. ٻين شين مان، توهان کي ڊيٽابيس جي باري ۾ ياد رکڻ جي ضرورت آهي. ڊيٽابيس کي لازمي طور تي شروع ڪيو وڃي، هڪ پاسورڊ رجسٽر ٿيڻ گهرجي، هڪ صارف رجسٽر ٿيڻ لازمي آهي، هڪ نشاني پيدا ٿيڻ گهرجي، وغيره.
ٻيو مسئلو لائبريرين جي مختلف نسخن جو آهي. اهو اڪثر ٿئي ٿو ته هڪ ڊولپر مختلف منصوبن تي ڪم ڪري ٿو. اتي ھڪڙو پراجيڪٽ آھي، جيڪو پنج سال اڳ شروع ٿيو (2017 کان - ايڊيٽر جو نوٽ). شروعات ۾ اسان MySQL 5.5 سان شروع ڪيو. اتي پڻ جديد منصوبا آھن جتي اسان MySQL جا وڌيڪ جديد ورجن لاڳو ڪرڻ جي ڪوشش ڪري رھيا آھيون، مثال طور 5.7 يا پراڻا (2017 ۾ - ايڊيٽر جو نوٽ)
ڪو به ماڻهو جيڪو MySQL سان ڪم ڪري ٿو اهو ڄاڻي ٿو ته اهي لائبريريون انحصار رکن ٿيون. اهو 2 ڊيٽابيس کي گڏ ڪرڻ لاء ڪافي مشڪل آهي. گهٽ ۾ گهٽ، اهو مسئلو آهي ته پراڻي ڪلائنٽ کي نئين ڊيٽابيس سان ڳنڍڻ لاء. ان جي نتيجي ۾ ڪيترن ئي مسئلن کي جنم ڏئي ٿو.
ايندڙ مسئلو اهو آهي جڏهن هڪ ڊولپر مقامي مشين تي ڪم ڪري ٿو، هو مقامي وسيلن، مقامي فائلون، مقامي رام استعمال ڪري ٿو. مسئلن جي حل کي ترقي ڪرڻ وقت سڀني ڳالهين کي حقيقت جي فريم ورڪ ۾ ڪيو ويندو آهي ته اهو هڪ مشين تي ڪم ڪري ٿو. ھڪڙو مثال اھو ٿيندو جڏھن اسان وٽ پيداوار 3 ۾ پس منظر سرور آھي، ۽ ڊولپر فائلن کي روٽ ڊاريڪٽري ۾ محفوظ ڪري ٿو ۽ اتان کان nginx فائلون وٺي ٿو درخواست جو جواب ڏيڻ لاء. جڏهن اهڙو ڪوڊ پيداوار ۾ اچي ٿو، اهو ظاهر ٿئي ٿو ته فائل 3 سرورز مان هڪ تي موجود آهي.
مائڪرو سروسز جي هدايت هن وقت ترقي ڪري رهي آهي. جڏهن اسان پنهنجن وڏن ايپليڪيشنن کي ڪجهه ننڍن حصن ۾ ورهائيندا آهيون جيڪي هڪ ٻئي سان رابطو ڪن ٿا. هي توهان کي اجازت ڏئي ٿو ته هڪ مخصوص ٽاسڪ اسٽيڪ لاءِ ٽيڪنالاجيون چونڊيو. اهو پڻ توهان کي ڊولپرز جي وچ ۾ ڪم ۽ ذميواري جي علائقي کي ورهائڻ جي اجازت ڏئي ٿو.
هڪ فرنٽ اينڊ ڊولپر، JS ۾ ترقي ڪري رهيو آهي، حقيقت ۾ پس منظر تي ڪو به اثر نه آهي. پس منظر ڊولپر، موڙ ۾، ترقي ڪري ٿو، اسان جي صورت ۾، ريل تي روبي ۽ فرينڊنڊ سان مداخلت نٿو ڪري. تعامل API استعمال ڪندي ڪيو ويندو آهي.
بونس جي طور تي، ڊاڪر استعمال ڪندي اسان اسٽيجنگ تي وسيلن کي ٻيهر استعمال ڪرڻ جي قابل هئاسين. هر پروجيڪٽ، ان جي خاصيتن جي ڪري، ڪجهه سيٽنگون گهربل آهن. جسماني طور تي، اهو ضروري هو ته يا ته هڪ ورچوئل سرور کي مختص ڪرڻ ۽ انهن کي الڳ الڳ ترتيب ڏيڻ، يا ڪنهن قسم جي متغير ماحول کي ورهائڻ ۽ پروجيڪٽ هڪ ٻئي تي اثر انداز ڪري سگهن ٿا، لائبريرين جي ورزن تي منحصر ڪري ٿو.
اوزار. اسان ڇا استعمال ڪريون؟
- Docker پاڻ. A Dockerfile هڪ واحد ايپليڪيشن جي انحصار کي بيان ڪري ٿو.
- Docker-compose هڪ بنڊل آهي جيڪو اسان جي ڪيترن ئي ڊڪر ايپليڪيشنن کي گڏ ڪري ٿو.
- اسان استعمال ڪريون ٿا GitLab ذريعو ڪوڊ اسٽور ڪرڻ لاءِ.
- اسان سسٽم جي انضمام لاءِ GitLab-CI استعمال ڪندا آهيون.
رپورٽ ٻن حصن تي مشتمل آهي.
پهريون حصو توهان کي ٻڌائيندو ته ڊولپرز جي مشينن تي ڊڪر کي ڪيئن هلائڻ.
ٻيو حصو ڳالهائيندو GitLab سان ڪيئن لهه وچڙ ۾، اسان ٽيسٽ ڪيئن هلون ٿا ۽ اسٽيجنگ ڏانهن ڪيئن وڃون ٿا.
Docker هڪ ٽيڪنالاجي آهي جيڪا اجازت ڏئي ٿي (اعلان واري طريقي سان استعمال ڪندي) ضروري اجزاء کي بيان ڪرڻ لاءِ. اهو هڪ مثال آهي Dockerfile. هتي اسان اعلان ڪريون ٿا ته اسان وراثت ۾ آهيون روبي جي سرڪاري ڊاکر تصوير: 2.3.0. ان ۾ روبي ورجن 2.3 انسٽال ٿيل آهي. اسان ضروري اسيمبلي لائبريريون ۽ NodeJS انسٽال ڪريو. اسان بيان ڪريون ٿا ته اسان ڊاريڪٽري ٺاهي رهيا آهيون /app. اسان ايپ ڊاريڪٽري کي ڪم ڪندڙ ڊاريڪٽري طور تفويض ڪريون ٿا. ھن ڊاريڪٽري ۾ اسين گھربل گھٽ ۾ گھٽ Gemfile ۽ Gemfile.lock رکون ٿا. پوء اسان پروجيڪٽ ٺاهيندا آهيون جيڪي هن انحصار واري تصوير کي نصب ڪن ٿا. اسان اشارو ڪريون ٿا ته ڪنٽينر خارجي بندرگاهه 3000 تي ٻڌڻ لاءِ تيار هوندو. آخري حڪم اهو حڪم آهي جيڪو سڌو سنئون اسان جي ايپليڪيشن کي لانچ ڪري ٿو. جيڪڏهن اسان پروجيڪٽ رن ڪمانڊ تي عمل ڪريون ٿا، ايپليڪيشن کي هلائڻ جي ڪوشش ڪندو ۽ مخصوص ڪمانڊ کي هلائڻ.
ھي ھڪڙو گھٽ ۾ گھٽ مثال آھي ڊاڪر-compose فائل جو. انهي حالت ۾، اسان ڏيکاريون ٿا ته اتي ٻن ڪنٽينرز جي وچ ۾ ڪنيڪشن آهي. اهو سڌو سنئون ڊيٽابيس سروس ۽ ويب سروس ۾ آهي. اسان جي ويب ايپليڪيشنن کي اڪثر ڪيسن ۾ ڊيٽا کي محفوظ ڪرڻ لاءِ بيڪ اينڊ جي طور تي ڪنهن قسم جي ڊيٽابيس جي ضرورت هوندي آهي. جيئن ته اسان MySQL استعمال ڪندا آهيون، مثال MySQL سان آهي - پر ڪجھ به اسان کي ڪجهه ٻيو ڊيٽابيس (PostgreSQL، Redis) استعمال ڪرڻ کان روڪي ٿو.
اسان وٺون ٿا MySQL 5.7.14 تصوير بغير تبديلين جي سرڪاري ماخذ کان ڊڪر حب کان. اسان تصوير گڏ ڪريون ٿا جيڪو اسان جي ويب ايپليڪيشن لاءِ ذميوار آهي موجوده ڊاريڪٽري مان. پهرين لانچ دوران، هو اسان لاء هڪ تصوير گڏ ڪري ٿو. پوء اهو حڪم هلندو آهي ته اسان هتي عمل ڪري رهيا آهيون. جيڪڏهن اسان واپس وڃون ٿا، اسان ڏسنداسين ته لانچ ڪمانڊ پوما ذريعي وضاحت ڪئي وئي هئي. پوما روبي ۾ لکيل هڪ خدمت آهي. ٻئين صورت ۾ اسان کي ختم ڪريون ٿا. هي حڪم اسان جي ضرورتن يا ڪمن جي لحاظ کان پاڻمرادو ٿي سگهي ٿو.
اسان اهو پڻ بيان ڪريون ٿا ته اسان کي اسان جي ڊولپر ميزبان مشين تي بندرگاهن کي 3000 کان 3000 ڪنٽينر بندرگاهن ڏانهن اڳتي وڌڻ جي ضرورت آهي. اهو خودڪار طريقي سان ڪيو ويندو آهي iptables ۽ ان جي پنهنجي ميڪانيزم کي استعمال ڪندي، جيڪو سڌو سنئون ڊاکر ۾ شامل آهي.
ڊولپر، اڳي وانگر، ڪنهن به دستياب IP پتي تائين رسائي ڪري سگھي ٿو، مثال طور، مشين جي 127.0.0.1 مقامي يا ٻاهرين IP پتي.
آخري لائن چوي ٿو ته ويب ڪنٽينر ڊي بي ڪنٽينر تي منحصر آهي. جڏهن اسان ويب ڪنٽينر کي لانچ ڪرڻ لاءِ سڏين ٿا، ڊاڪر-ڪمپوز پهريون ڀيرو اسان لاءِ ڊيٽابيس لانچ ڪندو. اڳ ۾ ئي ڊيٽابيس جي شروعات تي (حقيقت ۾، ڪنٽينر جي لانچ کان پوء! اهو ڊيٽابيس جي تيارگي جي ضمانت نٿو ڏئي) اهو اسان جي ايپليڪيشن، اسان جي پس منظر کي شروع ڪندو.
هي اسان کي غلطين کان بچڻ جي اجازت ڏئي ٿو جڏهن ڊيٽابيس مٿي نه آهي ۽ اسان کي وسيلن کي بچائڻ جي اجازت ڏئي ٿي جڏهن اسان ڊيٽابيس ڪنٽينر کي روڪيو، اهڙي طرح ٻين منصوبن لاء وسيلن کي آزاد ڪري.
هڪ منصوبي تي ڊيٽابيس ڊڪرائيزيشن استعمال ڪندي اسان کي ڇا ڏئي ٿو؟ اسان سڀني ڊولپرز لاءِ MySQL ورجن رڪارڊ ڪريون ٿا. اهو توهان کي ڪجهه غلطين کان بچڻ جي اجازت ڏئي ٿو جيڪا ٿي سگهي ٿي جڏهن نسخن ۾ ڦيرڦار، جڏهن نحو، ترتيب، ۽ ڊفالٽ سيٽنگون تبديل ٿي وڃن. هي توهان کي ڊيٽابيس، لاگ ان، پاسورڊ لاء هڪ عام ميزبان نالو بيان ڪرڻ جي اجازت ڏئي ٿو. اسان نالن جي زو کان پري ٿي رهيا آهيون ۽ config فائلن ۾ تڪرار جيڪي اڳ موجود هئا.
اسان وٽ اهو موقعو آهي ته ڊولپمينٽ ماحول لاءِ وڌيڪ بهتر ترتيب استعمال ڪريو، جيڪو ڊفالٽ کان مختلف هوندو. MySQL ڪمزور مشينن لاءِ ڊفالٽ طور ترتيب ڏنل آھي ۽ ان جي ڪارڪردگي تمام گھٽ آھي.
Docker توهان کي استعمال ڪرڻ جي اجازت ڏئي ٿو Python, Ruby, NodeJS, PHP مترجم مطلوب نسخو. اسان کي ڪنهن قسم جي ورجن مينيجر کي استعمال ڪرڻ جي ضرورت کان نجات حاصل ڪري. اڳي، هڪ rpm پيڪيج روبي لاءِ استعمال ڪيو ويو، جنهن توهان کي منصوبي جي لحاظ کان ورزن کي تبديل ڪرڻ جي اجازت ڏني. Docker ڪنٽينر جي مهرباني، اهو پڻ توهان کي اجازت ڏئي ٿو آساني سان لڏپلاڻ ڪوڊ ۽ ورزن ان سان گڏ انحصار سان. اسان کي مترجم ۽ ڪوڊ ٻنهي جي ورجن کي سمجهڻ ۾ ڪو مسئلو ناهي. ورجن کي اپڊيٽ ڪرڻ لاءِ، توھان کي ضرورت آھي پراڻي ڪنٽينر کي گھٽ ڪرڻ ۽ نئين ڪنٽينر کي وڌائڻو. جيڪڏهن ڪجهه غلط ٿئي ٿو، اسان نئين ڪنٽينر کي هيٺ ڪري سگهون ٿا، پراڻي ڪنٽينر کي بلند ڪري سگهون ٿا.
تصوير ٺاھڻ کان پوءِ، ڊولپمينٽ ۽ پروڊڪشن ۾ ڪنٽينر ساڳيا ھوندا. اهو خاص طور تي وڏي تنصيب لاء صحيح آهي.
Frontend تي اسان JavaScipt ۽ NodeJS استعمال ڪندا آهيون.
هاڻي اسان وٽ ReacJS تي اسان جو آخري منصوبو آهي. ڊولپر ڪنٽينر ۾ سڀڪنھن شيء کي شروع ڪيو ۽ گرم-ري لوڊ استعمال ڪندي ترقي ڪئي.
اڳيون، جاوا اسڪرپٽ گڏ ڪرڻ جو ڪم شروع ڪيو ويو آهي ۽ مستحڪم طور تي گڏ ڪيل ڪوڊ nginx ذريعي موڪليو ويو آهي، وسيلن کي بچايو.
هتي مون اسان جي تازي منصوبي جو هڪ خاڪو مهيا ڪيو آهي.
توهان ڪهڙا مسئلا حل ڪيا؟ اسان کي هڪ سسٽم ٺاهڻ جي ضرورت هئي جنهن سان موبائيل ڊوائيسز وچ ۾. اهي ڊيٽا وصول ڪن ٿا. امڪانن مان هڪ آهي هن ڊوائيس تي پش اطلاع موڪلڻ.
ان لاءِ اسان ڇا ڪيو آهي؟
اسان ايپليڪيشن کي هيٺين حصن ۾ ورهايو: JS ۾ هڪ منتظم حصو، هڪ پس منظر جيڪو ڪم ڪري ٿو REST انٽرفيس ذريعي Ruby on Rails. پس منظر ڊيٽابيس سان رابطو ڪري ٿو. نتيجو جيڪو پيدا ڪيو ويو آهي ڪلائنٽ کي ڏنو ويو آهي. منتظم پينل هڪ REST انٽرفيس ذريعي پس منظر ۽ ڊيٽابيس سان رابطو ڪري ٿو.
اسان کي پش نوٽيفڪيشن موڪلڻ جي به ضرورت هئي. هن کان اڳ، اسان وٽ هڪ منصوبو هو جنهن ۾ هڪ ميکانيزم لاڳو ڪيو ويو جيڪو موبائل پليٽ فارمن تي اطلاعن جي پهچائڻ جو ذميوار هو.
اسان ھيٺ ڏنل اسڪيم ٺاھيو آھي: برائوزر کان آپريٽر ايڊمن پينل سان رابطو ڪري ٿو، ايڊمن پينل پس منظر سان رابطو ڪري ٿو، ڪم آھي پش نوٽيفڪيشن موڪلڻ.
پش نوٽيفڪيشن ٻئي جزو سان لهه وچڙ ۾ آهي جيڪو NodeJS ۾ لاڳو ڪيو ويو آهي.
قطارون ٺهيل آهن ۽ اطلاع موڪليا ويا آهن انهن جي پنهنجي ميڪانيزم جي مطابق.
هتي ٻه ڊيٽابيس ٺاهيا ويا آهن. في الحال، Docker استعمال ڪندي، اسان 2 آزاد ڊيٽابيس استعمال ڪندا آهيون جيڪي ڪنهن به طريقي سان هڪ ٻئي سان ڳنڍيل نه آهن. انهي حقيقت کان علاوه انهن وٽ هڪ عام ورچوئل نيٽورڪ آهي، ۽ جسماني ڊيٽا ڊولپر جي مشين تي مختلف ڊائريڪٽرن ۾ ذخيرو ٿيل آهي.
ساڳي شيء، پر تعداد ۾. ڪوڊ ٻيهر استعمال هتي اهم آهي.
جيڪڏهن اڳ ۾ اسان لائبريرين جي صورت ۾ ڪوڊ ٻيهر استعمال ڪرڻ جي ڳالهه ڪئي هئي، ته هن مثال ۾ اسان جي سروس، جيڪا پش نوٽيفڪيشن جو جواب ڏئي ٿي، مڪمل سرور طور ٻيهر استعمال ڪئي وئي آهي. اهو هڪ API مهيا ڪري ٿو. ۽ اسان جي نئين ترقي ان سان رابطي ۾ اچي ٿي.
ان وقت اسان استعمال ڪري رهيا هئاسين NodeJS جو نسخو 4. هاڻي (2017 ۾ - ايڊيٽر جو نوٽ) اسان جي جديد ترقيات ۾ اسان استعمال ڪندا آهيون نسخو 7 NodeJS جو. لائبريرين جا نوان ورزن شامل ڪرڻ لاءِ نون اجزاء ۾ ڪو مسئلو ناهي.
جيڪڏهن ضروري هجي ته، توهان پش نوٽيفڪيشن سروس جي NodeJS ورزن کي ريفيڪٽر ۽ وڌائي سگهو ٿا.
۽ جيڪڏھن اسان API مطابقت برقرار رکي سگھون ٿا، پوء اھو ممڪن ٿيندو ان کي تبديل ڪرڻ لاء ٻين منصوبن سان جيڪي اڳ ۾ استعمال ڪيا ويا آھن.
ڇا توهان کي Docker شامل ڪرڻ جي ضرورت آهي؟ اسان اسان جي مخزن ۾ هڪ Dockerfile شامل ڪيو، جيڪو ضروري انحصار بيان ڪري ٿو. هن مثال ۾، اجزاء منطقي طور تي ورهايل آهن. هي هڪ پس منظر ڊولپر لاءِ گهٽ ۾ گهٽ کٽ آهي.
جڏهن هڪ نئون منصوبو ٺاهي رهيا آهيون، اسان هڪ Dockerfile ٺاهيندا آهيون ۽ گهربل ماحولياتي نظام کي بيان ڪندا آهيون (Python، Ruby، NodeJS). docker-compose ۾، اهو ضروري انحصار بيان ڪري ٿو - ڊيٽابيس. اسان بيان ڪريون ٿا ته اسان کي اهڙي ۽ اهڙي نسخي جي ڊيٽابيس جي ضرورت آهي، ڊيٽا کي اتي ۽ اتي رکڻ لاء.
اسان جامد مواد جي خدمت ڪرڻ لاء نينڪس سان گڏ هڪ الڳ ٽيون ڪنٽينر استعمال ڪندا آهيون. تصويرون اپ لوڊ ڪرڻ ممڪن آهي. پس منظر انهن کي اڳ ۾ تيار ڪيل حجم ۾ رکي ٿو، جيڪو پڻ نينڪس سان گڏ ڪنٽينر ۾ نصب ٿيل آهي، جيڪو جامد ڊيٽا مهيا ڪري ٿو.
nginx ۽ mysql جي ترتيب کي ذخيرو ڪرڻ لاء، اسان هڪ ڊڪر فولڊر شامل ڪيو جنهن ۾ اسان ضروري ترتيبن کي ذخيرو ڪندا آهيون. جڏهن هڪ ڊولپر پنهنجي مشين تي مخزن جو هڪ گٽ کلون ٺاهيندو آهي، هن وٽ اڳ ۾ ئي مقامي ترقي لاءِ هڪ منصوبو تيار آهي. هتي ڪو به سوال ناهي ته ڪهڙي بندرگاهه يا ڪهڙيون سيٽنگون لاڳو ٿين ٿيون.
اڳيون اسان وٽ ڪيترائي حصا آھن: منتظم، ڄاڻ-API، پش نوٽيفڪيشن.
اهو سڀ ڪجهه شروع ڪرڻ لاءِ، اسان هڪ ٻيو مخزن ٺاهيو جنهن کي سڏيو ويندو آهي dockerized-app. اسان في الحال هر جزو لاءِ ڪيترائي ذخيرا استعمال ڪريون ٿا. اهي صرف منطقي طور تي مختلف آهن - GitLab ۾ اهو هڪ فولڊر وانگر ڏسڻ ۾ اچي ٿو، پر ڊولپر جي مشين تي اهو هڪ خاص منصوبي لاء فولڊر وانگر نظر اچي ٿو. ھڪڙي سطح ھيٺ ڏنل اجزاء آھن جيڪي گڏ ڪيا ويندا.
هي هڪ مثال آهي مواد جو ڊڪرائزڊ ايپ. اسان هتي هڪ ڊڪر ڊاريڪٽري پڻ رکون ٿا، جنهن ۾ اسان سڀني حصن جي رابطي لاء گهربل ترتيبن کي ڀريندا آهيون. هتي هڪ README.md آهي جيڪو مختصر طور تي بيان ڪري ٿو ته منصوبي کي ڪيئن شروع ڪجي.
هتي اسان ٻه ڊاکر-ڪپوز فائلون لاڳو ڪيون آهن. اهو ڪيو ويو آهي مرحلن ۾ لانچ ڪرڻ جي قابل ٿيڻ لاء. جڏهن هڪ ڊولپر ڪرنل سان ڪم ڪري ٿو، هن کي پش نوٽيفڪيشن جي ضرورت ناهي، هو صرف ڊاکر-ڪپوز فائل لانچ ڪري ٿو ۽، مطابق، وسيلن کي محفوظ ڪيو ويو آهي.
جيڪڏهن پش نوٽيفڪيشن سان انضمام جي ضرورت آهي، ته پوءِ docker-compose.yaml ۽ docker-compose-push.yaml شروع ڪيا ويا آهن.
جيئن ته docker-compose.yaml ۽ docker-compose-push.yaml فولڊر ۾ آهن، هڪ واحد ورچوئل نيٽ ورڪ خودڪار طريقي سان ٺهيل آهي.
اجزاء جي وضاحت. هي هڪ وڌيڪ ترقي يافته فائل آهي جيڪو اجزاء گڏ ڪرڻ جو ذميوار آهي. هتي ڇا قابل ذڪر آهي؟ هتي اسان بيلنسر جزو متعارف ڪرايو.
هي هڪ تيار ٿيل ڊاڪر تصوير آهي جيڪا هلندي آهي نينڪس ۽ هڪ ايپليڪيشن جيڪا ڊڪر ساکٽ کي ٻڌي ٿي. متحرڪ، جيئن ڪنٽينرز کي بند ۽ بند ڪيو ويو آهي، نينڪس ترتيب ٻيهر ٺاهي وئي آهي. اسان ٽئين سطح جي ڊومين جا نالا استعمال ڪندي اجزاء جي سنڀال کي ورهايو ٿا.
ڊولپمينٽ ماحول لاءِ اسان استعمال ڪريون ٿا .dev ڊومين - api.informer.dev. .dev ڊومين سان گڏ ايپليڪيشنون ڊولپر جي مقامي مشين تي موجود آهن.
ان کان پوء ترتيبون هر منصوبي ڏانهن منتقل ڪيا ويا آهن ۽ سڀئي منصوبا هڪ ئي وقت ۾ گڏ ڪيا ويا آهن.
جيڪڏهن اسان ان کي گرافڪ طور تي ظاهر ڪريون ٿا، اهو ظاهر ٿئي ٿو ته ڪلائنٽ اسان جو برائوزر يا ڪنهن قسم جو اوزار آهي جنهن سان اسان بيلنسر کي درخواستون ڪندا آهيون.
بيلنس اهو طئي ڪري ٿو ته ڊومين جي نالي جي بنياد تي ڪهڙي ڪنٽينر تائين رسائي جي ضرورت آهي.
اهو ٿي سگهي ٿو nginx، جيڪو JS مهيا ڪري ٿو منتظم پينل کي. اهو nginx طرفان ڪري سگهجي ٿو، جيڪو API مهيا ڪري ٿو، يا جامد فائلون، جيڪي تصويرون لوڊ ڪرڻ جي صورت ۾ نينگڪس پاران مهيا ڪيل آهن.
ڊراگرام ڏيکاري ٿو ته ڪنٽينرز هڪ مجازي نيٽ ورڪ سان ڳنڍيل آهن ۽ هڪ پراکسي جي پويان لڪيل آهن.
ڊولپر جي مشين تي، توهان IP کي ڄاڻڻ واري ڪنٽينر تائين رسائي ڪري سگهو ٿا، پر اصول ۾ اسين هن کي استعمال نٿا ڪريون. عملي طور تي سڌي رابطي جي ڪا ضرورت ناهي.
منهنجي ايپليڪيشن کي ڊڪرائيز ڪرڻ لاءِ مون کي ڪهڙو مثال ڏسڻ گهرجي؟ منهنجي خيال ۾، هڪ سٺو مثال آهي سرڪاري ڊاکر تصوير MySQL لاءِ.
اهو ڪافي پيچيده آهي. اتي ڪيترائي نسخا آهن. پر ان جي ڪارڪردگي توهان کي ڪيترن ئي ضرورتن کي پورو ڪرڻ جي اجازت ڏئي ٿي جيڪا اڳتي وڌڻ جي عمل ۾ پيدا ٿي سگهي ٿي. جيڪڏهن توهان وقت وٺو ۽ سمجھو ته اهو سڀ ڪيئن لهي ٿو، ته پوءِ مان سمجهان ٿو ته توهان کي ان تي عمل ڪرڻ ۾ ڪا به پريشاني نه ٿيندي.
Hub.docker.com عام طور تي github.com جي لنڪ تي مشتمل آهي، جتي خام ڊيٽا سڌو سنئون مهيا ڪئي وئي آهي جتان توهان پنهنجي تصوير ٺاهي سگهو ٿا.
وڌيڪ هن مخزن ۾ هڪ اسڪرپٽ docker-endpoint.sh آهي، جيڪو شروعاتي شروعاتي ۽ ايپليڪيشن لانچ جي وڌيڪ پروسيسنگ لاء ذميوار آهي.
انهي مثال ۾ پڻ ماحول جي متغير استعمال ڪندي ترتيب ڏيڻ جو امڪان آهي. ماحول جي متغير جي وضاحت ڪندي جڏهن هڪ واحد ڪنٽينر کي هلائڻ يا ڊڪر-ڪمپوز ذريعي، اسان اهو چئي سگهون ٿا ته اسان کي MySQL تي روٽ لاءِ ڊڪر لاءِ خالي پاسورڊ سيٽ ڪرڻ جي ضرورت آهي يا جيڪو اسان چاهيون ٿا.
ھڪڙو اختيار آھي ھڪڙو بي ترتيب پاسورڊ ٺاھيو. اسان چئون ٿا ته اسان کي صارف جي ضرورت آهي، اسان کي صارف لاء پاسورڊ قائم ڪرڻ جي ضرورت آهي، ۽ اسان کي ڊيٽابيس ٺاهڻ جي ضرورت آهي.
اسان جي منصوبن ۾، اسان Dockerfile کي ٿورڙي متحد ڪيو آهي، جيڪو شروعاتي لاء ذميوار آهي. اتي اسان ان کي اسان جي ضرورتن مطابق ترتيب ڏنو ته صرف صارف جي حقن کي وڌائڻ لاءِ جيڪي ايپليڪيشن استعمال ڪن ٿا. اهو ممڪن آهي ته مستقبل ۾ ايپليڪيشن ڪنسول مان هڪ ڊيٽابيس ٺاهي. روبي ايپليڪيشنون ڊيٽابيس ٺاهڻ، تبديل ڪرڻ، ۽ حذف ڪرڻ لاء حڪم آهن.
اهو هڪ مثال آهي ته MySQL جو هڪ مخصوص نسخو github.com تي ڪهڙو نظر اچي ٿو. توھان کوليو Dockerfile ۽ ڏسو ته انسٽاليشن ڪيئن ٿيندي آھي اتي.
docker-endpoint.sh اسڪرپٽ داخلا پوائنٽ لاء ذميوار آهي. شروعاتي شروعات دوران، ڪجھ تياري جي عملن جي ضرورت پوندي آھي ۽ اھي سڀ عمل شروعاتي رسم الخط ۾ شامل آھن.
اچو ته ٻئي حصي ڏانهن وڃو.
اسان کي تبديل ڪيو gitlab کي ذخيرو ڪرڻ لاء ذريعو ڪوڊ. هي هڪ انتهائي طاقتور نظام آهي جنهن ۾ هڪ بصري انٽرفيس آهي.
Gitlab اجزاء مان هڪ Gitlab CI آهي. اهو توهان کي حڪمن جو هڪ سلسلو بيان ڪرڻ جي اجازت ڏئي ٿو جيڪو بعد ۾ استعمال ڪيو ويندو ڪوڊ پهچائڻ واري نظام کي منظم ڪرڻ يا هلائڻ لاءِ خودڪار ٽيسٽ.
Gitlab CI 2 تي رپورٽ - روبي روس ڪلب جي رپورٽ ڪافي تفصيلي آهي ۽ ٿي سگهي ٿي توهان جي دلچسپيءَ جو.
ھاڻي اسان ڏسنداسين ته ڇا Gitlab CI کي چالو ڪرڻ جي ضرورت آھي. Gitlab CI شروع ڪرڻ لاء، اسان کي صرف .gitlab-ci.yml فائل کي منصوبي جي روٽ ۾ رکڻو پوندو.
هتي اسان بيان ڪريون ٿا ته اسان رياستن جو هڪ سلسلو انجام ڏيڻ چاهيون ٿا جهڙوڪ ٽيسٽ، تعیناتي.
اسان اسڪرپٽ تي عمل ڪريون ٿا جيڪي سڌي طرح اسان جي ايپليڪيشن جي ڊاڪر-ڪپوز تعمير کي سڏين ٿا. اهو صرف پس منظر جو هڪ مثال آهي.
اڳتي هلي اسان چئون ٿا ته ڊيٽابيس کي تبديل ڪرڻ ۽ ٽيسٽ هلائڻ لاءِ لڏپلاڻ ڪرڻ ضروري آهي.
جيڪڏهن اسڪرپٽ صحيح طريقي سان جاري ڪيا ويا آهن ۽ هڪ غلطي ڪوڊ واپس نه ٿا ڪن، پوء سسٽم کي ترتيب ڏيڻ جي ٻئي مرحلي ڏانهن اڳتي وڌندو آهي.
ڊيپلائيشن اسٽيج في الحال اسٽيجنگ لاء لاڳو ڪيو ويو آهي. اسان منظم نه ڪيو ڪو-ڊائون ٽائم ريسٽارٽ.
اسان زبردستي سڀني ڪنٽينرز کي وجھون ٿا، ۽ پوء اسان سڀني ڪنٽينرز کي ٻيهر اٿاريو، ٽيسٽ دوران پهرين اسٽيج تي گڏ ڪيو ويو.
اچو ته ڊيٽابيس لڏپلاڻ کي هلائيون جيڪي ڊولپرز طرفان لکيل هئا موجوده متغير ماحول لاءِ.
هتي هڪ نوٽ آهي ته اهو صرف ماسٽر برانچ تي لاڳو ٿيڻ گهرجي.
ٻين شاخن کي تبديل ڪرڻ وقت ڪم نٿو ڪري.
اهو ممڪن آهي ته شاخن سان گڏ rollouts کي منظم ڪرڻ.
ھن کي وڌيڪ منظم ڪرڻ لاءِ، اسان کي انسٽال ڪرڻو پوندو Gitlab Runner.
هي افاديت گولانگ ۾ لکيل آهي. اهو هڪ واحد فائل آهي جيئن گولانگ دنيا ۾ عام آهي، جنهن کي ڪنهن به انحصار جي ضرورت ناهي.
شروعات ۾ اسان رجسٽر ڪريون ٿا Gitlab Runner.
اسان کي Gitlab ويب انٽرفيس ۾ ڪيڏي ملي ٿي.
ان کان پوء اسان ڪمانڊ لائن تي شروعاتي ڪمانڊ کي سڏيندا آهيون.
ڊائلاگ موڊ ۾ Gitlab رنر کي ترتيب ڏيڻ (شيل، ڊڪر، ورچوئل بڪس، ايس ايس ايڇ)
Gitlab Runner تي ڪوڊ .gitlab-ci.yml سيٽنگ جي بنياد تي هر ڪم تي عمل ڪندو.
اهو ڪيئن ڏسڻ ۾ اچي ٿو Gitlab ۾ ويب انٽرفيس ۾. GItlab CI کي ڳنڍڻ کان پوء، اسان وٽ هڪ پرچم آهي جيڪو ڏيکاري ٿو ته تعمير ڪهڙي حالت ۾ آهي.
اسان ڏسون ٿا ته 4 منٽ اڳ هڪ واعدو ڪيو ويو هو جنهن سڀني ٽيسٽ پاس ڪيو ۽ ڪنهن به پريشاني جو سبب نه بڻيو.
اسان وڌيڪ تفصيل سان تعميرات کي ڏسي سگهون ٿا. هتي اسان ڏسون ٿا ته ٻه رياستون گذري ويون آهن. اسٽيجنگ تي جانچ جي حالت ۽ تعیناتي جي حالت.
جيڪڏهن اسان هڪ مخصوص تعمير تي ڪلڪ ڪندا آهيون، اتي حڪمن جو ڪنسول آئوٽ هوندو جيڪو عمل ۾ شروع ڪيو ويو .gitlab-ci.yml مطابق.
هي اهو آهي جيڪو اسان جي پيداوار جي ڪهاڻي وانگر ڏسڻ ۾ اچي ٿو. اسان ڏسون ٿا ته ڪامياب ڪوششون ڪيون ويون آهن. جڏهن ٽيسٽ پيش ڪيا ويا آهن، اهي ايندڙ قدم ڏانهن نه ويندا آهن ۽ اسٽيجنگ ڪوڊ اپڊيٽ نه ڪيو ويو آهي.
جڏهن اسان ڊاکر تي عمل ڪيو ته اسان اسٽيجنگ ۾ ڪهڙا مسئلا حل ڪيا؟ اسان جو سسٽم حصن تي مشتمل آهي ۽ اسان کي صرف ڪجهه حصن کي ٻيهر شروع ڪرڻ جي ضرورت آهي جيڪي مخزن ۾ اپڊيٽ ڪيا ويا هئا، ۽ نه سڄي سسٽم کي.
هن کي ڪرڻ لاء، اسان کي هر شيء کي الڳ فولڊر ۾ الڳ ڪرڻو پوندو.
اسان جي ائين ڪرڻ کان پوء، اسان کي حقيقت سان مسئلو هو ته Docker-compose هر فولڊر لاء پنهنجي نيٽ ورڪ جي جاء ٺاهي ٿو ۽ ان جي پاڙيسري جي اجزاء کي نه ڏسي.
چوڌاري حاصل ڪرڻ لاء، اسان ڊاکر ۾ دستي طور تي نيٽورڪ ٺاهيو. Docker-compose ۾ اهو لکيل هو ته توهان کي هن پروجيڪٽ لاءِ اهڙو نيٽ ورڪ استعمال ڪرڻ گهرجي.
اهڙيء طرح، هر جزو جيڪو هن ميش سان شروع ٿئي ٿو سسٽم جي ٻين حصن ۾ اجزاء ڏسي ٿو.
ايندڙ مسئلو ڪيترن ئي منصوبن جي وچ ۾ اسٽيجنگ کي ورهائڻ آهي.
جيئن ته اهو سڀ ڪجهه خوبصورت ڏسڻ لاء ۽ پيداوار جي ممڪن حد تائين ويجهو آهي، اهو سٺو آهي ته پورٽ 80 يا 443 استعمال ڪريو، جيڪو WEB ۾ هر جڳهه استعمال ڪيو ويندو آهي.
اسان اهو ڪيئن حل ڪيو؟ اسان سڀني وڏن منصوبن لاءِ ھڪڙو گٽلاب رنر مقرر ڪيو.
Gitlab توهان کي اجازت ڏئي ٿو ته ڪيترن ئي ورهايل Gitlab رنرز کي لانچ ڪرڻ، جيڪي صرف هڪ هڪ ڪري سڀني ڪمن کي هڪ افراتفري ترتيب ۾ وٺي ويندا ۽ انهن کي هلائيندا.
گھر جي مسئلن کان بچڻ لاء، اسان اسان جي منصوبن جي گروپ کي ھڪڙي گٽليب رنر تائين محدود ڪيو، جيڪو اسان جي حجمن کي بغير مسئلن جي نقل ڪري ٿو.
اسان nginx-proxy کي الڳ لانچ اسڪرپٽ ۾ منتقل ڪيو ۽ ان ۾ سڀني منصوبن جا گرڊ لکيا.
اسان جي پروجيڪٽ وٽ ھڪڙو گرڊ آھي، ۽ بيلنس ۾ ڪيترائي گرڊ آھن پراجيڪٽ جي نالن جي بنياد تي. اهو ڊومين نالن سان اڳتي وڌائي سگھي ٿو.
اسان جون درخواستون پورٽ 80 تي ڊومين ذريعي اچن ٿيون ۽ ڪنٽينرز جي هڪ گروپ ڏانهن حل ٿيل آهن جيڪي هن ڊومين جي خدمت ڪن ٿا.
ٻيا ڪهڙا مسئلا هئا؟ اھو اھو آھي جيڪو سڀ ڪنٽينرز ڊفالٽ طور روٽ طور ھلندا آھن. هي سسٽم جو روٽ غير برابر روٽ ميزبان آهي.
تنهن هوندي، جيڪڏهن توهان ڪنٽينر ۾ داخل ڪيو، اهو روٽ هوندو ۽ جيڪو فائل اسان هن ڪنٽينر ۾ ٺاهيو اهو روٽ حق حاصل ڪري ٿو.
جيڪڏهن ڪو ڊولپر ڪنٽينر ۾ داخل ٿيو ۽ اتي ڪي ڪمانڊ ڏنا جيڪي فائلون ٺاهي، پوءِ ڪنٽينر ڇڏي، پوءِ هن جي ڪم ڪندڙ ڊاريڪٽري ۾ هن وٽ هڪ فائل آهي جنهن تائين هن کي رسائي ناهي.
اهو ڪيئن حل ٿي سگهي ٿو؟ توھان شامل ڪري سگھوٿا صارف جيڪي ڪنٽينر ۾ ھوندا.
جڏهن اسان صارف کي شامل ڪيو ته ڪهڙا مسئلا پيدا ٿيا؟
جڏهن هڪ صارف ٺاهيو، گروپ جي سڃاڻپ (UID) ۽ صارف جي سڃاڻپ (GID) اڪثر نه ملنديون آهن.
ھن مسئلي کي حل ڪرڻ لاءِ ڪنٽينر ۾ اسان استعمال ڪندا آھيون استعمال ڪندڙ ID 1000 سان.
اسان جي حالت ۾، هن حقيقت سان ٺهڪي اچي ٿي ته تقريبا سڀني ڊولپرز Ubuntu OS استعمال ڪندا آهن. ۽ Ubuntu OS ۾ پهريون صارف ID 1000 آهي.
ڇا اسان وٽ منصوبا آهن؟
Docker دستاويز ٻيهر پڙهو. پروجيڪٽ فعال طور تي ترقي ڪري رهيو آهي، دستاويز تبديل ٿي رهيو آهي. ڊيٽا جيڪا ٻه يا ٽي مهينا اڳ حاصل ڪئي وئي هئي، آهستي آهستي پراڻي ٿيندي پئي وڃي.
ڪجھ مسئلا جيڪي اسان حل ڪيا آھن شايد اڳ ۾ ئي معياري طريقن سان حل ڪيا ويا آھن.
مان واقعي اڳتي وڌڻ چاهيان ٿو ۽ سڌو سنئون آرڪيسٽريشن ڏانهن.
ھڪڙو مثال آھي Docker جي ٺاھيل ميڪانيزم کي Docker Swarm سڏيو ويندو آھي، جيڪو دٻي مان نڪرندو آھي. مان ڊاکر سوارم ٽيڪنالاجي جي بنياد تي پيداوار ۾ ڪجهه لانچ ڪرڻ چاهيان ٿو.
اسپوننگ ڪنٽينرز لاگز سان ڪم ڪرڻ کي تڪليف ڏين ٿا. هاڻي لاگز الڳ ٿي ويا آهن. اهي ڪنٽينر ۾ پکڙيل آهن. ڪمن مان هڪ آهي ويب انٽرفيس ذريعي لاگ تائين آسان رسائي.
جو ذريعو: www.habr.com