نوټ. ژباړه: د کوبرنیټس ټولنه کې، د GitOps په نوم یو رجحان څرګند شهرت ترلاسه کوي، لکه څنګه چې موږ په شخصي توګه لیدلي دي، KubeCon اروپا 2019. دا اصطلاح نسبتا وروستي وه د Weaveworks د مشر لخوا - الیکسس ریچارډسن - او د عملیاتي ستونزو حل کولو لپاره د پراختیا کونکو سره پیژندل شوي وسیلو کارول (په ابتدايي توګه Git، له همدې امله نوم). په ځانګړي توګه ، موږ په ګیټ کې د دې تشکیلاتو ذخیره کولو او په اوتومات ډول په کلستر کې د بدلونونو رامینځته کولو سره د کبرنیټس عملیاتو په اړه خبرې کوو. Matthias Jg پدې مقاله کې د دې رول آوټ لپاره د دوه لارو په اړه خبرې کوي.
تېر کال (په حقیقت کې، په رسمي توګه دا د اګست په 2017 کې پیښ شوي - نږدې. ژباړه.) په کبرنیټس کې د غوښتنلیکونو ځای په ځای کولو لپاره نوې تګلاره شتون لري. دا د GitOps په نوم یادیږي، او دا د بنسټیز مفکورې پر بنسټ والړ دی چې د ګومارنې نسخې د Git ذخیره خوندي چاپیریال کې تعقیب کیږي.
د دې طریقې اصلي ګټې په لاندې ډول دي::
- د ګمارلو نسخه کول او تاریخ بدلول. د ټول کلستر حالت په Git ذخیره کې زیرمه شوی، او ځای پرځای کول یوازې د ژمنو له لارې تازه کیږي. سربیره پردې ، ټول بدلونونه د ژمنې تاریخ په کارولو سره تعقیب کیدی شي.
- د پیژندل شوي Git کمانډونو په کارولو سره رول بیک. ساده
git resetتاسو ته اجازه درکوي په ګمارلو کې بدلونونه بیا تنظیم کړئ؛ تیر حالتونه تل شتون لري. - د لاسرسي کنټرول چمتو دی. عموما، د Git سیسټم ډیری حساس معلومات لري، نو ډیری شرکتونه د هغې ساتنې ته ځانګړې پاملرنه کوي. په دې اساس، دا محافظت د ګمارنې سره په عملیاتو کې هم پلي کیږي.
- د ګمارنې لپاره پالیسۍ. ډیری Git سیسټمونه په اصل کې د څانګې لخوا د څانګې پالیسي ملاتړ کوي — د بیلګې په توګه، یوازې د پلټ غوښتنې کولی شي ماسټر تازه کړي، او بدلونونه باید د ټیم بل غړي لخوا بیاکتنه او ومنل شي. لکه څنګه چې د لاسرسي کنټرول سره، ورته پالیسۍ د ګمارلو تازه معلوماتو کې پلي کیږي.
لکه څنګه چې تاسو لیدلی شئ، د GitOps میتود ډیری ګټې شتون لري. په تیر کال کې، دوه طریقې ځانګړی شهرت ترلاسه کړ. یو د فشار پر بنسټ دی، بل یې د پل پر بنسټ دی. مخکې لدې چې موږ دوی ته وګورو ، راځئ لومړی وګورو چې د کوبرنیټس ځانګړي ګمارنې څه ډول ښکاري.
د ځای پرځای کولو میتودونه
په وروستیو کلونو کې، Kubernetes د ګمارنې لپاره مختلف میتودونه او وسایل رامینځته کړي:
- د اصلي Kubernetes/Kustomize ټیمپلیټونو پراساس. دا په Kubernetes کې د غوښتنلیکونو ځای پرځای کولو ترټولو اسانه لار ده. پراختیا کونکی لومړني YAML فایلونه رامینځته کوي او پلي کوي. د ورته ټیمپلیټونو په دوامداره توګه له لیکلو څخه د خلاصون لپاره ، کوسټومیز رامینځته شوی (دا د کوبرنیټس ټیمپلیټونه په ماډلونو بدلوي). نوټ. ژباړه: Kustomize په kubectl کې مدغم شوی دی .
- د هیلم چارټونه. د هیلم چارټونه تاسو ته اجازه درکوي د ټیمپلیټونو سیټ جوړ کړئ، انټ کانټینرونه، سایډ کارونه، او داسې نور، کوم چې د ټیمپلیټ پر بنسټ د طریقې په پرتله د انعطاف وړ حساس کولو اختیارونو سره د غوښتنلیکونو ځای پرځای کولو لپاره کارول کیږي. دا میتود د ټیمپلیټ شوي YAML فایلونو پراساس دی. هیلم دوی د مختلفو پیرامیټونو سره ډکوي او بیا یې ټیلر ته لیږي، د کلستر یوه برخه چې کلستر ته یې ځای پرځای کوي او تازه کولو او رول بیک ته اجازه ورکوي. مهمه خبره دا ده چې هیلم په اصل کې یوازې مطلوب ارزښتونه په ټیمپلیټونو کې داخلوي او بیا یې په ورته ډول پلي کوي لکه څنګه چې په دودیز چلند کې ترسره کیږي. (په دې اړه نور ولولئ چې دا ټول څنګه کار کوي او تاسو څنګه کولی شئ دا زموږ کې وکاروئ - نږدې ژباړه.). د چمتو شوي هیلم چارټونو پراخه ډولونه شتون لري چې د دندو پراخه لړۍ پوښي.
- بدیل وسیلې. ډیری بدیل وسایل شتون لري. هغه څه چې دوی ټول پکې مشترک دي دا دي چې دوی ځینې ټیمپلیټ فایلونه د Kubernetes - لوستلو وړ YAML فایلونو ته اړوي او بیا یې کاروي.
زموږ په کار کې، موږ په دوامداره توګه د مهمو وسیلو لپاره د هیلم چارټونه کاروو (ځکه چې دوی لا دمخه ډیر شیان چمتو کړي، کوم چې ژوند خورا اسانه کوي) او "خالص" Kubernetes YAML فایلونه زموږ د خپلو غوښتنلیکونو ځای پرځای کولو لپاره.
کش کړئ او فشار ورکړئ
زما په وروستي بلاګ پوسټونو کې، ما وسیله معرفي کړه ، کوم چې تاسو ته اجازه درکوي د ګیټ ذخیره ته ټیمپلیټونه ژمن کړئ او د کانټینر د هرې ژمنې یا فشار وروسته پلي کول تازه کړئ. زما تجربه ښیې چې دا وسیله د پل تګ لارې په وده کې یو له اصلي څخه دی ، نو زه به ډیری وختونه ورته مراجعه وکړم. که تاسو غواړئ د دې کارولو څرنګوالي په اړه نور معلومات ترلاسه کړئ ، دلته .
نو! د GitOps کارولو ټولې ګټې د دواړو طریقو لپاره ورته پاتې دي.
د کشولو پر بنسټ چلند
د پلولو طریقه د دې حقیقت پراساس ده چې ټول بدلونونه د کلستر دننه پلي کیږي. په کلستر کې یو آپریټر شتون لري چې په منظم ډول د اړونده ګیټ او ډاکر راجسټری ذخیره چیک کوي. که دوی ته کوم بدلون راشي، د کلستر حالت په داخلي توګه تازه کیږي. دا پروسه عموما خورا خوندي ګڼل کیږي، ځکه چې هیڅ بهرنی مراجع د کلستر مدیر حقونو ته لاسرسی نلري.
پرو:
- هیڅ بهرنی پیرودونکی حق نلري چې په کلستر کې بدلون راولي؛ ټول تازه معلومات له دننه څخه بهر شوي.
- ځینې وسیلې تاسو ته اجازه درکوي چې د هیلم چارټ تازه معلومات همغږي کړئ او کلسټر سره یې وصل کړئ.
- د ډاکر راجسټری د نوي نسخو لپاره سکین کیدی شي. که نوی عکس شتون ولري ، د Git ذخیره او ځای په ځای کول نوي نسخې ته تازه کیږي.
- د پل وسیلې په مختلف نوم ځایونو کې د مختلف Git ذخیره کولو او اجازو سره توزیع کیدی شي. د دې څخه مننه، یو څو اړخیز ماډل کارول کیدی شي. د مثال په توګه، A ټیم ممکن د نوم ځای A وکاروي، ټیم B ممکن د نوم ځای B وکاروي، او د زیربنا ټیم ممکن نړیوال ځای وکاروي.
- د یوې قاعدې په توګه، وسایل خورا لږ وزن لري.
- د وسیلو سره یوځای شوی لکه آپریټر ، رازونه د Git ذخیره کې کوډ شوي ذخیره کیدی شي او په کلستر کې بیرته ترلاسه کیدی شي.
- د CD پایپ لاینونو سره هیڅ اړیکه نشته ځکه چې ګمارنې په کلستر کې واقع کیږي.
Минусы:
- د هیلم چارټونو څخه د ګمارلو رازونو اداره کول د منظمو په پرتله خورا ستونزمن دي، ځکه چې دوی باید لومړی د مهر شوي رازونو په بڼه تولید شي، بیا د داخلي آپریټر لخوا ډیکریټ شوي، او یوازې وروسته یې د پل وسیلې لپاره شتون لري. بیا تاسو کولی شئ په هیلم کې خوشې کول د دمخه ځای پرځای شوي رازونو ارزښتونو سره پرمخ وړئ. ترټولو اسانه لاره دا ده چې د ټولو هیلم ارزښتونو سره یو راز رامینځته کړئ چې د پلي کولو لپاره کارول کیږي ، ډیکریټ یې کړئ او ګیټ ته یې ژمن کړئ.
- کله چې تاسو د پلولو طریقه اخلئ، تاسو د وسیلو د ایستلو سره تړلي یاست. دا په کلستر کې د ګمارنې پروسې دودیز کولو وړتیا محدودوي. د مثال په توګه، Kustomize د دې حقیقت له مخې پیچلی دی چې دا باید مخکې له دې چې وروستي ټیمپلیټونه Git ته ژمن وي پرمخ ځي. زه دا نه وایم چې تاسو نشئ کولی واحد وسیلې وکاروئ ، مګر دا ستاسو د ګمارنې پروسې کې مدغم کول خورا ستونزمن دي.
د فشار پر بنسټ چلند
د فشار په طریقه کې، یو بهرنی سیسټم (په عمده توګه د CD پایپ لاینونه) د Git ذخیره کولو ژمنې وروسته یا که پخوانی CI پایپ لاین بریالی وي کلستر ته ځای پرځای کول پیلوي. په دې طریقه، سیسټم کلستر ته لاس رسی لري.
Плюсы:
- امنیت د Git ذخیره کولو او جوړولو پایپ لاین لخوا ټاکل کیږي.
- د هیلم چارټونو ځای په ځای کول اسانه دي او د هیلم پلگ انونو ملاتړ کوي.
- د رازونو اداره کول اسانه دي ځکه چې رازونه په پایپ لاینونو کې کارول کیدی شي او په Git کې کوډ شوي ذخیره کیدی شي (د کارونکي غوره توبونو پورې اړه لري).
- د یوې ځانګړې وسیلې سره هیڅ تړاو نشته، ځکه چې هر ډول کارول کیدی شي.
- د کانټینر نسخه تازه کول د جوړولو پایپ لاین لخوا پیل کیدی شي.
Минусы:
- د کلستر لاسرسي ډاټا د جوړونې سیسټم دننه ده.
- د پلي کولو کانټینرونو تازه کول لاهم د پل پروسې سره اسانه دي.
- د CD سیسټم باندې خورا ډیر انحصار ، ځکه چې هغه پایپ لاینونه چې موږ ورته اړتیا لرو ممکن په اصل کې د ګیتلاب چلونکو لپاره لیکل شوي وي ، او بیا ټیم پریکړه کوي چې Azure DevOps یا Jenkins ته لاړ شي ... او باید د جوړ شوي پایپ لاینونو لوی شمیر مهاجرت وکړي.
پایلې: فشار یا کش کول؟
لکه څنګه چې معمولا قضیه وي، هره طریقه خپل ګټې او زیانونه لري. ځینې کارونه له یوه سره اسانه او له بل سره ډېر ستونزمن وي. په لومړي سر کې ما په لاسي ډول ګمارنې ترسره کولې، مګر وروسته له دې چې ما د ویو فلکس په اړه یو څو مقالې ولیدې، ما پریکړه وکړه چې د ټولو پروژو لپاره د GitOps پروسې پلي کړم. د بنسټیزو ټیمپلیټونو لپاره دا اسانه وه، مګر بیا ما د هیلم چارټونو سره ستونزې پیل کړې. په هغه وخت کې، ویو فلکس یوازې د هیلم چارټ آپریټر لومړنۍ نسخه وړاندې کړه، مګر حتی اوس هم ځینې دندې په لاسي ډول د رازونو رامینځته کولو او پلي کولو اړتیا له امله خورا ستونزمن دي. تاسو استدلال کولی شئ چې د پلولو طریقه خورا خوندي ده ځکه چې د کلستر اسناد د کلستر څخه بهر د لاسرسي وړ ندي، دا خورا ډیر خوندي کوي چې دا د اضافي هڅو ارزښت لري.
د یو څه فکر کولو وروسته، زه ناڅاپي پایلې ته ورسیدم چې دا داسې نه ده. که موږ د اجزاو په اړه وغږیږو چې اعظمي محافظت ته اړتیا لري ، پدې لیست کې به پټ ذخیره ، CI/CD سیسټمونه ، او د Git ذخیره شامل وي. د دوی دننه معلومات خورا زیان منونکي دي او اعظمي محافظت ته اړتیا لري. سربیره پردې ، که څوک ستاسو د Git ذخیره ته ننوځي او کولی شي هلته کوډ فشار ورکړي ، دوی کولی شي هر هغه څه ځای په ځای کړي چې دوی یې غواړي (که دا پل یا فشار وي) او د کلستر سیسټمونو ته نفوذ وکړي. په دې توګه، ترټولو مهمې برخې چې باید خوندي شي د Git ذخیره او CI/CD سیسټمونه دي، نه د کلستر اعتبار. که تاسو د دې ډول سیسټمونو لپاره ښه تنظیم شوي پالیسي او امنیتي کنټرولونه لرئ، او د کلستر اسناد یوازې په پایپ لاینونو کې د رازونو په توګه استخراج شوي، د پلې لارې اضافه امنیت ممکن هغومره ارزښتناکه نه وي لکه څنګه چې په اصل کې فکر کیږي.
نو، که د پلې کولو طریقه ډیره سخته وي او امنیتي ګټه نه ورکوي، ایا دا منطقي نه ده چې یوازې د فشار تګلاره وکاروئ؟ مګر یو څوک ممکن استدلال وکړي چې د فشار په لاره کې تاسو د CD سیسټم سره ډیر تړلي یاست او شاید، دا به غوره وي چې دا کار ونه کړئ ترڅو په راتلونکي کې د مهاجرت ترسره کول اسانه وي.
زما په نظر (د تل په څیر)، تاسو باید هغه څه وکاروئ چې د یوې ځانګړې قضیې لپاره خورا مناسب وي یا یوځای کړئ. په شخصي توګه، زه دواړه طریقې کاروم: د پل پر بنسټ د ګمارلو لپاره د ویو فلکس چې ډیری یې زموږ خپل خدمتونه شامل دي، او د هیلم او پلگ انونو سره د فشار طریقه، کوم چې په کلستر کې د هیلم چارټونو پلي کول اسانه کوي او تاسو ته اجازه درکوي چې په بې ساري ډول رازونه رامینځته کړئ. زه فکر کوم چې هیڅکله به یو واحد حل د ټولو قضیو لپاره مناسب نه وي ، ځکه چې تل ډیری باریکي شتون لري او دوی په ځانګړي غوښتنلیک پورې اړه لري. دا ویل کیږي، زه د GitOps ډیره سپارښتنه کوم - دا ژوند خورا اسانه کوي او امنیت ښه کوي.
زه امید لرم چې پدې موضوع کې زما تجربه به تاسو سره مرسته وکړي پریکړه وکړي چې کوم میتود ستاسو د ګمارنې ډول لپاره خورا مناسب دی ، او زه به ستاسو د نظر په اوریدو خوښ شم.
د ژباړونکي څخه PS یادښت
د پل موډل نیمګړتیا دا ده چې په ګیټ کې وړاندې شوي څرګندونه ایښودل ګران دي ، مګر هیڅ زیان شتون نلري چې د پل موډل کې د CD پایپ لاین له رول آوټ څخه جلا ژوند کوي او په لازمي ډول د کټګورۍ پایپ لاین کیږي. په دوامداره توګه پلي کول. له همدې امله، لا زیاتو هڅو ته اړتیا ده چې د ټولو ګمارلو څخه د دوی حالت راټول کړي او په یو ډول د CD سیسټم ته په غوره توګه د logs/status ته لاسرسی چمتو کړي.
پدې معنی ، د فشار ماډل موږ ته اجازه راکوي چې لږترلږه د رول آوټ ځینې تضمین چمتو کړو ، ځکه چې د پایپ لاین ژوند د رول آوټ ژوند سره مساوي کیدی شي.
موږ دواړه ماډلونه هڅه وکړه او د مقالې لیکوال په څیر ورته پایلې ته ورسیدو:
- د پل ماډل زموږ لپاره مناسب دی چې په ډیری کلسترونو کې د سیسټم برخو تازه معلومات تنظیم کړئ (وګورئ. ).
- د GitLab CI پر بنسټ د پش ماډل د هیلم چارټونو په کارولو سره د غوښتنلیکونو رول کولو لپاره ښه مناسب دی. په ورته وخت کې، د پایپ لاینونو دننه د ځای پرځای کولو رول د وسیلې په کارولو سره څارل کیږي . په هرصورت ، زموږ د دې پروژې په شرایطو کې ، موږ دوامداره "GitOps" واوریدل کله چې موږ په KubeCon Europe'19 کې زموږ په موقف کې د DevOps انجینرانو فشاري ستونزو په اړه بحث وکړ.
د ژباړونکي څخه PPS
زموږ په بلاګ کې هم ولولئ:
- «»
- «»
- «»
- «".
یوازې راجستر شوي کاروونکي کولی شي په سروې کې برخه واخلي. مهرباني وکړئ
ایا تاسو GitOps کاروئ؟
-
هو، د تګ لاره
-
هو، فشار ورکړئ
-
هو، کش کړئ + فشار ورکړئ
-
هو، بل څه
-
نه
30 کاروونکو رایه ورکړه. 10 کاروونکي منع شوي.
سرچینه: www.habr.com