اسان جي اوپن سورس آهي GitOps CLI يوٽيليٽي بلڊنگ ۽ ڊليوري لاءِ ايپليڪيشنون Kubernetes تائين. IN تصويري ڪليڪٽر ۾ هڪ نئون فيچر متعارف ڪرايو ويو: مواد جي ذريعي تصويرن کي ٽيگ ڪرڻ يا مواد تي ٻڌل ٽيگنگ. هينئر تائين، ويرف ۾ عام ٽيگنگ اسڪيم شامل آهي ڊاڪر تصويرون کي گيٽ ٽيگ، گيٽ برانچ يا گٽ ڪمٽ ذريعي ٽيگ ڪرڻ. پر انهن سڀني منصوبن ۾ نقصان آهن جيڪي مڪمل طور تي نئين ٽيگنگ حڪمت عملي ذريعي حل ڪيا ويا آهن. ان جي باري ۾ تفصيل ۽ ڇو اهو تمام سٺو آهي ڪٽي هيٺ آهن.
هڪ Git مخزن مان مائڪرو سروسز جو هڪ سيٽ رولنگ
هڪ صورتحال اڪثر ٿئي ٿي جڏهن هڪ ايپليڪيشن ڪيترن ئي وڌيڪ يا گهٽ آزاد خدمتن ۾ ورهايل آهي. انهن خدمتن جي رليز آزاديء سان ٿي سگهي ٿي: هڪ وقت ۾ هڪ يا وڌيڪ خدمتون جاري ڪري سگھجن ٿيون، جڏهن ته باقي ڪنهن به تبديلي کان سواء ڪم جاري رکڻ گهرجي. پر ڪوڊ اسٽوريج ۽ پروجيڪٽ مينيجمينٽ جي نقطي نظر کان، اهڙي ايپليڪيشن سروسز کي هڪ مخزن ۾ رکڻ لاء وڌيڪ آسان آهي.
حالتون آهن جڏهن خدمتون حقيقي طور تي آزاد آهن ۽ هڪ واحد ايپليڪيشن سان لاڳاپيل نه آهن. انهي صورت ۾، اهي الڳ پروجيڪٽ ۾ واقع هوندا ۽ انهن جي رليز هر منصوبي ۾ الڳ CI/CD پروسيس ذريعي ڪئي ويندي.
جڏهن ته، حقيقت ۾، ڊولپر اڪثر ڪري هڪ واحد ايپليڪيشن کي ڪيترن ئي microservices ۾ ورهائيندا آهن، پر هر هڪ لاء هڪ الڳ مخزن ۽ پروجيڪٽ ٺاهڻ ... هڪ واضح اوورڪيل آهي. اها اها صورتحال آهي جنهن تي وڌيڪ بحث ڪيو ويندو: ڪيتريون ئي اهڙيون مائڪرو سروسز هڪ واحد پروجيڪٽ جي مخزن ۾ واقع آهن ۽ CI/CD ۾ هڪ واحد عمل ذريعي رليز ٿينديون آهن.
Git برانچ ۽ Git ٽيگ پاران ٽيگنگ
اچو ته سڀ کان وڌيڪ عام ٽيگنگ حڪمت عملي استعمال ڪئي وئي آهي - ٽيگ يا شاخ. Git شاخن لاءِ، تصويرن کي شاخ جي نالي سان ٽيگ ڪيو ويو آھي، ھڪڙي وقت ھڪڙي شاخ لاءِ ھڪڙي ئي ڇپيل تصوير آھي ان شاخ جي نالي سان. Git tags لاءِ، تصويرن کي ٽيگ جي نالي جي مطابق ٽيگ ڪيو ويو آھي.
جڏهن هڪ نئون گٽ ٽيگ ٺاهيو ويندو آهي - مثال طور، جڏهن هڪ نئون نسخو جاري ڪيو ويندو آهي - هڪ نئون ڊاکر ٽيگ ٺاهيو ويندو سڀني پروجيڪٽ جي تصويرن لاءِ Docker رجسٽري ۾:
-
myregistry.org/myproject/frontend:v1.1.10 -
myregistry.org/myproject/myservice1:v1.1.10 -
myregistry.org/myproject/myservice2:v1.1.10 -
myregistry.org/myproject/myservice3:v1.1.10 -
myregistry.org/myproject/myservice4:v1.1.10 -
myregistry.org/myproject/myservice5:v1.1.10 -
myregistry.org/myproject/database:v1.1.10
اهي نوان تصويري نالا هيلم ٽيمپليٽس ذريعي Kubernetes جي ترتيب ڏانهن منتقل ڪيا ويا آهن. جڏهن حڪم سان ترتيب ڏيڻ شروع ڪيو وڃي werf deploy فيلڊ کي اپڊيٽ ڪيو پيو وڃي image تبديل ٿيل تصوير جي نالي جي ڪري ڪبرنيٽس وسيلا ظاهر ڪري ٿو ۽ لاڳاپيل وسيلن کي ٻيهر شروع ڪري ٿو.
مسئلو: ان صورت ۾ جڏهن، حقيقت ۾، تصوير جو مواد پوئين رول آئوٽ (گٽ ٽيگ) کان تبديل نه ٿيو آهي، پر صرف ان جي ڊڪر ٽيگ، اهو ٿئي ٿو اضافي هن ايپليڪيشن کي ٻيهر شروع ڪرڻ ۽، مطابق، ڪجهه دير جو وقت ممڪن آهي. جيتوڻيڪ هن ريسٽارٽ کي انجام ڏيڻ جو ڪو به حقيقي سبب نه هو.
نتيجي طور، موجوده ٽيگنگ اسڪيم سان ضروري آهي ته ڪيترن ئي الڳ Git ذخيرن کي باهه ڏيڻ ۽ انهن ڪيترن ئي مخزن جي رول آئوٽ کي منظم ڪرڻ جو مسئلو پيدا ٿئي ٿو. عام طور تي، اهڙي منصوبي کي اوورلوڊ ۽ پيچيده ٿي سگهي ٿو. اهو بهتر آهي ته ڪيترن ئي خدمتن کي هڪ واحد مخزن ۾ گڏ ڪيو وڃي ۽ Docker ٽيگ ٺاهيو وڃي ته جيئن ڪو به غير ضروري ٻيهر شروع نه ٿئي.
Git ڪمٽ پاران ٽيگنگ
werf وٽ پڻ هڪ ٽيگنگ حڪمت عملي آهي Git ڪميٽ سان لاڳاپيل.
Git-commit هڪ Git مخزن جي مواد جي سڃاڻپ ڪندڙ آهي ۽ Git مخزن ۾ فائلن جي ترميم جي تاريخ تي منحصر آهي، تنهنڪري اهو منطقي لڳي ٿو ته ان کي ڊاکر رجسٽري ۾ تصويرن کي ٽيگ ڪرڻ لاء استعمال ڪيو وڃي.
جڏهن ته، Git ڪمٽ پاران ٽيگ ڪرڻ جا ساڳيا نقصان آهن جيئن گيٽ شاخن يا گيٽ ٽيگ ذريعي ٽيگنگ:
- هڪ خالي ڪمٽ ٺاهي سگهجي ٿو جيڪا ڪنهن به فائلن کي تبديل نه ڪندي، پر تصوير جي ڊاکر ٽيگ کي تبديل ڪيو ويندو.
- هڪ ضم ڪرڻ جو عزم پيدا ٿي سگهي ٿو جيڪو فائلن کي تبديل نٿو ڪري، پر تصوير جي ڊاکر ٽيگ کي تبديل ڪيو ويندو.
- هڪ انجام ٿي سگهي ٿو ته Git ۾ انهن فائلن کي تبديل ڪري ٿو جيڪي تصوير ۾ درآمد نه ڪيا ويا آهن، ۽ تصوير جي Docker ٽيگ کي ٻيهر تبديل ڪيو ويندو.
Git برانچ جو نالو ٽيگ ڪرڻ تصويري ورزن کي ظاهر نٿو ڪري
گٽ شاخن لاء ٽيگنگ حڪمت عملي سان لاڳاپيل هڪ ٻيو مسئلو آهي.
شاخ جي نالي سان ٽيگنگ ان وقت تائين ڪم ڪري ٿي جيستائين ان شاخ تي ڪمٽٽس ترتيب وار ترتيب سان گڏ ڪيا وڃن.
جيڪڏهن موجوده اسڪيم ۾ صارف هڪ خاص شاخ سان لاڳاپيل هڪ پراڻي ڪمٽ کي ٻيهر تعمير ڪرڻ شروع ڪري ٿو، پوء werf ساڳئي ڊاکر ٽيگ استعمال ڪندي تصوير کي ٻيهر لکندو، پراڻي ڪمٽ لاء تصوير جي نئين ٺهيل ورزن سان. ھاڻي ھاڻي ھن ٽيگ کي استعمال ڪندي ڊبليومينٽس پوڊس کي ٻيهر شروع ڪرڻ وقت تصوير جي مختلف ورزن کي ڇڪڻ جو خطرو آھي، جنھن جي نتيجي ۾ اسان جي ايپليڪيشن جو CI سسٽم سان لاڳاپو ختم ٿي ويندو ۽ غير مطابقت پذير ٿي ويندو.
ان کان علاوه، انهن جي وچ ۾ ٿوري وقت سان گڏ هڪ شاخ ۾ مسلسل ڌڪڻ سان، پراڻي ڪمٽ کي نئين کان بعد ۾ مرتب ڪيو وڃي ٿو: تصوير جو پراڻو نسخو Git برانچ ٽيگ استعمال ڪندي نئين کي مٿي ڪري ڇڏيندو. اهڙا مسئلا CI / CD سسٽم ذريعي حل ڪري سگھجن ٿا (مثال طور، GitLab CI ۾ بعد ۾ پائپ لائن ڪمن جي هڪ سيريز لاءِ شروع ڪئي وئي آهي). بهرحال، سڀئي سسٽم هن جي حمايت نٿا ڪن ۽ اهڙي بنيادي مسئلي کي روڪڻ لاء هڪ وڌيڪ قابل اعتماد طريقو هجڻ گهرجي.
مواد تي ٻڌل ٽيگنگ ڇا آهي؟
تنهن ڪري، مواد جي بنياد تي ٽيگنگ ڇا آهي - مواد طرفان تصويرون ٽيگنگ.
ڊاڪر ٽيگ ٺاهڻ لاءِ، اهو نه آهي Git primitives (Git برانچ، Git tag...) جيڪي استعمال ڪيا وڃن ٿا، پر هڪ چيڪسم سان جڙيل آهي:
- تصوير جو مواد. تصوير جي سڃاڻپ ٽيگ ان جي مواد کي ظاهر ڪري ٿو. جڏهن هڪ نئون نسخو ٺاهيندي، اهو سڃاڻپ ڪندڙ تبديل نه ٿيندو جيڪڏهن تصوير ۾ فائلون تبديل نه ڪيون آهن؛
- Git ۾ هن تصوير ٺاهڻ جي تاريخ. مختلف Git شاخن سان لاڳاپيل تصويرون ۽ مختلف تعمير جي تاريخ werf ذريعي مختلف ID ٽيگ هونديون.
اهڙي سڃاڻپ ڪندڙ ٽيگ کي سڏيو ويندو آهي تصوير اسٽيج جي دستخط.
هر تصوير مرحلن جي هڪ سيٽ تي مشتمل آهي: from, before-install, git-archive, install, imports-after-install, before-setup... git-latest-patch وغيره هر اسٽيج ۾ هڪ سڃاڻپ ڪندڙ هوندو آهي جيڪو ان جي مواد کي ظاهر ڪري ٿو - اسٽيج دستخط (اسٽيج دستخط).
آخري تصوير، انهن مرحلن تي مشتمل آهي، انهن مرحلن جي سيٽ جي نام نهاد دستخط سان ٽيگ ٿيل آهي - مرحلو دستخط، - جيڪا تصوير جي سڀني مرحلن لاءِ عام ٿي رهي آهي.
ترتيب مان هر تصوير لاء werf.yaml عام صورت ۾، اتي ان جي پنهنجي دستخط هوندي ۽، مطابق، هڪ Docker ٽيگ.
اسٽيج دستخط انهن سڀني مسئلن کي حل ڪري ٿو:
- خالي Git ڪمن جي مزاحمتي.
- Git جي خلاف مزاحمت ڪندڙ جيڪي فائلون تبديل ڪن ٿيون جيڪي تصوير سان لاڳاپيل نه آهن.
- تصوير جي موجوده ورزن کي ختم ڪرڻ جو مسئلو پيدا نٿو ٿئي جڏهن برانچ جي پراڻي گٽ ڪمٽس لاءِ تعميرات کي ٻيهر شروع ڪيو وڃي.
ھاڻي ھاڻي تجويز ڪيل ٽيگنگ حڪمت عملي آھي ۽ سڀني CI سسٽم لاءِ werf ۾ ڊفالٽ آھي.
werf ۾ ڪيئن فعال ۽ استعمال ڪجي
حڪم هاڻي هڪ لاڳاپيل اختيار آهي werf publish: --tag-by-stages-signature=true|false
هڪ CI سسٽم ۾، ٽيگنگ حڪمت عملي حڪم طرفان بيان ڪئي وئي آهي werf ci-env. اڳي ئي، ان لاءِ وضاحت ڪئي وئي هئي werf ci-env --tagging-strategy=tag-or-branch. هاڻي، جيڪڏهن توهان وضاحت ڪريو werf ci-env --tagging-strategy=stages-signature يا هي اختيار بيان نه ڪريو، werf ڊفالٽ طور تي ٽيگنگ حڪمت عملي استعمال ڪندو stages-signature. ٽيم werf ci-env خودڪار طور تي حڪم لاء ضروري جھنڊو مقرر ڪندو werf build-and-publish (يا werf publish)، تنهنڪري انهن حڪمن لاء اضافي اختيارن جي وضاحت ڪرڻ جي ضرورت ناهي.
مثال طور، حڪم:
werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature... ھيٺيون تصويرون ٺاھي سگھو ٿا:
-
registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d -
registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6
اهو آهي 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d تصوير جي مرحلن جو هڪ دستخط آهي backend۽ f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - تصوير جي مرحلن جي دستخط frontend.
جڏهن خاص فنڪشن استعمال ڪندي werf_container_image и werf_container_env هيلم ٽيمپليٽس ۾ ڪجھ به تبديل ڪرڻ جي ڪا ضرورت ناهي: اهي فنڪشن خودڪار طور تي صحيح تصوير جا نالا ٺاهيندا.
مثال CI سسٽم ۾ ٺاھ جوڙ:
type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deployتشڪيل تي وڌيڪ معلومات دستاويز ۾ موجود آهي:
- ;
- ;
- .
ڪل
- نئون اختيار
werf publish --tag-by-stages-signature=true|false. - نئين اختيارن جو قدر
werf ci-env --tagging-strategy=stages-signature|tag-or-branch(جيڪڏهن بيان نه ڪيو ويو آهي، ڊفالٽ ٿيندوstages-signature). - جيڪڏهن توهان اڳ ۾ استعمال ڪيو ٽيگنگ جا آپشن گيٽ ڪمٽس لاءِ (
WERF_TAG_GIT_COMMITيا اختيارwerf publish --tag-git-commit COMMIT)، پوء پڪ ڪريو ته ٽيگنگ حڪمت عملي تي سوئچ ڪريو مرحلو- دستخط. - اهو بهتر آهي ته فوري طور تي نئين منصوبن کي نئين ٽيگنگ اسڪيم ڏانهن تبديل ڪيو وڃي.
- جڏهن werf 1.1 ڏانهن منتقل ڪيو وڃي، اهو مشورو ڏنو ويو آهي ته پراڻن منصوبن کي نئين ٽيگنگ اسڪيم ڏانهن تبديل ڪيو وڃي، پر پراڻي ٽيگ يا شاخ اڃا تائين سپورٽ آهي.
مواد تي ٻڌل ٽيگنگ آرٽيڪل ۾ شامل ڪيل سڀني مسئلن کي حل ڪري ٿي:
- ڊاکر ٽيگ جو نالو مزاحمت خالي Git ڪمن لاءِ.
- ڊاکر ٽيگ جي نالي جي لچڪ گيٽ کي ڪم ڪري ٿو جيڪا فائلن کي تبديل ڪري ٿي تصوير سان غير لاڳاپيل.
- تصوير جي موجوده ورزن کي ختم ڪرڻ جي مسئلي جي اڳواڻي نه ڪندو آهي جڏهن گيٽ شاخن لاءِ پراڻي گٽ ڪمٽس لاءِ تعميرات کي ٻيهر شروع ڪندي.
ان کي استعمال ڪريو! ۽ اسان جو دورو ڪرڻ نه وساريو مسئلو پيدا ڪرڻ يا موجوده هڪ ڳولڻ لاءِ، هڪ پلس شامل ڪريو، هڪ پي آر ٺاهيو يا صرف پروجيڪٽ جي ترقي کي ڏسو.
پي ايس
اسان جي بلاگ تي پڻ پڙهو:
- «»
- «»
- «"؛
- werf ۾ جدت بابت نوٽس جو هڪ سلسلو:
- «"؛
- «"؛
- «"؛
- «».
جو ذريعو: www.habr.com