انتشار روی ناوگانی از نودهای لبه، یک مسئلهٔ هماهنگی است: همهٔ نودها یک سخت‌افزار، کیفیت شبکه یا زمان اتصال ندارند. یک انتشار موفق باید هم نسخهٔ مطلوب را مشخص کند و هم توضیح دهد وقتی یک نود عقب افتاد یا نسخهٔ جدید مشکل داشت، چه اتفاقی می‌افتد.
وضعیت مطلوب را نسخه‌بندی کنیم
نسخهٔ ایمیج، تنظیمات و قراردادهای وابسته باید قابل پیگیری باشند. GitOps از وضعیت مطلوب نسخه‌بندی‌شده و جریان تطبیق با وضعیت واقعی استفاده می‌کند. مستندات کنترلرهای Kubernetes سازوکار مقایسهٔ وضعیت مطلوب و فعلی را توضیح می‌دهند.
برای هر نود، نسخهٔ مطلوب را از آخرین نسخهٔ مشاهده‌شده جدا ثبت کنید. نبود گزارش جدید، اثبات موفقیت انتشار نیست. نسخهٔ ایمیج را به شناسهٔ قابل اعتماد متصل کنید تا بازسازی با یک تگ متغیر، محتوای متفاوتی تحویل ندهد.
Canary باید نمایندهٔ شرایط واقعی باشد
گروه آزمایشی را فقط از بهترین نودها انتخاب نکنید. تفاوت سخت‌افزار، کیفیت ارتباط و حجم کار را در انتخاب در نظر بگیرید. معیار عبور به گروه بعدی باید به عملیات واقعی مرتبط باشد؛ آماده‌شدن فرایند به‌تنهایی نشان نمی‌دهد ثبت سفارش یا دریافت داده سالم است.
سلامت را در چند لایه ببینیم
بررسی آمادگی سرویس، درخواست کاربردی و وضعیت منابع، پرسش‌های متفاوتی را جواب می‌دهند. مستندات Deployment در Kubernetes وضعیت پیشرفت انتشار و تاریخچهٔ نسخه‌ها را پوشش می‌دهند. در طراحی عملیات، توقف پیشرفت باید به یک تصمیم روشن برای توقف یا بررسی منتهی شود.
روی نود دور از مرکز، آخرین زمان گزارش را کنار نتیجهٔ سلامت نشان دهید. یک وضعیت سالمِ قدیمی را به‌عنوان سلامت فعلی نمایش ندهید. اگر خطاها بالا رفتند، گسترش انتشار را متوقف کنید و شواهد همان گروه را بررسی کنید.
Rollback برنامه با بازگشت داده فرق دارد
نگه‌داشتن ایمیج قبلی لازم است، اما کافی نیست. اگر نسخهٔ جدید ستون یا داده‌ای را حذف کرده باشد، اجرای برنامهٔ قدیمی مشکل را حل نمی‌کند. تغییرات قرارداد و پایگاه داده را تدریجی طراحی کنید: ابتدا سازگاری دو نسخه، سپس مهاجرت و در نهایت حذف مسیر قدیمی.
نودهای آفلاین و هزینهٔ توزیع
نود قطع‌شده پس از اتصال باید وضعیت مطلوب معتبر را ببیند، نه فهرستی مبهم از فرمان‌های ازدست‌رفته. اندازهٔ ایمیج، دفعات دانلود و تعداد تلاش‌های مجدد روی هزینه و زمان تحویل اثر دارند. از دید FinOps، کاهش مصرف باید با نیاز عملیاتی سنجیده شود؛ حذف منابع حیاتی به‌خاطر یک عدد کوچک‌تر، معیار موفقیت مناسبی نیست.
چک‌لیست قبل از انتشار
- نسخهٔ جاری را در مخزن ثبت و ایمیج قبلی را حفظ کنید.
- سازگاری تنظیمات و داده با نسخهٔ قبلی را بررسی کنید.
- معیار توقف، مالک تصمیم و مسیر بازیابی را مشخص کنید.
- انتشار را با گروه محدود آغاز کنید و نتیجهٔ کاربردی را ببینید.
- قطع شبکه و بازگشت یک نود عقب‌افتاده را آزمایش کنید.
بریف زیرساخت لبهٔ شرکت ملی پست زمینهٔ این مسئله را نشان می‌دهد. همچنین تجربهٔ والدنت در انتشار پلتفرم دنتال و همگام‌سازی Offline-first را ببینید.