در بخش قبل در مورد Git archive صحبت کردیم که یک ابزار مفید برای ایجاد بسته های قابل توزیع از مخازن Git است. در این بخش می خواهیم در مورد مبحث دیگری با نام GitOps صحبت کنیم.

در حال حاضر بسیاری از سازمان ها، DevOps را بخشی از استراتژی تحول دیجیتال خود می دانند، زیرا فرهنگ مسئولیت پذیری مشترک، شفافیت و بازخورد سریع تر را تقویت می کند. در عین حال که فاصله بین تیم های توسعه و عملیات، کاهش یافته، فرایند ها نیز کاهش می یابند. بنابراین سازمان ها با پرکاربردترین سیستم کنترل نسخه در جهان امروز یا همان Git، پیش می روند.

DevOps مجموعه ای از عملکرد هایی است که توسعه نرم افزار و عملیات IT را با هم ترکیب می کند. هدف آن کوتاه کردن چرخه عمر توسعه سیستم ها و ارائه تحویل مداوم با کیفیت بالای نرم افزار است. DevOps، با توسعه نرم افزار چابک مکمل است و چندین جنبه DevOps از روش چابک به دست آمده است.

ابزارهایی که تحولی در GitOps ایجاد کرده اند، مجموعه ای از روش ها هستند که به توسعه دهندگان این امکان را می دهند که کارهای بیشتری مربوط به عملیات IT انجام دهند.

GitOps چیست؟

GitOps در هسته اصلی خود، زیرساخت مبتنی بر کد (code-based) و رویه های عملیاتی است که به Git به عنوان یک سیستم Source Control، متکی است. در حقیقت GitOps یک تکامل از Infrastructure as Code (IaC)، و بهترین روش DevOps است. GitOps از Git به عنوان منبع واحد درست و مکانیزم کنترل برای ایجاد، به روزرسانی و حذف معماری سیستم استفاده می کند. به عبارت ساده تر، این روش از درخواست های Pull در Git، جهت تایید و گسترش خودکار تغییرهای زیرساخت سیستم، استفاده می کند.

علاوه بر Git به عنوان مکانیزم کلیدی DevOps، از GitOps برای توصیف ابزارهایی که، قابلیت پیش فرض Git را تقویت می کنند، نیز استفاده می شود. این ابزارها در درجه اول با مدل های عملیاتی، برای زیرساخت ها و برنامه های مبتنی بر Kubernetes (Kubernetes یک پلتفرم منبع باز محبوب برای تنظیم container است، که به صورت اتوماتیک بسیاری از کارهای عملیاتی مورد نیاز چرخه عمر یک container را انجام می دهد). استفاده می شدند. توسعه، بحث و گفتگو در جامعه DevOps برای آوردن ابزارهای GitOps به سایر پلتفرم ها به جز Kubernetes، مانند Terraform، در حال انجام است.

GitOps اطمینان می دهد که زیرساخت های ابری (Cloud) سیستم، بلافاصله براساس وضعیت مخزن Git، قابل تکرار هستند. درخواست های Pull، وضعیت مخزن Git را اصلاح می کنند. پس از تایید و Merge، درخواست های Pull به طور خودکار، زیرساخت جاری را با وضعیت مخزن، مجددا پیکربندی و همگام سازی (sync) می کنند. در حقیقت، این گردش کار در درخواست Pull برای همگام سازی، هسته اصلی GitOps است.

تاریخچه GitOps

Git، ابزاری مهم برای توسعه نرم افزار است که امکان درخواست Pull و گردش کار را برای بررسی کد فراهم می کند. درخواست های Pull، باعث افزایش دید در تغییرهای ورودی یک کد می شود و ارتباط، بحث و بررسی تغییرها را تقویت می کند.

درخواست های Pull، یک ویژگی اساسی در توسعه نرم افزار به صورت تیمی هستند و روش ساخت نرم افزار توسط تیم ها و کسب و کار ها را تغییر می دهند. همچنین، شفافیت و مقیاس پذیری را برای فرایندهایی که قبلا مبهم بوده است، ایجاد می کند. درخواست های Pull در Git، به پیشرفت فرایندهای DevOps در توسعه نرم افزار کمک می کنند. مدیران سیستم که معمولا در انجام تغییرها تردید داشتند، اکنون از روش های جدید توسعه نرم افزار مانند چابک و DevOps استقبال می کنند.

مدیریت سیستم ها به عنوان یک مهارت، سابقه ای خوبی ندارد. مدیران سیستم قبلا با اتصال یا تهیه ماشین آلات در یک سرور Rack فیزیکی (سرور Rack، ساختاری است که به طور خاص برای قرار دادن تجهیزات فنی از جمله روترها، سوئیچ ها، Hub ها و البته سرورها طراحی شده است) یا از طریق API، سخت افزار را به صورت دستی مدیریت می کردند. علاوه بر فرایند تهیه دستی، بسیاری از کارهای پیکربندی دستی، یک روال عادی بود. مدیران و سرپرستان مجموعه های سفارشی، اسکریپت ها و پیکربندی های ضروری را نگه داشته و آن ها را با هم و در مکان های مختلف قرار می دادند. این اسکریپت ها ممکن بود در هر زمان نقض شده یا گم شوند. اما از آن جایی که زنجیره ابزار سفارشی به طور منظم، مستند یا به اشتراک گذاشته نمی شد، همکاری بسیار سخت و چالش برانگیز بود.

جنبش DevOps، از این باتلاق اولیه سیستم ها ناشی شد. DevOps بهترین ایده ها را از مهندسی نرم افزار گرفت و آن ها را در مدیریت سیستم ها به کار برد.

IaC (Infrastructure as Code)، یکی از بزرگترین افشاگری های DevOps است. پیش از این، مدیران سیستم برای پیکربندی سیستم ها از اسکریپت های ضروری سفارشی استفاده می کردند. اما نرم افزار Imperative برای دستیابی به وضعیت دلخواه، دنباله ی متفاوتی از مراحل را طی می کرد، برای مثال:

نرم افزار Imperative اغلب مستعد خطا است و با تغییر توالی وقایع، شکستن آن آسان می شود. توسعه نرم افزار مدرن، از الگو های اجباری فاصله گرفته و به سمت الگو های نرم افزاری Declarative رفته است.

نرم افزار Declarative به جای دنباله ای از دستورها، از اعلام وضعیت مورد انتظار پیروی می کند. در اینجا مقایسه ای بین عبارات ضروری و DevOps Declarative وجود دارد.

در حالی که عبارات ضروری ممکن است به صورت زیر باشند:

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

نسخه ی Declarative این کار، به سادگی به این صورت است: 4 ماشین، نرم افزاری از این URL دارند، که در این دایرکتوری نصب شده است.

IaC، ابزارهای مدیریت سیستم Declarative را بیش از راه حل های ضروری سفارشی، تقویت کرده و ارتقا می دهد. این امر منجر به ظهور فناوری هایی مانند Docker Containers، Ansible، Terraform و Kubernetes شد که از فایل های پیکربندی استاتیک Declarative استفاده می کنند. خوانایی و قابلیت تکرارپذیری، از نتایج مفید آن است. این فایل های پیکربندی به طور طبیعی برای ردیابی و بررسی، به Git اضافه شدند. این فرایند تقریبا نزدیک به کار GitOps است اما به طور کامل GitOps نیست.

بسیاری از مشکلات مدیریت سیستم سنتی، در این مرحله از تاریخ DevOps حل شده است. فایل ها و ابزارهای پیکربندی اکنون در یک مکان مرکزی ذخیره می شوند و توسط بسیاری از اعضای تیم، مستند شده و قابل دسترسی هستند. برای پیگیری اصلاحات در پیکربندی و تقویت بحث و بررسی در همکاری، از Commit ها و درخواست های Pull استفاده شد. تنها مشکل باقیمانده در این مرحله این است که پیکربندی، هنوز از سیستم جاری جدا نشده است. پس از تایید درخواست پیکربندی و Merge در مخزن، سیستم جاری به صورت دستی به روز می شود تا با وضعیت مخزن استاتیک، مطابقت داشته باشد. این دقیقا مشکلی است که GitOps حل کرده است.

ایده GitOps ابتدا توسط WeaveWorks، یک شرکت مدیریتی Kubernetes استخراج و به اشتراک گذاشته شد و از آن زمان در سراسر جامعه DevOps گسترش یافته است. GitOps یک افزونه (extension) از IaC و پیکربندی Declarative است که در بالا در مورد آن صحبت شد. GitOps برخی از امکانات جادویی را به گردش کار درخواست Pull، اضافه کرده که وضعیت سیستم جاری را با مخزن پیکربندی استاتیک، همگام سازی می کند.

مزایای GitOps

GitOps، بسیاری از مزایای مشابه گردش کار در توسعه نرم افزار شاخه Feature چابک، را دارا است. اولین مزیت مهم، سهولت Adoption به دلیل استفاده از ابزارهای رایج است. Git، استاندارد سیستم های کنترل نسخه و ابزاری متداول برای توسعه نرم افزار، برای اکثر توسعه دهندگان و تیم های نرم افزاری است. این امر باعث می شود تا توسعه دهندگان آشنا به Git، به مشارکت کنندگان (Contributors) تبدیل شوند و در GitOps همکاری کنند.

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

GitOps شفافیت و نیازهای زیرساختی سازمان را در مورد نسخه اصلی فراهم می کند. تمام پیکربندی های سیستم در یک مخزن مرکزی وجود دارد و به اعضای تیم کمک می کند. درخواست های Pull از طریق سرویس های میزبان Git مانند Bitbucket، دارای ابزار غنی برای بررسی کد و تفسیر بحث است. همچنین، حلقه های ارتباطی غیرفعال ایجاد می کند که به تیم مهندسی، امکان مشاهده و نظارت بر تغییرهای زیرساختی را به صورت کامل می دهد.

GitOps می تواند بهره وری را برای یک تیم DevOps بسیار افزایش دهد. به آن ها این امکان را می دهد تا به سرعت پیکربندی های جدید زیرساخت را تجربه کنند. اگر تغییرهای جدید، مطابق انتظار عمل نکنند، یک تیم می تواند با استفاده از Git history تغییرها را به حالت تثبیت شده قبلی برگرداند. این فوق العاده قدرتمند است زیرا قابلیت "undo" در زیرساخت های پیچیده را فراهم می کند.

شیوه ی کار GitOps

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

برای دستیابی به نصب کامل GitOps، یک پلتفرم pipeline مورد نیاز است.Jenkins ، Bitbucket Pipelines یا CircleCi برخی از ابزارهای معروف pipeline می باشند که مکمل GitOps هستند. pipeline ها، خودکار بوده و شکاف بین درخواست های Pull در Git و سامانه هماهنگ کننده را از بین می برند. پس از ایجاد pipeline hooks و درخواست های Pull، دستور ها برای قطعه تنظیم شده و هماهنگ کننده، اجرا می شوند.

یک الگو یا کامپوننت جدیدی که به طور خاص با GitOps معرفی می شود "اپراتور" GitOps است که مکانیزمی است که بین pipeline و سامانه هماهنگ کننده قرار دارد. یک درخواست Pull، pipeline را شروع می کند و محرک اپراتور می شود. اپراتور، وضعیت مخزن و شروع هماهنگ کننده را بررسی کرده و آن ها را همگام سازی می کند. در این جا اپراتور، کامپوننت جادویی GitOps خواهد بود.

مثال های GitOps

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

یکی از اعضای تیم، درخواست Pull جدیدی را ارائه می دهد که مقادیر load balancer را بهینه می کند. یکی از اعضای تیم دوم، درخواست Pull را بررسی و تایید کرده و در مخزن Merge می کند. این Merge، pipeline GitOps را آغاز می کند، که عملگر GitOps را تحریک می کند. اپراتور می بیند که load balancer تغییر کرده است. سپس با ابزار تنظیم کننده سیستم تایید می کند که با آنچه در Cluster تیم ها پخش می شود، مطابقت ندارد.

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

بیایید تصور کنیم که تیم به جای اینکه کمی مقادیر load balancer را بهینه کند، به صورت سریع برای استقرار یک نوع کاملا جدید load balancer، تصمیم بگیرد. آن ها احساس می كنند كه load balancer فعلی اساسا دارای نقص است و می خواهند گزینه دیگری را امتحان كنند. این تیم یک درخواست Pull ایجاد می کند که یک پیکربندی، load balancer را به طور کامل معرفی می کند و پیکربندی قدیمی را حذف می کند. سپس، از طریق pipeline تایید و مستقر می شود.

متاسفانه تیم به این نتیجه رسید که نوع جدید load balancer، با برخی دیگر از سرویس های Cluster آن ها سازگار نیست. load balancer جدید باعث خرابی های مهم در ترافیک و توقف عملکرد کاربر می شود. خوشبختانه به دلیل اینکه تیم pipeline به طور کامل GitOps را دارند، می توانند به سرعت این تغییرهای load balan er را لغو کنند. تیم، درخواست Pull دیگری را ارائه می دهد که مخزن را به load balancer قدیمی باز می گرداند. این مورد توسط pipeline GitOps مورد توجه قرار گرفته و به طور خودکار مستقر خواهد شد. در نهایت به سرعت زیرساخت ها را بهبود می بخشد.

جمع بندی

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

منبع

https://www.atlassian.com/git/tutorials/gitops

آیا GitOps مهم ترین مورد در DevOps است؟