بسیاری از ما، با توجه به اصطلاح جدید بعدی در وبلاگ یا کنفرانس فناوری اطلاعات، دیر یا زود سؤال مشابهی را می پرسیم: «این چیست؟ کلید واژه دیگر، "کلمات" یا واقعاً چیزی است که ارزش توجه دقیق، مطالعه و نوید دادن به افق های جدید را دارد؟ در مورد این اصطلاح برای من هم همین اتفاق افتاد GitOps چند لحظه پیش. مسلح به بسیاری از مقالات موجود، و همچنین دانش همکاران از شرکت ، سعی کردم بفهمم که چه نوع جانوری است و کاربرد آن در عمل چگونه به نظر می رسد.
به هر حال، در مورد تازگی این اصطلاح GitOps همچنین نظرسنجی اخیر ما می گوید: بیش از نیمی از افراد مورد بررسی هنوز با اصول آن شروع به کار نکرده اند.
بنابراین، مشکل مدیریت زیرساخت جدید نیست. بسیاری از ارائه دهندگان ابری برای یک دهه خوب در دسترس عموم بوده اند و به نظر می رسد باید کار تیم های زیرساخت را ساده و بی تکلف می کردند. با این حال، هنگامی که با فرآیند توسعه برنامه (جایی که سطح اتوماسیون به افق های جدید و جدید می رسد) مقایسه می شود، پروژه های زیرساختی هنوز اغلب شامل بسیاری از وظایف دستی هستند و به دانش و متخصصان ویژه نیاز دارند، به ویژه با توجه به الزامات امروزی برای تحمل خطا، انعطاف پذیری، مقیاس پذیری و کشش. .
خدمات ابری در برآوردن این الزامات بسیار موفق بودند و آنها بودند که انگیزه قابل توجهی به توسعه این رویکرد دادند. IaC. این قابل درک است. از این گذشته ، آنها بودند که پیکربندی یک مرکز داده کاملاً مجازی را امکان پذیر کردند: هیچ سرور فیزیکی ، رک ، اجزای شبکه وجود ندارد ، کل زیرساخت را می توان با استفاده از اسکریپت ها و فایل های پیکربندی توصیف کرد.
بنابراین دقیقاً چه تفاوتی وجود دارد GitOps از IaC? با این سوال بود که تحقیقاتم را شروع کردم. پس از صحبت با همکاران، توانستم به مقایسه زیر برسم:
GitOps
IaC
همه کدها در یک مخزن git ذخیره می شوند
نسخه کد اختیاری است
شرح کد اعلامی / بی قدرتی
هر دو توصیف اعلامی و امری قابل قبول است
تغییرات با استفاده از مکانیسم‌های درخواست ادغام / درخواست کشش اعمال می‌شوند
هماهنگی، تایید و همکاری اختیاری است
فرآیند عرضه به‌روزرسانی خودکار است
فرآیند عرضه به‌روزرسانی استاندارد نیست (اتوماتیک، دستی، کپی کردن فایل‌ها، استفاده از خط فرمان و غیره)
به عبارت دیگر GitOps دقیقاً از طریق اعمال اصول متولد شد IaC. اولا، زیرساخت ها و پیکربندی ها اکنون می توانند به همان شیوه برنامه ها ذخیره شوند. ذخیره سازی کد آسان است، به اشتراک گذاری، مقایسه و استفاده از قابلیت های نسخه سازی آسان است. نسخه ها، شاخه ها، تاریخچه. و همه اینها در یک مکان عمومی برای کل تیم. بنابراین، استفاده از سیستم های کنترل نسخه به یک پیشرفت کاملا طبیعی تبدیل شد. به طور خاص، git، به عنوان محبوب ترین.
از سوی دیگر، امکان خودکارسازی فرآیندهای مدیریت زیرساخت فراهم شد. اکنون می توان آن را سریع تر، قابل اطمینان تر و ارزان تر انجام داد. علاوه بر این، اصول CI / CD قبلاً در بین توسعه دهندگان نرم افزار شناخته شده و محبوب بود. فقط لازم بود دانش و مهارت های شناخته شده قبلی را به یک منطقه جدید منتقل و به کار ببریم. با این حال، این اقدامات از تعریف استاندارد زیرساخت به عنوان کد فراتر رفتند، از این رو مفهوم GitOps.
کنجکاوی GitOpsالبته، همچنین در این واقعیت که این یک محصول، افزونه یا پلتفرم مرتبط با هیچ فروشنده ای نیست. این بیشتر یک پارادایم و مجموعه ای از اصول است، مشابه اصطلاح دیگری که با آن آشنا هستیم: DevOps.
شرکت ما دو تعریف از این اصطلاح جدید ارائه کرده ایم: نظری و عملی. بیایید با نظری شروع کنیم:
GitOps یک متدولوژی است که بهترین اصول DevOps را که برای توسعه برنامه‌ها استفاده می‌شود، مانند کنترل نسخه، همکاری، هماهنگ‌سازی، CI/CD و چالش‌های مدیریت خودکار زیرساخت را به کار می‌گیرد.
تمام فرآیندها GitOps من با ابزارهای موجود کار می کنم. همه کدهای زیرساخت در مخزن git از قبل آشنا ذخیره می شوند، تغییرات مانند هر کد برنامه دیگر از طریق فرآیند تأیید می گذرد، و فرآیند انتشار خودکار است، که به ما امکان می دهد خطاهای انسانی را به حداقل برسانیم، قابلیت اطمینان و تکرارپذیری را افزایش دهیم.
از نقطه نظر عملی، توضیح می دهیم GitOps به شرح زیر است:
ما قبلا زیرساخت را به عنوان کد به عنوان یکی از اجزای کلیدی این فرمول مورد بحث قرار داده ایم. بقیه اعضا را معرفی می کنیم.
درخواست ادغام (نام جایگزین برای Pull Request). از نظر فرآیند، MR درخواستی برای اعمال تغییرات کد و سپس ادغام شاخه ها است. اما از نظر ابزارهایی که استفاده می کنیم، این بیشتر فرصتی است برای دریافت تصویری کامل از تمام تغییرات ایجاد شده: نه تنها تفاوت کد جمع آوری شده از تعداد معینی از commit ها، بلکه زمینه، نتایج آزمایش و نتیجه مورد انتظار نهایی اگر ما در مورد کد زیرساخت صحبت می کنیم، پس ما علاقه مندیم که دقیقاً چگونه زیرساخت تغییر کند، چه تعداد منابع جدید اضافه یا حذف می شود، تغییر می کند. ترجیحاً در قالبی راحت‌تر و خواندنی‌تر. برای ارائه دهندگان ابر، ایده خوبی است که بدانند تأثیر مالی این تغییر چه خواهد بود.
اما MR همچنین وسیله ای برای همکاری، تعامل، ارتباط است. جایی که سیستم کنترل و تعادل وارد عمل می شود. از نظرات ساده گرفته تا تاییدیه ها و اظهارات رسمی.
خوب، آخرین مؤلفه: CI/CD، همانطور که قبلاً می دانیم، امکان خودکارسازی فرآیند ایجاد تغییرات زیرساخت و آزمایش (از بررسی ساده نحوی تا تجزیه و تحلیل کد استاتیک پیچیده تر) را فراهم می کند. و همچنین در تشخیص بعدی رانش: تفاوت بین وضعیت واقعی و مطلوب سیستم. به عنوان مثال، در نتیجه تغییرات دستی غیرمجاز یا خرابی سیستم.
بله، اصطلاح GitOps هیچ چیز کاملا جدیدی را به ما معرفی نمی کند، چرخ را دوباره اختراع نمی کند، بلکه به سادگی تجربه انباشته شده را در یک منطقه جدید به کار می گیرد. اما قدرت آن در آن نهفته است.
و اگر به طور ناگهانی علاقه مند شدید که همه چیز در عمل چگونه به نظر می رسد، از شما دعوت می کنم به ما نگاه کنید ، که در آن مرحله به مرحله نحوه استفاده از GitLab را به شما می گویم:
-
اصول اولیه GitOps را پیاده سازی کنید
-
ایجاد و ایجاد تغییرات در زیرساخت ابر (به عنوان مثال Yandex Cloud)
-
تشخیص خودکار انحراف سیستم از حالت دلخواه با استفاده از نظارت فعال
https://bit.ly/34tRpwZ
منبع: www.habr.com