هغه څه چې موږ (او نه یوازې موږ) د اوږدې مودې لپاره انتظار کوو هغه پیښ شوي: ، زموږ د خلاصې سرچینې افادیت د غوښتنلیکونو رامینځته کولو او کبرنیټس ته یې وړاندې کولو لپاره ، اوس د 3-طریقه ضمیمه پیچونو په کارولو سره د بدلونونو پلي کولو ملاتړ کوي! برسېره پر دې، دا ممکنه ده چې د K8s موجوده سرچینې د هیلم ریلیزونو کې د دې سرچینو له بیا جوړولو پرته غوره کړي.
که دا خورا لنډ وي، نو موږ یې واچوو WERF_THREE_WAY_MERGE=enabled - موږ ګمارنه ترلاسه کوو "لکه څنګه چې kubectl apply"، د موجوده هیلم 2 تاسیساتو سره مطابقت لري او حتی یو څه نور.
مګر راځئ چې د تیورۍ سره پیل وکړو: په حقیقت کې د 3-طریقه انضمام پیچ څه دي، خلک څنګه د دوی د تولید کولو طریقې سره مخ شوي، او ولې دوی د کوبرنیټس پر بنسټ زیربنا سره د CI/CD پروسو کې مهم دي؟ او له هغې وروسته، راځئ وګورو چې 3-طریقه یوځای کول په ویرف کې څه دي، کوم حالتونه د ډیفالټ لخوا کارول کیږي او دا څنګه اداره کیږي.
د 3-طریقه یوځای کولو پیچ څه شی دی؟
نو ، راځئ چې د YAML څرګندولو کې بیان شوي سرچینې په کوبرنیټس کې د بیان شوي سرچینو پلي کولو دنده سره پیل کړو.
د منابعو سره کار کولو لپاره، Kubernetes API لاندې بنسټیز عملیات وړاندې کوي: جوړول، پیچ کول، بدلول او حذف کول. داسې انګیرل کیږي چې د دوی په مرسته دا اړینه ده چې د کلستر لپاره د منابعو یو مناسب دوامداره رول جوړ کړي. هغه څنګه؟
د kubectl لازمي امرونه
په Kubernetes کې د شیانو اداره کولو لپاره لومړۍ لاره د دې شیانو رامینځته کولو ، بدلولو او حذف کولو لپاره د kubectl لازمي امرونو کارول دي. په ساده ډول:
- ډله
kubectl runتاسو کولی شئ ګمارنه یا دنده پرمخ وړئ:kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE - ډله
kubectl scale- د نقلونو شمیر بدل کړئ:kubectl scale --replicas=3 deployment/mysql - او داسې نور.
دا طریقه ممکن په لومړي نظر کې اسانه ښکاري. په هرصورت، ستونزې شتون لري:
- دا ستونزمن دی اتومات.
- څنګه انعکاس ترتیب په Git کې؟ په کلستر کې د بدلونونو بیاکتنه څنګه وکړو؟
- څنګه چمتو کول د تولید وړتیا د بیا پیل په اړه تشکیلات؟
- ...
دا روښانه ده چې دا طریقه د کوډ په توګه د غوښتنلیک او زیربنا ذخیره کولو سره ښه نه ده (IaC؛ یا حتی د یو ډیر عصري اختیار په توګه، د Kubernetes په ایکوسیستم کې د شهرت ترلاسه کول). له همدې امله، دا حکمونه په کوبیکټل کې نور پرمختګ نه دی ترلاسه کړی.
عملیات جوړ کړئ، ترلاسه کړئ، بدل کړئ او حذف کړئ
د ابتدايي سره جوړول دا ساده ده: مینی فیسټ عملیاتو ته واستوئ create kube api او سرچینه جوړه شوې. د YAML نمایش په ګیټ کې زیرمه کیدی شي او د کمانډ په کارولو سره رامینځته کیدی شي kubectl create -f manifest.yaml.
С لرې کول هم ساده: ورته بدیل manifest.yaml له ګیټ څخه ټیم ته kubectl delete -f manifest.yaml.
عملیات replace تاسو ته اجازه درکوي په بشپړ ډول د سرچینې ترتیب له نوي سره بدل کړئ، پرته له دې چې سرچینې بیا جوړ کړئ. دا پدې مانا ده چې مخکې له دې چې سرچینې ته بدلون ورکړئ، دا منطقي ده چې د عملیاتو سره اوسنۍ نسخه پوښتنه وکړئ get، دا بدل کړئ او د عملیاتو سره یې تازه کړئ replace. kube apiserver جوړ شوی دی او، که د جراحي وروسته get اعتراض بدل شوی، بیا عملیات replace دا به کار ونکړي.
په Git کې د ترتیب ذخیره کولو لپاره او د ځای په ځای کولو سره یې تازه کړئ، تاسو اړتیا لرئ عملیات ترسره کړئ get، د Git څخه تشکیلات د هغه څه سره یوځای کړئ چې موږ ترلاسه کړي ، او اجرا یې کړئ replace. د ډیفالټ په واسطه، کیوبیکل یوازې تاسو ته اجازه درکوي کمانډ وکاروئ kubectl replace -f manifest.yamlچیرته manifest.yaml - یو دمخه بشپړ چمتو شوی (زموږ په قضیه کې یوځای شوی) منشور چې نصبولو ته اړتیا لري. دا معلومه شوه چې کاروونکي اړتیا لري د ادغام څرګندونه پلي کړي، او دا کومه کوچنۍ خبره نه ده ...
دا هم د یادونې وړ ده چې که څه هم manifest.yaml او په Git کې زیرمه شوی، موږ نشو کولی مخکې له مخکې پوه شو چې ایا دا اړینه ده چې یو شی جوړ کړئ یا یې تازه کړئ - دا باید د کاروونکي سافټویر لخوا ترسره شي.
ټول: ایا موږ کولی شو دوامداره رول آوټ جوړ کړو یوازې د رامینځته کولو ، بدلولو او حذف کولو په کارولو سره ، ډاډ ترلاسه کول چې د زیربنا تشکیلات په Git کې د کوډ او مناسب CI/CD سره زیرمه شوي؟
په اصل کې، موږ کولی شو ... د دې لپاره تاسو به د ادغام عملیات پلي کولو ته اړتیا ولرئ منشور او یو ډول پابندۍ چې:
- په کلستر کې د یو شی شتون چک کوي،
- د لومړنیو سرچینو جوړول ترسره کوي،
- تازه کوي یا ړنګوي.
کله چې تازه کول، مهرباني وکړئ په یاد ولرئ سرچینې ممکن بدل شوي وي له تیرې ورځې راهیسې get او په اتوماتيک ډول د خوشبینۍ تالاشۍ قضیه اداره کړئ - د تازه کولو تکرار هڅې وکړئ.
په هرصورت، ولې څرخ بیا ایجاد کړئ کله چې کیوب اپیسرور د سرچینو تازه کولو لپاره بله لاره وړاندې کوي: عملیات patch، کوم چې کارونکي د ځینې بیان شوي ستونزو څخه خلاصوي؟
پچ
اوس موږ پیچونو ته ورسیږو.
پیچونه په Kubernetes کې موجوده شیانو کې د بدلونونو پلي کولو لومړنۍ لار ده. عملیات patch دا د دې په څیر کار کوي:
- د کیوب اپیسرور کارونکي اړتیا لري چې د JSON فورمه کې پیچ واستوي او اعتراض مشخص کړي،
- او apiserver به پخپله د اعتراض اوسني حالت سره معامله وکړي او اړین شکل ته به یې راوړي.
په دې حالت کې د خوشبینۍ تالاشۍ ته اړتیا نشته. دا عملیات د ځای په ځای کولو څخه ډیر اعالن کوونکی دی، که څه هم په لومړي سر کې دا ممکن بل ډول ښکاري.
په دې ډول:
- د عملیاتو په کارولو سره
createموږ د Git څخه د منشور مطابق یو شی جوړوو، - له لارې
delete- حذف کړئ که چیرې توکي نور اړتیا نه وي - له لارې
patch- موږ اعتراض بدلوو، دا په Git کې بیان شوي شکل ته راوړو.
په هرصورت، د دې کولو لپاره، تاسو اړتیا لرئ چې جوړ کړئ سمه ټوټه!
څنګه پیچ په هیلم 2 کې کار کوي: 2-طریقه یوځای کول
کله چې تاسو لومړی ریلیز نصب کړئ، هیلم عملیات ترسره کوي create د چارټ سرچینو لپاره.
کله چې د هرې سرچینې لپاره د هیلم ریلیز تازه کول:
- د پخواني چارټ او اوسني چارټ نسخې څخه د سرچینې نسخې ترمینځ پیچ په پام کې نیسي ،
- دا پیچ پلي کوي.
موږ به دا پیچ ووایو 2-طريقه د ګډولو پیچځکه چې دوه منشورونه د هغې په جوړولو کې ښکیل دي:
- سرچینې د تیر خوشې کیدو څخه څرګندیږي،
- سرچینې د اوسني سرچینې څخه څرګندیږي.
کله چې عملیات لرې کول delete په kube apiserver کې د سرچینو لپاره ویل کیږي چې په تیرو خپرونو کې اعلان شوي، مګر په اوسني کې ندي اعلان شوي.
د 2 لارې ادغام پیچ چلند ستونزه لري: دا لامل کیږي په کلستر کې د سرچینې ریښتیني حالت او په Git کې څرګند شوي سره همغږي څخه بهر.
د یوې بېلګې په مرسته د ستونزې تشریح
- په Git کې، یو چارټ یو منشور ذخیره کوي په کوم کې چې ساحه
imageځای پرځای کول مهم ديubuntu:18.04. - د کارونکي له لارې
kubectl editد دې ساحې ارزښت ته بدل شوubuntu:19.04. - کله چې د هیلم چارټ بیا ځای په ځای کول پیچ نه تولیدويځکه چې میدان
imageد خوشې کولو پخوانۍ نسخه او اوسني چارټ کې ورته دي. - د بیا ځای پرځای کولو وروسته
imageپاتېubuntu:19.04که څه هم چارټ واييubuntu:18.04.
موږ غیر همغږي ترلاسه کړه او اعالمیه له لاسه ورکړه.
همغږي شوې سرچینه څه ده؟
عموما خبرې کول بشپړ دا ناشونې ده چې د منابعو منشور په روان کلستر کې او د Git څخه منشور تر مینځ میچ ترلاسه کړئ. ځکه چې په ریښتیني منشور کې ممکن د خدماتو تشریحات/لیبلونه ، اضافي کانټینرونه او نور معلومات وي چې د ځینې کنټرولرانو لخوا په متحرک ډول د سرچینې څخه اضافه شوي او لرې شوي. موږ نشو کولی او نه غواړو دا معلومات په Git کې وساتو. په هرصورت، موږ هغه ساحې غواړو چې موږ په واضح ډول په Git کې مشخص کړي ترڅو د رول آوټ په وخت کې مناسب ارزښتونه واخلي.
دا دومره عام وګرځي د منابعو همغږي قاعده: کله چې سرچینه راوباسئ ، تاسو کولی شئ یوازې هغه ساحې بدل یا حذف کړئ چې د Git څخه په څرګند ډول مشخص شوي (یا په تیرو نسخه کې مشخص شوي او اوس حذف شوي).
3-طريقه د ګډولو پیچ
اصلي مفکوره : موږ د Git څخه د مینی فیسټ وروستۍ پلي شوي نسخه او د Git څخه د مینی فیسټ هدف نسخه ترمینځ پیچ رامینځته کوو ، د روان کلستر څخه د مینی فیسټ اوسنۍ نسخه په پام کې نیولو سره. پایله لرونکی پیچ باید د ترکیب شوي سرچینې قانون سره مطابقت ولري:
- نوي ساحې په نښه شوي نسخه کې اضافه شوي د پیچ په کارولو سره اضافه شوي؛
- په وروستي پلي شوي نسخه کې پخوانۍ موجودې ساحې او په نښه شوي نسخه کې شتون نلري د پیچ په کارولو سره بیا تنظیم شوي؛
- د څیز په اوسنۍ نسخه کې ساحې چې د مینیفیسټ د هدف نسخې څخه توپیر لري د پیچ په کارولو سره تازه کیږي.
دا په دې اصولو کې دی چې پیچونه رامینځته کوي kubectl apply:
- د منشور وروستۍ پلي شوې نسخه پخپله د اعتراض په تشریح کې زیرمه شوې ،
- هدف - د ټاکل شوي YAML فایل څخه اخیستل شوی،
- اوسنی یو د چلولو کلستر څخه دی.
اوس چې موږ تیوري ترتیب کړې، دا وخت دی چې تاسو ته ووایاست چې موږ په ویرف کې څه وکړل.
په werf کې د بدلونونو پلي کول
مخکې، werf، د هیلم 2 په څیر، د 2-طریقه یوځای کولو پیچونه کارول.
پیچ ترمیم
د نوي ډول پیچونو ته د بدلولو لپاره - 3-طریقه یوځای کول - لومړی ګام چې موږ ورته معرفي کړ د ترمیم پیچ.
کله چې ګمارل کیږي، یو معیاري 2-طریقه یوځای کولو پیچ کارول کیږي، مګر werf سربیره پردې یو پیچ رامینځته کوي چې د سرچینې اصلي حالت به د هغه څه سره همغږي کړي چې په Git کې لیکل شوي (دا ډول پیچ د ورته همغږي شوي سرچینې قاعدې په کارولو سره رامینځته شوی چې پورته تشریح شوي) .
که چیرې غیر همغږي رامینځته شي ، د ځای په ځای کولو په پای کې کارونکي د ورته پیغام او پیچ سره یو خبرداری ترلاسه کوي چې باید سرچینې په همغږي شوي شکل ته راوړلو لپاره پلي شي. دا پیچ هم په یو ځانګړي تبصره کې ثبت شوی werf.io/repair-patch. داسې انګیرل کیږي چې د کاروونکي لاسونه сам دا پیچ به پلي کړي: werf به دا په هیڅ ډول پلي نه کړي.
د ترمیم پیچونه رامینځته کول یو لنډمهاله اقدام دی چې تاسو ته اجازه درکوي واقعیا د 3-طریقه ضمیمه اصولو پراساس د پیچونو رامینځته کولو ازموینه وکړئ ، مګر په اوتومات ډول دا پیچونه مه پلي کوئ. اوس مهال، دا عملیاتي حالت د ډیفالټ په واسطه فعال شوی.
3-طریقه یوځای کولو پیچ یوازې د نوي ریلیزونو لپاره
د دسمبر په 1، 2019 کې، د ویرف بیټا او الفا نسخې پیل کیږي په تلواله د بشپړ شوي 3-طریقه یوځای کولو پیچ وکاروئ یوازې د نوي هیلم ریلیزونو کې بدلونونو پلي کولو لپاره چې د ویرف له لارې رامینځته شوي. موجوده ریلیزونه به د 2-way-merge + ترمیم پیچ طریقې کارولو ته دوام ورکړي.
دا عملیاتي حالت په واضح ډول د ترتیب کولو له لارې فعال کیدی شي WERF_THREE_WAY_MERGE_MODE=onlyNewReleases اوس.
تبصره: فیچر په څو خپرونو کې په ویرف کې راڅرګند شو: په الفا چینل کې دا د نسخې سره چمتو شو ، او په بیټا چینل کې - سره .
د ټولو ریلیزونو لپاره 3-طریقه یوځای کولو پیچ
د دسمبر په 15، 2019 کې پیل کیږي، د werf بیټا او الفا نسخې په ټولو ریلیزونو کې د بدلونونو پلي کولو لپاره د ډیفالټ په واسطه د بشپړ 3-طریقه انضمام پیچ کارولو پیل کوي.
دا عملیاتي حالت په واضح ډول د ترتیب کولو له لارې فعال کیدی شي WERF_THREE_WAY_MERGE_MODE=enabled اوس.
د سرچینو اتوماتیک کولو سره څه وکړي؟
په Kubernetes کې د اتوماتیک کولو دوه ډولونه شتون لري: HPA (افقی) او VPA (عمودی).
افقی په اوتومات ډول د عکسونو شمیر غوره کوي ، عمودی - د سرچینو شمیر. د نقلونو شمیر او د سرچینې اړتیاوې دواړه د سرچینې په منشور کې مشخص شوي (د سرچینې منشور وګورئ). spec.replicas او یا spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory и ).
ستونزه: که چیرې یو کاروونکي په چارټ کې یوه سرچینه ترتیب کړي ترڅو د سرچینو لپاره ځانګړي ارزښتونه مشخص کړي یا د دې سرچینې لپاره ریپلیکا او آټوسکلرونه فعال شوي وي، نو د هرې ګمارنې سره werf به دا ارزښتونه هغه څه ته بیا تنظیم کړي چې په چارټ کې لیکل شوي. .
د ستونزې دوه حلونه شتون لري. د پیل کولو لپاره، دا غوره ده چې په چارټ منشور کې په ښکاره ډول د اتوماتیک شوي ارزښتونو مشخص کولو څخه مخنیوی وشي. که دا اختیار د کوم دلیل لپاره مناسب نه وي (د بیلګې په توګه، ځکه چې دا د ابتدايي سرچینو محدودیتونو او په چارټ کې د نقلونو شمیر ټاکلو لپاره مناسب دی)، نو بیا werf لاندې تشریحات وړاندې کوي:
-
werf.io/set-replicas-only-on-creation=true -
werf.io/set-resources-only-on-creation=true
که دا ډول تشریح شتون ولري، werf به په هر ګمارنه کې ورته ارزښتونه بیا تنظیم نه کړي، مګر یوازې به یې تنظیم کړي کله چې سرچینه په پیل کې جوړه شي.
د نورو جزیاتو لپاره، د پروژې اسناد وګورئ и .
د 3-طريقه انضمام پیچ کارول منع کړئ
کارونکي کولی شي دا مهال د چاپیریال متغیر په کارولو سره په ویرف کې د نوي پیچونو کارول منع کړي WERF_THREE_WAY_MERGE_MODE=disabled. په هرصورت، پیل کول د 1 کال د مارچ له 2020 څخه، دا بندیز به نور پلي نشي. او دا به یوازې د 3-طریقه یوځای کولو پیچونو کارول ممکن وي.
په ویرف کې د سرچینو اختیارول
د 3-طريقه انضمام پیچونو سره د بدلونونو پلي کولو میتود کې مهارت موږ ته اجازه راکړه چې سمدلاسه دا ډول خصوصیت پلي کړو لکه د هیلم ریلیز کې په کلستر کې موجود سرچینې غوره کول.
هیلم 2 یوه ستونزه لري: تاسو نشئ کولی په چارټ مینیفیسټونو کې سرچینه اضافه کړئ چې دمخه یې په کلستر کې شتون لري پرته له دې چې دا سرچینې له سکریچ څخه بیا جوړ کړي (وګورئ. , ). موږ ورف ته درس ورکړ چې د خلاصون لپاره موجوده سرچینې ومني. د دې کولو لپاره ، تاسو اړتیا لرئ د چلولو کلستر څخه د سرچینې په اوسني نسخه کې تشریح نصب کړئ (د مثال په توګه ، کارول kubectl edit):
"werf.io/allow-adoption-by-release": RELEASE_NAMEاوس سرچینې ته اړتیا ده چې په چارټ کې تشریح شي او بل ځل چې ویرف د مناسب نوم سره یو ریلیز ځای په ځای کړي، موجوده سرچینې به په دې خوشې کې ومنل شي او د هغې تر کنټرول لاندې پاتې شي. برسېره پردې، د خوشې کولو لپاره د سرچینې منلو په بهیر کې، werf به د منابعو اوسنی حالت د چلولو کلستر څخه هغه حالت ته راوړي چې په چارټ کې تشریح شوي، د ورته 3-طريقه انضمام پیچونو او د منابعو ترکیب شوي قاعدې په کارولو سره.
تبصره: ترتیب WERF_THREE_WAY_MERGE_MODE د منابعو په خپلولو اغیزه نه کوي - د خپلولو په حالت کې، د 3-طریقه یوځای کولو پیچ تل کارول کیږي.
جزیات - په .
پایلې او راتلونکي پلانونه
زه امید لرم چې د دې مقالې وروسته دا روښانه شوې چې د 3-طریقه انضمام پیچ څه دي او ولې دوی ته راغلي. د werf پروژې د پراختیا په اړه د عملي نظر څخه، د دوی پلي کول د هیلم په څیر د ګمارنې د ښه کولو په لور یو بل ګام و. اوس تاسو کولی شئ د تشکیلاتو ترکیب سره د ستونزو په اړه هیر کړئ ، کوم چې ډیری وختونه د هیلم 2 کارولو پرمهال رامینځته کیږي. په ورته وخت کې ، د هیلم ریلیز کې د دمخه ډاونلوډ شوي کوبرنیټ سرچینو غوره کولو نوې ګټور خصوصیت اضافه شوی.
د هیلم په څیر ګمارلو کې لاهم ځینې مسلې او ننګونې شتون لري، لکه د ګو ټیمپلیټ کارول، چې موږ به یې حل کولو ته دوام ورکړو.
د سرچینو د تازه کولو میتودونو او اختیارونو په اړه معلومات هم موندل کیدی شي .
هیلم ۳
د ځانګړې یادونې وړ یوازې بله ورځ د هیلم - v3 نوې لوی نسخه - کوم چې د 3-طریقه یوځای کولو پیچ هم کاروي او د ټیلر څخه خلاصیږي. د هیلم نوې نسخه اړتیا لري موجوده تاسیسات د نوي خوشې کولو ذخیره کولو بڼه کې بدلولو لپاره.
ویرف، د هغې برخې لپاره، دا مهال د ټیلر کارولو څخه ځان خلاص کړی، د 3-طریقه یوځای کولو ته بدل شوی او اضافه شوی ، پداسې حال کې چې د موجوده هیلم 2 تاسیساتو سره مطابقت پاتې کیږي (د مهاجرت سکریپټونو اجرا کولو ته اړتیا نلري). له همدې امله، تر هغه چې werf Helm 3 ته لاړ شي، د werf کاروونکي د Helm 3 په پرتله د Helm 2 اصلي ګټې له لاسه نه ورکوي (werf دوی هم لري).
په هرصورت، د هیلم 3 کوډبیس ته د ویرف بدلول ناگزیر دي او په نږدې راتلونکي کې به پیښ شي. احتمالا دا به werf 1.1 یا werf 1.2 وي (په اوس وخت کې د werf اصلي نسخه 1.0 ده؛ د werf نسخه کولو وسیله په اړه د نورو معلوماتو لپاره، وګورئ ). د دې وخت په جریان کې، هیلم 3 به د ثبات لپاره وخت ولري.
PS
زموږ په بلاګ کې هم ولولئ:
- په ویرف کې د نوښتونو په اړه د یادښتونو لړۍ:
- «»
- «»
- «".
- «»
- «»
- «".
سرچینه: www.habr.com