محتوای آموزشی وبلاگ نت‌آرام
نصب بسته‌های Node.js روی هاست شروع می‌شود، اما با
ENOMEM، Killed یا قطع ناگهانی تمام می‌شود. این نشانه‌ها می‌توانند به حافظه ناکافی یا محدودیت منابع حساب مربوط باشند، ولی به تنهایی علت را ثابت نمی‌کنند. فرایند نصب، استخراج بسته، اجرای اسکریپت و build نیازهای متفاوتی دارند.ابتدا زمان و مرحله شکست را پیدا می‌کنیم، بعد محدودیت واقعی حساب و گزینه‌های سازگار با پروژه را بررسی می‌کنیم. تغییر یک عدد حافظه در Node الزاماً محدودیت هاست را برنمی‌دارد.
۱. ببینید خطا در نصب رخ می‌دهد یا build
در Terminal یا SSH همان حساب، پوشه و نسخه‌های محیط آزمایشی را ببینید:
کد / دستورpwd
node --version
npm --version
ls -la package.json package-lock.json
گزارش نصب را بخوانید: آیا خطا هنگام دانلود، اجرای
postinstall یک بسته، ساخت افزونه بومی یا اجرای npm run build رخ داده است؟ نام مرحله و چند خط نخست خطا را همراه زمان یادداشت کنید. نشانی مخزن خصوصی و توکن را قبل از فرستادن گزارش بپوشانید.اگر پیغام
EACCES است، مشکل می‌تواند دسترسی پوشه یا کش باشد و راهنمای رفع EACCES در npm مناسب‌تر است. اگر خطای JavaScript heap out of memory دیده می‌شود، علاوه بر سهمیه سیستم، سقف heap همان فرایند هم باید بررسی شود.۲. محدودیت حساب را از حافظه کل جدا کنید
در پنل هاست، اگر بخش Resource Usage یا گزارش مشابه دارید، زمان خطا را با مصرف حافظه و خطاهای ثبت‌شده همان حساب مقایسه کنید. نام بخش و امکانات بسته به پنل و سرویس فرق می‌کند. در هاست‌هایی که از CloudLinux استفاده می‌کنند، محدودیت حساب یا LVE ممکن است مستقل از حافظه آزاد کل سرور باشد.
دستور
free -h در بعضی محیط‌ها حافظه میزبان را نشان می‌دهد و لزوماً سقف قابل استفاده حساب را مشخص نمی‌کند. خروجی ulimit -a هم فقط بعضی محدودیت‌های فرایند را نشان می‌دهد، نه همه سیاست‌های سرویس. اگر گزارش پنل ندارید، زمان، نام برنامه و متن خطا را بدون اطلاعات محرمانه به پشتیبانی بدهید تا رخداد همان حساب بررسی شود.۳. نصب را در کپی جدا و با وابستگی‌های درست امتحان کنید
کد و فایل قفل تأییدشده را در پوشه آزمایشی قرار دهید. اگر پروژه از npm و فایل قفل هماهنگ استفاده می‌کند:
کد / دستورcd ~/node-app-test
pwd
npm ci
مسیر نمونه را عوض کنید.
npm ci پوشه node_modules موجود در همان مسیر را حذف می‌کند و ممکن است اسکریپت‌های نصب بسته‌ها را اجرا کند؛ روی نسخه فعال یا کد نامطمئن اجرا نکنید. اگر فایل قفل نامعتبر است، ابتدا آن را با نسخه تأییدشده پروژه هماهنگ کنید.اگر برنامه فقط در مرحله build به وابستگی‌های توسعه نیاز دارد، حذف کورکورانه آن‌ها با
--omit=dev می‌تواند خطای جدید بسازد. ابتدا مشخص کنید کدام بسته برای ساخت و کدام بسته برای اجرای نهایی لازم است. حذف گزینه‌های امنیتی یا غیرفعال‌کردن همه اسکریپت‌ها ممکن است نصب ناقص ایجاد کند.برای جداکردن «استخراج بسته» از «اسکریپت نصب»، فقط در همان کپی آزمایشی مورد اعتماد و پس از ثبت خطای کامل، یک بار می‌توانید این آزمون تشخیصی را انجام دهید:
کد / دستورnpm ci --ignore-scripts
این فرمان اسکریپت‌های نصب را اجرا نمی‌کند و بار دیگر
node_modules همان پوشه آزمایشی را پاک و بازسازی می‌کند. اگر این حالت موفق و نصب معمولی ناموفق شد، اسکریپت یا مرحله ساخت یکی از احتمال‌هاست؛ به تنهایی نام بسته مقصر را ثابت نمی‌کند. خروجیِ نصب بدون اسکریپت ممکن است ناقص باشد و نباید به عنوان نسخه نهایی منتشر شود. در نسخه npm دارای این گزینه، یک اجرای کنترل‌شده npm ci --foreground-scripts در همان کپی می‌تواند خروجی اسکریپت مسئول را روشن‌تر کند؛ چون ممکن است دوباره فشار ایجاد شود، ابتدا ظرفیت و زمان مناسب را با میزبان هماهنگ کنید.۴. راهکار را متناسب با مرحله شکست انتخاب کنید
اگر گزارش نشان می‌دهد یک اسکریپت نصب یا build به بیش از سقف حساب نیاز دارد، از توسعه‌دهنده درباره کاهش هم‌زمانی یا ساخت در محیط مناسب بپرسید. روش دقیق به ابزار پروژه بستگی دارد؛ متغیرهای عمومی و ناشناس را از اینترنت کپی نکنید. در صورت نیاز واقعی، افزایش منابع سرویس یا انجام build در محیط سازگار و انتقال خروجی تأییدشده می‌تواند مناسب باشد.
خروجی آماده فقط وقتی قابل انتقال است که سیستم‌عامل، معماری، نسخه Node، فایل‌های موردنیاز و روش اجرای پروژه با مقصد سازگار باشند. پوشه
node_modules دارای افزونه بومی ساخته‌شده در ویندوز یا مک را نباید بدون بررسی به لینوکس برد؛ راهنمای invalid ELF این تفاوت را توضیح می‌دهد.برای پروژه‌ای که واقعاً قابلیت ساخت خارج از هاست را دارد، یک مسیر عملی این است: روی محیط ساخت لینوکسیِ سازگار و کپی پروژه،
npm ci و سپس فرمان build تعریف‌شده پروژه را اجرا کنید؛ خروجی را با آزمون‌های همان پروژه بررسی کنید و فقط فایل‌های لازم، فایل قفل و نسخه کد تأییدشده را با روش استقرار پروژه منتقل کنید. روی مقصد، وابستگی‌های لازم زمان اجرا باید با همان نسخه Node و معماری سازگار نصب شوند. صرف کپی پوشه build برای همه فریم‌ورک‌ها کافی نیست؛ مثلاً فایل‌های استاتیک یا افزونه بومی ممکن است مرحله جداگانه بخواهند.اگر build کامل از قبل ساخته شده و مستندات پروژه تأیید می‌کند بسته‌های توسعه در زمان اجرا لازم نیستند، می‌توانید در کپی آزمایشیِ مخصوص اجرای خروجی این حالت را امتحان کنید:
کد / دستورnpm ci --omit=dev
npm ls --omit=dev --depth=0
این دو فرمان به ترتیب وابستگی‌های مناسب اجرای production را طبق فایل قفل نصب و فهرست سطح اول را نمایش می‌دهند. این روش مشکل حافظه مرحله build را حل نمی‌کند و اگر برنامه یا مرحله پس از نصب به بسته توسعه نیاز داشته باشد شکست می‌خورد. ابتدا اجرای واقعی خروجی را تست کنید؛ در غیر این صورت به نصب کامل و ظرفیت مناسب برگردید. هر دو
npm ci این بخش فقط برای پوشه آزمایشی‌اند و node_modules همان پوشه را جایگزین می‌کنند.افزایش
--max-old-space-size می‌تواند سقف heap یک فرایند Node را تغییر دهد، اما حافظه واقعی یا سهمیه حساب را افزایش نمی‌دهد. عدد خیلی بزرگ ممکن است برخورد به محدودیت کل را بیشتر کند. این گزینه را فقط وقتی خطا و اندازه‌گیری به heap مربوط است و ظرفیت واقعی اجازه می‌دهد، در محیط آزمایشی تنظیم کنید.۵. نتیجه را در خود پنل آزمایش کنید
پس از نصب موفق، آزمون پروژه و مرحله build موردنیاز را در محیط آزمایشی اجرا کنید. سپس برنامه را با نسخه Node و روش پنل بالا بیاورید و یک قابلیت واقعی را امتحان کنید. سبز شدن نصب به معنی سلامت اتصال پایگاه داده یا تمام مسیرهای برنامه نیست. نسخه قبلی را برای بازگشت نگه دارید.
مشخصات هاست Node.js نت‌آرام و رفتار نصب تمیز در مستندات npm ci آمده است.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام