Kubernetes ته د غوښتنلیکونو جوړولو او رسولو لپاره زموږ د خلاصې سرچینې GitOps CLI افادیت دی. IN د عکس راټولونکي کې یو نوی خصوصیت معرفي شو: د مینځپانګې لخوا د عکسونو نښه کول یا د منځپانګې پر بنسټ نښه کول. تر دې دمه ، په ویرف کې د ټاګ کولو ځانګړي سکیم کې د ګیټ ټګ ، ګیټ برانچ یا ګیټ کمیټ لخوا د ډاکر عکسونو ټګ کول شامل دي. مګر دا ټول سکیمونه نیمګړتیاوې لري چې په بشپړ ډول د نوي ټیګ کولو ستراتیژۍ لخوا حل شوي. د دې په اړه توضیحات او ولې دا خورا ښه دی د کټ لاندې دي.
د یو Git ذخیره څخه د مایکرو خدماتو سیټ رول کول
یو حالت اکثرا هغه وخت پیښیږي کله چې غوښتنلیک په ډیری یا لږ خپلواک خدماتو ویشل کیږي. د دې خدماتو خوشې کول په خپلواک ډول پیښ کیدی شي: یو یا څو خدمتونه په یو وخت کې خوشې کیدی شي، پداسې حال کې چې پاتې باید پرته له کوم بدلون څخه کار ته دوام ورکړي. مګر د کوډ ذخیره کولو او پروژې مدیریت له نظره ، دا خورا اسانه دی چې دا ډول غوښتنلیک خدمات په یو واحد ذخیره کې وساتئ.
داسې شرایط شتون لري کله چې خدمتونه واقعیا خپلواک وي او د یو واحد غوښتنلیک سره تړاو نلري. په دې حالت کې، دوی به په جلا پروژو کې موقعیت ولري او د دوی خوشې کول به په هره پروژه کې د جلا CI/CD پروسو له لارې ترسره شي.
په هرصورت، په واقعیت کې، پراختیا کونکي اکثرا یو واحد غوښتنلیک په څو مایکرو سرویسونو ویشي، مګر د هر یو لپاره جلا ذخیره او پروژه رامینځته کول ... یو روښانه حد دی. دا هغه وضعیت دی چې نور به پرې بحث وشي: ډیری داسې مایکرو خدمتونه په یوه واحد پروژه ذخیره کې موقعیت لري او خوشې کول په CI/CD کې د یوې پروسې له لارې پیښیږي.
د Git څانګې او Git ټاګ لخوا نښه کول
راځئ چې ووایو د ټاګ کولو ترټولو عام ستراتیژي کارول کیږي - ټګ یا څانګه. د ګیټ څانګو لپاره ، عکسونه د څانګې نوم سره ټګ شوي ، د یوې څانګې لپاره په یو وخت کې د دې څانګې په نوم یوازې یو خپور شوی عکس شتون لري. د Git ټاګونو لپاره ، عکسونه د ټاګ نوم سره سم ټګ شوي.
کله چې نوی ګیټ ټاګ رامینځته شي - د مثال په توګه ، کله چې نوې نسخه خپره شي - د ډاکر راجسټری کې د پروژې ټولو عکسونو لپاره به نوی ډاکر ټاګ رامینځته شي:
-
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
د دې نوي عکس نومونه د هیلم ټیمپلیټونو له لارې د کبرنیټس ترتیب ته لیږدول شوي. کله چې د قوماندې سره ګمارل پیل کړئ werf deploy ساحه تازه کیږي image په Kubernetes کې سرچینې د بدل شوي عکس نوم له امله اړونده سرچینې څرګندوي او بیا پیل کوي.
ستونزه: په هغه حالت کې چې په حقیقت کې د عکس مینځپانګه د تیر رول آوټ (Git ټاګ) راهیسې نه بدله شوې ، مګر یوازې د دې ډاکر ټاګ ، دا پیښیږي اضافي د دې غوښتنلیک بیا پیل کول او په وینا، یو څه ځنډ ممکن دی. که څه هم د دې بیا پیل کولو لپاره هیڅ ریښتینی دلیل شتون نلري.
د پایلې په توګه ، د اوسني ټاګینګ سکیم سره دا اړینه ده چې څو جلا Git ذخیره کټاره شي او ستونزه د دې څو ذخیره کولو تنظیم کولو تنظیم کولو کې رامینځته کیږي. په عموم کې، دا ډول سکیم ډیر بار او پیچلی دی. دا غوره ده چې ډیری خدمات په یو واحد ذخیره کې یوځای کړئ او د ډاکر ټاګونه رامینځته کړئ ترڅو هیڅ غیر ضروري بیا پیل نشي.
د ګیټ ژمنې لخوا نښه کول
werf د ګیټ کمیټ سره تړلې د ټاګ کولو ستراتیژي هم لري.
Git-commit د Git ذخیره کولو مینځپانګو لپاره پیژندونکی دی او د Git ذخیره کې د فایلونو ترمیم تاریخ پورې اړه لري ، نو دا منطقي بریښي چې دا د ډاکر راجسټري کې د عکسونو ټګ کولو لپاره وکاروئ.
په هرصورت ، د ګیټ کمیټ لخوا ټاګ کول ورته زیانونه لري لکه د Git څانګو یا Git ټاګونو لخوا ټاګ کول:
- یو خالي ژمنې رامینځته کیدی شي چې هیڅ فایلونه نه بدلوي ، مګر د عکس ډاکر ټاګ به بدل شي.
- د ادغام ژمنې رامینځته کیدی شي چې فایلونه نه بدلوي ، مګر د عکس ډاکر ټاګ به بدل شي.
- یو ژمنتیا رامینځته کیدی شي چې په Git کې هغه فایلونه بدل کړي چې عکس ته نه وارد شوي ، او د عکس ډاکر ټاګ به بیا بدل شي.
د ګیټ څانګې نوم ټګ کول د عکس نسخه نه منعکس کوي
د Git څانګو لپاره د ټاګ کولو ستراتیژۍ سره تړلې بله ستونزه شتون لري.
د څانګې نوم په واسطه نښه کول تر هغه وخته کار کوي چې په دې څانګه کې ژمنې په ترتیب سره په تاریخي ترتیب کې راټول شوي وي.
که چیرې په اوسني سکیم کې کاروونکي د یوې ټاکلې څانګې سره تړلې زاړه ژمنې بیا رغول پیل کړي، نو بیا به werf د ورته ډاکر ټاګ په کارولو سره د زاړه ژمنې لپاره د عکس نوي جوړ شوي نسخه سره انځور بیا لیکي. له اوس څخه د دې ټاګ په کارولو سره ګمارل د پوډونو بیا پیل کولو پر مهال د عکس مختلف نسخه ایستلو خطر پرمخ وړي ، چې په پایله کې به زموږ غوښتنلیک د CI سیسټم سره اړیکه له لاسه ورکړي او غیر همغږي شي.
سربیره پردې ، د دوی ترمینځ د لنډې مودې سره یوې څانګې ته د پرله پسې فشارونو سره ، زوړ ژمنتیا ممکن د نوي څخه وروسته تالیف شي: د عکس زوړ نسخه به د ګیټ برانچ ټاګ په کارولو سره نوی له سره لیکي. دا ډول ستونزې د CI/CD سیسټم لخوا حل کیدی شي (د مثال په توګه ، په GitLab CI کې د وروستي پایپ لاین د یو لړ ژمنو لپاره پیل شوی). په هرصورت، ټول سیسټمونه د دې ملاتړ نه کوي او د داسې بنسټیزې ستونزې د مخنیوي لپاره باید د باور وړ لاره وي.
د منځپانګې پر بنسټ ټګنګ څه شی دی؟
نو، د منځپانګې پر بنسټ ټګنګ څه شی دی - د منځپانګې په واسطه د انځورونو ټګ کول.
د ډاکر ټاګونو رامینځته کولو لپاره ، دا د Git لومړني (Git برانچ ، Git ټاګ ...) ندي چې کارول کیږي ، مګر یو چیکسم چې ورسره تړاو لري:
- د انځور منځپانګه. د عکس ID ټګ د هغې مینځپانګه منعکس کوي. کله چې نوې نسخه جوړه کړئ، دا پیژندونکی به بدل نشي که چیرې په عکس کې فایلونه بدل شوي نه وي؛
- په ګیټ کې د دې عکس رامینځته کولو تاریخ. د مختلف Git څانګو سره تړلي عکسونه او د werf له لارې مختلف جوړ تاریخ به مختلف ID ټاګونه ولري.
دا ډول پیژندونکی ټاګ ورته ویل کیږي د عکس مرحله لاسلیک.
هر انځور د پړاوونو سیټ لري: from, before-install, git-archive, install, imports-after-install, before-setup، ... git-latest-patch etc هره مرحله یو پیژندونکی لري چې د هغې مینځپانګې منعکس کوي - مرحله لاسلیک (د مرحلې لاسلیک).
وروستی انځور، چې د دې مرحلو څخه جوړ دی، د دې مرحلو د سیټ د تش په نامه لاسلیک سره نښه شوی - مرحلې لاسلیک، - کوم چې د عکس ټولو مرحلو لپاره عمومي کول دي.
د ترتیب څخه د هر عکس لپاره werf.yaml په عمومي حالت کې، هلته به خپل لاسلیک وي او په وینا، د ډاکر ټاګ.
د مرحلې لاسلیک دا ټولې ستونزې حل کوي:
- د خالي 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). - که تاسو دمخه د Git ژمنو لپاره د ټاګ کولو اختیارونه کارولي وي (
WERF_TAG_GIT_COMMITیا اختیارwerf publish --tag-git-commit COMMIT)، بیا ډاډه اوسئ چې د ټاګ کولو ستراتیژۍ ته لاړشئ مرحلې - لاسلیک. - دا غوره ده چې سمدلاسه نوې پروژې نوي ټاګ کولو سکیم ته واړوئ.
- کله چې werf 1.1 ته لیږدول کیږي، نو دا مشوره ورکول کیږي چې زاړه پروژې نوي ټاګ کولو سکیم ته واړوئ، مګر زاړه ټګ یا څانګه لا تر اوسه ملاتړ کیږي.
د مینځپانګې پراساس ټاګ کول ټول هغه ستونزې حل کوي چې په مقاله کې پوښل شوي:
- د ډاکر ټاګ نوم د خالي ګیټ ژمنو لپاره مقاومت.
- Git ته د ډاکر ټاګ نوم انعطاف ژمنې کوي چې د عکس سره غیر اړونده فایلونه بدلوي.
- د عکس د اوسنۍ نسخې د ترمیم کولو ستونزې لامل نه کیږي کله چې د Git څانګو لپاره د زاړه Git کمیټونو لپاره جوړونه بیا پیل کول.
وکاروئ! او له موږ سره لیدنه مه هیروئ د یوې مسلې رامینځته کولو یا موجوده موندلو لپاره ، پلس اضافه کړئ ، PR رامینځته کړئ یا په ساده ډول د پروژې پرمختګ وګورئ.
PS
زموږ په بلاګ کې هم ولولئ:
- «»
- «»
- «»
- په ویرف کې د نوښتونو په اړه د یادښتونو لړۍ:
- «»
- «»
- «»
- «".
سرچینه: www.habr.com