گیت آپس gitOps چیست؟

GitOps متد و راهی برای توسعه نرم‌افزار روی سیستم‌های ابری (Cloud) و تمرکز اصلی آن بر ابزار‌های توسعه‌محور (Developer-centric) مانند Git است که تقریبا اکثر برنامه‌نویس‌ها با آن آشنایی دارند. ایده اصلی GitOps داشتن یک Git repository (مخزن گیت) است که همیشه توصیفی از محیط زیرساخت و عملیات را دارد و تمامی مراحل Git را که شامل Pull و Push و … می‌شود، به صورت اتوماتیک انجام می‌دهد. 

اگر قصد توسعه برنامه جدیدی را دارید یا می‌خواهید سیستم‌های قبلی را آپدیت کنید، کافی است Repository را به روزرسانی کنید؛ بقیه موارد را Automated Process برای شما انجام می‌دهد. برای درک بهتر از Automated Process یا خودکارسازی امور، مقاله «دواپس چیست؟» را مطالعه کنید.

تاریخچه GitOps

در سال‌های ۲۰۱۴ تا ۲۰۱۶، شرکت‌های ارائه‌دهنده سرویس‌های ابری و به خصوص PaaS (اPlatform as a Service) تلاش می‌کردند تا پلتفرم خود را برای توسعه‌دهندگان بهینه کنند و فرایند توسعه نرم‌افزار را به فرایندی ساده و سریع در فضای ابری تبدیل کنند؛ اما این تلاش‌ها تا سال ۲۰۱۶ نتیجه چشم‌گیری نداشتند. 

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

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

کاربردهای GitOps چیست؟

گیت‌آپس کاربردهای زیادی دارد که هرکدام به نحوی به فرایند توسعه و استقرار نرم‌افزار کمک می‌کنند. اما شاخص‌ترین کاربردهای GitOps شامل موارد زیر هستند:

• ایجاد مسیر (پایپ‌لاین) توسعه
• ایجاد پیش‌نیازهای توسعه در یک محیط امن‌تر
• دسترسی راحت‌تر به سورس کدها
• شفافیت بیشتر در سطح پلتفرم‌ها
• مدیریت پیکربندی‌ها
• استقرار و ارائه خوشه در کوبرنتیز

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

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

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

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

وقتی می‌گوییم سرعت بالا منظور این است که هر تیم می‌تواند با خیال راحت چندین بار در روز سیستم را به‌روزرسانی کند و نتایج را در همان لحظه ببیند. 

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

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

مدیریت راحت‌تر Credentialها (اعتبارات)

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

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

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

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

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

این امر باعث می‌شود تا تیم‌ها قدم به قدم به یک زبان و دانش مشترک در توسعه نرم‌افزار برسند.

راه‌اندازی و روش کار با گیت

برای استفاده از GitOps باید ابتدا نرم‌افزار گیت (معمولا نرم‌افزار GitLab) را روی سیستم و سرور نصب کنید؛ البته می‌توانید از نسخه آنلاین گیت یعنی GitHub هم استفاده کنید. برای نصب گیت یک سیستم عامل بسته به نوع سرورها و بار کاری انتخاب کنید و نرم‌افزار را نصب کنید. بعد از این مرحله، باید یک یوزر بسازید و سطح دسترسی این یوزر به ریپوزیتوری و محیط نرم‌افزار را مشخص کنید.

سپس فولدری تحت عنوان Git-server ایجاد کنید. در فولدر کلیک راست کنید و گزینه Git Bash Here را انتخاب کنید. سپس دستور git init webine.git –bare را اجرا کنید. سرور گیت شما نصب شده است و حالا باید از آن یک Clone بگیرید.

برای این کار در یک درایو متفاوت از درایو Git Server فولدری تحت عنوان Clone بسازید و مجددا Git Bash Here را انتخاب کنید. سپس دستور git clone D:/Git_server/webine.git را اجرا کنید.

برای کار با گیت و راه‌اندازی آن آموزش‌های مختلفی وجود دارد که می‌توانید به صورت متنی یا ویدیویی از این آموزش‌ها استفاده کنید.

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

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

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

GitOps در اصل کل فرایند استقرار اپلیکیشن و محیط اجرای آن را به صورت متمرکز درون مخازن کد سازماندهی می‌کند که شامل دو Repository است: 

۱. Application repository: که شامل Source code اپلیکیشن و Deployment manifestها جهت استقرار اپلیکیشن می‌شود.

۲. Environment configuration repository: که شامل تمامی 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 YAMLs مورد نیاز برای توسعه اپلیکیشن قرار می‌گیرد. 

هر زمان اپلیکیشن و کدها به‌روزرسانی شود، build pipeline به سرعت از container images یک 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 شما را به روزرسانی کند داشته باشید.

با ساختن branchهای جداگانه در environment repository، شما می‌توانید چندین محیط را در GitOps مدیریت کنید. باید operator یا pipeline را طوری تنظیم کنید که به تغییرات در branch و محیط توسعه یا دیگر محیط‌ها واکنش نشان دهد.

جمع‌بندی

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