GitOps چیست؟ گسترش devops به Kubernetes و فراتر از آن

GitOps همان تکنیک‌هایی را برای استقرار زیرساخت‌ها به کار می‌برد که devops و استفاده از CI/CD برای استقرار برنامه‌ها

دهه گذشته برنامه نویسی شاهد تغییرات انقلابی زیادی بوده است. یکی از مجموعه‌ای از شیوه‌های حول devops برخاسته است، که تیم‌های توسعه و عملیات را در یک فرآیند کاری مشترک، و ادغام مستمر و تحویل مستمر (CI/CD) تراز می‌کند. )، که در آن تیم‌های توسعه‌دهنده به‌روزرسانی‌های افزایشی ثابت را به یک پایگاه کد ارائه می‌کنند. دگرگونی دیگر از حرکت مرتبط از پایگاه‌های کد یکپارچه به سرویس‌های میکرو که در کانتینرها اجرا می‌شوند مبتنی بر ابر است که توسط پلتفرم‌های ارکستراسیون مانند Kubernetes مدیریت می‌شوند.

برنامه‌های مبتنی بر کانتینر که بر روی سیستم‌های خوشه‌ای یا در فضای ابری اجرا می‌شوند، حتی با پلتفرمی مانند Kubernetes که همه چیز را هماهنگ می‌کند، می‌تواند پیچیده و دشوار باشد. GitOps مجموعه‌ای از روش‌های نوظهور است که هدف آن ساده‌سازی این کار مدیریتی با استفاده از تکنیک‌هایی از دنیای devops و CI/CD است.

کلید GitOps ایده زیرساخت به‌عنوان کد است که همان رویکردی را برای تامین زیرساخت‌ها اتخاذ می‌کند که devops برای تهیه برنامه‌ها استفاده می‌کند. بنابراین، نه تنها برنامه، بلکه ماشین‌ها و شبکه‌های میزبان زیربنایی نیز در فایل‌هایی توضیح داده می‌شوند که می‌توانند مانند هر کد دیگری در سیستم کنترل نسخه، با فرآیندهای خودکار و سپس برای همگرایی دنیای واقعی در نظر گرفته شوند. برنامه ای که در آن فایل ها توضیح داده شده است.

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

GitOps تعریف شده

Weaveworks شرکتی است که بیشترین تلاش را برای رایج کردن مفهوم GitOps انجام داده است. ما کمی به جزئیات نقش Weaveworks خواهیم پرداخت، اما ابتدا اجازه دهید نگاهی به تعریف شرکت بیندازیم. از GitOps، که دو برابر است:

• یک مدل عملیاتی برای Kubernetes و سایر فناوری‌های بومی ابری که مجموعه‌ای از بهترین روش‌ها را ارائه می‌کند که استقرار، مدیریت و نظارت را برای خوشه‌ها و برنامه‌های کاربردی یکپارچه می‌کند.
• مسیری به سمت تجربه توسعه دهنده برای مدیریت برنامه ها. که در آن خطوط لوله CI/CD سرتاسر و جریان‌های کاری Git هم برای عملیات و هم برای توسعه اعمال می‌شوند.

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

تعریف Git

Git در GitOps به سیستم کنترل نسخه توزیع شده بسیار محبوب اشاره دارد که توسط لینوس توروالدز در سال ۲۰۰۵ توسعه یافته است. em>شاخه هایکدی که قبل از ادغام آنها در کد تولید، با آنها سرهم می کنند. یک مفهوم کلیدی در Git، درخواست کشش است که در آن یک توسعه‌دهنده به طور رسمی از کدهایی که روی آن کار می‌کردند می‌خواهد تا در شعبه دیگری در پایگاه کد ادغام شود.

یک درخواست Git pull فرصتی را برای اعضای تیم فراهم می کند تا قبل از رسیدن به توافق در مورد اینکه آیا کد جدید باید به برنامه اضافه شود، با یکدیگر همکاری کرده و بحث کنند. Git همچنین نسخه‌های قدیمی‌تر کد را ذخیره می‌کند، که باعث می‌شود در صورت بروز مشکل، به راحتی به آخرین نسخه خوب برگردید و به شما امکان می‌دهد به سرعت ببینید چه چیزی بین ویرایش‌ها تغییر کرده است. Git ممکن است به عنوان زیربنای GitHub شناخته شود، یک سیستم کنترل نسخه با میزبانی ابری، اما Git خود نرم افزار منبع باز است که می تواند در هر جایی، از سرورهای داخلی سازمانی مستقر شود. به رایانه شخصی شما.

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

آخرین چیزی که قبل از حرکت باید بگوییم: با وجود اینکه “Git” دقیقاً در نام وجود دارد، GitOps در واقع به استفاده از Git نیاز ندارد. فروشگاه هایی که قبلاً روی سایر نرم افزارهای کنترل نسخه مانند Subversion سرمایه گذاری شده اند، می توانند GitOps را نیز پیاده سازی کنند. اما Git به طور گسترده در دنیای devops برای پیاده سازی CI/CD استفاده می شود، بنابراین اکثر پروژه های GitOps در نهایت از Git استفاده می کنند.

فرایند CI/CD چیست؟

نگاهی کامل به CI/CD خارج از محدوده این مقاله است—به توضیح InfoWorld در مورد این موضوع مراجعه کنید—اما لازم است چند کلمه در مورد CI/CD بگوییم زیرا در هسته اصلی آن قرار دارد. نحوه عملکرد GitOps ادغام پیوسته نیمی از CI/CD توسط مخازن کنترل نسخه مانند Git فعال می‌شود: توسعه‌دهندگان می‌توانند به‌جای عرضه نسخه‌های جدید و عظیم و یکپارچه هر چند ماه یا سال یک‌بار، بهبودهای کوچک ثابتی در پایگاه کد خود ایجاد کنند. قطعه استقرار مداوم توسط سیستم‌های خودکاری به نام pipelines که کد جدید را می‌سازند، آزمایش می‌کنند و به تولید می‌رسانند، ممکن می‌شود.

دوباره، ما همچنان در مورد کد در اینجا صحبت می‌کنیم، و معمولاً رویایی از کدهای اجرایی نوشته شده در یک زبان برنامه‌نویسی مانند C یا جاوا یا جاوا اسکریپت را جمع‌آوری می‌کند. اما در GitOps، “کدی” که ما مدیریت می کنیم تا حد زیادی از فایل های پیکربندی تشکیل شده است. این فقط یک جزئیات جزئی نیست – در قلب کاری است که GitOps انجام می دهد. همانطور که گفتیم، این فایل های پیکربندی «منبع منفرد حقیقت» هستند که توصیف می کنند که سیستم ما چگونه باید باشد. آنها به جای آموزنده، اظهاری هستند. این بدان معناست که به جای گفتن “راه اندازی ده سرور”، فایل پیکربندی به سادگی می گوید: “این سیستم شامل ده سرور است.”

نیم CI از معادله GitOps به توسعه دهندگان این امکان را می دهد که به سرعت ترفندها و بهبودهایی را در این فایل های پیکربندی ارائه دهند. نیمی از CD زمانی اتفاق می‌افتد که عوامل نرم‌افزاری خودکار تمام تلاش خود را می‌کنند تا اطمینان حاصل کنند که نسخه زنده برنامه منعکس‌کننده توضیحات موجود در فایل‌های پیکربندی است – که همگرا به مدل اعلامی باشد، به زبان GitOps.

GitOps و Kubernetes

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

1. یک برنامه‌نویس برای یک ویژگی جدید یک درخواست Git pull ارائه می‌کند.
2. کد بررسی و تأیید می‌شود، سپس در پایگاه کد اصلی ادغام می‌شود.
3. ادغام خط لوله CI/CD را راه اندازی می کند، که به طور خودکار کد جدید را آزمایش و بازسازی می کند و آن را در یک رجیستری مستقر می کند.
4. یک عامل نرم افزار متوجه به روز رسانی می شود، کد جدید را از رجیستری می کشد و فایل پیکربندی (نوشته شده در YAML) را در مخزن پیکربندی به روز می کند.
5. یک عامل نرم افزاری در خوشه Kubernetes تشخیص می دهد که خوشه قدیمی است، بر اساس فایل پیکربندی، تغییرات را انجام می دهد و ویژگی جدید را به کار می گیرد.

Weaveworks و GitOps

واضح است که مراحل ۴ و ۵ در اینجا بیشتر کارهای سنگین را انجام می دهند. عوامل نرم افزاری که به طور جادویی “منبع حقیقت” را در مخزن Git با برنامه واقعی Kubernetes همگام می کنند، جادویی هستند که GitOps را ممکن می کند. همانطور که گفتیم، در اصطلاح GitOps، فرآیند ساخت سیستم‌های زنده بیشتر شبیه سیستم‌های ایده‌آل توصیف‌شده در فایل‌های پیکربندی همگرایی نامیده می‌شود. (زمانی که سیستم زنده و سیستم ایده‌آل با هم هماهنگ نباشند، این واگرایی است.) در حالت ایده‌آل، همگرایی با فرآیندهای خودکار حاصل می‌شود، اما محدودیت‌هایی برای آنچه اتوماسیون می‌تواند انجام دهد وجود دارد و گاهی اوقات مداخله انسان نیز انجام می‌شود. لازم است.

ما این فرآیند را در اینجا به صورت کلی توضیح داده‌ایم، اما در واقع، اگر واقعاً به صفحه Weaveworks بروید، «عامل‌های نرم‌افزاری» که ذکر کردیم بخشی از پلتفرم Weave Cloud این شرکت هستند. اصطلاح “GitOps” توسط مدیر عامل Weaveworks الکسیس ریچاردسون ابداع شد، و این تا حدی باعث جذابیت پلتفرم Weaveworks برای توسعه دهندگانی می شود که قبلاً در دنیای devops و CI/CD غرق شده اند.

اما Weaveworks هرگز ادعای انحصار GitOps را نداشته است، که بیشتر یک فلسفه و مجموعه ای از بهترین شیوه ها است تا یک محصول خاص. GitOps به عنوان وبلاگ CloudBees، شرکتی که راه‌حل‌های CI/CD، یادداشت‌ها را ارائه می‌کند، یک باز را نشان می‌دهد. مدل خنثی فروشنده که در واکنش به راه‌حل‌های اختصاصی مدیریت‌شده Kubernetes توسط فروشندگان ابری بزرگ مانند آمازون، گوگل و مایکروسافت ایجاد شد. CloudBees راه‌حل‌های GitOps خودش را ارائه می‌کند، مانند تعدادی از بازیکنان در این فضا.

GitOps و devops

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

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

• مشاهده پذیری: سیستم های GitOps نظارت، ثبت، ردیابی و تجسم را در برنامه های پیچیده ارائه می دهند تا توسعه دهندگان بتوانند ببینند چه چیزی خراب است و کجاست.
• کنترل نسخه و مدیریت تغییر: بدیهی است که این یک مزیت کلیدی استفاده از سیستم کنترل نسخه مانند Git است. به‌روزرسانی‌های ناقص را می‌توان به راحتی بازگرداند.
• اقتباس آسان: GitOps بر اساس مهارت‌های توسعه‌دهنده بسیاری از توسعه‌دهندگان است.
• بهره وری: GitOps بهره وری را افزایش می دهد که توسعه و CI/CD به حوزه های دیگر آورده است.
• حسابرسی: به لطف Git، هر عملی را می‌توان در یک تعهد خاص ردیابی کرد و ردیابی علت خطاها را آسان می‌کند.

حتی اگر از Kubernetes استفاده نمی‌کنید، احتمالاً GitOps دیر یا زود بخشی از گردش کار شما خواهد بود.