وقتی صحبت از Deployment می‌کنیم، منظورمون فقط انتقال فایل‌های نرم‌افزار به سرور نیست؛ بلکه باید مشخص کنیم چطور نسخه‌ی جدید جایگزین نسخه‌ی فعلی بشه، بدون اینکه تجربه‌ی کاربران مختل بشه.
در مجموعه‌ی استراتژی‌های دیپلوی، روش‌هایی رو بررسی می‌کنیم که هرکدوم با رویکرد متفاوتی نسخه‌ی جدید نرم‌افزار رو منتشر می‌کنن.
در مقاله‌ی قبل با Big Bang Deployment آشنا شدیم؛ روشی که در اون کل برنامه یک‌باره متوقف و جایگزین میشه. اما اگر چند نمونه از برنامه داشته باشیم، می‌تونیم به‌جای متوقف کردن همه‌ی اون‌ها، هر بار فقط تعدادی رو به‌روزرسانی کنیم.
به این روش Rolling Update Deployment می‌گیم.
Rolling Update چطور کار می‌کنه؟
در حال رسم نمودار…
فرض کنید برنامه‌ی شما روی چهار سرور یا چهار Instance اجرا شده و همه‌ی اون‌ها نسخه‌یv1رو دارن.
در Rolling Update، به‌جای اینکه هر چهار Instance هم‌زمان متوقف بشن، به‌تدریج جایگزین میشن:
۳. بعد از تأیید سلامت نسخه‌ی جدید، وارد چرخهی دریافت ترافیک میشه.
۴. همین فرایند برای Instanceهای بعدی تکرار میشه.
در نتیجه، در طول دیپلوی ممکنه نسخه‌های قدیمی و جدید هم‌زمان در حال اجرا باشن.
نکتهی مهم اینه که Rolling Update لزوماً به معنی تغییر ترافیک کاربران نیست؛ معمولاً هر Instance پس از آماده شدن جایگزین نمونهی قبلی میشه و Load Balancer ترافیک رو بین نمونههای آماده توزیع می‌کنه.
مثال با Laravel
فرض کنید یک برنامه‌ی Laravel روی سه سرور اجرا شده و هر سه پشت یک Load Balancer قرار دارن.
برای انتشار نسخه‌ی جدید می‌تونیم:
ابتدا سرور اول رو از Load Balancer خارج کنیم.
نسخه‌ی جدید رو روی اون مستقر کنیم.
وابستگیها و Migrationهای لازم رو مدیریت کنیم.
بعد از Health Check موفق، سرور رو دوباره وارد مدار کنیم.
همین مراحل رو برای سرورهای بعدی تکرار کنیم.
در این معماری، چند نکته اهمیت زیادی دارن:
Session و Cache مشترک:اگر Session کاربران روی فایل‌های محلی هر سرور ذخیره بشه، ممکنه با جابهجایی درخواستها بین نسخهها، مشکلاتی ایجاد بشه. استفاده از یک Backend مشترک مثل Redis می‌تونه این مسئله رو حل کنه.
فایل‌های Upload شده:بهتره فایل‌های کاربران روی Storage مشترک یا Object Storage نگهداری بشن، نه اینکه هر نسخه فقط فایل‌های محلی خودش رو داشته باشه.
Database Migration:چون نسخه‌ی قدیمی و جدید هم‌زمان اجرا میشن، تغییرات دیتابیس باید با هر دو نسخه سازگار باشن.
Queue Worker:Workerهای Laravel پردازشهای طولانیمدت هستن و باید به‌صورت کنترلشده Reload یا Restart بشن تا کد جدید رو دریافت کنن.
مثال با Next.js
Next.js هم می‌تونه به‌صورت چند Instance از Node.js اجرا بشه.
فرض کنید سه Instance از برنامه پشت Nginx یا یک Load Balancer قرار دارن:
متن ساده
Load Balancer
/ | \
/ | \
App 1 App 2 App 3
v1 v1 v1
در زمان دیپلوی، ابتدا Instance اول با نسخه‌ی جدید جایگزین میشه:
متن ساده
Load Balancer
/ | \
/ | \
App 1 App 2 App 3
v2 v1 v1
بعد از بررسی سلامت اون، ترافیک به نسخه‌ی جدید هدایت میشه و دو Instance باقیمونده هم به همین ترتیب به‌روزرسانی میشن.
برای این کار می‌تونیم از Docker و Kubernetes یا چند Process مستقل Node.js استفاده کنیم.
در Next.js باید به چند نکته توجه کنیم:
نسخه‌ی Build شدهی برنامه باید بین Instanceها مشخص و قابل شناسایی باشه.
تنظیمات Cache و Revalidation در معماری چند Instance باید هماهنگ باشن.
در صورت استفاده از Server Actions، تنظیمات موردنیاز برای سازگاری Instanceها باید رعایت بشه.
Instance جدید قبل از دریافت ترافیک باید آماده و سالم باشه.
نقش Kubernetes در Rolling Update
یکی از قابلیتهای مهم Kubernetes، پشتیبانی از Rolling Update در Deploymentهاست.
دو پارامتر مهم در این فرایند وجود داره:
maxUnavailable: حداکثر تعداد Podهایی که در زمان به‌روزرسانی میتونن در دسترس نباشن.
maxSurge: حداکثر تعداد Podهای اضافهای که در زمان به‌روزرسانی میتونن ایجاد بشن.
برای مثال:
YAML
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable:1
maxSurge:1
با این تنظیمات، Kubernetes می‌تونه یک Pod اضافه ایجاد کنه و حداکثر یک Pod رو در زمان به‌روزرسانی از دسترس خارج کنه.
البته این تنظیمات بهتنهایی تضمین نمیکنن که برنامه بدون خطا باقی بمونه. Readiness Probe، ظرفیت منابع و تعداد Replicaها هم اهمیت دارن.
مزایا و معایب Rolling Update
مزایا:
نیازی به متوقف کردن کل سرویس نیست.
هزینهی زیرساخت معمولاً از Blue-Green کمتره.
امکان کنترل سرعت انتشار وجود داره.
در صورت بروز مشکل، میشه ادامهی انتشار رو متوقف کرد.
معایب:
نسخه‌های قدیمی و جدید برای مدتی هم‌زمان اجرا میشن.
Rollback ممکنه نیازمند به‌روزرسانی مجدد چند Instance باشه.
تغییرات ناسازگار دیتابیس میتونن مشکلساز بشن.
مدیریت چند Instance و هماهنگی Cache و Session پیچیدگی بیشتری داره.
جمع‌بندی
Rolling Update راهکاری برای جایگزینی تدریجی نسخه‌های نرمافزاره. به‌جای اینکه کل برنامه رو متوقف کنیم، Instanceها رو بهترتیب به‌روزرسانی می‌کنیم.
این روش برای برنامههایی که چند Instance دارن و میتونن نسخه‌های مختلفی از کد رو برای مدت کوتاهی تحمل کنن، انتخاب مناسبیه.
در مقاله‌ی بعدی سراغ Blue-Green Deployment میریم؛ روشی که به‌جای به‌روزرسانی تدریجی Instanceهای فعلی، یک محیط جدید ایجاد می‌کنه و بعد از آماده شدن اون، ترافیک رو به‌صورت یک‌باره منتقل می‌کنه.
محمد علی
نظرات
هنوز نظری ثبت نشده است. اولین نفر باشید!