سلام هر!
مان واقعي سڌو سنئون موضوع ڏانهن وڃڻ چاهيان ٿو، پر منهنجي ڪهاڻي بابت ٿورو ٻڌائڻ وڌيڪ صحيح ٿيندو:
جائز آهي
مان ھڪڙو پروگرامر آھيان جنھن سان سرور تي فرنٽ اينڊ سنگل پيج ايپليڪيشن، اسڪالا/جاوا ۽ نوڊجز کي ترقي ڪرڻ ۾ تجربو آھي.
ڪافي عرصي تائين (يقيناً ٻه يا ٽي سال)، مان ان راءِ جو هو ته ڊڪر آسمان مان مننا آهي ۽ عام طور تي هڪ تمام ٿڌو اوزار آهي ۽ بلڪل هر ڊولپر ان کي استعمال ڪرڻ جي قابل هوندو. ۽ انهي مان اهو آهي ته هر ڊولپر کي پنهنجي مقامي مشين تي Docker انسٽال ڪرڻ گهرجي. منهنجي راءِ بابت ڇا آهي، انهن خالي جاين تي نظر وجهو جيڪي ساڳئي ايڇ تي پوسٽ ٿيل آهن. هر سيڪنڊ ۾ ڊڪر جو ذڪر آهي، ۽ جيڪڏهن توهان ان جي مالڪ آهيو، اهو توهان جو مقابلو فائدو ٿيندو 😉
منهنجي رستي ۾، مون ڪيترن ئي ماڻهن سان ملاقات ڪئي، انهن جي مختلف رويي سان ڊڪر ۽ ان جي ماحولياتي نظام ڏانهن. ڪجھ چيو ته اھو ھڪڙو آسان شيء آھي جيڪو ڪراس پليٽ فارم ڪارڪردگي جي ضمانت ڏئي ٿو. ٻئي کي سمجهه ۾ نه پئي آيو ته اهي ڪنٽينر ۾ ڇو هلن ۽ ان مان ڪهڙو فائدو ٿيندو، ٽئين کي ڪا به پرواهه نه هئي ۽ نه پروڙيائين (انهن صرف ڪوڊ لکيو ۽ گهر هليا ويا- مون کي انهن سان حسد، طريقو :)
استعمال ڪرڻ جا سبب
مون ڊڪر ڇو استعمال ڪيو؟ شايد هيٺين سببن جي ڪري:
- ڊيٽابيس لانچ، 99 سيڪڙو ايپليڪيشنون انهن کي استعمال ڪن ٿيون
- فرنٽ اينڊ ورهائڻ لاءِ nginx شروع ڪرڻ ۽ پس منظر ڏانهن پراکسي ڪرڻ
- توھان ايپليڪيشن کي ڊاکر تصوير ۾ پيڪ ڪري سگھو ٿا، ھن طريقي سان منھنجي ايپليڪيشن ڪم ڪندي جتي ڪٿي ڊڪر موجود آھي، تقسيم جو مسئلو فوري طور تي حل ڪيو ويندو
- خدمت جي دريافت کان ٻاهر، توهان microservices ٺاهي سگهو ٿا، هر ڪنٽينر (هڪ عام نيٽ ورڪ سان ڳنڍيل) آساني سان هڪ عرف ذريعي ٻئي تائين پهچي سگهي ٿو، تمام آسان
- اهو مزو آهي هڪ ڪنٽينر ٺاهڻ ۽ ان ۾ ”راند“ ڪرڻ.
ڇا مان هميشه ڊڪر بابت پسند نٿو ڪريان:
- منهنجي ايپليڪيشن کي ڪم ڪرڻ لاءِ، مون کي ضرورت آهي Docker پاڻ سرور تي. مون کي ان جي ضرورت ڇو آهي جيڪڏهن منهنجون ايپليڪيشنون jre يا nodejs تي هلن ٿيون ۽ انهن لاءِ ماحول اڳ ۾ ئي سرور تي آهي؟
- جيڪڏهن مان پنهنجي (نجي) مقامي طور تي ٺاهيل تصوير کي ريموٽ سرور تي هلائڻ چاهيان ٿو، ته پوءِ مون کي پنهنجي ڊاڪر ريپوزٽري جي ضرورت آهي، مون کي رجسٽري جي ضرورت آهي ڪٿي ڪم ڪرڻ لاءِ ۽ مون کي https کي ترتيب ڏيڻ جي به ضرورت آهي، ڇاڪاڻ ته ڊڪر ڪلي صرف https تي ڪم ڪري ٿو. اوه لعنت... اتي اختيار آهن، يقينا، تصوير کي مقامي طور تي محفوظ ڪرڻ لاءِ
docker save۽ صرف تصوير موڪليو scp ذريعي... پر اها تمام گهڻي جسماني حرڪت آهي. ۽ ان کان علاوه، اهو ڏسڻ ۾ اچي ٿو "ڪيچ" حل جيستائين توهان جو پنهنجو مخزن ظاهر ٿئي docker-compose. اهو صرف ڪنٽينرز کي هلائڻ جي ضرورت آهي. اهو ئي سڀ ڪجهه آهي. هو ٻيو ڪجهه به نٿو ڪري سگهي.Docker-composeان جي فائلن جي نسخن جو هڪ گروپ آهي، ان جي پنهنجي نحو. ڪو مسئلو ناهي ته اهو ڪيترو بيان ڪندڙ آهي، مان انهن جي دستاويز کي پڙهڻ نٿو چاهيان. مون کي ڪٿي به ضرورت نه پوندي.- جڏهن هڪ ٽيم ۾ ڪم ڪري رهيا آهن، اڪثر ماڻهو هڪ ڊاکرفائل کي تمام خراب انداز سان لکندا آهن، اهو نه سمجهندا آهن ته اهو ڪيئن ڪيش ڪيو ويو آهي، هر شي کي شامل ڪريو جيڪي انهن کي گهربل آهي ۽ تصوير جي ضرورت ناهي، انهن تصويرن مان ورثي ۾ حاصل ڪريو جيڪي Dockerhub يا خانگي ريپوزٽري ۾ نه آهن، ڪجهه ٺاهيو.
docker-composeڊيٽابيس سان گڏ فائلون ۽ ڪجھ به نه رهي. ساڳئي وقت، ڊولپر فخر سان اعلان ڪن ٿا ته ڊڪر ٿڌو آهي، هر شيء انهن لاء مقامي طور تي ڪم ڪري ٿو، ۽ HR اهم طور تي خالي جاء تي لکي ٿو: "اسان ڊاکر استعمال ڪندا آهيون ۽ اسان کي اهڙي ڪم جي تجربي سان اميدوار جي ضرورت آهي." - مان ڊاکر ۾ هر شي کي وڌائڻ بابت خيالن سان مسلسل پريشان آهيان: postgresql، kafka، redis. اها افسوس جي ڳالهه آهي ته هر شيءِ ڪنٽينرز ۾ ڪم نه ڪندي آهي، نه ته هر شي کي ترتيب ڏيڻ ۽ هلائڻ آسان آهي. هي ٽئين پارٽي ڊولپرز جي حمايت ڪئي آهي، ۽ نه پاڻ وينڊرز طرفان. ۽ رستي ۾، سوال فوري طور تي پيدا ٿئي ٿو: وينڊرز ڊاکر ۾ پنهنجن شين کي برقرار رکڻ بابت پريشان نه ڪندا، اهو ڇو آهي، شايد اهي ڪجهه ڄاڻن ٿا؟
- سوال هميشه ڪنٽينر ڊيٽا جي تسلسل بابت پيدا ٿئي ٿو. ۽ پوءِ توھان سوچيو، ڇا مان صرف ھوسٽ ڊاريڪٽري کي مائونٽ ڪريان يا ڊاڪر حجم ٺاھيان يا ھڪڙو ڊيٽا ڪنٽينر ٺاھيو جيڪو ھاڻي آھي
deprecated؟ جيڪڏهن مان هڪ ڊاريڪٽري کي نصب ڪريان ٿو، ته پوء مون کي پڪ ڪرڻ جي ضرورت آهي ته ڪنٽينر ۾ استعمال ڪندڙ جي uid ۽ gid ان صارف جي سڃاڻپ سان ملن ٿيون جنهن ڪنٽينر کي لانچ ڪيو، ٻي صورت ۾ ڪنٽينر پاران ٺاهيل فائلون روٽ حقن سان ٺاهي وينديون. جيڪڏهن مان استعمال ڪريانvolumeپوء ڊيٽا صرف ڪجهه ۾ ٺاهي ويندي/usr/*۽ اتي به ساڳي ڪهاڻي uid ۽ gid سان گڏ پهرين صورت ۾ هوندي. جيڪڏهن توهان ٽئين پارٽي جو حصو شروع ڪري رهيا آهيو، توهان کي دستاويز پڙهڻ جي ضرورت آهي ۽ سوال جو جواب ڳولڻ جي ضرورت آهي: "ڪهڙي ڪنٽينر ڊائريڪٽرن ۾ جزو فائلون لکندو آهي؟"
مون کي هميشه اها حقيقت پسند نه هئي ته مون کي ڊاڪر سان گهڻي عرصي تائين ٽينڪر ڪرڻو پوندو شروعاتي اسٽيج تي: مون سمجهيو ته ڪنٽينر ڪيئن لانچ ڪيا وڃن، ڪهڙيون تصويرون لانچ ڪيون وڃن، ميڪ فائلون ٺاهيون جن ۾ ڊگها ڊاڪر ڪمانڊز جا عرف شامل هئا. مون کي نفرت هئي ڊڪر ڪمپوز ڇاڪاڻ ته مان ڊاڪر ايڪو سسٽم ۾ ٻيو اوزار سکڻ نه ٿي چاهيان. ۽ docker-compose up اهو مون کي پريشان ڪيو، خاص طور تي جيڪڏهن اهي اڃا تائين اتي ملن ٿا build تعميرات، اڳ ۾ ئي گڏ ڪيل تصويرن جي ڀيٽ ۾. بس مان واقعي چاهيان ٿو ته صرف هڪ پيداوار کي موثر ۽ جلدي ٺاهڻ. پر مان سمجهي نه سگهيو آهيان ته ڊڪر ڪيئن استعمال ڪجي.
جواب ڏيڻ وارو تعارف
تازو (ٽي مهينا اڳ)، مون هڪ DevOps ٽيم سان گڏ ڪم ڪيو، تقريبن هر ميمبر جو ڊڪر جي طرف منفي رويو هو. سببن لاء:
- docker ضابطو iptables (جيتوڻيڪ توهان ان کي بند ڪري سگهو ٿا daemon.json ۾)
- ڊاکر بگي آهي ۽ اسان ان کي پيداوار ۾ نه هلائينداسين
- جيڪڏهن ڊاکر ڊيمون حادثو ٿئي ٿو، ته پوء سڀني ڪنٽينر انفراسٽرڪچر جي حادثي سان مطابق
- ڊاکر جي ضرورت ناهي
- ڇو ڊڪر جيڪڏهن جوابي ۽ ورچوئل مشينون آهن
ساڳئي نوڪري ۾، مون کي هڪ ٻئي اوزار سان واقف ٿي ويو - جوابي. مون ان جي باري ۾ هڪ ڀيرو ٻڌو، پر مون ڪوشش نه ڪئي ته منهنجي پنهنجي راند جا ڪتاب لکڻ جي. ۽ ھاڻي مون پنھنجو ڪم لکڻ شروع ڪيو ۽ پوءِ منھنجي نظر بلڪل بدلجي وئي! ڇو ته مون محسوس ڪيو: جواب ڏيڻ وارا ساڳيا ڊاکر ڪنٽينرز، تصويري ٺاھڻ، نيٽ ورڪ، وغيره کي هلائڻ لاء ماڊل آھن، ۽ ڪنٽينرز کي نه رڳو مقامي طور تي، پر ريموٽ سرورز تي پڻ هلائي سگھجي ٿو! منهنجي لذت جي ڪا به حد نه هئي - مون کي هڪ عام اوزار مليو ۽ منهنجي ميڪفائل ۽ ڊاکر-ڪپوز فائلن کي اڇلائي ڇڏيو، انهن کي يامل ڪمن سان تبديل ڪيو ويو. ڪوڊ استعمال ڪندي گھٽايو ويو تعميرات وانگر loop, whenوغيره
ڊڪر ٽئين پارٽي جي اجزاء کي هلائڻ لاءِ جيئن ته ڊيٽابيس
مان تازو ssh tunnels سان واقف ٿي چڪو آهيان. اهو ظاهر ٿيو ته اهو تمام آسان آهي "اڳتي" هڪ ريموٽ سرور جي بندرگاهه کي مقامي بندرگاهه ڏانهن. ريموٽ سرور يا ته ڪلائوڊ ۾ هڪ مشين ٿي سگهي ٿو يا ورچوئل بڪس ۾ هلندڙ هڪ ورچوئل مشين. جيڪڏهن منهنجو ساٿي يا مون کي ڊيٽابيس جي ضرورت آهي (يا ڪجهه ٻي ٽئين پارٽي جزو)، اسان صرف هن جزو سان سرور کي شروع ڪري سگهون ٿا ۽ ان کي بند ڪري سگهون ٿا جڏهن سرور جي ضرورت ناهي. پورٽ فارورڊنگ ساڳيو اثر ڏئي ٿو جيئن ڊاکر ڪنٽينر ۾ هلندڙ ڊيٽابيس.
هي حڪم منهنجي مقامي بندرگاهن کي ريموٽ سرور ڏانهن موڪلي ٿو پوسٽ گريسڪ ايل:
ssh -L 9000:localhost:5432 [ايميل محفوظ ٿيل]
ريموٽ سرور استعمال ڪندي ٽيم جي ترقي سان مسئلو حل ڪري ٿو. اهڙو سرور هڪ ئي وقت ڪيترن ئي ڊولپرز طرفان استعمال ڪري سگهجي ٿو؛ انهن کي ضرورت نه آهي ته پوسٽ گريسڪ ايل کي ترتيب ڏيڻ، ڊاڪر ۽ ٻين پيچيدگين کي سمجهڻ. هڪ ريموٽ سرور تي، توهان Docker ۾ ساڳيو ڊيٽابيس انسٽال ڪري سگهو ٿا، جيڪڏهن اهو هڪ مخصوص ورزن انسٽال ڪرڻ ڏکيو آهي. سڀني ڊولپرز کي ضرورت آهي ssh رسائي فراهم ڪرڻ!
مون تازو پڙهيو آهي ته SSH سرنگون هڪ باقاعده وي پي اين جي محدود ڪارڪردگي آهن! توهان صرف انسٽال ڪري سگهو ٿا OpenVPN يا ٻيون VPN لاڳو ڪرڻ، انفراسٽرڪچر قائم ڪريو ۽ استعمال لاءِ ڊولپرز کي ڏيو. هي تمام ٿڌو آهي!
خوشقسمتيء سان، AWS، GoogleCloud ۽ ٻيا توهان کي مفت استعمال جو هڪ سال ڏيو، تنهنڪري انهن کي استعمال ڪريو! اهي سستا آهن جيڪڏهن توهان انهن کي بند ڪريو جڏهن استعمال ۾ نه هجي. مان هميشه حيران ٿي ويس ته مون کي هڪ ريموٽ سرور جي ضرورت آهي gcloud وانگر، اهو لڳي ٿو ته مون انهن کي ڳولي ورتو.
مقامي مجازي مشين جي طور تي، توهان ساڳيو الپائن استعمال ڪري سگهو ٿا، جيڪو فعال طور تي ڊاکر ڪنٽينرز ۾ استعمال ڪيو ويندو آهي. چڱو، يا ڪجھ ٻيون ھلڪو وزن جي تقسيم مشين کي تيز ڪرڻ لاء.
هيٺيون لڪير: توهان ريموٽ سرورز يا ورچوئل باڪس ۾ ڊيٽابيس ۽ ٻيون انفراسٽرڪچر سامان هلائي سگهو ٿا ۽ هلائي سگهو ٿا. مون کي انهن مقصدن لاءِ ڊڪر جي ضرورت ناهي.
ڊاکر تصويرون ۽ تقسيم بابت ٿورڙو
مون ا already ۾ ئي لکيو آهي جنهن ۾ مان اهو ٻڌائڻ چاهيان ٿو ته ڊاکر تصويرون استعمال ڪرڻ ڪا به گارنٽي فراهم نٿو ڪري. Docker تصويرن جي ضرورت آهي صرف هڪ ڊاکر ڪنٽينر ٺاهڻ لاءِ. جيڪڏهن توهان ڊاکر تصوير ڏانهن اپڊيٽ ڪري رهيا آهيو، ته توهان ڊاکر ڪنٽينرز کي استعمال ڪرڻ لاء اپڊيٽ ڪري رهيا آهيو ۽ توهان صرف انهن کي استعمال ڪندا.
ڇا توھان ڪٿي ڏٺو آھي جتي سافٽ ويئر ڊولپر پنھنجي پروڊڪٽس کي صرف ڊاکر تصوير ۾ پورٽ ڪندا آھن؟
اڪثر پراڊڪٽس جو نتيجو هڪ مخصوص پليٽ فارم لاء بائنري فائلون آهن؛ اهي صرف ڊاکر تصوير ۾ شامل ڪيا ويا آهن، جيڪا گهربل پليٽ فارم مان ورثي ۾ ملي ٿي. ڇا توهان ڪڏهن حيران ڪيو آهي ته ڊڪر هب تي ڪيتريون ئي ساڳيون تصويرون ڇو آهن؟ مثال طور nginx داخل ڪريو، توھان ڏسندا 100500 تصويرون مختلف ماڻھن کان. انهن ماڻهن پاڻ نينڪس کي ترقي نه ڪئي، انهن صرف پنهنجي ڊاکر تصوير ۾ سرڪاري نينڪس شامل ڪيو ۽ ڪنٽينر لانچ ڪرڻ جي سهولت لاءِ پنهنجي ترتيب سان ان کي سيزن ڪيو.
عام طور تي، توهان صرف ان کي tgz ۾ ذخيرو ڪري سگهو ٿا، جيڪڏهن ڪنهن کي ان کي ڊاکر ۾ هلائڻ جي ضرورت آهي، پوء انهن کي اجازت ڏيو tgz کي Dockerfile ۾ شامل ڪريو، گهربل ماحول مان ورثي ۾ ۽ اضافي بنون ٺاهي جيڪي ايپليڪيشن کي پاڻ کي tgz ۾ تبديل نه ڪن. ڪو به ماڻهو جيڪو ڊاکر تصوير ٺاهيندو اهو ڄاڻندو ته tgz ڇا آهي ۽ هن کي ڪم ڪرڻ جي ضرورت آهي. اهو ڪيئن آهي مان ڊاکر استعمال ڪريان ٿو
هيٺئين لڪير: مون کي ڊاکر رجسٽري جي ضرورت ناهي، مان ڪجهه قسم جو S3 استعمال ڪندس يا صرف فائل اسٽوريج جهڙوڪ گوگل ڊرائيو/ڊراپ باڪس
CI ۾ Docker
سڀئي ڪمپنيون جن لاءِ مون ڪم ڪيو آهي ساڳيا آهن. اهي عام طور تي گروسري آهن. اهو آهي، انهن وٽ هڪ ايپليڪيشن آهي، هڪ ٽيڪنالاجي اسٽيڪ (چڱو، شايد ٻه يا ٽي پروگرامنگ ٻوليون).
اهي ڪمپنيون ڊاکر استعمال ڪن ٿيون انهن جي سرور تي جتي سي آءِ عمل هلندو آهي. سوال: توهان کي توهان جي سرور تي ڊاکر ڪنٽينر ۾ پروجيڪٽ ٺاهڻ جي ضرورت آهي؟ ڇو نه صرف تعمير لاءِ ماحول تيار ڪيو وڃي، مثال طور، هڪ جوابي پلے بڪ لکو جيڪو نوڊج، php، jdk، ڪاپي ssh ڪيز وغيره جا ضروري ورجن انسٽال ڪندو سرور تي جنهن ۾ تعمير ٿيندي؟
هاڻي مان سمجهان ٿو ته اهو پاڻ کي پيرن ۾ گولي هڻي رهيو آهي، ڇاڪاڻ ته ڊاکر پنهنجي اڪيلائيء سان ڪو فائدو نه آڻيندو آهي. مسئلا مون کي ڊيڪر ۾ CI سان مليا:
- ٻيهر توهان کي ٺاهڻ لاء هڪ ڊاکر تصوير جي ضرورت آهي. توھان کي ھڪڙي تصوير ڳولڻ جي ضرورت آھي يا پنھنجي ڊاکر فائل لکڻو پوندو.
- 90٪ جيڪو توهان کي اڳتي وڌڻ جي ضرورت آهي ڪجهه ssh چابيون، ڳجهي ڊيٽا جيڪا توهان ڊاکر تصوير ڏانهن لکڻ نٿا چاهيو.
- ڪنٽينر پيدا ٿئي ٿو ۽ مري وڃي ٿو، سڀ ڪيچ ان سان گڏ گم ٿي ويا آهن. ايندڙ تعمير سڀني پروجيڪٽ جي انحصار کي ٻيهر ڊائون لوڊ ڪندي، جيڪو وقت سازي ۽ غير موثر آهي، ۽ وقت پئسا آهي.
ڊولپرز ڊاکر ڪنٽينرز ۾ منصوبا نه ٺاهيندا آهن (مان هڪ ڀيرو اهڙو پرستار هو، حقيقت ۾، مون کي ماضي ۾ پنهنجي لاء افسوس محسوس ٿيو xD). جاوا ۾ اهو ممڪن آهي ته ڪيترائي نسخا هجن ۽ انهن کي هڪ حڪم سان تبديل ڪريو جنهن جي توهان کي هاڻي ضرورت آهي. اهو ساڳيو آهي nodejs ۾، اتي nvm آهي.
ٿڪل
مان سمجهان ٿو ته ڊڪر هڪ تمام طاقتور ۽ لچڪدار اوزار آهي، اهو ان جي خرابي آهي (آواز عجيب، ها). ان جي مدد سان، ڪمپنيون آساني سان ان تي ڇڪي سگهن ٿيون ۽ ان کي استعمال ڪري سگھن ٿيون جتي ضرورت هجي ۽ نه هجي. ڊولپرز پنهنجن ڪنٽينرز کي لانچ ڪن ٿا، انهن مان ڪجهه ماحول، پوء اهو سڀ آسانيء سان CI ۽ پيداوار ۾ وهندو آهي. DevOps ٽيم لکي رهي آهي ڪجهه قسم جو ڪوڊ انهن ڪنٽينرز کي هلائڻ لاءِ.
استعمال ڪريو صرف ڊڪر تي سڀ کان تازو توهان جي ڪم جي فلو ۾ اسٽيج، ان کي شروع ۾ پروجيڪٽ ۾ نه ڇڪيو. اهو توهان جي ڪاروباري مسئلن کي حل نه ڪندو. هو صرف مسئلن کي ٻئي سطح تي منتقل ڪندو ۽ پنهنجو حل پيش ڪندو، توهان ٻيڻو ڪم ڪندا.
جڏهن ڊڪر جي ضرورت آهي: مان ان نتيجي تي پهتو آهيان ته ڊڪر هڪ ڏنل عمل کي بهتر ڪرڻ ۾ تمام سٺو آهي، پر بنيادي ڪارڪردگي جي تعمير ۾ نه.
جيڪڏهن توهان اڃا تائين ڊاکر استعمال ڪرڻ جو فيصلو ڪيو، پوء:
- انتهائي محتاط ٿي
- ڊولپرز کي ڊڪر استعمال ڪرڻ تي مجبور نه ڪريو
- ان جي استعمال کي ھڪڙي جڳھ تي مقامي ڪريو، ان کي سڀني Dockfile ۽ docker-compose repositories ۾ نه پکيڙيو
پي
- مون کي تازو مليو ۽ اهي چون ٿا ته اهو جواب ڏيڻ سان تمام سٺو ڪم ڪري ٿو ۽ توهان کي تصويرن جي تعمير جي عمل کي متحد ڪرڻ جي اجازت ڏئي ٿو (ڊاڪر تصوير سميت)
پڙهڻ لاءِ توهان جي مهرباني، مان چاهيان ٿو ته توهان جي معاملن ۾ شفاف فيصلا ۽ پيداواري ڪم ڪندڙ ڏينهن!
جو ذريعو: www.habr.com