توھان ھاڻي ٺاھي سگھوٿا ڊاڪر تصويرون werf ۾ باقاعده Dockerfile استعمال ڪندي

ڪڏهن به دير کان بهتر. يا ڪيئن اسان تقريبن هڪ سنگين غلطي ڪئي آهي باقاعده ڊاڪرفائلس لاءِ سپورٽ نه هجڻ ڪري ايپليڪيشن تصويرون ٺاهڻ لاءِ.

اسان بابت ڳالهائينداسين werf - GitOps افاديت جيڪا ڪنهن به CI/CD سسٽم سان ضم ٿي ٿي ۽ پوري ايپليڪيشن لائف سائيڪل جو انتظام مهيا ڪري ٿي، اجازت ڏئي ٿي:

• تصويرون گڏ ڪرڻ ۽ شايع ڪرڻ،
• Kubernetes ۾ ايپليڪيشنن کي ترتيب ڏيو،
• خاص پاليسيون استعمال ڪندي غير استعمال ٿيل تصويرون حذف ڪريو.

پروجيڪٽ جو فلسفو گهٽ سطحي اوزار گڏ ڪرڻ آهي هڪ واحد متحد سسٽم ۾ جيڪو DevOps انجنيئرن کي ايپليڪيشنن تي ڪنٽرول ڏئي ٿو. جيڪڏهن ممڪن هجي، موجوده افاديت (جهڙوڪ هيلم ۽ ڊڪر) استعمال ٿيڻ گهرجي. جيڪڏهن ڪنهن مسئلي جو حل نه آهي، ته اسان ان لاءِ گهربل هر شي ٺاهي ۽ سپورٽ ڪري سگهون ٿا.

پس منظر: توهان جي پنهنجي تصوير ڪليڪٽر

اھو اھو آھي جيڪو werf ۾ تصويري ڪليڪٽر سان ٿيو: عام ڊاکرفائل اسان لاءِ ڪافي نه ھو. جيڪڏهن توهان پروجيڪٽ جي تاريخ تي هڪ تڪڙو نظر وٺو، اهو مسئلو اڳ ۾ ئي werf جي پهرين نسخن ۾ ظاهر ٿيو (پوء اڃا تائين. ڊيپ طور سڃاتو وڃي ٿو).

ڊاڪر تصويرن ۾ ايپليڪيشنن کي تعمير ڪرڻ لاء هڪ اوزار ٺاهڻ دوران، اسان جلدي محسوس ڪيو ته Dockerfile اسان لاء ڪجهه خاص ڪمن لاء مناسب نه هو.

1. هيٺين معياري اسڪيم جي مطابق عام ننڍيون ويب ايپليڪيشنون ٺاهڻ جي ضرورت آهي:
   • انسٽال ڪريو سسٽم جي وسيع ايپليڪيشن انحصار،
   • ايپليڪيشن انحصار لائبريرين جو هڪ بنڊل انسٽال ڪريو،
   • اثاثا گڏ ڪرڻ،
   • ۽ سڀ کان اهم، تصوير ۾ ڪوڊ کي جلدي ۽ موثر طور تي تازه ڪاري ڪريو.
2. جڏهن پروجيڪٽ فائلن ۾ تبديليون ڪيون وينديون آهن، بلڊر کي لازمي طور تي تبديل ٿيل فائلن تي پيچ لاڳو ڪندي هڪ نئين پرت ٺاهڻ گهرجي.
3. جيڪڏهن ڪجهه فائلون تبديل ٿي ويون آهن، پوء اهو ضروري آهي ته لاڳاپيل منحصر اسٽيج کي ٻيهر تعمير ڪيو وڃي.

اڄ اسان جي ڪليڪٽر وٽ ٻيا به ڪيترائي امڪان آهن، پر اهي ابتدائي خواهشون ۽ خواهشون هيون.

عام طور تي، ٻه ڀيرا سوچڻ کان سواء، اسان پاڻ کي هٿياربند ڪيو پروگرامنگ ٻولي سان جيڪو اسان استعمال ڪيو (هيٺ ڏسو) ۽ عمل ڪرڻ لاء روڊ کي مارو ذاتي DSL! مقصدن جي مطابق، ان جو مقصد اسٽيج ۾ اسيمبلي جي عمل کي بيان ڪرڻ ۽ فائلن تي انهن مرحلن جي انحصار کي طئي ڪرڻ جو ارادو ڪيو ويو. ۽ ان کي مڪمل ڪيو پنهنجو ڪليڪٽر، جنهن DSL کي فائنل گول ۾ تبديل ڪيو - گڏ ڪيل تصوير. پهرين تي DSL روبي ۾ هو، پر جيئن Golang ڏانهن منتقلي - اسان جي ڪليڪٽر جي ترتيب کي YAML فائل ۾ بيان ڪرڻ شروع ڪيو.

روبي ۾ ڊيپ لاءِ پراڻي ترتيب

YAML تي werf لاء موجوده ترتيب

وقت سان گڏ ڪليڪٽر جو ميکانيزم به تبديل ٿيو. پهرين ۾، اسان صرف اسان جي ترتيب مان اڏامي تي هڪ عارضي Dockerfile ٺاهي، ۽ پوء اسان عارضي ڪنٽينرز ۾ اسيمبليء جي هدايتن کي هلائڻ شروع ڪيو ۽ ڪم ڪيو.

NB: هن وقت، اسان جو ڪليڪٽر، جيڪو پنهنجي ترتيب سان ڪم ڪري ٿو (YAML ۾) ۽ سڏيو ويندو آهي اسٽيپل ڪليڪٽر، اڳ ۾ ئي هڪ انتهائي طاقتور اوزار ۾ ترقي ڪري چڪو آهي. ان جي تفصيلي وضاحت الڳ مضمونن جي لائق آهي، ۽ بنيادي تفصيل ۾ ڳولي سگهجن ٿا دستاويز.

مسئلي جي آگاهي

پر اسان محسوس ڪيو، ۽ فوري طور تي نه، ته اسان هڪ غلطي ڪئي هئي: اسان قابليت شامل نه ڪيو معياري Dockerfile ذريعي تصويرون ٺاهيو ۽ انهن کي هڪ ئي آخر کان آخر تائين ايپليڪيشن مينيجمينٽ انفراسٽرڪچر ۾ ضم ڪريو (يعني تصويرون گڏ ڪريو، ترتيب ڏيو ۽ صاف ڪريو). اهو ڪيئن ممڪن ٿي سگهي ٿو ته ڪبرنيٽس ۾ تعیناتي لاءِ هڪ اوزار ٺاهيو ۽ Dockerfile سپورٽ تي عمل نه ڪيو وڃي، يعني. اڪثر منصوبن لاءِ تصويرون بيان ڪرڻ جو معياري طريقو؟

هن سوال جو جواب ڏيڻ بدران، اسان هڪ حل پيش ڪندا آهيون. ڇا جيڪڏهن توهان وٽ اڳ ۾ ئي هڪ Dockerfile آهي (يا Dockerfiles جو هڪ سيٽ) ۽ werf استعمال ڪرڻ چاهيو ٿا؟

NB: رستي جي ذريعي، توهان به werf استعمال ڪرڻ چاهيندا آهيو؟ مکيه خاصيتون هيٺ ڏنل آهن:

• تصوير جي صفائي سميت مڪمل ايپليڪيشن مينيجمينٽ چڪر؛
• ڪيترن ئي تصويرن جي اسيمبلي کي منظم ڪرڻ جي صلاحيت هڪ ئي وقت ۾ هڪ ترتيب کان؛
• هيلم سان مطابقت رکندڙ چارٽس لاءِ بهتر ترتيب ڏيڻ وارو عمل.

انهن جي هڪ وڌيڪ مڪمل فهرست ڏسي سگهجي ٿو منصوبي جو صفحو.

تنهن ڪري، جيڪڏهن اڳ ۾ اسان کي پيش ڪيو وڃي ها Dockerfile کي ٻيهر لکڻ جي اسان جي ترتيب ۾، هاڻي اسان خوشيء سان چونداسين: "اچو ته توهان جي ڊاکرفائل کي تعمير ڪريو!"

ڪئين استعمال ڪجي

هن خصوصيت جي مڪمل عمل درآمد ۾ ظاهر ٿيو werf v1.0.3-beta.1. عام اصول سادو آهي: صارف werf config ۾ موجود Dockerfile جو رستو بيان ڪري ٿو، ۽ پوءِ حڪم هلائي ٿو werf build... ۽ اھو اھو آھي - ورف تصوير کي گڏ ڪندو. اچو ته هڪ خلاصو مثال ڏسو.

اچو ته ايندڙ جو اعلان ڪريون Dockerfile منصوبي جي روٽ ۾:

FROM ubuntu:18.04
RUN echo Building ...

۽ اعلان ڪنداسين werf.yamlجيڪو هن کي استعمال ڪري ٿو Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

سڀ! کاٻو ڀ run werf build:

ان کان علاوه، توھان ھيٺ ڏنل بيان ڪري سگھو ٿا werf.yaml هڪ ئي وقت ۾ مختلف Dockerfiles مان ڪيترائي تصويرون ٺاهڻ لاءِ:

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

آخرڪار، اهو پڻ اضافي تعميراتي پيٽرولن کي پاس ڪرڻ جي حمايت ڪري ٿو، جهڙوڪ --build-arg и --add-host - werf config ذريعي. Dockerfile تصوير جي تشڪيل جي مڪمل وضاحت تي دستياب آهي دستاويز صفحو.

ان کي ڪيئن ڪم ڪندو؟

تعمير جي عمل دوران، ڊاکر جي ڪم ۾ مقامي تہن جي معياري ڪيش. بهرحال، ڇا ضروري آهي ته werf پڻ Dockerfile ترتيبن کي ان جي انفراسٽرڪچر ۾ ضم ڪري ٿو. هن جو مطلب ڇا آهي؟

1. Dockerfile مان ٺهيل هر تصوير هڪ اسٽيج تي مشتمل آهي جنهن کي سڏيو ويندو آهي dockerfile (توهان وڌيڪ پڙهي سگهو ٿا ته ڪهڙا مرحلا werf ۾ آهن هتي).
2. اسٽيج لاء dockerfile werf هڪ دستخط جو حساب ڪري ٿو جيڪو Dockerfile ترتيب جي مواد تي منحصر آهي. جڏهن Dockerfile ٺاھ جوڙ تبديل ٿي، اسٽيج دستخط تبديل ٿي dockerfile ۽ werf هن اسٽيج جي ٻيهر تعمير کي نئين ڊاکرفائل ترتيب سان شروع ڪري ٿو. جيڪڏهن دستخط تبديل نه ٿئي، پوء werf تصوير کي ڪيش مان وٺي ٿو (ورف ۾ دستخط جي استعمال بابت وڌيڪ تفصيل بيان ڪيا ويا آهن هن رپورٽ).
3. اڳيون، گڏ ڪيل تصويرون حڪم سان شايع ڪري سگھجن ٿيون werf publish (يا werf build-and-publish) ۽ ان کي استعمال ڪريو ڪبرنيٽس تائين پهچائڻ لاءِ. ڊاڪر رجسٽري ۾ شايع ٿيل تصويرون معياري ويرف صاف ڪرڻ وارو اوزار استعمال ڪندي صاف ڪيون وينديون، يعني. پراڻيون تصويرون (N ڏينهن کان وڌيڪ پراڻا)، غير موجود Git شاخن سان لاڳاپيل تصويرون، ۽ ٻيون پاليسيون خودڪار طريقي سان صاف ٿي وينديون.

هتي بيان ڪيل نقطن بابت وڌيڪ تفصيل دستاويزن ۾ ڳولهي سگهجن ٿا:

• اشاعت جي عمل;
• ڪبرنيٽس جي ٺهڻ واري عمل سان انضمام;
• صفائي جي عمل.

نوٽس ۽ احتياط

1. خارجي URL ADD ۾ سپورٽ نه آهي

في الحال اهو هڪ خارجي URL کي هدايت ۾ استعمال ڪرڻ جي حمايت ناهي ADD. Werf هڪ ٻيهر تعمير شروع نه ڪندو جڏهن وسيلو مخصوص URL تي تبديل ٿي ويندو. اسان جلد ئي ھن خصوصيت کي شامل ڪرڻ جو ارادو رکون ٿا.

2. توھان تصوير ۾ .git شامل نٿا ڪري سگھو

عام طور تي ڳالهائڻ، ڊاريڪٽري شامل ڪرڻ .git تصوير ۾ - هڪ خراب خراب عمل ۽ هتي ڇو آهي:

1. ته .git آخري تصوير ۾ رهي ٿو، اهو اصولن جي ڀڃڪڙي ڪري ٿو 12 فيڪٽر ايپ: جيئن ته حتمي تصوير هڪ واحد ڪمٽ سان ڳنڍيل هجڻ گهرجي، اهو ڪرڻ ممڪن ناهي git checkout من پسند انجام.
2. .git تصوير جي سائيز کي وڌائي ٿو (مخزن وڏي ٿي سگهي ٿو ڇاڪاڻ ته وڏيون فائلون هڪ ڀيرو ان ۾ شامل ڪيون ويون آهن ۽ پوءِ ختم ڪيون ويون آهن). ڪم جي وڻ جي سائيز صرف هڪ مخصوص ڪمٽ سان لاڳاپيل نه هوندي Git ۾ آپريشن جي تاريخ تي. انهي حالت ۾، اضافي ۽ بعد ۾ هٽائڻ .git حتمي تصوير کان ڪم نه ڪندي: تصوير اڃا تائين هڪ اضافي پرت حاصل ڪندي - هي ڪيئن ڪم ڪندو آهي Docker.
3. ڊاکر هڪ غير ضروري ٻيهر تعمير شروع ڪري سگهي ٿو، جيتوڻيڪ ساڳيو ڪم تعمير ڪيو پيو وڃي، پر مختلف ڪم جي وڻن کان. مثال طور، GitLab ٺاهي ٿو الڳ ڪلون ڊائريڪٽرن ۾ /home/gitlab-runner/builds/HASH/[0-N]/yourproject جڏهن متوازي اسيمبلي کي فعال ڪيو وڃي. اضافي reassembly حقيقت جي ڪري ٿي ويندي ڊاريڪٽري .git ساڳي مخزن جي مختلف ڪلون ٿيل نسخن ۾ مختلف آهي، جيتوڻيڪ ساڳي ڪمٽ تعمير ٿيل آهي.

آخري نقطو پڻ نتيجا آهي جڏهن werf استعمال ڪندي. Werf جي ضرورت آهي ته تعمير ٿيل ڪيش موجود هجي جڏهن ڪجهه حڪم هلائي رهيا آهن (مثال طور. werf deploy). جڏهن اهي حڪم هلندا آهن، werf ۾ بيان ڪيل تصويرن لاء اسٽيج جي دستخط جي حساب سان werf.yaml، ۽ اهي لازمي طور تي اسيمبلي جي ڪيش ۾ هجن - ٻي صورت ۾ حڪم ڪم جاري رکڻ جي قابل نه هوندا. جيڪڏهن اسٽيج جي دستخط مواد تي منحصر آهي .git، پوءِ اسان کي هڪ ڪيش ملي ٿو جيڪو غير لاڳاپيل فائلن ۾ تبديلين لاءِ غير مستحڪم آهي، ۽ ويرف اهڙي نگراني کي معاف نه ڪري سگهندو (وڌيڪ تفصيل لاءِ، ڏسو دستاويز).

مجموعي طور تي صرف ڪجهه ضروري فائلون شامل ڪرڻ هدايتن جي ذريعي ADD ڪنهن به صورت ۾ تحريري جي ڪارڪردگي ۽ اعتبار وڌائي ٿو Dockerfile، ۽ انهي لاءِ گڏ ڪيل ڪيش جي استحڪام کي پڻ بهتر بڻائي ٿو Dockerfile, Git ۾ غير لاڳاپيل تبديلين لاء.

نتيجو

اسان جي پنهنجي بلڊر کي مخصوص ضرورتن لاءِ لکڻ لاءِ اسان جو شروعاتي رستو سخت، ايماندار ۽ سڌو هو: معياري ڊاڪرفائل جي مٿان ڪڇ استعمال ڪرڻ بدران، اسان پنهنجو حل ڪسٽم نحو سان لکيو. ۽ هن جا فائدا هئا: اسٽيپل ڪليڪٽر پنهنجي ڪم سان مڪمل طور تي نقل ڪري ٿو.

بهرحال، اسان جي پنهنجي بلڊر کي لکڻ جي عمل ۾، اسان موجوده ڊاکرفائلس جي حمايت جي نظر کي وڃائي ڇڏيو. اهو نقص هاڻي طئي ڪيو ويو آهي، ۽ مستقبل ۾ اسان ڊاڪر فائل سپورٽ کي ترقي ڪرڻ جو منصوبو ٺاهيون ٿا اسان جي ڪسٽم اسٽيپل بلڊر سان گڏ تقسيم ٿيل تعميرن لاءِ ۽ تعميرات لاءِ ڪبرنيٽس استعمال ڪندي (يعني ڪبرنيٽس اندر رنرن تي ٺاهي ٿو، جيئن ڪنيڪو ۾ ڪيو ويندو آهي).

تنهن ڪري، جيڪڏهن توهان وٽ اوچتو ڪجهه ڊاکرفائلس ڀرسان بيٺل آهن ... ڪوشش ڪر werf!

پي ايس موضوع تي دستاويزن جي فهرست

• ھدايتون تڪڙو شروع ڪرڻ لاءِ;
• dockerfile بلڊر ترتيبون;
• اسٽيج ڊوائيس werf ۾;
• تصوير جي اشاعت جو عمل;
• ڪبرنيٽس جي ٺهڻ واري عمل سان انضمام;
• صفائي جي عمل;
• اسٽيپل بلڊر ڊاکرفائل جي متبادل طور.

اسان جي بلاگ ۾ پڻ پڙهو: "werf - ڪبرنيٽس ۾ CI / CD لاءِ اسان جو اوزار (جائزو ۽ وڊيو رپورٽ)».

جو ذريعو: www.habr.com