اسان اسان جي ٽيڪنيڪل ڊائريڪٽر جي تازي تقريرن جي بنياد تي اشاعتن سان پنهنجو بلاگ شروع ڪنداسين (دمتري Stolyarov). اهي سڀئي 2016 ۾ مختلف پيشه ور واقعن ۾ ٿي ويا ۽ ڊي اوپس ۽ ڊڪر جي موضوع لاءِ وقف ڪيا ويا. بدو آفيس ۾ ڊاڪر ماسڪو جي گڏجاڻي مان هڪ وڊيو، اسان وٽ اڳ ۾ ئي آهي آن لائن. نون مضمونن سان گڏ گڏ ڪيا ويندا جيڪي رپورٽن جي مضمون کي بيان ڪن ٿا. تنهنڪري…
31 مئي ڪانفرنس ۾ فيسٽيول “روسي انٽرنيٽ ٽيڪنالاجيز” (RIT++ 2016) جي حصي جي طور تي منعقد ڪيو ويو، سيڪشن “مسلسل تعیناتي ۽ تعیناتي” “ڊاڪر سان مسلسل پهچائڻ جا بهترين طريقا” رپورٽ سان کوليا ويا. اهو ڊڪر ۽ ٻين اوپن سورس پراڊڪٽس کي استعمال ڪندي مسلسل پهچائڻ (سي ڊي) جي عمل جي تعمير لاءِ بهترين طريقن جو خلاصو ۽ ترتيب ڏنو. اسان پيداوار ۾ انهن حلن سان ڪم ڪندا آهيون، جيڪا اسان کي عملي تجربي تي ڀروسو ڪرڻ جي اجازت ڏئي ٿي.
جيڪڏهن توهان وٽ هڪ ڪلاڪ خرچ ڪرڻ جو موقعو آهي ، اسان ان کي مڪمل طور تي ڏسڻ جي صلاح ڏيو ٿا. ٻي صورت ۾، هيٺ ڏنل متن جي شڪل ۾ مکيه خلاصو آهي.
Docker سان مسلسل پهچائڻ
هيٺ مسلسل پهچائڻ اسان واقعن جي زنجير کي سمجھون ٿا جنهن جي نتيجي ۾ Git مخزن مان ايپليڪيشن ڪوڊ پهرين پيداوار ۾ اچي ٿو، ۽ پوء آرڪائيو ۾ ختم ٿئي ٿو. هوء هن وانگر نظر اچي ٿي: گٽ → تعمير → ٽيسٽ → رليز → هلائڻ.
اڪثر رپورٽ تعمير اسٽيج (ايپليڪيشن اسيمبلي) ڏانهن وقف ڪئي وئي آهي، ۽ عنوانن کي ڇڏڻ ۽ هلائڻ تي مختصر طور تي ڇڪايو ويو آهي. اسان انهن مسئلن ۽ نمونن جي باري ۾ ڳالهائينداسين جيڪي توهان کي انهن کي حل ڪرڻ جي اجازت ڏين ٿا، ۽ انهن نمونن جا مخصوص عمل مختلف ٿي سگهن ٿا.
هتي Docker جي ضرورت ڇو آهي؟ اهو ڪجھ به نه آهي ته اسان هن اوپن سورس ٽول جي حوالي سان مسلسل پهچائڻ جي طريقن بابت ڳالهائڻ جو فيصلو ڪيو. جيتوڻيڪ پوري رپورٽ ان جي استعمال لاءِ وقف ڪئي وئي آهي، ڪيترن ئي سببن کي ظاهر ڪيو ويو آهي جڏهن ايپليڪيشن ڪوڊ رول آئوٽ جي بنيادي نموني تي غور ڪيو وڃي.
مکيه rollout نموني
تنهن ڪري، جڏهن اسان ايپليڪيشن جا نوان ورزن ٺاهيندا آهيون، اسان کي ضرور منهن ڏيڻو پوندو بند وقت جو مسئلو، پيداوار جي سرور جي سوئچنگ دوران پيدا ٿيل. ايپليڪيشن جي پراڻي ورزن کان نئين تائين ٽريفڪ فوري طور تي تبديل نه ٿي ڪري سگھجي: پهرين اسان کي پڪ ڪرڻ گهرجي ته نئون نسخو نه صرف ڪاميابي سان ڊائون لوڊ ڪيو ويو آهي، پر پڻ "گرم اپ" (يعني درخواستن جي خدمت ڪرڻ لاء مڪمل طور تي تيار آهي).
اهڙيء طرح، ڪجهه وقت لاء اپليڪيشن جي ٻنهي نسخن (پراڻي ۽ نئين) هڪ ئي وقت ڪم ڪندو. جيڪو خود بخود ٿي وڃي ٿو گڏيل وسيلن جي تڪرار: نيٽ ورڪ، فائيل سسٽم، IPC، وغيره. Docker سان، هي مسئلو آساني سان حل ڪيو ويو آهي ايپليڪيشن جي مختلف ورزن کي الڳ ڪنٽينرز ۾ هلائڻ سان، جنهن لاءِ وسيلن جي اڪيلائي جي ضمانت آهي ساڳئي ميزبان (سرور/ورچوئل مشين). يقينا، توهان بغير ڪنهن موصليت جي ڪجهه چالن سان حاصل ڪري سگهو ٿا، پر جيڪڏهن هڪ تيار ڪيل ۽ آسان اوزار آهي، ته پوء ان جي سامهون سبب آهي - ان کي نظرانداز نه ڪرڻ.
ڪنٽينرائيزيشن مهيا ڪري ٿي ٻيا ڪيترائي فائدا جڏهن مقرر ڪيا وڃن. ڪنهن به درخواست تي منحصر آهي مخصوص نسخو (يا نسخي جي حد) مترجم, ماڊيولز / ايڪسٽينشن جي دستيابي، وغيره، گڏو گڏ انهن جا نسخا. ۽ اهو لاڳو ٿئي ٿو نه رڳو فوري طور تي قابل عمل ماحول تي، پر سڄي ماحول تي، بشمول سسٽم سافٽ ويئر ۽ ان جو نسخو (استعمال ٿيل لينڪس ڊويزن تائين). انهي حقيقت جي ڪري ته ڪنٽينرز ۾ نه رڳو ايپليڪيشن ڪوڊ، پر اڳ ۾ نصب ٿيل سسٽم ۽ گهربل ورزن جي ايپليڪيشن سافٽ ويئر، توهان انحصار سان مسئلن جي باري ۾ وساري سگهو ٿا.
اچو ته اختصار ڪريون مکيه rollout نموني نون نسخن ۾ هيٺين عنصرن کي نظر ۾ رکندي:
- پهرين تي، ايپليڪيشن جو پراڻو نسخو پهرين ڪنٽينر ۾ هلندو آهي.
- ان کان پوءِ نئون ورزن رول ڪيو ويندو آهي ۽ ٻئي ڪنٽينر ۾ ”گرم اپ“ ڪيو ويندو آهي. اهو قابل ذڪر آهي ته هي نئون نسخو پاڻ کي نه رڳو اپڊيٽ ڪوڊ ڪري سگھي ٿو، پر ان جي ڪنهن به انحصار سان گڏ، سسٽم اجزاء (مثال طور، OpenSSL جو نئون نسخو يا پوري تقسيم).
- جڏهن نئون نسخو مڪمل طور تي درخواستن جي خدمت ڪرڻ لاءِ تيار هوندو آهي، ٽريفڪ پهرين ڪنٽينر کان ٻئي ۾ تبديل ٿي ويندي آهي.
- پراڻو نسخو هاڻي روڪي سگهجي ٿو.
ايپليڪيشن جي مختلف ورزن کي الڳ ڪنٽينرز ۾ ترتيب ڏيڻ جو هي طريقو هڪ ٻي سهولت فراهم ڪري ٿو - جلدي واپسي پراڻي ورزن ڏانهن (آخرڪار، اهو ڪافي آهي ته ٽرئفڪ کي گهربل ڪنٽينر ڏانهن تبديل ڪرڻ).
حتمي پهرين سفارش ڪجهه اهڙي آواز وانگر آهي جيڪا ڪئپٽن کي به غلطي نه ملي سگهي: "[جڏهن ڊڪر سان مسلسل پهچائڻ کي منظم ڪرڻ] Docker استعمال ڪريو [۽ سمجھو ته اهو ڇا ڏئي ٿو]" ياد رکو، هي هڪ چانديء جي گولي ناهي جيڪا هر مسئلي کي حل ڪندي، پر هڪ اوزار جيڪو هڪ شاندار بنياد فراهم ڪري ٿو.
پيداواري صلاحيت
"ٻيهر پيدا ڪرڻ" جي ذريعي اسان جو مطلب آهي عام طور تي مشڪلاتن جو هڪ سيٽ جنهن کي منهن ڏيڻو پوي ٿو جڏهن آپريٽنگ ايپليڪيشنون. اسان اهڙين ڪيسن بابت ڳالهائي رهيا آهيون:
- اسٽيجنگ لاءِ معيار واري کاتي پاران چيڪ ڪيل اسڪرپٽ کي پيداوار ۾ صحيح طور تي ٻيهر تيار ڪيو وڃي.
- ايپليڪيشنون سرورز تي شايع ٿيل آهن جيڪي مختلف مخزن جي آئيني مان پيڪيجز وصول ڪري سگھن ٿيون (وقت سان گڏ اهي اپڊيٽ ڪيا ويندا آهن، ۽ انهن سان گڏ نصب ٿيل ايپليڪيشنن جا نسخا).
- "سڀ ڪجهه مقامي طور تي مون لاء ڪم ڪري ٿو!" (...۽ ڊولپرز کي پيداوار ۾ اجازت نه آهي.)
- توهان کي پراڻي (آرڪائيو ٿيل) ورزن ۾ ڪجهه چيڪ ڪرڻ جي ضرورت آهي.
- ...
انهن جو عام جوهر ان حقيقت ڏانهن ڇڪي ٿو ته استعمال ٿيل ماحول جي مڪمل تعميل (انهي سان گڏ انساني عنصر جي غير موجودگي) ضروري آهي. اسان ڪيئن ضمانت ڏئي سگهون ٿا reproducibility؟ Docker تصويرون ٺاهيو Git مان ڪوڊ جي بنياد تي، ۽ پوء انھن کي ڪنھن ڪم لاء استعمال ڪريو: ٽيسٽ سائيٽن تي، پيداوار ۾، پروگرامرز جي مقامي مشينن تي ... ساڳئي وقت، اھو ضروري آھي ته ڪمن کي گھٽائڻ لاء جيڪي انجام ڏنا ويا آھن. после تصوير کي گڏ ڪرڻ: اهو آسان آهي، گهٽ ۾ گهٽ غلطيون آهن.
انفراسٽرڪچر ڪوڊ آهي
جيڪڏهن بنيادي ڍانچي جي گهرج (سرور سافٽ ويئر جي دستيابي، ان جو نسخو، وغيره) رسمي ۽ "پروگرام ٿيل" نه آهن، پوء ڪنهن به ايپليڪيشن اپڊيٽ جي رول آئوٽ تباهي جا نتيجا ٿي سگهن ٿا. مثال طور، اسٽيجنگ ۾ توهان اڳ ۾ ئي PHP 7.0 ڏانهن تبديل ڪيو آهي ۽ ان جي مطابق ڪوڊ ٻيهر لکيو آهي - پوء ان جي پيداوار ۾ ڪجهه پراڻي PHP (5.5) سان ظاهر ٿئي ٿي، يقيناً ڪنهن کي حيران ڪري ڇڏيندو. توهان شايد مترجم نسخي ۾ وڏي تبديلي جي باري ۾ نه وساريو، پر "شيطان تفصيل ۾ آهي": تعجب ٿي سگهي ٿو ڪنهن به انحصار جي معمولي تازه ڪاري ۾.
هن مسئلي کي حل ڪرڻ لاء هڪ طريقو طور سڃاتو وڃي ٿو IaC (بنيادي ڍانچي جي طور تي ڪوڊ، "انفراسٽرڪچر جيئن ڪوڊ") ۽ ايپليڪيشن ڪوڊ سان گڏ انفراسٽرڪچر جي ضرورتن کي محفوظ ڪرڻ ۾ شامل آهي. ان کي استعمال ڪندي، ڊولپرز ۽ DevOps ماهر ڪم ڪري سگهن ٿا ساڳي Git ايپليڪيشن مخزن سان، پر ان جي مختلف حصن تي. هن ڪوڊ مان، گٽ ۾ هڪ ڊاکر تصوير ٺاهي وئي آهي، جنهن ۾ ايپليڪيشن کي ترتيب ڏني وئي آهي اڪائونٽ جي بنيادي جوڙجڪ جي سڀني خاصيتن کي. سادي لفظ ۾، تصويرن کي گڏ ڪرڻ لاء اسڪرپٽ (قاعدن) کي هڪ ئي مخزن ۾ هجڻ گهرجي سورس ڪوڊ سان ۽ گڏجي گڏ ڪيو وڃي.
ملٽي ليئر ايپليڪيشن آرڪيٽيڪچر جي صورت ۾ - مثال طور، اتي نينڪس آهي، جيڪو اڳ ۾ ئي ڊڪر ڪنٽينر اندر هلندڙ ايپليڪيشن جي سامهون بيٺو آهي - ڊاڪر تصويرون هر پرت لاءِ گٽ ۾ ڪوڊ مان ٺاهيون وڃن ٿيون. پوءِ پھرين تصوير ۾ ھڪ ائپليڪيشن ھوندي جنھن ۾ مترجم ۽ ٻيو ”قريب“ انحصار شامل ھوندو، ۽ ٻي تصوير ۾ upstream nginx ھوندو.
Docker تصويرون، گيٽ سان رابطي
اسان گٽ مان گڏ ڪيل سڀني ڊڪر تصويرون کي ٻن ڀاڱن ۾ ورهايو: عارضي ۽ ڇڏڻ. عارضي تصويرون Git ۾ برانچ جي نالي سان ٽيگ ٿيل، ايندڙ ڪمٽ طرفان اوور رائٽ ڪري سگھجي ٿو ۽ صرف ڏيک لاءِ (پيداوار لاءِ نه). هي انهن جو اهم فرق آهي ڇڏڻ وارن کان: توهان ڪڏهن به نه ٿا ڄاڻو ته انهن ۾ ڪهڙو خاص عزم آهي.
اهو عارضي تصويرن ۾ گڏ ڪرڻ جو احساس رکي ٿو: ماسٽر برانچ (توهان پاڻمرادو ان کي الڳ سائيٽ ڏانهن رول آئوٽ ڪري سگهو ٿا ماسٽر جي موجوده ورزن کي مسلسل ڏسڻ لاءِ)، شاخن سان رليز، مخصوص جدت جون شاخون.
عارضي تصويرن جي ڏيک کان پوء پيداوار ۾ ترجمي جي ضرورت اچي ٿي، ڊولپرز هڪ خاص ٽيگ لڳايو. خودڪار طور تي ٽيگ ذريعي گڏ ڪيل تصوير ڇڏڻ (ان جو ٽيگ Git جي ٽيگ سان ملندو آهي) ۽ اسٽيجنگ ڏانهن وڌايو ويو آهي. جيڪڏهن اها ڪاميابي سان تصديق ڪئي وئي آهي معيار کاتي طرفان، اها پيداوار ڏانهن ويندي آهي.
ڊيپ
بيان ڪيل هر شي (رول آئوٽ، تصويري اسيمبلي، بعد ۾ سار سنڀال) بيش اسڪرپٽ ۽ ٻين "بهتر" اوزار استعمال ڪندي آزاديء سان لاڳو ٿي سگهي ٿو. پر جيڪڏهن توهان اهو ڪريو ٿا، ته پوء ڪجهه نقطي تي عمل درآمد وڏي پيچيدگي ۽ خراب ڪنٽرول جي سبب ٿي ويندي. ان کي سمجھندي، اسان CI/CD تعمير ڪرڻ لاءِ پنھنجي خاص ورڪ فلو يوٽيلٽي ٺاھيو آھي. ڊيپ.
ان جو سورس ڪوڊ روبي ۾ لکيل آهي، اوپن سورس ۽ شايع ٿيل آهي . بدقسمتي سان، دستاويز هن وقت اوزار جو ڪمزور ترين نقطو آهي، پر اسان ان تي ڪم ڪري رهيا آهيون. ۽ اسين ڊيپ بابت هڪ کان وڌيڪ ڀيرا لکنداسين ۽ ڳالهائينداسين، ڇاڪاڻ ته ... اسان خلوص سان ان جي صلاحيتن کي پوري دلچسپي برادري سان حصيداري ڪرڻ جو انتظار نٿا ڪري سگهون، پر ان دوران، پنهنجا مسئلا موڪليو ۽ درخواستون ڪڍو ۽ / يا GitHub تي منصوبي جي ترقي جي پيروي ڪريو.
اپڊيٽ ڪيو ويو آگسٽ 13، 2019: في الحال هڪ پروجيڪٽ ڊيپ جو نالو تبديل ڪيو ويو , ان جو ڪوڊ مڪمل طور تي گو ۾ ٻيهر لکيو ويو آهي، ۽ ان جي دستاويز کي خاص طور تي بهتر ڪيو ويو آهي.
ڪوبنيٿس
ٻيو تيار ٿيل اوپن سورس ٽول جيڪو اڳ ۾ ئي پروفيشنل ماحول ۾ اهم سڃاڻپ حاصل ڪري چڪو آهي ڪوبنيٿس، هڪ ڊڪر مئنيجمينٽ ڪلستر. ڊاکر تي ٺهيل منصوبن جي آپريشن ۾ ان جي استعمال جو موضوع رپورٽ جي دائري کان ٻاهر آهي، تنهنڪري پيشڪش ڪجهه دلچسپ خاصيتن جي نظرثاني تائين محدود آهي.
رول آئوٽ لاءِ، ڪبرنيٽس پيش ڪري ٿو:
- تياري جي جاچ - ايپليڪيشن جي نئين ورزن جي تياري جي جانچ ڪندي (ان کي ٽرئفڪ کي تبديل ڪرڻ لاء)؛
- رولنگ اپڊيٽ - ڪنٽينرز جي ڪلستر ۾ ترتيب واري تصوير تازه ڪاري (بند، تازه ڪاري، لانچ جي تياري، ٽرئفڪ سوئچنگ)؛
- هم وقت سازي تازه ڪاري - هڪ تصوير کي مختلف طريقي سان ڪلستر ۾ اپڊيٽ ڪرڻ: پهرين ڪنٽينرز جي اڌ تي، پوء باقي تي؛
- ڪينري رليز - هڪ نئين تصوير کي لانچ ڪرڻ محدود (ننڍو) ڪنٽينرز تي بي ضابطگين جي نگراني ڪرڻ لاءِ.
جيئن ته مسلسل ترسيل نه رڳو هڪ نئين ورزن جو رليز آهي، ڪبرنيٽس وٽ بعد ۾ انفراسٽرڪچر جي سار سنڀال لاءِ ڪيتريون ئي صلاحيتون آهن: بلٽ ان مانيٽرنگ ۽ سڀني ڪنٽينرز لاءِ لاگنگ، خودڪار اسڪيلنگ وغيره. اهو سڀ ڪجهه اڳ ۾ ئي ڪم ڪري رهيو آهي ۽ صرف مناسب جي انتظار ۾ آهي. توهان جي عملن ۾ عمل درآمد.
آخري سفارشون
- Docker استعمال ڪريو.
- توھان جي سڀني ضرورتن لاءِ ايپليڪيشنن جون ڊڪر تصويرون ٺاھيو.
- اصول تي عمل ڪريو "انفراسٽرڪچر ڪوڊ آهي."
- گٽ کي ڊڪر سان ڳنڍيو.
- رول آئوٽ جي ترتيب کي منظم ڪريو.
- تيار ٿيل پليٽ فارم استعمال ڪريو (Kubernetes يا ٻيو).
وڊيوز ۽ سلائڊ
ڪارڪردگي کان وڊيو (اٽڪل هڪ ڪلاڪ) (رپورٽ پاڻ 5 منٽ کان شروع ٿئي ٿي - هن پل کان کيڏڻ لاءِ لنڪ جي پيروي ڪريو).
رپورٽ جي پيشڪش:
پي ايس
اسان جي بلاگ تي موضوع تي ٻيون رپورٽون:
- «» (دمتري اسٽولياروف؛ مئي 27، 2019 DevOpsConf تي);
- «» (دمتري اسٽوليروف؛ نومبر 8، 2018 HighLoad++ تي);
- «» (دمتري اسٽوليروف؛ نومبر 7، 2017 HighLoad++ تي);
- «» (دمتري اسٽولياروف؛ 6 جون، 2017 تي RootConf).
جو ذريعو: www.habr.com