سه مسئولیت متفاوت
Argo CD برای استقرار اعلامی برنامه‌ها، وضعیت مطلوب ثبت‌شده در Git را با وضعیت واقعی خوشه مقایسه می‌کند. در معماری رسمی، API Server رابط کاربر و دسترسی را ارائه می‌کند، Repository Server محتوای مخزن و خروجی ابزارهایی مانند Helm یا Kustomize را آماده می‌کند و Application Controller اختلاف وضعیت را دنبال می‌کند.
این تفکیک مهم است: تولید فایل‌های نهایی استقرار، تصمیم درباره تغییر منابع و اجرای خود برنامه یک کار واحد نیستند. Argo CD نیز جایگزین تمام مراحل ساخت و آزمون نرم‌افزار در CI نیست.
همگام‌بودن الزاماً سالم‌بودن نیست
ممکن است منابع خوشه با فایل‌های Git هماهنگ باشند، اما برنامه به دلیل تنظیم اشتباه، وابستگی بیرونی یا کمبود ظرفیت کار نکند. بنابراین باید وضعیت همگام‌سازی و سلامت برنامه را جدا دید. روشن‌کردن همگام‌سازی خودکار، حذف منابع و اصلاح خودکار تغییرات خارج از Git نیز تصمیم‌های جداگانه‌اند.
یک تمرین پیشنهادی برای تیم عملیاتی
در یک namespace آزمایشی، ابتدا برنامه‌ای کم‌خطر را با همگام‌سازی دستی مدیریت کنید. یک تغییر کوچک مانند تعداد replica را در Git ثبت کنید و قبل از اعمال، تفاوت ایجادشده را بخوانید. سپس همان مقدار را به‌صورت دستی در خوشه تغییر دهید و ببینید اختلاف چگونه گزارش می‌شود. هدف تمرین، مشاهده چرخه تصمیم است؛ نه فعال‌کردن همه گزینه‌های خودکار از روز اول.
بعد از این آزمون، مالک مخزن و مالک دسترسی خوشه را مشخص کنید. مخزنی که هر مشارکت‌کننده می‌تواند آزادانه در آن تغییر بدهد نباید بدون کنترل به حسابی با اختیار کامل خوشه متصل شود. نگهداری اسرار در فایل معمولی Git نیز راه‌حل مناسبی برای این تمرین نیست.
بازگشت را قبل از نیاز تمرین کنید
سناریوی فرضی بازگشت را با یک تغییر سازگار آغاز کنید؛ برای نمونه، بازگرداندن نسخه ایمیج برنامه. اما تغییر پایگاه داده، حذف حجم یا اجرای یک Job ممکن است تنها با بازگرداندن commit خنثی نشود. معیار موفقیت را در سطح سرویس تعریف کنید: پاسخ سالم، داده قابل‌استفاده و ثبت دقیق آنچه تغییر کرده است.
از یک تغییر کوچک تا وضعیت اجراشده
برای فهم جریان کار، یک برنامه وب با دو نمونه اجرایی را در نظر بگیرید. تعداد نمونه‌ها و تصویر برنامه در مخزن ثبت شده‌اند. توسعه‌دهنده تغییری می‌سازد که تصویر را به نسخه آزمایش‌شده تازه‌ای اشاره می‌دهد. پس از بازبینی و ادغام، Argo CD محتوای مخزن را می‌خواند و منابع قابل اعمال را تولید می‌کند. این مرحله ممکن است شامل پردازش قالب یا ترکیب فایل‌های تنظیم باشد. سپس نتیجه تولیدشده با منابع موجود در خوشه مقایسه می‌شود. تفاوت تصویر، تعداد نمونه‌ها یا سایر فیلدهای تحت مدیریت باعث می‌شود برنامه از وضعیت همگام خارج دیده شود.
خود مقایسه به معنی استقرار نیست. سیاست همگام‌سازی تعیین می‌کند آیا ابزار منتظر اقدام انسان می‌ماند یا تغییر را خودکار اعمال می‌کند. پس از اعمال، کنترل‌گرهای Kubernetes کار خود را انجام می‌دهند؛ برای مثال کنترل‌گر استقرار، مجموعه جدیدی از پادها ایجاد می‌کند و به تدریج نمونه‌های قدیمی را کم می‌کند. Argo CD مالک همه جزئیات اجرای برنامه نیست. اگر تصویر دانلود نمی‌شود یا فضای کافی برای زمان‌بندی وجود ندارد، باید رخدادهای همان منابع و وضعیت خوشه را بررسی کرد. جداسازی این مسئولیت‌ها از نسبت دادن هر شکست استقرار به GitOps جلوگیری می‌کند.
تفاوت همگامی و سلامت
برنامه‌ای ممکن است از نظر تعریف با مخزن همگام باشد ولی سالم نباشد. برای نمونه، تصویر مطلوب روی استقرار ثبت شده، اما برنامه به پایگاه داده وصل نمی‌شود. در جهت عکس، ممکن است خدمت فعلاً سالم پاسخ دهد ولی شخصی تعداد نمونه‌ها را مستقیم تغییر داده باشد و اختلاف با مخزن وجود داشته باشد. این دو وضعیت پاسخ دو سؤال مختلف هستند: آیا وضعیت واقعی با قصد ثبت‌شده برابر است و آیا منابع از نظر قواعد سلامت قابل استفاده‌اند؟ داشبورد عملیاتی باید هر دو را نشان دهد و هیچ‌کدام را جانشین آزمون واقعی خدمت نکند.
برای آزمایش این تفکیک، ابتدا تصویری سالم مستقر کنید. سپس در محیط غیرتولیدی مقدار تصویری ناموجود را در مخزن قرار دهید. مشاهده کنید تغییر چگونه اعمال می‌شود، پاد چه خطایی می‌دهد و وضعیت سلامت چگونه تغییر می‌کند. در آزمون دیگر، بدون تغییر مخزن تعداد نمونه‌ها را دستی عوض کنید. نتیجه به سیاست اصلاح خودکار اختلاف وابسته خواهد بود. این دو آزمایش کمک می‌کنند تیم تفاوت شکست در ساخت منابع، شکست در اعمال و شکست در اجرای برنامه را به چشم ببیند.
تولید منابع باید قابل بازتولید باشد
اگر یک ورودی ثابت در دو زمان خروجی متفاوت بسازد، تشخیص اختلاف دشوار می‌شود. قالب‌هایی که زمان جاری یا مقدار تصادفی تولید می‌کنند ممکن است هر بار تفاوت تازه‌ای بسازند. وابستگی به نسخه شناور یک بسته خارجی نیز می‌تواند بدون تغییر آشکار فایل محلی، نتیجه را عوض کند. برای محیط حساس، نسخه ابزار تولید منابع و وابستگی‌ها را روشن نگه دارید و خروجی مورد انتظار را در فرایند بازبینی بررسی کنید. هدف این نیست که همه خروجی‌ها حتماً به صورت دستی ذخیره شوند؛ هدف آن است که بتوان توضیح داد از یک بازبینی مشخص مخزن چه منابعی ساخته شده‌اند.
تفاوت‌های ایجادشده توسط کنترل‌گرهای دیگر نیز باید شناخته شوند. بعضی فیلدها در خوشه به طور طبیعی به‌روزرسانی می‌شوند. نادیده گرفتن اختلاف می‌تواند برای چنین فیلدهایی درست باشد، اما استثنای بسیار گسترده ممکن است تغییر غیرمجاز را پنهان کند. هر استثنا را به فیلد و دلیل مشخص محدود کنید. اگر تیم برای آرام کردن داشبورد تمام بخش مهمی از منبع را از مقایسه حذف کند، معنای همگامی ضعیف می‌شود. یک آزمون مناسب آن است که تغییر عمدی همان فیلد حساس هنوز قابل تشخیص باشد.
حذف منابع نیاز به فهم مالکیت دارد
برداشتن یک فایل از مخزن همیشه به معنی حذف فوری منبع در خوشه نیست؛ رفتار به تنظیم پاک‌سازی منابع وابسته است. قبل از فعال کردن حذف خودکار، مشخص کنید کدام منابع واقعاً متعلق به برنامه‌اند و کدام‌ها بین چند برنامه مشترک هستند. برای مثال حذف یک استقرار آزمایشی با حذف یک فضای ذخیره دارای داده واقعی پیامد یکسانی ندارد. منابع مشترک را با مرز مالکیت روشن مدیریت کنید تا دو برنامه بر سر یک شیء رقابت نکنند. بازبینی تغییر باید حذف‌ها را به اندازه ایجادها برجسته نشان دهد.
ترتیب اعمال نیز همیشه با ترتیب نام فایل‌ها تعیین نمی‌شود. وابستگی‌هایی مانند تعریف نوع منبع و نمونه‌های آن، یا آماده شدن یک خدمت قبل از کار راه‌اندازی، باید با سازوکار مناسب همان نسخه طراحی شوند. ابزارهای ترتیب‌دهی به معنی آماده بودن قطعی سامانه خارجی نیستند. اگر یک کار پایگاه داده باید اجرا شود، رفتار تکرار، شکست و اجرای دوباره آن را مشخص کنید. کاری که فقط یک بار در آزمایش موفق شده ولی در تکرار داده را خراب می‌کند برای استقرار خودکار مناسب نیست.
دسترسی مخزن و دسترسی خوشه دو راز متفاوت‌اند
Argo CD برای خواندن مخزن و اعمال منابع به مجوزهایی نیاز دارد، اما این دو مجوز نباید بی‌دلیل یک دامنه اختیار داشته باشند. حساب خواندن مخزن معمولاً به نوشتن در همه مخزن‌ها نیاز ندارد. دسترسی خوشه نیز باید با نوع برنامه و مقصد استقرار هماهنگ باشد. در طراحی چندتیمی، محدودیت منبع مخزن، مقصد خوشه و نوع منابع مجاز را جدا بررسی کنید. رابط کاربری، حساب خودکار و حساب اضطراری باید مسیرهای احراز هویت و ثبت رخداد قابل تشخیص داشته باشند.
رازهای برنامه را نیز صرف وجود مخزن خصوصی متن آشکار ثبت نکنید. Argo CD می‌تواند بخشی از زنجیره تحویل باشد، ولی انتخاب روش مدیریت راز تصمیم جداگانه‌ای است. اگر افزونه تولید منابع به رمزگشایی نیاز دارد، محل کلید و دسترسی فرایند اجراکننده را بررسی کنید. خروجی خطا یا پیش‌نمایش منابع ممکن است داده حساس را آشکار کند. برای آزمایش از راز ساختگی استفاده کنید و مسیر نمایش، ثبت و نگهداری آن را ببینید. این کار از کشف دیرهنگام نشت در گزارش‌های ساخت جلوگیری می‌کند.
بازگشت نسخه فقط بازگرداندن فایل نیست
اگر نسخه جدید برنامه داده را به قالب ناسازگار تبدیل کرده باشد، برگرداندن اشاره تصویر لزوماً خدمت را بازیابی نمی‌کند. پیش از انتشار، سازگاری نسخه قبلی با تغییر پایگاه داده را بررسی کنید. برای تغییرهای حساس، مهاجرت مرحله‌ای و قابلیت خواندن قالب قبلی می‌تواند امکان بازگشت را حفظ کند. در گزارش استقرار، بازبینی مخزن، تصویر دقیق و مهاجرت انجام‌شده را به هم پیوند دهید. استفاده از برچسب شناور تصویر این پیوند را ضعیف می‌کند، چون یک نام ممکن است در زمان‌های متفاوت به محتوای متفاوت اشاره کند.
در رخداد اضطراری ممکن است لازم شود اصلاحی مستقیم در خوشه انجام شود. اگر سیاست اصلاح خودکار فعال است، ابزار ممکن است آن را به وضعیت مخزن برگرداند. بنابراین روش توقف موقت همگام‌سازی، ثبت علت و انتقال اصلاح به مخزن باید از قبل معلوم باشد. پس از پایان حادثه، اختلاف‌های باقی‌مانده را مرور کنید و منبع حقیقت را دوباره روشن سازید. باقی گذاشتن تغییر دستی نامستند باعث می‌شود استقرار بعدی به ظاهر بی‌ارتباط، خدمت را دوباره خراب کند.
عیب‌یابی مرحله‌ای یک همگام‌سازی شکست‌خورده
ابتدا مشخص کنید مخزن قابل خواندن است و بازبینی مورد انتظار انتخاب شده است. سپس تولید منابع را بررسی کنید: خطای قالب، وابستگی غایب یا مسیر اشتباه معمولاً پیش از تماس با خوشه رخ می‌دهد. در مرحله بعد، اعتبار منابع و مجوز اعمال را بررسی کنید؛ رد شدن توسط پذیرش Kubernetes با خطای ارتباطی یکسان نیست. اگر اعمال موفق بوده، وضعیت منابع، رخداد زمان‌بندی و گزارش برنامه را بخوانید. این ترتیب از تغییر بی‌دلیل مجوزهای گسترده برای رفع خطای ساده قالب جلوگیری می‌کند.
برای تحویل به تیم، یک تمرین کوچک شامل تغییر سالم، تصویر خراب، تغییر دستی و حذف کنترل‌شده منبع بسازید. در هر مورد انتظار را قبل از اجرا بنویسید. خروجی مطلوب این تمرین فقط آشنایی با دکمه همگام‌سازی نیست؛ تیم باید بتواند توضیح دهد کدام مؤلفه تصمیم گرفته، کدام مؤلفه اجرا کرده و برای اصلاح باید کدام لایه تغییر کند. این توانایی ارزش اصلی استفاده از مدل اعلامی و قابل بازبینی است.
آزمون پذیرش تیمی
یک همکار که نویسنده تنظیمات نبوده باید بتواند از روی مخزن، برنامه هدف و خوشه مقصد را پیدا کند. از او بخواهید یک تغییر کوچک و برگشت‌پذیر را بدون راهنمایی شفاهی آماده کند و اثر مورد انتظار را توضیح دهد. سپس همان تغییر را بازگرداند و نشان دهد منابع اضافی باقی نمانده‌اند. اگر برای یافتن یک راز، مسیر قالب یا مالک منبع به حافظه یک نفر وابسته هستید، فرایند هنوز کامل مستند نشده است. ثبت این ابهام‌ها پیش از حادثه، از افزودن ابزارهای بیشتر مفیدتر است. معیار پذیرش، امکان تکرار امن همین کار توسط عضو دیگر تیم در زمان معمول و در وضعیت اضطراری است.
