نوټ. ژباړه: له یوې وروستۍ خپرونې وروسته په GitOps کې د پل او پش میتودونو په اړه ، موږ په عمومي ډول د دې ماډل سره علاقه ولیدله ، مګر پدې موضوع کې د روسیې ژبې خورا لږ خپرونې شتون درلود (په ساده ډول په هابري کې هیڅ شتون نلري). له همدې امله، موږ خوښ یو چې ستاسو پام ته د بلې مقالې ژباړه وړاندیز کوو - که څه هم نږدې یو کال دمخه! - د Weaveworks څخه، چې سر یې د "GitOps" اصطلاح جوړه کړې. متن د تګلارې جوهر او د موجوده څخه کلیدي توپیرونه تشریح کوي.
یو کال دمخه موږ خپور کړ . وروسته بیا، موږ شریک کړل چې څنګه د Weaveworks ټیم یو SaaS په بشپړ ډول د Kubernetes پراساس پیل کړ او د بادل اصلي چاپیریال کې د ځای په ځای کولو، اداره کولو، او نظارت کولو لپاره یې د نسخې غوره کړنالرې رامینځته کړې.
مقاله مشهوره شوه. نورو خلکو د GitOps په اړه خبرې پیل کړې او د نوي وسیلو په خپرولو یې پیل وکړ , , , , او همداسی پسی. زموږ په ویب پاڼه کې ښکاره شو خپرونې او GitOps قضیې کاروي. مګر ځینې خلک لاهم پوښتنې لري. ماډل څنګه د دودیز ماډل څخه توپیر لري؟ او دوامداره تحویلي ()؟ ایا د کوبرنیټس کارول اړین دي؟
موږ ژر پوه شو چې یو نوی توضیح ته اړتیا وه، وړاندیز یې وکړ:
- د مثالونو او کیسې لوی شمیر؛
- د GitOps ځانګړی تعریف؛
- د دودیز دوامداره تحویل سره پرتله کول.
پدې مقاله کې موږ هڅه کړې چې دا ټول موضوعات تر پوښښ لاندې ونیسو. دا د GitOps او پراختیا کونکي او CI/CD لید ته تازه پیژندنه وړاندې کوي. موږ په ابتدايي توګه په کبرنیټس تمرکز کوو، که څه هم ماډل عمومي کیدی شي.
د GitOps سره لیدنه وکړئ
د الیس تصور وکړئ. هغه د کورنۍ بیمه پرمخ وړي، کوم چې خلکو ته روغتیا، موټر، کور، او د سفر بیمه وړاندې کوي څوک چې د قراردادونو دننه او بهر په ګوته کولو کې ډیر بوخت دي. د هغې سوداګرۍ د اړخ پروژې په توګه پیل شو کله چې ایلیس په بانک کې د ډیټا ساینس پوه په توګه کار کاوه. یوه ورځ هغې پوهیده چې هغه کولی شي پرمختللي کمپیوټر الګوریتمونه وکاروي ترڅو ډیټا په مؤثره توګه تحلیل کړي او د بیمې کڅوړې رامینځته کړي. پانګوالو دا پروژه تمویل کړه، او اوس د هغې شرکت په کال کې له 20 ملیون ډالرو څخه ډیر عاید راوړي او په چټکۍ سره وده کوي. اوس مهال، دا په مختلفو پوستونو کې 180 کسان کار کوي. پدې کې د ټیکنالوژۍ ټیم شامل دی چې وده کوي، ویب پاڼه، ډیټابیس ساتي، او د پیرودونکي اساس تحلیل کوي. د 60 کسانو ټیم د باب لخوا رهبري کیږي، د شرکت تخنیکي رییس.
د باب ټیم په بادل کې د تولید سیسټمونه ځای په ځای کوي. د دوی اصلي غوښتنلیکونه په GKE کې پرمخ ځي، په ګوګل کلاوډ کې د کبرنیټس څخه ګټه پورته کوي. سربیره پردې ، دوی په خپل کار کې مختلف ډیټا او تحلیلي وسیلې کاروي.
د کورنۍ بیمه د کانټینرونو کارولو لپاره نه وه جوړه شوې، مګر د ډاکر په لیوالتیا کې ښکیل شو. شرکت ډیر ژر وموندله چې GKE د نوي ب featuresو ازموینې لپاره د کلسترونو ځای په ځای کول اسانه کړي. د CI او Quay لپاره جینکنز د کانټینر راجسټری تنظیم کولو لپاره اضافه شوي ، د جینکنز لپاره سکریپټونه لیکل شوي چې نوي کانټینرونه او تشکیلات GKE ته اړوي.
یو څه وخت تېر شو. الیس او باب د دوی د غوره شوي چلند د فعالیت او په سوداګرۍ باندې د هغې اغیزې څخه ناخوښه وو. د کانټینرونو معرفي د محصولاتو وده دومره ښه نه کړه لکه څنګه چې ټیم تمه درلوده. ځینې وختونه ګمارنې به مات شي، او دا څرګنده نه وه چې آیا د کوډ بدلونونه ملامت دي. دا د تشکیلاتو بدلونونو تعقیب کول هم ستونزمن و. ډیری وختونه دا اړینه وه چې یو نوی کلستر رامینځته کړئ او غوښتنلیکونه دې ته واړوئ ، ځکه چې دا د سیسټم خرابیدو له مینځه وړو لپاره ترټولو اسانه لاره وه. الیس ویره درلوده چې وضعیت به خراب شي لکه څنګه چې غوښتنلیک رامینځته شوی (سربیره پردې ، د ماشین زده کړې پراساس یوه نوې پروژه جوړه شوې وه). باب ډیری کار اتومات کړی و او په دې نه پوهیده چې ولې پایپ لاین لاهم بې ثباته و، ښه اندازه یې نه درلوده، او وخت په وخت لاسي مداخلې ته اړتیا وه؟
بیا دوی د GitOps په اړه زده کړل. دا پریکړه په حقیقت کې هغه څه وګرځیدل چې دوی ورته اړتیا درلوده چې په ډاډه توګه پرمخ لاړ شي.
الیس او باب د کلونو لپاره د کوډ کاري فلو په توګه د Git، DevOps، او زیربناوو په اړه اوریدلي دي. هغه څه چې د GitOps په اړه ځانګړی دی دا دی چې دا د Kubernetes په شرایطو کې د دې نظرونو پلي کولو لپاره د غوره عملونو سیټ راوړي - دواړه حتمي او نورمال. دا موضوع په شمول .
د کورنۍ بیمه د GitOps پلي کولو پریکړه کوي. شرکت اوس د اتوماتیک عملیات ماډل لري چې د Kubernetes او ترکیبونو سره مطابقت لري سرعت سره ثباتځکه دوی:
- وموندله چې د ټیم تولید دوه چنده شوی پرته له دې چې څوک لیونی شي؛
- د سکریپټونو خدمت کول بند کړل. پرځای یې، دوی اوس کولی شي په نوو ځانګړتیاو تمرکز وکړي او د انجینرۍ تخنیکونو ته وده ورکړي - د بیلګې په توګه، د کانري رول آوټ معرفي کول او د ازموینې ښه کول؛
- موږ د ګمارنې پروسه ښه کړې ترڅو دا په ندرت سره مات شي؛
- پرته له لاسي مداخلې پرته د جزوي ناکامیو وروسته د ګمارنې بیا رغولو فرصت ترلاسه کړ؛
- اخیستل شوي کارولоد تحویلي سیسټمونو ډیر باور. الیس او باب وموندل چې دوی کولی شي ټیم د مایکرو سرویس ټیمونو ته وویشي چې په موازي توګه کار کوي.
- کولی شي د هرې ډلې د هڅو له لارې هره ورځ په پروژه کې 30-50 بدلونونه راولي او نوي تخنیکونه هڅه وکړي؛
- پروژې ته د نوي پراختیا کونکو راجلب کول اسانه دي ، څوک چې فرصت لري په څو ساعتونو کې د پل غوښتنې په کارولو سره تولید ته تازه معلومات وړاندې کړي؛
- په اسانۍ سره د SOC2 په چوکاټ کې تفتیش پاس کړئ (د خوندي ډیټا مدیریت اړتیاو سره د خدماتو چمتو کونکو موافقت لپاره؛ نور ولولئ ، د مثال په توګه ، - نږدې ژباړه.).
څه پیښ شو؟
GitOps دوه شیان دي:
- د Kubernetes او بادل اصلي لپاره عملیاتي ماډل. دا د کانټینر شوي کلسترونو او غوښتنلیکونو پلي کولو ، اداره کولو او نظارت کولو لپاره د غوره تمرینونو سیټ چمتو کوي. په شکل کې ښکلی تعریف от :
- د پراختیا کونکي متمرکز غوښتنلیک مدیریت چاپیریال رامینځته کولو لاره. موږ د Git کاري فلو دواړو عملیاتو او پراختیا ته پلي کوو. مهرباني وکړئ په یاد ولرئ چې دا یوازې د Git push په اړه ندي ، بلکه د CI/CD او UI/UX وسیلو ټول سیټ تنظیم کولو په اړه دي.
د Git په اړه یو څو خبرې
که تاسو د نسخې کنټرول سیسټمونو او د Git پر بنسټ کاري فلو سره بلد نه یاست، موږ د دوی په اړه د زده کړې سپارښتنه کوو. د څانګو سره کار کول او د پلي کولو غوښتنې ممکن په لومړي سر کې د تور جادو په څیر ښکاري ، مګر ګټې د هڅو ارزښت لري. دلته پيلول.
Kubernetes څنګه کار کوي
زموږ په کیسه کې، الیس او باب د یو څه مودې لپاره د کبرنیټس سره کار کولو وروسته GitOps ته مخه کړه. په حقیقت کې، GitOps د Kubernetes سره نږدې تړاو لري - دا د زیربنا او غوښتنلیکونو لپاره عملیاتي ماډل دی چې د Kubernetes پر بنسټ والړ دی.
Kubernetes کاروونکو ته څه ورکوي؟
دلته ځینې اصلي ځانګړتیاوې دي:
- د Kubernetes ماډل کې، هر څه په اعلاناتي بڼه کې تشریح کیدی شي.
- د Kubernetes API سرور دا اعالمیه د ان پټ په توګه اخلي او بیا په دوامداره توګه هڅه کوي چې کلستر په اعالمیه کې بیان شوي حالت ته راوړي.
- اعالمیه د ډیری کاري بارونو تشریح او اداره کولو لپاره کافي دي - "غوښتنلیکونه."
- د پایلې په توګه، په غوښتنلیک او کلستر کې بدلونونه د دې له امله واقع کیږي:
- د کانټینر عکسونو کې بدلون؛
- د اعلامیې مشخصاتو کې بدلون؛
- په چاپیریال کې غلطۍ - د بیلګې په توګه، د کانټینر حادثې.
د کبرنیټس لوی همغږي وړتیاوې
کله چې یو مدیر په تشکیلاتو کې بدلون راولي، د Kubernetes آرکیسټرټر به یې په کلستر کې پلي کړي تر هغه چې د هغه حالت وي. نوي ترتیب ته به نږدې نشي. دا ماډل د هر Kubernetes سرچینې لپاره کار کوي او د ګمرکي سرچینو تعریفونو (CRDs) سره د توزیع وړ دی. له همدې امله، د کوبرنیټس ګمارنې لاندې په زړه پوري ملکیتونه لري:
- اتومات: د Kubernetes تازه معلومات یو میکانیزم چمتو کوي ترڅو د بدلونونو پلي کولو پروسه په زړه پورې او په وخت سره پلي کړي.
- کنسرت: Kubernetes به تر بریالیتوب پورې د تازه معلوماتو هڅو ته دوام ورکړي.
- هوښیارتیا: د همغږي تکرار غوښتنلیکونه د ورته پایلې لامل کیږي.
- ډیټامینیزم: کله چې سرچینې کافي وي، د تازه کلستر حالت یوازې په مطلوب حالت پورې اړه لري.
GitOps څنګه کار کوي
موږ د Kubernetes په اړه کافي زده کړل ترڅو تشریح کړو چې څنګه GitOps کار کوي.
راځئ چې د کورنۍ بیمې د مایکرو خدماتو ټیمونو ته بیرته راشو. دوی معمولا څه کوي؟ لاندې لیست وګورئ (که په دې کې کوم توکي عجیب یا ناڅرګند ښکاري، مهرباني وکړئ نیوکه وکړئ او زموږ سره پاتې شئ). دا یوازې د جینکنز پر بنسټ کاري فلو مثالونه دي. ډیری نورې پروسې شتون لري کله چې د نورو وسیلو سره کار کوي.
اصلي شی دا دی چې موږ ګورو چې هر تازه معلومات د تشکیلاتو فایلونو او Git ذخیره کولو کې بدلونونو سره پای ته رسیږي. Git ته دا بدلونونه د "GitOps آپریټر" د کلستر تازه کولو لامل کیږي:
1. د کار بهیر: "جینکنز جوړ - ماسټر څانګه".
د دندو لیست:
- جینکنز ټګ شوي عکسونه Quay ته اړوي؛
- جینکنز ترتیب او هیلم چارټونه د ماسټر ذخیره کولو بالټ ته اړوي؛
- د کلاوډ فنکشن د ماسټر ذخیره کولو بالټ څخه د ماسټر ګیټ ذخیره ته ترتیب او چارټونه کاپي کوي؛
- د GitOps آپریټر کلستر تازه کوي.
2. جینکنز جوړونه - خوشې یا د هاټ فکس څانګه:
- جینکنز بې نښه شوي عکسونه کوې ته اړوي؛
- جینکنز ترتیب او هیلم چارټونه د سټیجینګ ذخیره کولو بالټ ته اړوي؛
- د کلاوډ فنکشن د سټیجینګ ذخیره کولو بالټ څخه د سټیګینګ ګیټ ذخیره ته ترتیب او چارټونه کاپي کوي؛
- د GitOps آپریټر کلستر تازه کوي.
3. جینکنز جوړول - پراختیا یا ځانګړتیا څانګه:
- جینکنز بې نښه شوي عکسونه کوې ته اړوي؛
- جینکنز ترتیب او هیلم چارټونه د پراختیا ذخیره کولو بالټ ته اړوي؛
- د کلاوډ فنکشن د پراختیا ذخیره کولو بالټ څخه د Git ذخیره کولو پراختیا ته ترتیب او چارټونه کاپي کوي؛
- د GitOps آپریټر کلستر تازه کوي.
4. د نوي پیرودونکي اضافه کول:
- مدیر یا مدیر (LCM/ops) Gradle ته زنګ وهي چې په پیل کې د شبکې بار بیلانسر (NLBs) ځای په ځای او تنظیم کړي؛
- LCM/ops د تازه معلوماتو لپاره د ګمارنې چمتو کولو لپاره یو نوی ترتیب کوي؛
- د GitOps آپریټر کلستر تازه کوي.
د GitOps لنډ تفصیل
- د هر چاپیریال لپاره د اعلاناتي مشخصاتو په کارولو سره د ټول سیسټم مطلوب حالت تشریح کړئ (زموږ په کیسه کې ، د باب ټیم په ګیټ کې د سیسټم ټول تنظیمات تعریفوي).
- د Git ذخیره د ټول سیسټم مطلوب حالت په اړه د حقیقت یوازینۍ سرچینه ده.
- په مطلوب حالت کې ټول بدلونونه په Git کې د ژمنو له لارې رامینځته کیږي.
- ټول مطلوب کلستر پیرامیټونه پخپله په کلستر کې د لیدلو وړ دي. په دې توګه موږ کولی شو دا معلومه کړو چې ایا دوی سره یو ځای کیږي (متقابل، یوځای کیدل) یا توپیر ( توپیر، توپیر) مطلوب او مشاهده شوي حالتونه.
- که مطلوب او لیدل شوي حالتونه توپیر ولري، نو بیا:
- د همغږۍ میکانیزم شتون لري چې ژر یا وروسته په اوتومات ډول هدف او مشاهده شوي حالتونه همغږي کوي. د کلستر دننه، Kubernetes دا کار کوي.
- پروسه سمدلاسه د "بدلون ژمن" خبرتیا سره پیل کیږي.
- د یو څه تنظیم شوي مودې وروسته ، د "تفاوت" خبرتیا لیږل کیدی شي که چیرې ایالتونه مختلف وي.
- په دې توګه، په Git کې ټولې ژمنې کلستر ته د تایید وړ او نامتو تازه معلوماتو لامل کیږي.
- رول بیک یو مخکیني مطلوب حالت ته کنورژن دی.
- همغږي حتمي ده. د هغې پیښې په لاندې ډول ښودل کیږي:
- د یوې ټاکلې مودې لپاره هیڅ توپیر خبرتیا نشته.
- "کنورډ" خبرتیا (د مثال په توګه ویب هک، د ګیټ رایټ بیک پیښه).
انحراف څه شی دی؟
راځئ چې یو ځل بیا تکرار کړو: ټول مطلوب کلستر ملکیتونه باید پخپله په کلستر کې د لیدلو وړ وي.
د اختلاف ځینې مثالونه:
- په Git کې د څانګو یوځای کولو له امله د تشکیلاتو فایل کې بدلون.
- د GUI پیرودونکي لخوا رامینځته شوي Git ژمنې له امله د تشکیلاتو فایل کې بدلون.
- په ګیټ کې د PR له امله مطلوب حالت ته ډیری بدلونونه وروسته د کانټینر عکس او تشکیل بدلونونو رامینځته کولو سره.
- د کلستر په حالت کې بدلون د یوې تېروتنې له امله، د سرچینو شخړه د "خراب چلند" په پایله کې، یا په ساده ډول د اصلي حالت څخه تصادفي انحراف.
د انسجام میکانیزم څه شی دی؟
ځینې مثالونه:
- د کانټینرونو او کلسترونو لپاره، د کنورژن میکانیزم د Kubernetes لخوا چمتو شوی.
- ورته میکانیزم د Kubernetes-based غوښتنلیکونو او ډیزاینونو اداره کولو لپاره کارول کیدی شي (لکه Istio او Kubeflow).
- د Kubernetes، د عکس ذخیره کولو او Git ترمنځ د عملیاتي تعامل اداره کولو لپاره یو میکانیزم چمتو کوي ، کومه برخه ده .
- د بیس ماشینونو لپاره، د کنورژن میکانیزم باید اعلاناتي او خپلواکه وي. زموږ د تجربې څخه موږ کولی شو دا ووایو دې تعریف ته نږدې ، مګر لاهم د انسان کنټرول ته اړتیا لري. په دې معنی، GitOps د کوډ په توګه د زیربناوو دود پراخوي.
GitOps Git د Kubernetes عالي کنورژن انجن سره ترکیب کوي ترڅو د استحصال لپاره ماډل چمتو کړي.
GitOps موږ ته اجازه راکوي چې ووایو: یوازې هغه سیسټمونه چې تشریح او مشاهده کیدی شي اتومات او کنټرول کیدی شي.
GitOps د ټول کلاوډ اصلي سټیک لپاره دی (د مثال په توګه ، ټیرفارم ، او داسې نور)
GitOps یوازې Kubernetes ندي. موږ غواړو چې ټول سیسټم په اعالمیه توګه پرمخ ولاړ شي او همغږي وکاروئ. د ټول سیسټم له مخې موږ د چاپیریال ټولګه بولو چې د Kubernetes سره کار کوي - د بیلګې په توګه، "dev cluster 1"، "production"، etc. په هر چاپیریال کې ماشینونه، کلسترونه، غوښتنلیکونه، او همدارنګه د بهرنیو خدماتو لپاره انٹرفیسونه شامل دي چې ډاټا، څارنه چمتو کوي. او داسې نور
په یاد ولرئ چې په دې قضیه کې د بوټسټریپینګ ستونزې لپاره Terraform څومره مهم دی. Kubernetes باید یو ځای ځای په ځای شي، او د Terraform کارولو معنی دا ده چې موږ کولی شو ورته GitOps کاري فلو پلي کړو ترڅو د کنټرول پرت رامینځته کړو چې د کوبرنیټس او غوښتنلیکونه لاندې کوي. دا یو ګټور غوره تمرین دی.
د Kubernetes په سر کې پرتونو ته د GitOps مفاهیمو پلي کولو باندې قوي تمرکز شتون لري. په اوس وخت کې، د Istio، Helm، Ksonnet، OpenFaaS او Kubeflow لپاره د GitOps ډوله حلونه شتون لري، او همدارنګه د مثال په توګه، د پلومي لپاره، کوم چې د بادل اصلي لپاره د غوښتنلیکونو پراختیا لپاره یو پرت رامینځته کوي.
Kubernetes CI/CD: د نورو طریقو سره د GitOps پرتله کول
لکه څنګه چې ویل شوي، GitOps دوه شیان دي:
- د Kubernetes او بادل اصلي لپاره عملیاتي ماډل پورته تشریح شوي.
- د پراختیا کونکي متمرکز غوښتنلیک مدیریت چاپیریال ته لاره.
د ډیری لپاره ، GitOps اساسا د Git فشارونو پراساس د کار فلو دی. موږ هم هغه خوښوو. مګر دا ټول ندي: راځئ چې اوس CI/CD پایپ لاینونو ته وګورو.
GitOps د Kubernetes لپاره دوامداره ګمارنه (CD) وړوي
GitOps د دوامداره ګمارنې میکانیزم وړاندیز کوي چې د جلا "ګمارنې مدیریت سیسټمونو" اړتیا له مینځه وړي. Kubernetes ستاسو لپاره ټول کار کوي.
- د غوښتنلیک تازه کول په Git کې تازه کولو ته اړتیا لري. دا مطلوب حالت ته د لیږد تازه دی. "ګمارنه" بیا د تازه شوي توضیحاتو پراساس پخپله د Kubernetes لخوا په کلستر کې ترسره کیږي.
- د طبیعت له امله چې کوبرنیټس څنګه کار کوي ، دا تازه معلومات متضاد دي. دا د دوامداره ګمارنې لپاره میکانیزم چمتو کوي چې په کې ټول تازه معلومات اټومي دي.
- نوټ: د GitOps آپریټر وړاندیز کوي چې Git او Kubernetes مدغم کوي او CD ته اجازه ورکوي چې د کلستر مطلوب او اوسني حالت پخلا کولو سره ترسره شي.
د کوبیک او سکریپټ پرته
تاسو باید د خپل کلستر د تازه کولو لپاره د Kubectl کارولو څخه ډډه وکړئ، او په ځانګړې توګه د کیوبیکل کمانډونو ګروپ لپاره د سکریپټونو کارولو څخه ډډه وکړئ. پرځای یې، د GitOps پایپ لاین سره، یو کاروونکي کولی شي د ګیټ له لارې خپل کوبرنیټس کلستر تازه کړي.
په ګټو کې شامل دي:
- سمه ده. د تازه معلوماتو یوه ډله پلي کیدی شي ، بدلیږي او په پای کې تایید کیدی شي ، موږ د اټومي پلي کولو هدف ته نږدې کوو. په مقابل کې، د سکریپټونو کارول د همغږۍ هیڅ تضمین نه وړاندې کوي (لاندې په دې اړه نور).
- امنیت. کیلسي های ټاور: "ستاسو د کوبرنیټس کلستر ته لاسرسی د اتومات وسیلو او مدیرانو ته محدود کړئ څوک چې د دې ډیبګ کولو یا ساتلو مسؤل دي." هم وګوره د خوندیتوب او تخنیکي مشخصاتو سره موافقت په اړه ، او همدارنګه د بې پروایی لیکل شوي جینکنز سکریپټ څخه د اعتبارونو غلا کولو سره.
- د کاروونکي تجربه. Kubectl د Kubernetes اعتراض ماډل میخانیکونه افشا کوي، کوم چې خورا پیچلي دي. په عین حال کې، کاروونکي باید د سیسټم سره په لوړه کچه د خلاصون سره اړیکه ونیسي. دلته به زه بیا کیلي ته مراجعه وکړم او د لیدو وړاندیز وکړم .
د CI او CD ترمنځ توپیر
GitOps موجوده CI/CD ماډلونه ښه کوي.
یو عصري CI سرور د آرکیسټریشن وسیله ده. په ځانګړې توګه، دا د CI پایپ لاینونو تنظیمولو لپاره وسیله ده. پدې کې جوړونه، ازموینه، د ډنډ سره یوځای کول، او نور شامل دي. د CI سرورونه د پیچلو څو مرحلو پایپ لاینونو مدیریت اتومات کوي. یو عام لالچ دا دی چې د Kubernetes تازه معلوماتو سیټ سکریپټ کړئ او دا د پایپ لاین برخې په توګه پرمخ وړئ ترڅو کلستر ته بدلونونه فشار ورکړئ. په حقیقت کې، دا هغه څه دي چې ډیری ماهرین یې کوي. په هرصورت، دا غوره نه دی، او دلته ولې.
CI باید ترنک ته د تازه معلوماتو فشار ورکولو لپاره وکارول شي ، او د کوبرنیټس کلستر باید د دې تازه معلوماتو پراساس خپل ځان بدل کړي ترڅو د CD داخلي اداره کړي. موږ ورته غږ کوو ، د CI پش ماډل برعکس. سي ډي برخه ده د وخت آرکیسټریشن.
ولې د CI سرورونه باید په کبرنیټس کې د مستقیم تازه معلوماتو له لارې CDs ونه کړي
د CI دندو د سیټ په توګه Kubernetes ته مستقیم تازه معلومات تنظیمولو لپاره د CI سرور مه کاروئ. دا هغه ضد نمونه ده چې موږ یې په اړه خبرې کوو ستاسو په بلاګ کې.
راځئ چې بیرته الیس او باب ته لاړ شو.
له کومو ستونزو سره مخ شول؟ د باب CI سرور په کلستر کې بدلونونه پلي کوي، مګر که دا په پروسه کې ټکر شي، باب به نه پوهیږي چې کلستر په کوم حالت کې دی (یا باید وي) یا دا څنګه حل کړي. د بریالیتوب په صورت کې هم همداسې ده.
راځئ فرض کړو چې د باب ټیم یو نوی عکس جوړ کړی او بیا یې د عکس ځای پرځای کولو لپاره د دوی ګمارنې پیچلې کړې (ټول د CI پایپ لاین څخه).
که عکس په نورمال ډول جوړ شي، مګر پایپ لاین ناکام شي، ټیم باید معلومه کړي:
- ایا اوسمهال تازه شوی؟
- ایا موږ یو نوی جوړونه پیل کوو؟ ایا دا به د غیر ضروري اړخیزو اغیزو لامل شي - د ورته بدلیدونکي عکس دوه جوړیدو امکان سره؟
- ایا موږ باید د جوړولو چلولو دمخه راتلونکي تازه کولو ته انتظار وکړو؟
- په ریښتیا څه غلط شوي؟ کوم ګامونه باید تکرار شي (او کوم یو د تکرار لپاره خوندي دي)؟
د ګیټ پراساس کاري فلو رامینځته کول تضمین نه کوي چې د باب ټیم به له دې ستونزو سره مخ نشي. دوی لاهم کولی شي د ژمنې فشار ، ټاګ یا کوم بل پیرامیټر سره غلطي وکړي؛ په هرصورت، دا طریقه لاهم د ټولو یا هیڅ شی نه څرګند شوي چلند ته خورا نږدې ده.
د لنډیز کولو لپاره، دلته دی چې ولې د CI سرورونه باید د CD سره معامله ونه کړي:
- د تازه کولو سکریپټونه تل ټاکونکي نه وي؛ په دوی کې غلطي کول اسانه دي.
- د CI سرورونه د اعلاناتي کلستر ماډل سره نه یوځای کیږي.
- د بې کفایتۍ تضمین کول ستونزمن دي. کاروونکي باید د سیسټم ژور سیمانټیک پوه شي.
- د یوې برخې ناکامۍ څخه بیرته راګرځیدل خورا ستونزمن دي.
د هیلم په اړه یادونه: که تاسو غواړئ هیلم وکاروئ، موږ وړاندیز کوو چې دا د GitOps آپریټر سره یوځای کړئ لکه . دا به د همغږۍ ډاډ ترلاسه کولو کې مرسته وکړي. هیلم پخپله نه ټاکونکی دی او نه اټومي.
GitOps د Kubernetes لپاره د دوامداره تحویلي پلي کولو غوره لارې په توګه
د الیس او باب ټیم GitOps پلي کوي او کشف کوي چې د سافټویر محصولاتو سره کار کول خورا اسانه شوي ، لوړ فعالیت او ثبات ساتل. راځئ چې دا مقاله د یو مثال سره پای ته ورسوو چې ښیې د دوی نوې تګلاره څه ډول ښکاري. په یاد ولرئ چې موږ ډیری د غوښتنلیکونو او خدماتو په اړه خبرې کوو، مګر GitOps د ټول پلیټ فارم اداره کولو لپاره کارول کیدی شي.
د Kubernetes لپاره عملیاتي ماډل
لاندې انځور ته وګورئ. دا Git او د کانټینر عکس ذخیره وړاندې کوي د دوه منظم شوي ژوند دورې لپاره د شریکو سرچینو په توګه:
- د دوامداره ادغام پایپ لاین چې Git ته فایلونه لوستل او لیکي او کولی شي د کانټینر عکسونو ذخیره تازه کړي.
- د Runtime GitOps پایپ لاین چې ګمارل د مدیریت او مشاهدې سره ترکیب کوي. دا Git ته فایلونه لوستل او لیکي او کولی شي د کانټینر عکسونه ډاونلوډ کړي.
اصلي موندنې څه دي؟
- د اندیښنو جلا کول: مهرباني وکړئ په یاد ولرئ چې دواړه پایپ لاینونه یوازې د Git یا د عکس ذخیره کولو تازه کولو سره اړیکه نیولی شي. په بل عبارت، د CI او د چلولو چاپیریال تر منځ د اور وژونکي شتون لري. موږ دې ته د "غیر متغیر فایروال" وایو (بې ثباته فایروال)، ځکه چې ټول ذخیره تازه نوي نسخې رامینځته کوي. د دې موضوع په اړه د نورو معلوماتو لپاره، 72-87 سلایډونو ته مراجعه وکړئ .
- تاسو کولی شئ هر CI او Git سرور وکاروئ: GitOps د هرې برخې سره کار کوي. تاسو کولی شئ د خپلې خوښې CI او Git سرورونو، د عکس ذخیره کولو، او ټیسټ سویټونو کارولو ته دوام ورکړئ. په بازار کې نږدې ټول نور دوامداره تحویلي وسیلې د دوی خپل CI/Git سرور یا د عکس ذخیره کولو ته اړتیا لري. دا ممکن د بادل اصلي پراختیا کې یو محدود فاکتور شي. د GitOps سره، تاسو کولی شئ پیژندل شوي وسیلې وکاروئ.
- پیښې د ادغام وسیلې په توګه: هرڅومره ژر چې په ګیټ کې ډاټا تازه شي ، ویو فلکس (یا د ویو کلاوډ آپریټر) د چلولو وخت خبر کوي. هرکله چې کبرنیټس د بدلون سیټ ومني ، ګیټ تازه کیږي. دا د GitOps لپاره د کاري فلو تنظیم کولو لپاره ساده ادغام ماډل چمتو کوي ، لکه څنګه چې لاندې ښودل شوي.
پایلې
GitOps د هر عصري CI/CD وسیلې لخوا اړین قوي تازه تضمین چمتو کوي:
- اتومات
- همغږي
- کمزوري
- عزم
دا مهم دی ځکه چې دا د بادل اصلي پراختیا کونکو لپاره عملیاتي ماډل وړاندیز کوي.
- د سیسټمونو د مدیریت او څارنې دودیزې وسیلې د عملیاتي ټیمونو سره تړلي دي چې په رن بوک کې فعالیت کوي. (د معمول پروسیجرونو او عملیاتو یوه مجموعه - نږدې ژباړه.)، د یو ځانګړي ځای په ځای کولو پورې تړلی.
- د کلاوډ اصلي سیسټمونو مدیریت کې ، د لیدنې وسیلې د ګمارنې پایلو ارزولو غوره لاره ده ترڅو پراختیایی ټیم دوی ته ژر ځواب ووایی.
تصور وکړئ ډیری کلسترونه په مختلف بادلونو کې ویشل شوي او ډیری خدمتونه د دوی د خپلو ټیمونو او ګمارنې پلانونو سره. GitOps د دې ټول کثرت اداره کولو لپاره د پیمانه متغیر ماډل وړاندیز کوي.
PS د ژباړونکي څخه
زموږ په بلاګ کې هم ولولئ:
- «»
- «»
- «".
یوازې راجستر شوي کاروونکي کولی شي په سروې کې برخه واخلي. مهرباني وکړئ
ایا تاسو د GitOps په اړه پوهیږئ مخکې لدې چې دا دوه ژباړې په Habré کې څرګندې شي؟
-
هو، زه هرڅه پوهیدم
-
یوازې سطحي
-
نه
35 کاروونکو رایه ورکړه. 10 کاروونکي منع شوي.
سرچینه: www.habr.com