GitOps: مقایسه روش‌های کشش و فشار

توجه داشته باشید. ترجمه: در جامعه Kubernetes، روندی به نام GitOps در حال محبوبیت آشکاری است، همانطور که شخصاً شاهد آن بودیم. بازدید KubeCon Europe 2019. این اصطلاح نسبتاً اخیر بود اختراع کرد توسط رئیس Weaveworks - Alexis Richardson - و به معنای استفاده از ابزارهای آشنا برای توسعه دهندگان (در درجه اول Git، از این رو نام) برای حل مشکلات عملیاتی است. به طور خاص، ما در مورد عملکرد Kubernetes با ذخیره تنظیمات آن در Git و ایجاد خودکار تغییرات در خوشه صحبت می کنیم. Matthias Jg در این مقاله در مورد دو رویکرد به این عرضه صحبت می کند.

سال گذشته، (در واقع، به طور رسمی این اتفاق در اوت 2017 رخ داد - تقریباً ترجمه.) رویکرد جدیدی برای استقرار برنامه‌ها در Kubernetes وجود دارد. GitOps نامیده می شود و بر اساس این ایده اولیه است که نسخه های استقرار در محیط امن یک مخزن Git ردیابی می شوند.

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

1. استقرار نسخه و تاریخچه تغییر. وضعیت کل خوشه در یک مخزن Git ذخیره می شود و استقرارها فقط از طریق commit ها به روز می شوند. علاوه بر این، تمام تغییرات را می توان با استفاده از تاریخچه commit پیگیری کرد.
2. بازگشت با استفاده از دستورات آشنای Git. ساده git reset به شما امکان می دهد تغییرات در استقرارها را بازنشانی کنید. حالت های گذشته همیشه در دسترس هستند.
3. کنترل دسترسی آماده. به طور معمول، یک سیستم Git حاوی داده های حساس زیادی است، بنابراین اکثر شرکت ها توجه ویژه ای به محافظت از آن دارند. بر این اساس، این حفاظت در مورد عملیات با استقرار نیز اعمال می شود.
4. سیاست های استقرار. اکثر سیستم‌های Git به طور بومی از سیاست‌های شاخه به شاخه پشتیبانی می‌کنند – برای مثال، فقط درخواست‌های کششی می‌توانند Master را به‌روزرسانی کنند و تغییرات باید توسط یکی دیگر از اعضای تیم بررسی و پذیرفته شوند. همانند کنترل دسترسی، سیاست‌های مشابهی برای به‌روزرسانی‌های استقرار اعمال می‌شود.

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

روش های استقرار

در سال های اخیر، Kubernetes روش ها و ابزارهای مختلفی را برای استقرار ایجاد کرده است:

1. بر اساس الگوهای بومی Kubernetes/Customize. این ساده ترین راه برای استقرار برنامه ها در Kubernetes است. توسعه دهنده فایل های اولیه YAML را ایجاد کرده و آنها را اعمال می کند. برای رهایی از بازنویسی مداوم همان قالب ها، Kustomize توسعه داده شد (قالب های Kubernetes را به ماژول تبدیل می کند). توجه داشته باشید. ترجمه: Kustomize با kubectl ادغام شده است انتشار Kubernetes 1.14.
2. نمودارهای هلم. نمودارهای هلم به شما امکان می‌دهند مجموعه‌ای از قالب‌ها، کانتینرهای اولیه، سایدکارها و غیره ایجاد کنید که برای استقرار برنامه‌های کاربردی با گزینه‌های سفارشی‌سازی انعطاف‌پذیرتر نسبت به رویکرد مبتنی بر الگو استفاده می‌شوند. این روش بر اساس فایل های YAML قالب بندی شده است. Helm آنها را با پارامترهای مختلف پر می کند و سپس آنها را به Tiller می فرستد، یک جزء خوشه ای که آنها را در خوشه مستقر می کند و اجازه به روز رسانی و بازگشت را می دهد. نکته مهم این است که Helm اساساً فقط مقادیر مورد نظر را در قالب ها وارد می کند و سپس آنها را به همان روشی که در رویکرد سنتی انجام می شود اعمال می کند. (در مورد نحوه کار و نحوه استفاده از آن در ما بیشتر بخوانید مقاله هلم - تقریبا ترجمه.). طیف گسترده ای از نمودارهای هلم آماده وجود دارد که طیف گسترده ای از وظایف را پوشش می دهد.
3. ابزارهای جایگزین. ابزارهای جایگزین زیادی وجود دارد. وجه مشترک همه آنها این است که برخی از فایل های قالب را به فایل های YAML قابل خواندن Kubernetes تبدیل کرده و سپس از آنها استفاده می کنند.

در کار خود، ما دائماً از نمودارهای Helm برای ابزارهای مهم استفاده می کنیم (زیرا آنها چیزهای زیادی از قبل آماده کرده اند، که زندگی را بسیار آسان تر می کند) و فایل های Kubernetes YAML "خالص" برای استقرار برنامه های خودمان.

بکشید فشار دهید

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

توجه داشته باشید تمام مزایای استفاده از GitOps برای هر دو رویکرد یکسان است.

رویکرد مبتنی بر کشش

رویکرد کشش بر این واقعیت استوار است که همه تغییرات از درون خوشه اعمال می شود. یک اپراتور در داخل کلاستر وجود دارد که به طور منظم مخازن مربوط به Git و Docker Registry را بررسی می کند. اگر تغییری در آنها رخ دهد، وضعیت خوشه به صورت داخلی به روز می شود. این فرآیند به طور کلی بسیار امن در نظر گرفته می شود، زیرا هیچ مشتری خارجی به حقوق مدیر خوشه دسترسی ندارد.

مزایا:

1. هیچ مشتری خارجی حق ایجاد تغییرات در خوشه را ندارد؛ همه به‌روزرسانی‌ها از داخل ارائه می‌شوند.
2. برخی از ابزارها همچنین به شما امکان می‌دهند به‌روزرسانی‌های نمودار Helm را همگام‌سازی کنید و آنها را به خوشه پیوند دهید.
3. Docker Registry را می توان برای نسخه های جدید اسکن کرد. اگر تصویر جدیدی در دسترس باشد، مخزن Git و استقرار آن به نسخه جدید به روز می شود.
4. ابزارهای کششی را می توان در فضای نام های مختلف با مخازن و مجوزهای Git مختلف توزیع کرد. به لطف این، می توان از یک مدل چند مستاجر استفاده کرد. به عنوان مثال، تیم A ممکن است از فضای نام A استفاده کند، تیم B ممکن است از فضای نام B، و تیم زیرساخت ممکن است از فضای جهانی استفاده کند.
5. به عنوان یک قاعده، ابزارها بسیار سبک وزن هستند.
6. همراه با ابزارهایی مانند اپراتور اسرار مهر و موم شده بیتنامی، اسرار را می توان به صورت رمزگذاری شده در یک مخزن Git ذخیره کرد و در کلاستر بازیابی کرد.
7. هیچ اتصالی به خطوط لوله CD وجود ندارد زیرا استقرار در داخل خوشه رخ می دهد.

منفی:

1. مدیریت اسرار استقرار از نمودارهای Helm دشوارتر از موارد معمولی است، زیرا ابتدا باید به شکل اسرار مهر و موم شده تولید شوند، سپس توسط یک اپراتور داخلی رمزگشایی شوند و تنها پس از آن در دسترس ابزار کشش قرار گیرند. سپس می توانید نسخه را در Helm با مقادیر موجود در رازهای از قبل مستقر شده اجرا کنید. ساده ترین راه این است که یک راز با تمام مقادیر Helm که برای استقرار استفاده می شود ایجاد کنید، آن را رمزگشایی کنید و به Git متعهد کنید.
2. وقتی رویکرد کششی را در پیش می گیرید، به ابزارهای کششی گره می خورید. این توانایی سفارشی کردن فرآیند استقرار در یک خوشه را محدود می کند. به عنوان مثال، Kustomize به دلیل این واقعیت پیچیده است که باید قبل از متعهد شدن قالب های نهایی به Git اجرا شود. من نمی گویم نمی توانید از ابزارهای مستقل استفاده کنید، اما ادغام آنها در فرآیند استقرار شما دشوارتر است.

رویکرد مبتنی بر فشار

در رویکرد فشار، یک سیستم خارجی (عمدتاً خطوط لوله CD) پس از یک تعهد به مخزن Git یا در صورت موفقیت خط لوله قبلی CI، استقرارها را در خوشه راه اندازی می کند. در این رویکرد، سیستم به خوشه دسترسی دارد.

مزایا:

1. امنیت توسط مخزن Git و خط لوله ساخت تعیین می شود.
2. استقرار نمودارهای Helm ساده تر است و از افزونه های Helm پشتیبانی می کند.
3. مدیریت اسرار آسان تر است زیرا اسرار را می توان در خطوط لوله استفاده کرد و همچنین می تواند به صورت رمزگذاری شده در Git ذخیره شود (بسته به ترجیحات کاربر).
4. هیچ ارتباطی با ابزار خاصی وجود ندارد، زیرا می توان از هر نوع استفاده کرد.
5. به روز رسانی نسخه کانتینر را می توان توسط خط لوله ساخت آغاز کرد.

منفی:

1. داده های دسترسی خوشه ای در داخل سیستم ساخت قرار دارند.
2. به روز رسانی کانتینرهای استقرار همچنان با فرآیند کشش آسان تر است.
3. وابستگی شدید به سیستم CD، زیرا خطوط لوله مورد نیاز ما ممکن است در ابتدا برای Gitlab Runners نوشته شده باشند، و سپس تیم تصمیم می گیرد به Azure DevOps یا Jenkins برود... و باید تعداد زیادی از خطوط لوله ساخت را مهاجرت کند.

نتایج: فشار یا کشیدن؟

همانطور که معمولاً اتفاق می افتد، هر رویکردی مزایا و معایب خود را دارد. انجام برخی کارها با یکی آسان تر و با دیگری دشوارتر است. ابتدا به صورت دستی استقرارها را انجام می‌دادم، اما پس از اینکه با چند مقاله در مورد Weave Flux مواجه شدم، تصمیم گرفتم که فرآیندهای GitOps را برای همه پروژه‌ها پیاده‌سازی کنم. برای قالب‌های اولیه این کار آسان بود، اما پس از آن من با نمودارهای Helm با مشکل مواجه شدم. در آن زمان، Weave Flux تنها یک نسخه ابتدایی از Helm Chart Operator را ارائه می‌کرد، اما حتی در حال حاضر برخی از کارها به دلیل نیاز به ایجاد اسرار دستی و اعمال آنها دشوارتر هستند. شما می توانید استدلال کنید که رویکرد کشش بسیار ایمن تر است زیرا اعتبار خوشه در خارج از خوشه قابل دسترسی نیست و آن را بسیار ایمن تر می کند که ارزش تلاش اضافی را دارد.

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

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

به نظر من (مثل همیشه) باید از آنچه برای یک مورد خاص یا ترکیب مناسب تر است استفاده کنید. من شخصا از هر دو روش استفاده می‌کنم: Weave Flux برای استقرارهای مبتنی بر کشش که بیشتر شامل خدمات خودمان است، و رویکرد فشاری با Helm و افزونه‌ها، که اعمال نمودارهای Helm را در خوشه آسان می‌کند و به شما امکان می‌دهد اسرار یکپارچه ایجاد کنید. من فکر می کنم هرگز یک راه حل واحد مناسب برای همه موارد وجود نخواهد داشت، زیرا همیشه تفاوت های ظریف زیادی وجود دارد و آنها به کاربرد خاص بستگی دارند. همانطور که گفته شد، من به شدت GitOps را توصیه می کنم - زندگی را بسیار آسان تر می کند و امنیت را بهبود می بخشد.

امیدوارم تجربه من در مورد این موضوع به شما کمک کند تصمیم بگیرید کدام روش برای نوع استقرار شما مناسب تر است و خوشحال می شوم نظر شما را بشنوم.

PS یادداشت از مترجم

نقطه ضعف مدل pull این است که قرار دادن مانیفست های رندر شده در Git دشوار است، اما هیچ نقطه ضعفی وجود ندارد که خط لوله CD در مدل کششی جدا از رول اوت زندگی می کند و اساسا به یک خط لوله دسته بندی تبدیل می شود. درخواست مداوم. بنابراین، تلاش بیشتری برای جمع‌آوری وضعیت آنها از همه استقرارها و به نحوی فراهم کردن دسترسی به گزارش‌ها/وضعیت، ترجیحاً با ارجاع به سیستم CD، مورد نیاز است.

از این نظر، مدل فشار به ما اجازه می‌دهد تا حداقل برخی از تضمین‌های عرضه را ارائه دهیم، زیرا طول عمر خط لوله را می‌توان با طول عمر راه‌اندازی برابر کرد.

ما هر دو مدل را امتحان کردیم و به نتایج مشابه نویسنده مقاله رسیدیم:

1. مدل کششی برای سازماندهی به‌روزرسانی‌های اجزای سیستم در تعداد زیادی از خوشه‌ها مناسب است (نگاه کنید به. مقاله ای در مورد اپراتور افزونه).
2. مدل فشار مبتنی بر GitLab CI برای ارائه برنامه‌های کاربردی با استفاده از نمودار Helm مناسب است. در همان زمان، گسترش استقرار در خطوط لوله با استفاده از ابزار نظارت می شود ورف. به هر حال، در چارچوب این پروژه ما، هنگامی که مشکلات مبرم مهندسان DevOps را در غرفه خود در KubeCon Europe'19 مورد بحث قرار دادیم، صدای ثابت "GitOps" را شنیدیم.

PPS از مترجم

در وبلاگ ما نیز بخوانید:

• «نکات و ترفندهای Kubernetes: انتقال منابع در حال اجرا در یک کلاستر به مدیریت Helm 2"؛
• «معرفی kubedog، کتابخانه ای برای ردیابی منابع Kubernetes"؛
• «گسترش و تکمیل Kubernetes (بازبینی و گزارش تصویری)"؛
• «نکاتی برای ایجاد گردش کار سفارشی در GitLab CI'.

فقط کاربران ثبت نام شده می توانند در نظرسنجی شرکت کنند. ورود، لطفا.

آیا از GitOps استفاده می کنید؟

• بله، رویکرد کششی

• بله، فشار دهید

• بله، بکشید + فشار دهید

• بله، چیز دیگری است

• بدون

30 کاربر رای دادند. 10 کاربر رای ممتنع دادند.

منبع: www.habr.com