مهاجرت به Node.js 26 LTS؛ چک‌لیست Next.js و Docker

نمونه کانتینر کوچک برای آزمایش Runtime

برای جداکردن مشکل محیط از کد محصول، ابتدا یک سرویس کوچک بسازید. این سرویس فقط پاسخ سلامت می‌دهد و هنگام توقف اتصال شنونده را می‌بندد. سپس همان الگو را با نیاز واقعی پروژه تطبیق دهید. بسته‌شدن درست شنونده، به‌تنهایی تخلیه همه کارهای پس‌زمینه و اتصال‌های بلندمدت را تضمین نمی‌کند؛ برای محصول دارای SSE یا صف، آزمون توقف اختصاصی لازم است. لاگ سلامت نباید کل محیط یا کلیدهای سرویس را برگرداند.

import http from 'node:http';

const port = Number(process.env.PORT || 3000);
const server = http.createServer((req, res) => {
  if (req.url !== '/healthz') {
    res.writeHead(404).end();
    return;
  }
  res.writeHead(200, {'Content-Type': 'application/json'});
  res.end(JSON.stringify({ok: true}));
});
server.listen(port, '0.0.0.0');
process.on('SIGTERM', () => {
  server.close(() => process.exit(0));
  setTimeout(() => process.exit(1), 10000).unref();
});

FROM node:26.13.0-bookworm-slim
WORKDIR /app
COPY --chown=node:node server.mjs ./server.mjs
USER node
ENV NODE_ENV=production
ENV PORT=3000
EXPOSE 3000
CMD ["node", "server.mjs"]

کد بالا وابستگی بیرونی ندارد؛ پروژه واقعی معمولاً به مرحله نصب و build جدا نیاز دارد. در راهنمای رسمی ساخت Docker، کوچک‌کردن زمینه ساخت، استفاده از کش و کنترل نسخه پایه توضیح داده شده است. در پاستا نیز راهنمای Dockerfile نقطه شروع مناسبی است. کل مخزن، فایل .env و نسخه‌های پشتیبان دیتابیس را صرفاً برای راحتی با COPY وارد ایمیج نکنید.

بسته‌های بومی، libc و تفاوت معماری

کتابخانه‌های پردازش تصویر، رمزنگاری یا اتصال دیتابیس ممکن است باینری آماده وابسته به نسخه Node، معماری و کتابخانه سیستم داشته باشند. کپی‌کردن node_modules ساخته‌شده روی ویندوز یا سیستم دیگری به کانتینر لینوکس روش مطمئنی نیست. نصب را در محیط هدف انجام دهید. همچنین تغییر هم‌زمان از Debian به Alpine ممکن است مسئله libc را به مهاجرت Runtime اضافه کند؛ اگر هدف فقط ارتقای Node است، بی‌دلیل چند متغیر محیطی را با هم عوض نکنید.

یادداشت رسمی نسخه درباره نیاز احتمالی libatomic در باینری‌های لینوکس، هنگام مهاجرت از شاخه‌های قدیمی‌تر، هشدار می‌دهد. اگر Runtime با پیام کتابخانه گمشده شروع نمی‌شود، ابتدا تصویر پایه و بسته‌های واقعی آن را بررسی کنید. دانلود یک فایل تصادفی از وب یا اجرای برنامه با دسترسی root پاسخ مناسبی نیست. پیام خطا، معماری و نام ایمیج را ثبت کنید و راه‌حل را در Dockerfile بازتولیدپذیر نگه دارید تا انتشار بعدی دوباره به همان مانع نخورد.

آزمون‌هایی که قبل از انتشار لازم‌اند

ابتدا آزمون‌های واحد و ساخت پروژه را روی نسخه فعلی و هدف اجرا کنید. سپس مسیرهای مهم کاربر را در محیط آزمایشی بررسی کنید: ورود، مشاهده داده مجاز، ارسال فرم، بارگذاری فایل و دسترسی به API. برای فروشگاه یا سرویس مالی، آزمون پرداخت را با داده و درگاه آزمایشی انجام دهید؛ ارتقای Runtime مجوز دست‌کاری سفارش واقعی نیست. اگر آزمونی ندارید، حداقل یک سناریوی ثابت با ورودی و نتیجه مورد انتظار بسازید؛ «صفحه باز شد» پوشش کافی نیست.

اندازه‌گیری عملکرد را با داده مشابه، منابع یکسان و چند تکرار انجام دهید. زمان ساخت، زمان شروع، مصرف حافظه و تأخیر درخواست را جدا بنویسید. نتیجه یک درخواست گرم را با میانگین محیط سرد قبلی مقایسه نکنید. اگر برنامه از API هوش مصنوعی استفاده می‌کند، تأخیر سرویس مدل را از Runtime جدا بسنجید؛ فراخوانی خارجی می‌تواند تفاوت کوچک نسخه Node را بپوشاند. مقاله عیب‌یابی پاسخ جریانی Next.js برای این مسیر مکمل است.

انتشار کنترل‌شده روی پاستا

در PaaS پاستا یک سرویس آزمایشی مستقل با داده غیرحساس یا نسخه مجاز داده بسازید. دامنه اصلی و ترافیک مشتری را تا پایان آزمون جابه‌جا نکنید. پورت، فرمان اجرا و بررسی سلامت باید با برنامه سازگار باشد. از لاگ ساخت مطمئن شوید نسخه هدف واقعاً انتخاب شده و وابستگی‌ها از کش ناسازگار باقی نمانده‌اند. قابلیت‌های انتشار هر طرح را از پنل و مستند جاری بررسی کنید؛ این مقاله قابلیت انتشار تدریجی خودکار را برای همه طرح‌ها وعده نمی‌دهد.

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

برنامه بازگشت را قبل از نیاز آماده کنید

نسخه قبلی کد و ایمیج را همراه با تنظیمات لازم نگه دارید و روش بازگشت را آزمایش کنید. بازگشت Runtime وقتی ممکن است که تغییرات دیتابیس و داده نیز با نسخه قبلی سازگار باشند. اگر هم‌زمان ستون حذف کرده‌اید یا قالب داده را غیرقابل بازگشت تغییر داده‌اید، انتخاب ایمیج قبلی کافی نیست. مهاجرت دیتابیس را در مرحله جدا، با الگوی سازگار و پشتیبان قابل بازیابی انجام دهید. برای داده واقعی، داشتن فایل بکاپ بدون تمرین بازیابی مدرک کافی نیست.

معیار توقف انتشار را از قبل تعیین کنید؛ مثلاً افزایش خطا در مسیر حیاتی، ناتوانی Worker در پردازش یا رشد غیرعادی حافظه. لازم نیست برای هر نوسان کوچک برگردید، اما نباید منتظر چند شکایت مشتری بمانید. مالک تصمیم، روش اطلاع‌رسانی و شناسه نسخه را ثبت کنید. این اطلاعات برای تیم کوچک هم مفید است؛ وقتی یک نفر درگیر رفع خطاست، نفر بعدی باید بداند چه چیزی منتشر شده و کدام گزینه بازگشت واقعاً امن است.

جمع‌بندی: ارتقا یک تغییر قابل اندازه‌گیری است

برای مهاجرت موفق، نسخه واقعی را ثبت کنید، تغییرات را کوچک نگه دارید، بسته‌های بومی را در محیط هدف بسازید و مسیر بازگشت را پیش از انتشار امتحان کنید. Node.js 26 LTS فرصت مناسبی برای برنامه‌ریزی نگهداری است، اما تضمین سرعت یا سازگاری نیست. اگر پروژه Next.js دارید، هاست Next.js و سرور نکست جی اس پاستا را برای محیط آزمایش و انتشار بررسی کنید. ارزش زیرساخت مدیریت‌شده این است که زمان بیشتری برای تست رفتار محصول داشته باشید، نه اینکه تست را حذف کنید.