gitOps چیست؟gitOps چیست؟

gitOps چیست؟

نویسنده: امید شریعتی

دسته بندی: دواپس
13 دقیقه زمان مطالعه
۱۴۰۰/۰۹/۱۶
0 نظر
امتیاز 3 از 5

GitOps متد و راهی برای ادامه توسعه روی سیستم‌های تحت cloud است. تمرکز اصلی آن، ابزار‌های توسعه‌محور (developer-centric)  مانند Git که تقریبا اکثر برنامه‌نویس‌ها با آن آشنایی دارند است.
ایده اصلی GitOps داشتن یک  Git repository است که همیشه توصیفی از محیط زیرساخت و عملیات را دارد و تمامی مراحل Git را که شامل pull و push و ... می‌شود، به صورت اتوماتیک انجام می‌دهد. 
اگر قصد توسعه برنامه جدیدی را دارید یا می‌خواهید سیستم‌های قبلی را update کنید، کافی است repository را update کنید؛ بقیه موارد را automated process  برای شما انجام می‌دهد. برای درک بهتر ازautomated process  یا خودکارسازی امور، مقاله «دواپس چیست؟» را مطالعه کنید.

چرا باید از GitOps استفاده کنیم؟

در ادامه به بررسی مزایای GitOps می‌پردازیم و دلایل استفاده از آن را بررسی می‌کنیم.

استقرار سریع‌تر در اکثر مواقع

همانطور که می‌دانید تمامی تکنولوژی‌هایی که از Continuous Deployment (استقرار پیوسته) پشتیبانی می‌کنند، وعده روند توسعه سریع‌تر را داده‌اند؛ اما نکته‌ای که GitOps را خاص‌تر از بقیه می‌کند این است که برای توسعه نیازی به تغییر ابزار ندارید، به این شکل که تمامی ابزارهای version control در توسعه نیز استفاده می‌شود.
وقتی می‌گوییم سرعت بالا منظور این است که هر تیم می‌تواند با خیال راحت چندین بار در روز سیستم را به‌روزرسانی کند و نتایج را در همان لحظه ببیند. 

شناسایی و رفع راحت‌تر و سریع‌تر خطاها (Error Recovery)

تصور کنید محیط production شما از سرویس خارج شده باشد؛ با کمک GitOps تاریخچه کاملی از این که محیط عملیات یا توسعه چه تغییراتی داشته است را در اختیار خواهید داشت. برای این موضوع، به راحتی با دستور git revert  خطا‌ها را نمایش می‌دهد و می‌توانید محیط توسعه را به حالت قبل بازگردانید.

مدیریت راحت‌تر Credentialها


GitOps امکان مدیریت deploymentها را در داخل محیط یا environment به شما می‌دهد. برای این کار environment شما فقط نیاز به دسترسی Repository و Image registry دارد و دیگر نیاز نیست به تک تک برنامه‌نویس‌های تیم دسترسی جدا بدهید.

مستندسازی خودکار استقرار (Self-document Deployment)

تا به حال برایتان پیش آمده که SSH’d را در سرور استفاده کرده باشید اما ندانید چه اتفاقی در آن جا رخ می‌دهد؟ در GitOps هر تغییر در هر محیط فقط در Repository  اتفاق می‌افتد. همیشه می‌توانید برنچ master خود را چک کنید و تمامی اطلاعات مربوط به توسعه و لاگ‌های push ،pull و کل تاریخچه تغییرات را مشاهده کنید.

دانش مشترک در تیم‌ها

یکی از استفاده‌های Git در تیم‌های نرم‌افزار، مشاهده تمامی تغییرات در ساختار پروژه است. به این ترتیب اعضای تیم می‌توانند به راحتی تمامی تغییرات اعمال شده را به همراه توضیحات ببینند، فرایند تغییر زیرساخت را اعمال کنند و به راحتی نمونه‌ای از نصب یک سیستم را مشاهده کنند.

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

در ادامه نحوه عملکرد GitOps را بررسی می‌کنیم:

پیکربندی محیط استقرار در Git repository

GitOps در اصل کل فرایند استقرار اپلیکیشن و محیط اجرای آن را به صورت متمرکز درون مخازن کد سازماندهی می‌کند که شامل دو repository است: 
Application repository-1: که شامل source code اپلیکیشن و deployment manifestها جهت استقرار اپلیکیشن می‌شود.
Environment configuration repository-2: که شامل تمامی deployment manifestهای زیرساختی محیط استقرار است. 
به بیان ساده‌تر این کدها مشخص می‌کنند که چه اپلیکیشن‌ها و سرویس‌های زیرساختی (مثل message broker, service mesh, monitoring ,tool) با چه پیکربندی و نسخه‌ای در محیط‌های مورد نظر تستی یا عملیاتی مستقر و اجرا شوند.

Push-based vs. Pull-based Deployments

دو روش پیاده‌سازی استراتژی در GitOps وجود دارد. Push-based و Pull-based. تفاوت بین این دو روش در این است که مطمئن شوند محیط توسعه دقیقا مشابه محیط زیرساخت است. در صورت امکان، بهتر است که از روش Pull-based استفاده شود؛ زیرا پیاده‌سازی آن ایمن‌تر است و نتیجه بهتری می‌دهد.

استقرار به روش Push-based

استراتژی Push-based بر اساس پیاده‌سازی ابزارهای محبوبی مانند Jenkins ،CircleCI یا Travis CI است. source code اپلیکیشن شما به صورت live داخل Application repository به همراه Kubernetes YAMLهای مورد نیاز برای توسعه اپلیکیشن قرار می‌گیرد. هر زمان اپلیکیشن و کدها به‌روزرسانی شود، build pipeline به سرعت فعالیت می‌کند که از container imageها یک build می‌گیرد. در آخر تنظیمات محیط repository با آخرین نسخه توسعه، به‌روزرسانی و هماهنگ می‌شود.
نکته: شما می‌توانید قالبی (template) از YAMLs را در application repository خود ذخیره کنید. در این صورت وقتی نسخه جدیدی از اپلیکیشن ساخته شود، template می‌تواند به خودی خود YAML را در تنظیمات محیط تولید کند.


هر تغییراتی در تنظیمات repository باعث می‌شود که pipeline به صورت خودکار ساخته شود و وظیفه این pipeline اعمال تمامی manifestها در تنظیمات محیط repository برای زیرساخت را بر عهده دارد. گاهی اوقات توسعه push-based را به راحتی نمی‌توان بر روی ساختارهای ابری (cloud) به صورت اتوماتیک (automated process)  اجرا کرد.
در این موارد توصیه می‌شود که از fine-granular configurable authorization system برای مجوز و سطح دسترسی بیشتر به ساختار ابری استفاده شود. نکته مهم دیگر که باید هنگام استفاده از این روش مد نظر داشته باشید این است که pipeline فقط در مواقعی که repository شما تغییر کند دچار تغییرات می‌شود.
این روش به صورت خودکار انحراف و تغییر در environment  را به شما اعلام نمی‌کند. یعنی نیاز به یک روش monitoring برای مشاهده مغایرت بین محیط توسعه و repository دارید.

استقرار به روش Pull-based

این مدل همانند مدل push-based  از یک استراتژی پیروی می‌کند اما تفاوت‌هایی در کارکرد pipeline با یکدیگر دارند. مدل قدیمی pipeline  CI/CD  یک رویداد خارجی  ایجاد می‌کرد؛ به طور مثال وقتی کد جدید به سمت repository اپلیکیشن شما push می‌شد، سیستم به همراه آن مدل pull-based را استفاده می‌کرد.
این مدل در اصل با مقایسه پی در پی بین محیط repository و موقعیت حال حاضر زیرساخت توسعه (deployment)، نقش pipeline را بر عهده دارد. به این ترتیب اگر تفاوتی در این دو مشاهده شود، ساخت پروژه را بر اساس محیط repository هماهنگ می‌کند. به علاوه image registry می‌تواند نسخه جدیدی از imageها را برای توسعه تشخیص دهد.
    


همانند مدل push-based، به محض این که محیط ما آپدیت شود، repository هم به‌روزرسانی می‌شود.
هنگامی که اپراتور تغییر کند، شما از راه‌های دیگر متوجه تغییرات آن می‌شوید. وقتی زیرساخت محیط به هر دلیلی تغییر کند، به نحوی که در repository  environment تعریف نشده باشد، این تغییرات بازگردانده می‌شود. این موضوع تضمین می‌کند که با غیر ممکن ساختن تغییرات مستقیم روی هر خوشه (cluster)، تمامی تغییرات در Git log  قابل ردیابی هستند.
این تغییرات زمانی به طور مستقیم مشکل توسعه به روش push-based را حل می‌کند که فقط environment به‌روزرسانی شود؛ اما این موضوع به این معنی نیست که شما به طور کامل نمی‌توانید monitoring داشته باشید.
 اگر به هر دلیلی  نتوانستید محیط خود را به وضعیت مطلوب درآورید، بیشتر سیستم‌ها از sending mails یا Slack notifications  پشتیبانی می‌کنند. به طور مثال اگر موفق نشدید container image را pull کنید، بهتر است یک monitoring جدا برای سیستم نصب کنید.
سیستم (operator) باید همیشه در جایی که environment قرار دارد قرار بگیرد؛ زیرا این موضوع از حالت god-mode جلوگیری می‌کند .هنگامی که نمونه استقرار واقعی در همان محیط توسعه باشد، دیگر نیازی به credentials به عنوان سرویس خارجی نخواهید داشت.

کار کردن با چندین مدل و محیط

همانطور که می‌دانید کار کردن با یک application repository در یک محیط برای اکثر برنامه‌ها واقعی است. وقتی شما از معماری microservice استفاده می‌کنید احتمالا می‌خواهید هر سرویس را در repository مخصوص خود قرار دهید.
GitOps این مورد را برای شما به راحتی کنترل می‌کند. شما همیشه می‌توانید multiple build pipelines که محیط repository شما را update کند داشته باشید.


با ساختن branchهای جداگانه در environment repository، شما می‌توانید چندین محیط را در GitOps مدیریت کنید. باید operator یا pipeline را طوری تنظیم کنید که به تغییرات در branch و محیط توسعه یا دیگر محیط‌ها واکنش نشان دهد.
جمع‌بندی
با توجه به استفاده روزمره Git در تمامی تیم‌های نرم‌افزاری، در آینده نه چندان دور GitOps قدم بزرگی در راستای حل چالش‌های موجود این حوزه برمی‌دارد. در این مقاله سعی کردیم استفاده از تکنولوژی GitOps را به طور مختصر شرح دهیم و همین طور انواع استراتژی‌های آن را مورد بررسی قرار دادیم.