GitOps چیست؟

توجه داشته باشید. ترجمه: پس از انتشار اخیر ماده در مورد روش‌های کشش و فشار در GitOps، ما به طور کلی به این مدل علاقه‌مند بودیم، اما انتشارات روسی زبان بسیار کمی در مورد این موضوع وجود داشت (به سادگی در هابره وجود ندارد). بنابراین، ما خوشحالیم که ترجمه مقاله دیگری را - البته تقریباً یک سال پیش - به شما توجه کنیم! - از Weaveworks، که رئیس آن اصطلاح "GitOps" را ابداع کرد. متن ماهیت رویکرد و تفاوت های کلیدی با رویکردهای موجود را توضیح می دهد.

یک سال پیش منتشر کردیم مقدمه ای بر GitOps. در آن زمان، نحوه راه‌اندازی یک SaaS کاملاً مبتنی بر Kubernetes توسط تیم Weaveworks را به اشتراک گذاشتیم و مجموعه‌ای از بهترین روش‌های تجویزی را برای استقرار، مدیریت و نظارت در یک محیط بومی ابری توسعه دادیم.

این مقاله محبوب شد. افراد دیگر شروع به صحبت در مورد GitOps کردند و شروع به انتشار ابزارهای جدید برای آن کردند فشار دادن, توسعه, اسرار, توابع, ادغام مداوم و غیره در وب سایت ما ظاهر شد تعداد زیادی انتشارات و موارد استفاده GitOps. اما برخی افراد هنوز سوال دارند. این مدل چه تفاوتی با مدل سنتی دارد؟ زیرساخت به عنوان کد و تحویل مستمر (تحویل مداوم)؟ آیا استفاده از Kubernetes ضروری است؟

ما به زودی متوجه شدیم که شرح جدیدی مورد نیاز است و ارائه می دهد:

1. تعداد زیادی مثال و داستان؛
2. تعریف خاص GitOps.
3. مقایسه با تحویل مستمر سنتی.

در این مقاله سعی کرده ایم به تمامی این موضوعات بپردازیم. این یک مقدمه به روز شده برای GitOps و یک توسعه دهنده و دیدگاه CI/CD ارائه می دهد. ما در درجه اول بر روی Kubernetes تمرکز می کنیم، اگرچه مدل را می توان تعمیم داد.

با GitOps آشنا شوید

آلیس را تصور کنید. او بیمه خانواده را اداره می‌کند، که بیمه سلامت، خودرو، خانه و مسافرت را به افرادی ارائه می‌کند که بیش از حد مشغول هستند و نمی‌توانند خودشان جزئیات قراردادها را بفهمند. زمانی که آلیس به عنوان دانشمند داده در یک بانک کار می کرد، کسب و کار او به عنوان یک پروژه جانبی شروع شد. یک روز او متوجه شد که می تواند از الگوریتم های کامپیوتری پیشرفته برای تجزیه و تحلیل موثرتر داده ها و فرموله کردن بسته های بیمه استفاده کند. سرمایه گذاران این پروژه را تامین مالی کردند و اکنون شرکت او سالانه بیش از 20 میلیون دلار درآمد دارد و به سرعت در حال رشد است. در حال حاضر 180 نفر در سمت های مختلف مشغول به کار هستند. این شامل یک تیم فناوری است که وب سایت، پایگاه داده را توسعه می دهد، نگهداری می کند و پایگاه مشتری را تجزیه و تحلیل می کند. این تیم 60 نفره توسط باب، مدیر فنی شرکت هدایت می شود.

تیم باب سیستم های تولید را در فضای ابری مستقر می کند. برنامه‌های اصلی آن‌ها با بهره‌گیری از Kubernetes در Google Cloud بر روی GKE اجرا می‌شوند. علاوه بر این، آنها از ابزارهای مختلف داده و تجزیه و تحلیل در کار خود استفاده می کنند.

بیمه خانواده قصد استفاده از کانتینرها را نداشت، اما در شور و شوق داکر گرفتار شد. این شرکت به زودی متوجه شد که GKE استقرار خوشه‌ها را برای آزمایش ویژگی‌های جدید آسان کرده است. Jenkins برای CI و Quay برای سازماندهی رجیستری کانتینر اضافه شدند، اسکریپت هایی برای Jenkins نوشته شد که کانتینرها و پیکربندی های جدیدی را به GKE منتقل کردند.

مدتی گذشت. آلیس و باب از عملکرد رویکرد انتخابی خود و تأثیر آن بر تجارت ناامید شدند. معرفی کانتینرها آنطور که تیم انتظار داشت بهره وری را بهبود بخشید. گاهی اوقات استقرارها خراب می شدند و مشخص نبود که آیا تغییرات کد مقصر هستند یا خیر. همچنین مشخص شد که ردیابی تغییرات پیکربندی دشوار است. اغلب لازم بود یک خوشه جدید ایجاد کنیم و برنامه ها را به آن منتقل کنیم، زیرا این ساده ترین راه برای از بین بردن آشفتگی سیستم بود. آلیس می ترسید که با توسعه برنامه، وضعیت بدتر شود (علاوه بر این، یک پروژه جدید مبتنی بر یادگیری ماشین در حال تولید بود). باب بیشتر کار را خودکار کرده بود و نمی‌دانست که چرا خط لوله هنوز ناپایدار است، مقیاس خوبی ندارد و نیاز به مداخله دستی دوره‌ای دارد؟

سپس آنها در مورد GitOps یاد گرفتند. این تصمیم دقیقاً همان چیزی بود که آنها برای حرکت با اطمینان به جلو نیاز داشتند.

آلیس و باب سال‌هاست که درباره Git، DevOps و زیرساخت به‌عنوان گردش‌کار کد می‌شنوند. چیزی که در مورد GitOps منحصر به فرد است این است که مجموعه ای از بهترین شیوه ها - هم قطعی و هم هنجاری - را برای اجرای این ایده ها در زمینه Kubernetes به ارمغان می آورد. این تم بارها و بارها افزایش یافت، از جمله در وبلاگ Weaveworks.

بیمه خانواده تصمیم به پیاده سازی GitOps می گیرد. این شرکت اکنون یک مدل عملیات خودکار دارد که با Kubernetes و کمباین ها سازگار است سرعت با ثباتچون آن ها:

• دریافتند که بهره وری تیم بدون اینکه کسی دیوانه شود دو برابر شده است.
• سرویس اسکریپت ها را متوقف کرد. در عوض، آنها اکنون می توانند بر روی ویژگی های جدید تمرکز کنند و روش های مهندسی را بهبود بخشند - به عنوان مثال، معرفی قناری ها و بهبود آزمایش.
• ما روند استقرار را بهبود بخشیده ایم به طوری که به ندرت خراب می شود.
• فرصتی برای بازیابی استقرار پس از شکست جزئی بدون مداخله دستی بدست آورد.
• خریداری شده استفاده شدهоاطمینان بیشتر در سیستم های تحویل آلیس و باب کشف کردند که می توانند تیم را به تیم های میکروسرویس تقسیم کنند که به طور موازی کار می کنند.
• می تواند هر روز 30-50 تغییر در پروژه با تلاش هر گروه ایجاد کند و تکنیک های جدید را امتحان کند.
• جذب توسعه دهندگان جدید به پروژه آسان است، کسانی که این فرصت را دارند تا با استفاده از درخواست های کشش ظرف چند ساعت به روز رسانی های تولید را ارائه دهند.
• به راحتی ممیزی را در چارچوب SOC2 عبور دهید (برای انطباق ارائه دهندگان خدمات با الزامات مدیریت داده ایمن؛ برای مثال، بیشتر بخوانید، اینجا - تقریبا ترجمه.).

چی شد؟

GitOps دو چیز است:

1. مدل عملیاتی برای Kubernetes و بومی ابر. مجموعه ای از بهترین شیوه ها را برای استقرار، مدیریت و نظارت بر خوشه ها و برنامه های کاربردی کانتینری ارائه می دهد. تعریف زیبا در فرم یک اسلاید از لوئیس فاسیرا:
2. مسیری برای ایجاد یک محیط مدیریت برنامه‌نویس محور. ما گردش کار Git را هم برای عملیات و هم برای توسعه اعمال می کنیم. لطفاً توجه داشته باشید که این فقط مربوط به Git push نیست، بلکه در مورد سازماندهی کل مجموعه ابزارهای CI/CD و UI/UX است.

چند کلمه در مورد Git

اگر با سیستم‌های کنترل نسخه و گردش کار مبتنی بر Git آشنا نیستید، به شدت توصیه می‌کنیم در مورد آنها بیاموزید. کار با شعبه ها و درخواست های کشش ممکن است در ابتدا مانند جادوی سیاه به نظر برسد، اما مزایای آن ارزش تلاش را دارد. اینجا مقاله خوب برای شروع.

Kubernetes چگونه کار می کند

در داستان ما، آلیس و باب پس از مدتی کار با Kubernetes به GitOps روی آوردند. در واقع، GitOps ارتباط نزدیکی با Kubernetes دارد - این یک مدل عملیاتی برای زیرساخت ها و برنامه های کاربردی مبتنی بر Kubernetes است.

Kubernetes چه چیزی به کاربران می دهد؟

در اینجا برخی از ویژگی های اصلی آورده شده است:

1. در مدل Kubernetes، همه چیز را می توان به صورت اظهاری توصیف کرد.
2. سرور Kubernetes API این اعلان را به عنوان ورودی دریافت می کند و سپس به طور مداوم تلاش می کند تا خوشه را به وضعیتی که در اعلان توضیح داده شده است برساند.
3. اعلامیه ها برای توصیف و مدیریت طیف گسترده ای از بارهای کاری - "برنامه ها" کافی است.
4. در نتیجه، تغییرات در برنامه و کلاستر به دلیل موارد زیر رخ می دهد:
   • تغییرات در تصاویر ظرف؛
   • تغییرات در مشخصات اعلامی؛
   • خطاهای محیط - به عنوان مثال، خرابی کانتینر.

قابلیت های بزرگ همگرایی Kubernetes

هنگامی که یک مدیر تغییرات پیکربندی را انجام می دهد، ارکستراتور Kubernetes آنها را تا زمانی که وضعیت آن در خوشه باشد اعمال می کند. به پیکربندی جدید نزدیک نخواهد شد. این مدل برای هر منبع Kubernetes کار می کند و با تعاریف منابع سفارشی (CRD) قابل توسعه است. بنابراین، استقرار Kubernetes دارای ویژگی های فوق العاده زیر است:

• اتوماسیون: به‌روزرسانی‌های Kubernetes مکانیزمی را برای خودکارسازی فرآیند اعمال تغییرات به‌موقع و برازنده ارائه می‌کنند.
• همگرایی: Kubernetes تا زمانی که موفقیت آمیز نباشد به تلاش برای به روز رسانی ادامه خواهد داد.
• ناتوانی: کاربردهای مکرر همگرایی به همین نتیجه منجر می شود.
• جبرگرایی: هنگامی که منابع کافی باشد، وضعیت خوشه به روز شده تنها به وضعیت مورد نظر بستگی دارد.

GitOps چگونه کار می کند

ما به اندازه کافی در مورد Kubernetes یاد گرفته ایم تا نحوه عملکرد GitOps را توضیح دهیم.

به تیم های ریزخدمات بیمه خانواده برگردیم. معمولا باید چه کار کنند؟ به لیست زیر نگاه کنید (اگر موارد موجود در آن عجیب یا ناآشنا به نظر می رسد، لطفا از انتقاد خودداری کنید و با ما همراه باشید). اینها فقط نمونه هایی از گردش کار مبتنی بر جنکینز هستند. هنگام کار با ابزارهای دیگر، بسیاری از فرآیندهای دیگر وجود دارد.

نکته اصلی این است که می بینیم که هر به روز رسانی با تغییراتی در فایل های پیکربندی و مخازن Git به پایان می رسد. این تغییرات در Git باعث می شود که "اپراتور GitOps" خوشه را به روز کند:

1. فرآیند کار: "ساخت جنکینز - شاخه اصلی'.
فهرست وظیفه یا لیست کار:

• جنکینز تصاویر برچسب گذاری شده را به اسکله هل می دهد.
• جنکینز پیکربندی و نمودارهای Helm را به سطل ذخیره اصلی فشار می دهد.
• تابع ابر پیکربندی و نمودارها را از سطل ذخیره سازی اصلی در مخزن اصلی Git کپی می کند.
• اپراتور GitOps خوشه را به روز می کند.

2. ساخت جنکینز - شاخه آزادسازی یا رفع فوری:

• جنکینز تصاویر بدون برچسب را به اسکله هل می دهد.
• جنکینز پیکربندی و نمودارهای Helm را به سطل ذخیره سازی مرحله بندی فشار می دهد.
• تابع ابر پیکربندی و نمودارها را از سطل ذخیره سازی مرحله بندی به مخزن مرحله بندی Git کپی می کند.
• اپراتور GitOps خوشه را به روز می کند.

3. جنکینز ساخت - توسعه یا ویژگی شاخه:

• جنکینز تصاویر بدون برچسب را به اسکله هل می دهد.
• جنکینز پیکربندی و نمودارهای Helm را به سطل ذخیره سازی توسعه فشار می دهد.
• تابع ابر پیکربندی و نمودارها را از سطل ذخیره سازی توسعه به مخزن توسعه Git کپی می کند.
• اپراتور GitOps خوشه را به روز می کند.

4. افزودن مشتری جدید:

• مدیر یا سرپرست (LCM/ops) با Gradle تماس می‌گیرد تا در ابتدا متعادل‌کننده‌های بار شبکه (NLB) را مستقر و پیکربندی کند.
• LCM/ops یک پیکربندی جدید را برای آماده کردن استقرار برای به‌روزرسانی‌ها انجام می‌دهد.
• اپراتور GitOps خوشه را به روز می کند.

توضیح مختصری از GitOps

1. وضعیت مطلوب کل سیستم را با استفاده از مشخصات اعلامی برای هر محیط توصیف کنید (در داستان ما، تیم باب کل پیکربندی سیستم را در Git تعریف می کند).
   • مخزن Git تنها منبع حقیقت در مورد وضعیت مطلوب کل سیستم است.
   • تمام تغییرات در حالت مورد نظر از طریق commit در Git انجام می شود.
   • تمام پارامترهای خوشه مورد نظر نیز در خود خوشه قابل مشاهده هستند. به این ترتیب می توانیم تعیین کنیم که آیا آنها منطبق هستند (همگرا، همگرا) یا متفاوت (واگرا، واگرایی) حالات مورد نظر و مشاهده شده.
2. اگر حالت های مورد نظر و مشاهده شده متفاوت باشد، آنگاه:
   • یک مکانیسم همگرایی وجود دارد که دیر یا زود به طور خودکار حالت های هدف و مشاهده شده را همگام می کند. در داخل خوشه، Kubernetes این کار را انجام می دهد.
   • این فرآیند بلافاصله با یک هشدار "تغییر متعهد" شروع می شود.
   • پس از مدتی قابل تنظیم، در صورت متفاوت بودن حالت ها، می توان یک هشدار "تفاوت" ارسال کرد.
3. به این ترتیب، تمام commit ها در Git باعث به روز رسانی های قابل تایید و غیرقابل اعتماد در خوشه می شوند.
   • بازگشت به حالت همگرایی به حالت مطلوب قبلی است.
4. همگرایی نهایی است. وقوع آن توسط:
   • هیچ هشدار متفاوتی برای مدت زمان مشخصی وجود ندارد.
   • هشدار "همگرا" (به عنوان مثال webhook، رویداد Writback Git).

واگرایی چیست؟

بیایید دوباره تکرار کنیم: تمام خصوصیات خوشه مورد نظر باید در خود خوشه قابل مشاهده باشد.

چند نمونه از واگرایی:

• تغییر در فایل پیکربندی به دلیل ادغام شاخه ها در Git.
• تغییر در فایل پیکربندی به دلیل یک commit Git که توسط مشتری GUI انجام شده است.
• تغییرات متعدد در حالت دلخواه به دلیل روابط عمومی در Git و به دنبال آن ایجاد تصویر کانتینر و تغییرات پیکربندی.
• تغییر در وضعیت خوشه به دلیل یک خطا، تضاد منابع منجر به "رفتار بد" یا صرفاً انحراف تصادفی از حالت اولیه.

مکانیسم همگرایی چیست؟

چند نمونه:

• برای کانتینرها و خوشه ها، مکانیسم همگرایی توسط Kubernetes ارائه شده است.
• از همین مکانیسم می توان برای مدیریت برنامه ها و طرح های مبتنی بر Kubernetes (مانند Istio و Kubeflow) استفاده کرد.
• مکانیزمی برای مدیریت تعامل عملیاتی بین Kubernetes، مخازن تصویر و Git فراهم می کند اپراتور GitOps Weave Flux، که بخشی است ابر ببافید.
• برای ماشین های پایه، مکانیسم همگرایی باید اعلامی و مستقل باشد. از تجربه خودمان می توانیم بگوییم Terraform نزدیک به این تعریف است، اما همچنان به کنترل انسان نیاز دارد. از این نظر، GitOps سنت زیرساخت را به عنوان کد گسترش می دهد.

GitOps Git را با موتور همگرایی عالی Kubernetes ترکیب می کند تا مدلی برای بهره برداری ارائه کند.

GitOps به ما اجازه می دهد بگوییم: فقط سیستم هایی که قابل توصیف و مشاهده هستند می توانند خودکار و کنترل شوند.

GitOps برای کل پشته بومی ابر (به عنوان مثال Terraform و غیره) در نظر گرفته شده است.

GitOps فقط Kubernetes نیست. ما می خواهیم کل سیستم به صورت اعلامی هدایت شود و از همگرایی استفاده کند. منظور ما از کل سیستم مجموعه‌ای از محیط‌هایی است که با Kubernetes کار می‌کنند - به عنوان مثال، "dev cluster 1"، "production" و غیره. هر محیط شامل ماشین‌ها، خوشه‌ها، برنامه‌ها و همچنین رابط‌هایی برای سرویس‌های خارجی است که داده‌ها، نظارت را ارائه می‌کنند. و غیره

توجه داشته باشید که Terraform در این مورد چقدر برای مشکل بوت استرپینگ اهمیت دارد. Kubernetes باید در جایی مستقر شود، و استفاده از Terraform به این معنی است که می‌توانیم همان گردش‌های کاری GitOps را برای ایجاد لایه کنترلی که زیربنای Kubernetes و برنامه‌ها است، اعمال کنیم. این بهترین تمرین مفید است.

تمرکز زیادی روی اعمال مفاهیم GitOps در لایه‌های بالای Kubernetes وجود دارد. در حال حاضر، راه حل هایی از نوع GitOps برای Istio، Helm، Ksonnet، OpenFaaS و Kubeflow و همچنین، به عنوان مثال، برای Pulumi وجود دارد که لایه ای برای توسعه برنامه های کاربردی برای cloud native ایجاد می کند.

Kubernetes CI/CD: مقایسه GitOps با سایر رویکردها

همانطور که گفته شد، GitOps دو چیز است:

1. مدل عملیاتی Kubernetes و بومی ابر که در بالا توضیح داده شد.
2. مسیری به سمت یک محیط مدیریت برنامه‌نویس محور.

برای بسیاری، GitOps در درجه اول یک گردش کار مبتنی بر فشارهای Git است. ما هم او را دوست داریم. اما این همه ماجرا نیست: اکنون به خطوط لوله CI/CD نگاهی بیندازیم.

GitOps استقرار مداوم (CD) را برای Kubernetes فعال می کند

GitOps مکانیزم استقرار مداوم را ارائه می دهد که نیاز به "سیستم های مدیریت استقرار" جداگانه را از بین می برد. Kubernetes همه کارها را برای شما انجام می دهد.

• به روز رسانی برنامه نیاز به به روز رسانی در Git دارد. این یک به روز رسانی تراکنشی به وضعیت مورد نظر است. سپس "استقرار" در داخل خوشه توسط خود Kubernetes بر اساس توضیحات به روز شده انجام می شود.
• با توجه به ماهیت نحوه عملکرد Kubernetes، این به روز رسانی ها همگرا هستند. این مکانیسمی را برای استقرار مداوم فراهم می کند که در آن همه به روز رسانی ها اتمی هستند.
• توجه: ابر ببافید یک اپراتور GitOps را ارائه می دهد که Git و Kubernetes را ادغام می کند و اجازه می دهد CD با تطبیق وضعیت مطلوب و فعلی خوشه انجام شود.

بدون کوبکتل و اسکریپت

شما باید از استفاده از Kubectl برای به روز رسانی کلاستر خود اجتناب کنید و به خصوص از استفاده از اسکریپت برای گروه بندی دستورات kubectl خودداری کنید. در عوض، با خط لوله GitOps، کاربر می تواند خوشه Kubernetes خود را از طریق Git به روز کند.

مزایا عبارتند از:

1. درست. گروهی از به روز رسانی ها را می توان اعمال کرد، همگرا کرد و در نهایت تایید کرد و ما را به هدف استقرار اتمی نزدیکتر می کند. در مقابل، استفاده از اسکریپت ها هیچ تضمینی برای همگرایی ارائه نمی دهد (در زیر در این مورد بیشتر توضیح می دهیم).
2. امنیت. نقل قول Kelsey Hightower: "دسترسی به خوشه Kubernetes خود را به ابزارهای اتوماسیون و مدیرانی که مسئول اشکال زدایی یا نگهداری آن هستند محدود کنید." همچنین ببینید نشریه من در مورد ایمنی و رعایت مشخصات فنی و همچنین مقاله ای در مورد هک Homebrew با سرقت اعتبارنامه از فیلمنامه جنکینز که به دقت نوشته شده است.
3. تجربه ی کاربر. Kubectl مکانیک مدل شی Kubernetes را که کاملاً پیچیده است، آشکار می کند. در حالت ایده آل، کاربران باید با سیستم در سطح بالاتری از انتزاع تعامل داشته باشند. در اینجا دوباره به کلسی اشاره می کنم و تماشا را توصیه می کنم چنین رزومه ای.

تفاوت بین CI و CD

GitOps مدل های CI/CD موجود را بهبود می بخشد.

یک سرور مدرن CI یک ابزار ارکستراسیون است. به ویژه، ابزاری برای هماهنگی خطوط لوله CI است. اینها شامل ساخت، آزمایش، ادغام در ترانک و غیره می‌شود. سرورهای CI مدیریت خطوط لوله چند مرحله‌ای پیچیده را خودکار می‌کنند. یک وسوسه رایج این است که مجموعه‌ای از به‌روزرسانی‌های Kubernetes را اسکریپت کنید و آن را به عنوان بخشی از خط لوله اجرا کنید تا تغییرات را در خوشه اعمال کنید. در واقع، این کاری است که بسیاری از کارشناسان انجام می دهند. با این حال، این بهینه نیست، و در اینجا دلیل آن است.

CI باید برای ارسال به‌روزرسانی‌ها به ترانک استفاده شود، و خوشه Kubernetes باید خود را بر اساس آن به‌روزرسانی‌ها تغییر دهد تا سی‌دی را به صورت داخلی مدیریت کند. ما آن را صدا می زنیم مدل کشی برای سی دیبرخلاف مدل CI push. سی دی بخشی است ارکستراسیون زمان اجرا.

چرا سرورهای CI نباید سی دی ها را از طریق به روز رسانی مستقیم در Kubernetes انجام دهند

از سرور CI برای هماهنگ کردن به‌روزرسانی‌های مستقیم Kubernetes به عنوان مجموعه‌ای از کارهای CI استفاده نکنید. این همان ضدالگوی است که ما در مورد آن صحبت می کنیم قبلا گفته شده است در وبلاگ شما

بیایید به آلیس و باب برگردیم.

با چه مشکلاتی مواجه شدند؟ سرور CI Bob تغییرات را در خوشه اعمال می کند، اما اگر در این فرآیند خراب شود، باب نمی داند خوشه در چه وضعیتی است (یا باید باشد) یا چگونه آن را برطرف کند. در صورت موفقیت هم همینطور است.

بیایید فرض کنیم که تیم باب یک تصویر جدید ساخته و سپس استقرارهای خود را برای استقرار تصویر (همه از خط لوله CI) وصله کردند.

اگر تصویر به طور معمول ساخته شود، اما خط لوله شکست بخورد، تیم باید بفهمد:

• آیا آپدیت منتشر شده است؟
• آیا ما یک ساخت جدید راه اندازی می کنیم؟ آیا این منجر به عوارض جانبی غیر ضروری خواهد شد - با امکان داشتن دو ساخت از یک تصویر تغییرناپذیر؟
• آیا قبل از اجرای بیلد باید منتظر آپدیت بعدی باشیم؟
• دقیقا چه مشکلی پیش آمد؟ کدام مراحل باید تکرار شوند (و کدام یک برای تکرار بی خطر هستند)؟

ایجاد یک گردش کار مبتنی بر Git تضمین نمی کند که تیم باب با این مشکلات مواجه نشود. آنها همچنان می توانند با فشار commit، تگ یا برخی پارامترهای دیگر اشتباه کنند. با این حال، این رویکرد هنوز به یک رویکرد صریح همه یا هیچ نزدیک‌تر است.

به طور خلاصه، در اینجا این است که چرا سرورهای CI نباید با CD سروکار داشته باشند:

• اسکریپت های به روز رسانی همیشه قطعی نیستند. اشتباه کردن در آنها آسان است.
• سرورهای CI به مدل خوشه ای اعلامی همگرا نمی شوند.
• تضمین ناتوانی دشوار است. کاربران باید معنای عمیق سیستم را درک کنند.
• بازیابی از یک شکست جزئی دشوارتر است.

نکته در مورد Helm: اگر می خواهید از Helm استفاده کنید، توصیه می کنیم آن را با یک اپراتور GitOps مانند فلاکس-هلم. این به اطمینان از همگرایی کمک می کند. خود هلم نه قطعی است و نه اتمی.

GitOps به عنوان بهترین راه برای پیاده سازی Continuous Delivery برای Kubernetes

تیم آلیس و باب GitOps را پیاده‌سازی می‌کنند و متوجه می‌شوند که کار با محصولات نرم‌افزاری، حفظ عملکرد و ثبات بالا بسیار آسان‌تر شده است. اجازه دهید این مقاله را با تصویری به پایان برسانیم که نشان می دهد رویکرد جدید آنها چگونه به نظر می رسد. به خاطر داشته باشید که ما بیشتر در مورد برنامه ها و خدمات صحبت می کنیم، اما GitOps را می توان برای مدیریت کل یک پلت فرم استفاده کرد.

مدل عامل برای Kubernetes

به نمودار زیر نگاه کنید. Git و مخزن تصویر ظرف را به عنوان منابع مشترک برای دو چرخه زندگی هماهنگ ارائه می کند:

• یک خط لوله ادغام پیوسته که فایل‌ها را در Git می‌خواند و می‌نویسد و می‌تواند یک مخزن از تصاویر کانتینر را به‌روزرسانی کند.
• یک خط لوله Runtime GitOps که استقرار را با مدیریت و قابلیت مشاهده ترکیب می کند. این فایل ها را در Git می خواند و می نویسد و می تواند تصاویر کانتینر را دانلود کند.

یافته های اصلی چیست؟

1. تفکیک نگرانی ها: لطفاً توجه داشته باشید که هر دو خط لوله فقط می توانند با به روز رسانی Git یا مخزن تصویر ارتباط برقرار کنند. به عبارت دیگر، یک فایروال بین CI و محیط زمان اجرا وجود دارد. ما آن را "دیوار آتش تغییر ناپذیری" می نامیم (فایروال تغییرناپذیری)، از آنجایی که تمام به روز رسانی های مخزن نسخه های جدیدی ایجاد می کنند. برای کسب اطلاعات بیشتر در مورد این موضوع، به اسلایدهای 72-87 مراجعه کنید این ارائه.
2. می توانید از هر سرور CI و Git استفاده کنید: GitOps با هر جزء کار می کند. می توانید به استفاده از سرورهای CI و Git، مخازن تصویر و مجموعه های آزمایشی مورد علاقه خود ادامه دهید. تقریباً سایر ابزارهای تحویل مداوم موجود در بازار به سرور CI/Git یا مخزن تصویر خود نیاز دارند. این ممکن است به یک عامل محدود کننده در توسعه ابر بومی تبدیل شود. با GitOps می توانید از ابزارهای آشنا استفاده کنید.
3. رویدادها به عنوان یک ابزار یکپارچه سازی: به محض به روز رسانی داده ها در Git، Weave Flux (یا اپراتور Weave Cloud) زمان اجرا را مطلع می کند. هر زمان که Kubernetes یک مجموعه تغییر را بپذیرد، Git به روز می شود. این یک مدل یکپارچه سازی ساده برای سازماندهی گردش کار برای GitOps، همانطور که در زیر نشان داده شده است، ارائه می دهد.

نتیجه

GitOps تضمین های قوی به روز رسانی مورد نیاز هر ابزار مدرن CI/CD را ارائه می دهد:

• اتوماسیون؛
• همگرایی؛
• ناتوانی؛
• جبرگرایی

این مهم است زیرا یک مدل عملیاتی برای توسعه دهندگان بومی ابر ارائه می دهد.

• ابزارهای سنتی برای مدیریت و نظارت بر سیستم‌ها با تیم‌های عملیاتی مرتبط هستند که در یک Runbook کار می‌کنند (مجموعه ای از رویه ها و عملیات معمول - تقریباً ترجمه)، به یک استقرار خاص گره خورده است.
• در مدیریت بومی ابر، ابزارهای مشاهده‌پذیری بهترین راه برای اندازه‌گیری نتایج استقرارها هستند تا تیم توسعه بتواند به سرعت پاسخ دهد.

خوشه های زیادی را تصور کنید که در ابرهای مختلف و سرویس های زیادی با تیم ها و برنامه های استقرار خود پراکنده شده اند. GitOps یک مدل متغیر در مقیاس برای مدیریت این همه فراوانی ارائه می دهد.

PS از مترجم

در وبلاگ ما نیز بخوانید:

• «GitOps: مقایسه روش‌های کشش و فشار"؛
• «معرفی kubedog، کتابخانه ای برای ردیابی منابع Kubernetes"؛
• «گسترش و تکمیل Kubernetes (بازبینی و گزارش تصویری)'.

فقط کاربران ثبت نام شده می توانند در نظرسنجی شرکت کنند. ورود، لطفا.

آیا قبل از اینکه این دو ترجمه در Habré ظاهر شوند، درباره GitOps می دانستید؟

• بله، من همه چیز را می دانستم

• فقط به صورت سطحی

• بدون

35 کاربر رای دادند. 10 کاربر رای ممتنع دادند.

منبع: www.habr.com