یک مجموعه کنترل‌گر، نه یک فرمان بزرگ
Flux از اجزای GitOps Toolkit تشکیل می‌شود. کنترل‌گر منبع، ورودی‌هایی مانند مخزن را دنبال و artifact مناسب آماده می‌کند؛ کنترل‌گرهای دیگر، از جمله Kustomize و Helm، مسئول اعمال و پیگیری منابع مربوط‌اند. مؤلفه‌های اعلان و خودکارسازی ایمیج نیز نقش‌های جداگانه دارند.
این تفکیک هنگام عیب‌یابی مفید است: آیا منبع دریافت نشده، artifact تولید نشده، اعمال تغییر شکست خورده یا برنامه پس از اعمال سالم نشده است؟ دیدن آخرین commit در مخزن، به‌تنهایی پاسخ هیچ‌کدام از مراحل بعد را ثابت نمی‌کند.
نمودار رسمی همراه مقاله، رابطه اجزای toolkit را نشان می‌دهد. همه قابلیت‌های موجود در آن لازم نیست از ابتدای هر استقرار فعال باشند.
چرخه تطبیق چه تعهدی ایجاد می‌کند؟
در مدل GitOps، وضعیت مطلوب باید روشن و قابل پیگیری باشد. تغییر دستی در خوشه و تغییر در مخزن دو مسیر متفاوت‌اند؛ باید بدانید کنترل‌گر در برابر اختلاف چه رفتاری دارد. همچنین منبعی که ابزار می‌خواند باید از نظر سطح دسترسی، بازبینی تغییر و حفاظت از شاخه متناسب با اختیار کنترل‌گر باشد.
آزمایش پیشنهادی برای یک برنامه کم‌خطر
در namespace آزمایشی، یک تغییر ساده مثل نسخه یک ایمیج نمایشی را از مخزن اعمال کنید. زمان دریافت منبع، آماده‌شدن artifact و رسیدن برنامه به وضعیت مورد انتظار را جدا ثبت کنید. اکنون یک تغییر نامعتبر ایجاد کنید و ببینید خطا در کدام مرحله گزارش می‌شود.
آزمون دوم را به قطع موقت دسترسی منبع اختصاص دهید. آیا برنامه موجود ادامه می‌دهد؟ آیا تغییرهای تازه متوقف می‌شوند؟ چه کسی هشدار می‌گیرد؟ پاسخ را از رفتار واقعی استقرار خود به دست آورید، نه از فرض اینکه همه خطاها باید یک اثر یکسان داشته باشند.
بازگشت، باید معنای عملیاتی داشته باشد
بازگرداندن commit می‌تواند تعریف منابع را به نسخه قبلی برگرداند، اما اثر حذف داده یا اجرای یک مهاجرت پایگاه داده الزاماً با آن خنثی نمی‌شود. برای برنامه فرضی، تغییرهای برگشت‌پذیر و برگشت‌ناپذیر را پیش از انتشار دسته‌بندی کنید.
پیشنهاد تحریریه این است که معیار پایان rollback را از دید کاربر بنویسید: پاسخ سالم، داده قابل خواندن و نسخه درست سرویس. صرفاً سبزشدن یک وضعیت همگام‌سازی کافی نیست.
حداقل اختیار و شواهد
حساب خواندن مخزن، حساب تغییر مخزن برای خودکارسازی و اختیار اعمال روی خوشه را یک راز مشترک نکنید. هر مسیر باید دلیل و دامنه مشخص داشته باشد. ثبت نسخه منبع و نتیجه تطبیق، کمک می‌کند بعداً بتوان فهمید کدام تغییر، چه زمانی و با چه نتیجه‌ای اعمال شده است.
مخزن وضعیت مطلوب را چگونه سازمان دهیم؟
در یک تیم کوچک می‌توان تعریف برنامه و تنظیمات محیط را در یک مخزن نگه داشت، اما مرز اختیار باید همچنان روشن باشد. تغییر تنظیمات تولید نباید صرف دسترسی توسعه‌دهنده به کد برنامه خودکار مجاز شود. شاخه، مسیر و روند بازبینی را متناسب با اختیار کنترل‌گر انتخاب کنید. اگر Flux با مجوز گسترده به خوشه متصل است، امکان نوشتن در مسیر خوانده‌شده از مخزن نیز عملاً اختیار مهمی ایجاد می‌کند. امنیت مخزن بخشی از امنیت خوشه می‌شود، حتی اگر هیچ اعتبار Kubernetes در رایانه توسعه‌دهنده نباشد.
برای چند محیط، اختلاف‌ها را صریح نگه دارید. مقدار replica، نام دامنه، منبع راز و محدودیت منابع ممکن است میان آزمایش و تولید متفاوت باشد. کپی کامل پوشه‌ها در ابتدا ساده است ولی می‌تواند اختلاف‌های ناخواسته ایجاد کند؛ انتزاع بیش از حد نیز فهم خروجی را دشوار می‌کند. معیار خوب این است که بازبین بتواند از تغییر پیشنهادی بفهمد در کدام محیط چه منبعی عوض خواهد شد. خروجی ساخته‌شده را پیش از ادغام بررسی کنید تا تغییر کوچک در یک پایه مشترک همه محیط‌ها را غافلگیر نکند.
هر مرحله یک ورودی و خروجی دارد
کنترل‌گر منبع باید به مخزن دسترسی پیدا کند و نسخه مورد نظر را دریافت کند. سپس کنترل‌گر مصرف‌کننده باید همان artifact را بسازد یا اعمال کند. در پایان، منابع برنامه باید به وضعیت سالم برسند. این مراحل ممکن است در زمان‌های متفاوت موفق شوند. برای نمونه، دریافت commit تازه موفق است ولی ساخت Kustomize به دلیل مسیر اشتباه شکست می‌خورد. در این حالت، جست‌وجوی مشکل در Pod برنامه که هنوز نسخه قبلی را اجرا می‌کند، نقطه شروع مناسبی نیست.
یک شناسه نسخه در گزارش انتشار نگه دارید و آن را از مخزن تا وضعیت کنترل‌گر و برنامه دنبال کنید. اگر تیم فقط می‌گوید «آخرین نسخه منتشر شد»، معلوم نیست آخرین نسخه از دید کدام جزء است. در برنامه آزمایشی، پاسخ سرویس می‌تواند شناسه نسخه را نمایش دهد. این روش کمک می‌کند ادعای اعمال پیکربندی را به رفتار قابل مشاهده کاربر وصل کنید. برای برنامه واقعی، اطلاعات عمومی پاسخ نباید اسرار ساخت یا جزئیات حساس زیرساخت را فاش کند.
وابستگی منابع را از تأخیر تصادفی جدا کنیم
بعضی منابع پیش‌نیاز دیگران‌اند؛ برای مثال تعریف یک نوع منبع باید پیش از نمونه‌های آن در دسترس باشد. اتکا به اینکه کنترل‌گر بالاخره در تلاش بعدی موفق می‌شود، همیشه تجربه عملیاتی مناسبی نیست. وابستگی‌های شناخته‌شده را با امکانات پشتیبانی‌شده ابزار بیان کنید و بررسی سلامت مناسب داشته باشید. با این حال، موفقیت ساخت یک منبع لزوماً به معنای آماده بودن سرویس خارجی مرتبط نیست. اگر برنامه به پایگاه داده بیرونی نیاز دارد، آن وابستگی باید در آزمون برنامه نیز دیده شود.
در آزمایش، یک پیش‌نیاز را عمداً دیر آماده کنید و رفتار منابع وابسته را مشاهده کنید. آیا خطا به اندازه کافی روشن است؟ آیا پس از رفع مشکل فرایند ادامه می‌یابد؟ آیا هشدار برای هر تلاش تکرار می‌شود و تیم را با پیام‌های مشابه پر می‌کند؟ این پرسش‌ها برای کیفیت عملیات مهم‌اند. تنظیم فاصله تطبیق یا زمان انتظار باید از رفتار واقعی وابستگی بیاید، نه از تلاش برای سبز کردن سریع داشبورد. انتظار طولانی بدون پیام روشن نیز به همان اندازه می‌تواند تشخیص را کند کند.
تغییر دستی و توقف تطبیق
در مدل GitOps، تغییر مستقیم در خوشه ممکن است در چرخه بعدی با وضعیت مخزن جایگزین شود. هنگام حادثه، تیم باید بداند چه زمانی توقف موقت تطبیق لازم است و چه کسی اختیار آن را دارد. توقف نباید بدون ثبت دلیل و برنامه بازگشت رها شود، زیرا پس از آن مخزن دیگر وضعیت واقعی را توضیح نمی‌دهد. اگر اصلاح فوری به صورت دستی انجام شد، تغییر پایدار متناظر باید در مخزن ثبت شود یا تصمیم بازگرداندن آن روشن باشد.
یک تمرین مفید، تغییر کوچک و بی‌خطر در یک منبع آزمایشی است. ابتدا رفتار اصلاح خودکار را ببینید، سپس در حالت توقف همان تغییر را انجام دهید و تفاوت را ثبت کنید. بعد تطبیق را از سر بگیرید و اطمینان پیدا کنید وضعیت نهایی قابل پیش‌بینی است. هدف این تمرین آموزش استفاده دائمی از تغییر دستی نیست؛ شناخت دقیق رفتار ابزار در وضعیت اضطراری است. بدون این شناخت، دو اپراتور ممکن است هم‌زمان با کنترل‌گر برای حفظ دو وضعیت متفاوت رقابت کنند.
حذف منابع و اهمیت سیاست پاک‌سازی
GitOps فقط درباره ایجاد و تغییر نیست؛ حذف فایل از مخزن نیز می‌تواند اثر عملی داشته باشد. سیاست پاک‌سازی باید برای منابع موقت و داده‌دار جدا بررسی شود. حذف اشتباه تعریف یک برنامه شاید به راحتی جبران شود، اما حذف منبعی با سیاست نگه‌داری نامناسب می‌تواند داده را متاثر کند. قبل از فعال کردن پاک‌سازی گسترده، یک منبع آزمایشی را حذف کنید و نتیجه را ببینید. همچنین اثر تغییر نام یا جابه‌جایی مسیر فایل را بررسی کنید تا حذف و ایجاد ناخواسته تشخیص داده شود.
در بازبینی تغییر، فایل‌های حذف‌شده را به اندازه فایل‌های تازه جدی بگیرید. اگر ساختار مخزن عوض می‌شود، خروجی نهایی منابع را با نسخه قبلی مقایسه کنید. هدف، اثبات حفظ منابع مورد نیاز است و نه صرفاً موفق بودن ساخت محلی. برای منابع حساس، سیاست محافظت و روش بازیابی باید جدا تعریف شود. بازگرداندن commit ممکن است شیء را دوباره ایجاد کند، اما درباره داده‌ای که قبلاً حذف شده است تعهدی ندارد؛ این محدودیت باید در برنامه تغییر صریح باشد.
رازها و زنجیره تأمین تغییر
قرار دادن راز خام در مخزن حتی خصوصی، دامنه انتشار آن را به تاریخچه و نسخه‌های محلی گسترش می‌دهد. روش مدیریت راز باید با امکانات محیط و کنترل دسترسی هماهنگ باشد. اگر از رمزگذاری فایل استفاده می‌شود، محل کلید بازگشایی و حسابی که به آن دسترسی دارد نیز بخشی از طراحی است. اگر راز از سامانه بیرونی می‌آید، خرابی آن سامانه و زمان تازه شدن داده را آزمایش کنید. هیچ‌کدام از این روش‌ها با حذف فایل از آخرین commit به تنهایی تاریخچه افشاشده را پاک نمی‌کنند.
خودکارسازی نسخه تصویر نیز باید محدوده مشخص داشته باشد. انتخاب هر برچسب تازه بدون سیاست نسخه و آزمون می‌تواند انتشار ناخواسته ایجاد کند. بهتر است مسیر انتخاب تصویر، پیشنهاد تغییر، بازبینی و اعمال آن قابل ردیابی باشد. برای عیب‌یابی، راهنمای رسمی Flux به تفکیک وضعیت منبع و کنترل‌گرها کمک می‌کند. معیار نهایی موفقیت همچنان خدمت سالم با نسخه مورد انتظار است؛ دریافت مخزن، اعمال YAML و آماده شدن برنامه سه شاهد مکمل هستند که باید کنار هم تفسیر شوند.
وقتی مخزن در دسترس نیست
قطع دسترسی مخزن معمولاً به معنی ناپدید شدن فوری برنامه‌های موجود نیست؛ اما توان دریافت تغییر تازه مختل می‌شود. تیم باید میان سلامت سرویس و سلامت مسیر انتشار تفاوت بگذارد. اگر تنها هشدار پاسخ وب وجود داشته باشد، خرابی طولانی مسیر GitOps ممکن است تا زمان نیاز فوری به انتشار کشف نشود. یک بررسی دوره‌ای از تازگی تطبیق و خطاهای منبع، این فاصله را آشکار می‌کند. نامعتبر شدن اعتبار مخزن، تغییر کلید میزبان و اختلال DNS نشانه‌های متفاوتی دارند و باید از پیام واقعی تشخیص داده شوند.
برای چرخش اعتبار مخزن، ابتدا امکان خواندن با اعتبار تازه را در محدوده کنترل‌شده بررسی کنید و سپس مصرف‌کننده را تغییر دهید. اعتبار قدیمی را تا پایان تأیید مطابق سیاست کوتاه‌مدت نگه دارید و پس از موفقیت لغو کنید. باقی گذاشتن همیشگی دو اعتبار، چرخش را ناقص می‌کند. در آزمون نهایی، یک تغییر بی‌خطر تازه منتشر کنید؛ سبز بودن وضعیت قدیمی اثبات نمی‌کند کنترل‌گر اکنون با اعتبار جدید به مخزن دسترسی دارد. همین اصل برای تغییر نشانی مخزن یا انتقال آن به میزبان دیگر نیز کاربرد دارد.
