منابع آموزشی و پژوهشی، برای دانشگاه و مدرسه
پشتیبانیانتشار محتوا
دورهٔ آموزشیرایگان

راه‌اندازی بک‌اند Node.js روی اوبونتو؛ از SSH تا HTTPS

۱۲ درس در ۴ فصل۱۵ ساعت و ۵۵ دقیقهدربارهٔ دوره
نقشهٔ راه و آماده‌سازی اوبونتودرس ۳ از ۱۲

نصب قابل شناسایی Node.js LTS روی اوبونتو؛ معماری، چکیده و مسیر ثابت

۷۵ دقیقه آموزش متنی
در این درس ۴ بخش

اکنون به اوبونتوی آزمایشی وصل هستیم و ابزارهای دانلود و استخراج آماده‌اند. هدف این درس این است که بتوانیم دقیق بگوییم کدام باینری Node اجرا می‌شود، از چه منبعی آمده، چه نسخه‌ای دارد و مدیر سرویس بعداً آن را از کدام مسیر پیدا خواهد کرد. نصب موفق فقط دیدن یک شماره نیست؛ مسیر، مالکیت و روش ارتقای آینده نیز بخشی از نتیجه‌اند. این مسیر از باینری رسمی آمادهٔ Node استفاده می‌کند و آن را در /opt قرار می‌دهد. دستورهای این درس در Bash اوبونتو اجرا می‌شوند؛ هیچ MSI ویندوزی روی اوبونتو نصب نمی‌کنیم و node_modules ویندوز را به سرور کپی نمی‌کنیم.

نسخهٔ LTS، اصلاحیه و معماری چه تفاوتی دارند؟

نسخهٔ LTS شاخه‌ای با دورهٔ پشتیبانی بلندمدت است و همچنان باید اصلاحیه‌های مناسبش دریافت شوند. در زمان تدوین این دستورها، ۲۹ اکتبر ۲۰۲۶، شاخهٔ ۲۴ هنوز LTS است و نمونهٔ نصب زیر v24.22.2 را مشخص می‌کند؛ شاخهٔ ۲۶ نیز LTS شده است. عدد نمونه را «آخرین نسخه برای همیشه» نخوانید. برای بازتولید نتیجه، نسخهٔ آزمایش‌شده را ثبت می‌کنیم؛ برای نگهداری، صفحهٔ رسمی پشتیبانی و انتشار را در تاریخ ارتقا دوباره بررسی می‌کنیم. تغییر شاخهٔ اصلی می‌تواند رفتار یا نیازهای سیستم را عوض کند، بنابراین روی سرور واقعی بدون آزمون سازگاری جهش نسخه انجام نمی‌دهیم.

معماری، نوع باینری متناسب با مجموعه‌دستورهای پردازنده و محیط اجراست. dpkg در اوبونتوی رایج x86-64 مقدار amd64 و در میزبان ARM64 مقدار arm64 می‌دهد، اما نام فایل Node برای اولی x64 است. این تفاوت نام‌گذاری را در یک نگاشت کوچک حل می‌کنیم؛ انتخاب فایل را با حدس از نام تجاری VPS انجام نمی‌دهیم. برای معماری دیگری، دستور نمونه عمداً توقف می‌کند. ممکن است Node روی معماری‌های بیشتری بسته داشته باشد، اما این تمرین فقط دو مسیر مشخص را پوشش می‌دهد. گسترش دامنهٔ پشتیبانی باید با مستندات همان نسخه و آزمون واقعی انجام شود، نه با حذف شرط توقف.

دو مرجع از دورهٔ قبل در اینجا کاربرد مستقیم دارند: درس نصب ویندوز توضیح می‌دهد شمارهٔ npm با Node یکی نیست و PATH چگونه فرمان را انتخاب می‌کند؛ درس انتخاب محیط توضیح می‌دهد چرا فضای اجرا و معماری را جدا ثبت می‌کنیم. در این مرحله آن قواعد را به لینوکس منتقل می‌کنیم، نه اینکه دستورهای PowerShell را در Bash کپی کنیم. #javascript همان زبان است؛ محیط باینری تغییر کرده است. بعدها #modules-import-export در کد برنامه باید با ماژول‌های نصب‌شده و نسخهٔ انتخابی سازگار بماند. اگر پروژهٔ دیگری engines متفاوت دارد، نخست همان نیاز را بررسی کنید و این نمونه را بدون تغییر به آن تحمیل نکنید.
نصب و تشخیص مسیر Node: https://www.darsavand.com/courses/nodejs-windows-backend-start?lesson=4d78897a-eb60-4f73-a5e4-4535d4294a57
انتخاب محیط و معماری: https://www.darsavand.com/courses/nodejs-windows-backend-start?lesson=9659b299-7f63-4ff0-a078-45b6dc67a57e

/opt در این تمرین محل نگهداری نرم‌افزار اضافهٔ مدیریت‌شده توسط مدیر ماشین است. مسیر نسخه‌دار، مثل /opt/node-v24.22.2-linux-x64، دقیقاً یک نسخه را نگه می‌دارد. پیوند نمادین /opt/node-current نام ثابتی است که به آن نسخه اشاره می‌کند. پیوند نمادین یک فایل برنامهٔ دوم نیست؛ نشانی مقصد را نگه می‌دارد. در آینده می‌توان پس از آزمون، مقصد پیوند را به نسخهٔ آمادهٔ دیگری تغییر داد، اما این درس فقط نصب اولیهٔ بدون جایگزینی را انجام می‌دهد. مدیر سرویس از /opt/node-current/bin/node استفاده خواهد کرد تا به تنظیمات نشست یک کاربر، نام پوشهٔ خانه یا فعال‌شدن خودکار nvm وابسته نباشد.

مدیر نسخه‌ای مانند nvm برای توسعهٔ تعاملی می‌تواند مفید باشد، اما فایل تنظیمات شل و PATH کاربر الزاماً در سرویس سیستمی خوانده نمی‌شود. بنابراین ترکیب «در ترمینال من کار می‌کند» و «در سرویس پیدا نمی‌شود» عجیب نیست. این دوره عمداً یک قرارداد ساده و صریح انتخاب کرده است؛ لازم نیست برای همان برنامه چند روش نصب هم‌زمان داشته باشید. اگر قبلاً /opt/node-current وجود دارد، یا Node دیگری روی ماشین نصب شده، پیش از هر تغییر مسیرش را ثبت کنید. برنامهٔ نصب زیر چیزی را روی پیوند موجود جایگزین نمی‌کند؛ روی میزبان غیرتازه باید مهاجرت را جدا طراحی کرد، نه اینکه شرط محافظ را بردارید.

bash
command -v node || true
command -v npm || true
ls -ld /opt/node-current 2>/dev/null || true
dpkg --print-architecture

این بلوک مشاهده‌ای است؛ خطاهای نبودن فرمان با true فقط برای ثبت وضعیت اولیه مدیریت شده‌اند و مجوز عبور از خطاهای نصب نیستند. اگر خروجی node به /usr/bin یا خانهٔ کاربر اشاره کرد، آن را یادداشت کنید؛ ما در مرحلهٔ آزمون از مسیر کامل باینری تازه استفاده می‌کنیم. اگر /opt/node-current فایل یا پوشهٔ واقعی و نه پیوند باشد، توقف کنید و مالک آن را بررسی کنید. استفادهٔ کور از ln -sfn ممکن است در چنین وضعیتی نتیجهٔ پیش‌بینی‌نشده داشته باشد؛ برای همین دستور اولیه فقط مقصدی تازه می‌سازد. در گزارش، مسیر موجود و دلیل انتخاب مسیر جدید باید قابل توضیح باشد.

دانلود را در پوشهٔ مستقل انجام دهید و پیش از نصب بررسی کنید

فایل باینری آماده، مجموعه‌ای از برنامه‌ها و کتابخانه‌های همراه است که از قبل برای معماری مشخص ساخته شده است. پسوند tar.xz یعنی فایل‌ها ابتدا در یک بایگانی tar جمع و سپس با xz فشرده شده‌اند؛ صرف این پسوند، اعتماد یا سازگاری را ثابت نمی‌کند. مرحلهٔ اول بلوک زیر یک پوشهٔ تازه در خانهٔ شما می‌سازد. دانلود و استخراج با حساب معمولی انجام می‌شود و هنوز چیزی وارد /opt نمی‌شود. نشانی‌ها فقط دامنهٔ رسمی nodejs.org و نسخهٔ صریح دارند. گزینهٔ fail در curl باعث می‌شود پاسخ HTTP ناموفق به‌عنوان موفقیت ذخیره نشود و set -eu نیز فرمان‌های بعد از شکست را متوقف می‌کند.

bash
(
  set -eu
  NODE_VERSION='v24.22.2'
  case "$(dpkg --print-architecture)" in
    amd64) NODE_ARCH='x64' ;;
    arm64) NODE_ARCH='arm64' ;;
    *) printf 'Unsupported architecture for this lab
' >&2; exit 1 ;;
  esac
  DIST="node-${NODE_VERSION}-linux-${NODE_ARCH}"
  ARCHIVE="${DIST}.tar.xz"
  WORK=$(mktemp -d "$HOME/node-download.XXXXXX")
  printf 'Download directory: %s
' "$WORK"
  cd "$WORK"
  curl --fail --show-error --silent --location --proto '=https'     -o "$ARCHIVE" "https://nodejs.org/dist/${NODE_VERSION}/${ARCHIVE}"
  curl --fail --show-error --silent --location --proto '=https'     -o SHASUMS256.txt "https://nodejs.org/dist/${NODE_VERSION}/SHASUMS256.txt"
  awk -v file="$ARCHIVE" '$2 == file { print; found++ } END { if (found != 1) exit 1 }'     SHASUMS256.txt > selected.sha256
  sha256sum --check selected.sha256
  mkdir unpacked
  tar --extract --xz --file "$ARCHIVE" --directory unpacked --no-same-owner
  test -x "unpacked/${DIST}/bin/node"
  "unpacked/${DIST}/bin/node" --version
  "unpacked/${DIST}/bin/node" -p 'process.platform + " " + process.arch'
  printf 'Verified source directory: %s/unpacked/%s
' "$WORK" "$DIST"
)

خروجی مورد انتظار شامل نام پوشهٔ دانلود، عبارت OK کنار نام بایگانی، نسخهٔ v24.22.2 و بستر linux با معماری انتخابی است. مسیر Verified source directory را برای مرحلهٔ بعد نگه دارید؛ آن یک خروجی واقعی روی دستگاه خودتان است و مسیر فرضی کتاب نیست. پرانتزها یک زیرپوسته می‌سازند؛ متغیرها و cd داخل آن بعد از پایان، نشست اصلی را تغییر نمی‌دهند. این رفتار عمدی است، پس در بلوک بعد به متغیر WORK قبلی تکیه نمی‌کنیم. اگر هیچ خطی با مسیر تأییدشده چاپ نشد، مرحله کامل نشده است. پیام خطا را بخوانید و فرمان نصب مدیریتی را اجرا نکنید.

SHA-256 یک چکیدهٔ محاسبه‌شده از بایت‌های فایل است. مقایسهٔ آن با فهرست منتشرشده کمک می‌کند خرابی انتقال یا تفاوت فایل را تشخیص دهید. اما دریافت بایگانی و چکیده از یک منبع، به‌تنهایی امضای مستقل ناشر را ثابت نمی‌کند؛ اگر همان منبع به خطر افتاده باشد، هر دو می‌توانند تغییر کنند. پروژهٔ Node فهرست امضاشده و راهنمای بررسی کلیدهای انتشار نیز دارد. در محیطی با نیاز زنجیرهٔ تأمین قوی‌تر، پیش از نصب آن مسیر را هم طبق کلیدهای مورد اعتماد بررسی کنید. این درس ادعا نمی‌کند فرمان sha256sum جای تأیید امضای ناشر یا بازبینی همهٔ وابستگی‌های نرم‌افزار را گرفته است.

نصب مدیریتی فقط برای مسیر تازه و تأییدشده

مرحلهٔ دوم را پس از موفقیت کامل دانلود انجام دهید. در بلوک زیر، مقدار SOURCE را با همان مسیر واقعی خط آخر عوض کنید؛ آن را از خروجی خودتان بردارید. مثال /home/labadmin/node-download.ABC123 فقط شکل مسیر را نشان می‌دهد و عمداً تا وقتی پوشهٔ واقعی نباشد از آزمون test عبور نمی‌کند. این بار sudo برای انتقال نرم‌افزار به /opt و تثبیت مالکیت لازم است. کد برنامه و Node قرار نیست بعداً توسط کاربر سرویس بازنویسی شوند. نصب تازه باید مقصدی نداشته باشد؛ اگر همان نسخه یا پیوند از قبل هست، توقف آگاهانه نتیجهٔ درست اجرای دوباره است، نه خطایی که با حذف بی‌بررسی باید خاموش شود.

bash
(
  set -eu
  SOURCE='/home/labadmin/node-download.ABC123/unpacked/node-v24.22.2-linux-x64'
  test -x "$SOURCE/bin/node"
  DIST=$(basename -- "$SOURCE")
  case "$DIST" in
    node-v24.22.2-linux-x64|node-v24.22.2-linux-arm64) ;;
    *) printf 'Unexpected source directory
' >&2; exit 1 ;;
  esac
  DEST="/opt/$DIST"
  if sudo test -e "$DEST" || sudo test -L "$DEST"; then
    printf 'Destination already exists; stop and inspect
' >&2; exit 1
  fi
  if sudo test -e /opt/node-current || sudo test -L /opt/node-current; then
    printf 'Runtime link already exists; stop and inspect
' >&2; exit 1
  fi
  sudo cp -a -- "$SOURCE" "$DEST"
  sudo chown -R root:root -- "$DEST"
  sudo chmod -R go-w -- "$DEST"
  sudo ln -s -- "$DEST" /opt/node-current
  /opt/node-current/bin/node --version
  readlink -f /opt/node-current
)

انتظار داریم همان نسخه از مسیر /opt اجرا شود و readlink مقصد نسخه‌دار واقعی را نشان دهد. مالکیت root:root و حذف امکان نوشتن گروه و دیگران کمک می‌کند حساب اجرای برنامه نتواند فایل اجرایی خودش را تغییر دهد. این تصمیم به معنی اجرای خود برنامه با root نیست؛ خواندن و اجرای فایل با مالک‌بودن آن متفاوت است. اگر کپی موفق شد ولی مرحلهٔ بعد شکست خورد، مسیر جدید را شناسایی و علت را بررسی کنید؛ دستور حذف خودکار گسترده قرار نداده‌ایم تا وضعیت نیمه‌کاره پنهان نشود. پیش از ادامه، ls -ld برای مسیر و ls -l برای فایل bin/node را بخوانید و مطمئن شوید مقصد پیوند همان نسخهٔ تأییدشده است.

PATH فهرستی از پوشه‌هاست که شل و بعضی ابزارها برای پیدا‌کردن نام فرمان جست‌وجو می‌کنند. اجرای /opt/node-current/bin/node به PATH متکی نیست، اما npm همراه Node معمولاً از env برای پیدا‌کردن node استفاده می‌کند. برای همین فقط نوشتن مسیر کامل npm همیشه کافی نیست؛ باید Node مناسب در محیط فرایند npm هم پیدا شود. بلوک زیر مسیر انتخابی را برای همین نشست Bash در اول PATH می‌گذارد. این کار فایل‌های تنظیمات سراسری سیستم را بازنویسی نمی‌کند و با خروج از نشست، اثرش از بین می‌رود. سرویس آینده مسیر مطلق Node را دارد و نباید به یادآوری این export وابسته باشد.

bash
export PATH="/opt/node-current/bin:$PATH"
hash -r
command -v node
node --version
node -p 'process.execPath'
node -p 'process.release.lts'
npm --version
printf 'console.log("runtime-ready", process.platform);
' > "$HOME/runtime-ready.mjs"
/opt/node-current/bin/node "$HOME/runtime-ready.mjs"

فرمان انتخاب‌شده باید زیر /opt/node-current/bin باشد و مسیر process.execPath می‌تواند به مسیر واقعی نسخه‌دار حل شود؛ این تفاوت طبیعی پیوند است. نام LTS شاخه باید گزارش شود و آخرین برنامه runtime-ready linux چاپ کند. شمارهٔ npm با Node یکی نیست. اگر npm پیامی دربارهٔ پیدا‌نشدن node داد، ابتدا PATH همان نشست را ببینید؛ نصب دوبارهٔ همهٔ بسته‌ها لازم نیست. اگر نسخهٔ قدیمی ظاهر شد، command -v و process.execPath را کنار هم بگذارید و مسیر واقعی را پیدا کنید. اگر فایل mjs خطای نحو داد، موضوع دیگر خرابی دانلود Node نیست؛ #debugging-console و بررسی خط فرمان و خط کد به لایهٔ برنامه کمک می‌کنند.

تمرین با پاسخ و تحویل قابل بررسی

تمرین اول: پس از قطع و اتصال دوبارهٔ SSH، node شناخته نمی‌شود اما /opt/node-current/bin/node --version درست کار می‌کند. پاسخ: نصب ممکن است سالم باشد و فقط export نشست قبلی باقی نمانده باشد؛ برای کار تعاملی PATH همان نشست را تنظیم کنید و برای سرویس از مسیر مطلق استفاده کنید. تمرین دوم: sha256sum شکست می‌خورد. پاسخ: استخراج و نصب را ادامه نمی‌دهیم؛ نسخه، نام فایل، منبع و انتقال را بررسی می‌کنیم و فایل نامنطبق را «تقریباً درست» نمی‌نامیم. تمرین سوم: ماشین arm64 است ولی فایل x64 انتخاب شده. پاسخ: نگاشت معماری را اصلاح می‌کنیم، نه اینکه با sudo خطای قالب اجرایی را حل کنیم.

تحویل این درس باید نسخهٔ Node و npm، معماری، پوشهٔ نسخه‌دار، مقصد پیوند، مالکیت و نتیجهٔ برنامهٔ کوچک را ثبت کند. #validation-contracts در اینجا یادآور یک عادت است: مرز هر مرحله را مشخص و دادهٔ نامعتبر را پیش از ورود به مرحلهٔ بعد رد کنید؛ خودِ مدخل کدکس دربارهٔ قرارداد ورودی برنامه است، نه جایگزین راهنمای نصب سیستم. دو مرور تکمیلی زیر کمک می‌کنند تفاوت اعتماد به مخزن با باینری مستقل و نقش محیط فرایند را دقیق‌تر ببینید. پس از موفقیت، درس بعد فایل‌های پروژه را با ساختار مشخص آماده می‌کند. هنوز سرویس وب یا گواهی صادر نشده و دسترسی عمومی پورت برنامه هم لازم نیست.
زنجیرهٔ اعتماد بسته‌ها در لینوکس: https://www.darsavand.com/courses/linux-advanced-administration?lesson=c19b1a63-edaf-4395-a212-637a0db7f52b
تنظیمات محیط در Node: https://www.darsavand.com/courses/nodejs-windows-backend-start?lesson=e5ebc43b-785b-432e-bd25-b5e825d5364c

منابع رسمی انگلیسی:
Node.js v24.22.2 release: https://nodejs.org/en/blog/release/v24.22.2
Node.js releases and support: https://nodejs.org/en/about/previous-releases
Node.js verification instructions: https://github.com/nodejs/node/blob/main/README.md#verifying-binaries
Node.js release keys: https://github.com/nodejs/release-keys
Node.js supported platforms: https://github.com/nodejs/node/blob/v24.22.2/BUILDING.md
GNU Coreutils sha256sum: https://www.gnu.org/software/coreutils/manual/coreutils.html#sha2-utilities
Bash command search: https://www.gnu.org/software/bash/manual/html_node/Command-Search-and-Execution.html

تألیف و مثال‌های اختصاصی: تحریریه درس‌آوند. نسخهٔ ثابت نمونه برای بازتولید است؛ وضعیت پشتیبانی و اصلاحیه‌ها هنگام نصب و ارتقا دوباره بررسی شوند.

ورود برای ثبت پیشرفت

متن درس‌های عمومی را بدون ورود بخوانید.

یادگیری‌ات را دنبال کن

برای نگهداری پیشرفت و ادامهٔ یادگیری از حساب خود استفاده کن.

ورود و ثبت‌نام
دربارهٔ این دوره

آموزش رایگان و مرحله‌به‌مرحلهٔ راه‌اندازی بک‌اند Node.js روی Ubuntu؛ ۱۲ درس مفصل از SSH و نصب تا systemd، Nginx، دامنه و HTTPS، همراه عیب‌یابی، انتشار و بازیابی.

پرسشی دربارهٔ این درس داری؟گفت‌وگو با پشتیبانی در حساب کاربری
یکجا انتخاب کن، راحت‌تر دریافت کن

انتخاب‌های من ۰ منبع

مجموعهٔ مطالعه‌ات را بساز.

کنار مقاله‌ها «انتخاب» را بزنید تا چند فایل را با هم دریافت کنید.

انتخاب مقاله‌های رایگان