Практычная схема для запуску аплікацыяў на Node.js у працоўны режым
Практычны спіс пераконтрацый для стварэння дапрыгаў на Node.js, які абяжыць серверы, секрэты, кантроль процэсаў, HTTPS, CI/CD, логаванне і архіваўванне.
Запуск прыгунковага дапраўніка Node.js на вашай сабе машыне — гэта простая частка.
npm run dev
Ваш API адпавядае. Ваша база дадзеных з’яўляеся у звязку. Усё выглядае нормальна.
Потым хтось спытае:
"Што, як нам выкліканы гэта ў працоўны сервіс?"
Тады стае ясна, што стварэнне API — гэта толькі палова задачы.
Пераход на працоўны сервіс прыносіць цэлы новы набор пытанняў:
- Дзе на самай працоўцы будзе запускаться дапраўнік?
- Што будзе прыманяць яго ў роботу, якщо ён зламаецца?
- Як уваходзячы трафік даступае да процэсу Node.js?
- Дзе трэба зберагчы зменныя сераўіса?
- Як налаштаваць HTTPS?
- Як выкліканы новыя версіі?
- Як ловіць адказы, калі яны выйшлі?
- Што будзе, як сам сервер перезапускацца?
Ёсць практычная структура для размышленняя працэйскай наладзе Node.js.
1. З’ясавайце архітектуру працэйкага режыму
Базовая наладка для працэйкага режыму зазвычай выглядае так:
Internet
│
▼
┌─────────┐
│ Nginx │
│ :80/443│
└────┬────┘
│
▼
┌─────────────┐
│ Node.js │
│ Application │
└──────┬──────┘
│
┌────────┼────────┐
▼ ▼ ▼
PostgreSQL Redis External APIs
Ключовая прынцыпа — канецкія корыстувачы зазвычай не должны падключацца безпосередня да чаго-небудзь такога:
localhost:3000
У замену Nginx стоіць перад, прымая публічныя запиты і перадаючы іх вашаму дапрыгу Node.js.
2. Падготавьце сервер
Вы можетэе выдазваць VPS або віртуальную машыну ў хмаре у такіх прадаўцах, як AWS, GCP, Azure або DigitalOcean.
Перш чым зрабіць што-небудзь інше, вам трэба наладзіць саму машыну.
У Ubuntu гэта зазвычай пачынаецца так:
sudo apt update
sudo apt upgrade -y
З таго моменту запыньце установку всіх інструментаў, якія неабходны вашаму дапрыгу.
Для самага Node.js зазвычай ўзгодна яго інсталаваць за дапамогою менеджера версій, такога як nvm, ўпэўніваючыся такім чынам, што вы можете контролаваць, яка самэўсёды версія працуе.
Паказвайце інсталаваныя версіі за дапамогою:
node -v
npm -v
Версія Node, якая працуе ў продакшэне, павінна збігацца з той, якую вы тэставалі локальна.
Гэта можа здавацца дробным деталем, але несувяжаныя версіі могу спрычыніць клопачлівыя і важкія для аднаведэння багі пасля развяртання.
3. Не кладзіце секрэты ў ваш код
Гэтую памылку лёгка здзейсніць, а таксама лёгка ўтримацца ад яе.
Утримайцеся ад прымусовага включэння пароляў і іншых кантрольных данных такім чынам:
const DATABASE_URL =
"postgresql://user:password@database.com/mydb";
І ніколі не дагружайце секрэты ў історыю вашага Git.
У замене задайце іх як змянныя сераўіса:
NODE_ENV=production
PORT=3000
DATABASE_URL=postgresql://...
REDIS_URL=redis://...
JWT_SECRET=...
Пасля чаго прынямайце іх у сваім кодзе за дапамогою:
process.env.DATABASE_URL
Убедзіцеся, што вашы файлы .env не ўключаюцца ў кантроль версій:
.env
.env.production
Адзін апавярожаны пароль базы дадзэных можа спакасті набагато большую шкоду, чым будзь-яя памылка падчас запуску.
4. Стварэнне прыемкі
Перад запускам прыемкі інсталюйце толькі залежнасці для працы ў рэальных умовах, а таксама выконайце крок стварэння, які можа знадобіцца вашай фреймворку.
Напрыклад, прыемка на TypeScript можа выконвацца так:
npm ci
npm run build
А пасля — запускце скомпільаванага рэзултата:
npm start
Точныя каманды буду разніцца залежна ад вашай тэхнічной структуры.
Важным ёсць такі прынцып:
Трафік з рэальных умоваў павінен прабіваць да вашай прыемкі для рэальных умоваў, а не да сервера разработкі.
Іншымі словамі, не заўсёды залишайце ў робочы стан нешта на кшталт:
npm run dev
як вашу працуючую прыемку.
5. Што будзе, якщо Node.js зламаецца?
Падазроўваючы, што вы запускаеце прыемкі безпосередна так:
node dist/server.js
У певны моменты ўсё йдзе не так, і процес зупіняецца неспадзевана.
Ваш API зараз не працюе, і нічога не можа яго запусціць знову.
Самэ гэтае явішчае проблему, якую рашыяе менеджер процэсаў.
PM2 — адна з найпопулярнейшых альтэратыў для гэтага.
Установіце яго на всю систему:
npm install -g pm2
Потым запусціце вашае прыкладнае програма пад наглядам PM2:
pm2 start dist/server.js --name my-api
Паказаце статус працы:
pm2 status
Паказаце логі:
pm2 logs my-api
Альбо перазапусціце яго за патрэбы:
pm2 restart my-api
Галоўная мета — не толькі простата ў викорыстоўванні. Гэта тое, што ваш процес тепер актываўна наглядзіцца, а не працуе ў вікні тэрміналу, спадзяючыся, што нішта яго не зупініць.
6. Змусіць прыкладную програму запускацца пасля перзапуску сервера
Серверы часам перезапускаюцца, чы то навмесна, чы не.
Напрыклад:
Server reboot
↓
Operating system starts
↓
Node.js application?
Вы не хачэце кожны раз, калі гэта выклікаецца, ручная працаваць через SSH.
PM2 можа стварыць скрыпт запуску для вашай системы:
pm2 startup
Потым зафіксавайце спіс процэсаў, якія зараз працуюць:
pm2 save
Калі гэта будзе рэалізавана, ваша аплікацыя сможа автаматычна запускаться зноў пасля перезапуску.
7. Размістыце Nginx прымаўшыя Node.js
Спадзяймося, ваш сервер Node.js прыўязаны да:
localhost:3000
Але вашы корыстувальнікі падключаюцца через:
https://api.example.com
Nginx можа скасаваць гэты прыемак, выступаючы як зворачны проксі.
Спрощаная настройка можа выглядаць так:
server {
listen 80;server_name api.example.com;
location / {
proxy_pass http://localhost:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
За гэтым сценарыем шлях запиту становіцца:
User
↓
https://api.example.com
↓
Nginx :80
↓
Node.js :3000
Таким чынам, порт, на які праслухоўвае аплікацыя Node.js, ніколі не павінен быць выкладзены безпосередна ў публічную інтэрнет-сеть.
8. Дадзіце HTTPS
Работа вашага прыёмніка API у звычным режыме
http://
Гэта недастык. Яго трэба выдаваць через
https://
Шырока адна з падходоў — гэта сумешчанне Let's Encrypt і Certbot.
Спачатку установіце Certbot:
sudo apt install certbot python3-certbot-nginx
Потым запрашайце і аплікуйце сертыфікат для вашага домэна:
sudo certbot --nginx -d api.example.com
Certbot сам абавярае выдачу сертыфіката і налаштоввае HTTPS за вас.
Калі гэта будзе адбылася, процес запрашання выглядае так:
Client
↓
HTTPS
↓
Nginx
↓
Node.js
↓
Database / Redis
9. Не забывайце пра фаервал
Не кожны порт на вашам сервере павінен быць доступны з зовнішняго свету.
Зазвычай вы хочаце, каб публіка могла доступвацца да:
80 → HTTP
443 → HTTPS
а таксама да доступу праз SSH:
22
Порты, якія викорыстоўвае PostgreSQL або Redis, зазвычай не павінны быць відкрытыя для інтэрнету, якщо толькі у вас немае конкрэтнай прычыны і жорсткіх мер контролю доступу.
Точныя правілы будуць разніцявацца залежна ад вашай налады, але галоўная засада застаецца тая ж:
Апавярнюйце толькі тое, што практычна трэба апавярнюць.
10. Ручная разгрузка работае, пакуль не перестане
Спачатку разгрузка можа выглядаць проста так:
git pull
npm install
npm run build
pm2 restart my-api
Гэта абсалютна нормальна для маленькага проекту.
Але раней чы пазней вы з’явіце, што знова і знова пераходзіце па той самый алгоритм:
Developer pushes code
↓
SSH into server
↓
git pull
↓
install dependencies
↓
build
↓
restart
У такі моменты цяжкае кераваць ручна, таму варта автоматызаваць процес.
11. CI/CD змінюе практыку работы
За дапамою такіх інструментаў, як GitHub Actions, процес можа стаць такім:
Developer
↓
git push
↓
GitHub
↓
CI/CD Pipeline
↓
Build + Test
↓
Deploy
↓
Production
Мінімальная вялічына апісання практыки работы можа выглядаць так:
name: Deploy
on:
push:
branches:
- mainjobs:
deploy:
runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4 - name: Install dependencies
run: npm ci - name: Build
run: npm run build - name: Test
run: npm test
Конкрэтныя крокі разгрузкі будуць залежна ад вашай інфраструктуры.
Найважлівейшым є основны прынцып:
Не автоматызавайце процес развярошчэння, які вы ўсё ўсё еща не разумеете.
Спачатку выучыце, як цэла караць вручную.
Толькі пасля чаго ператворыце павтараючыяся крокі на автоматызацыю.
12. Логаванне — не факультатыўнае
Програма можа здавацца працюючай нормальна, пакуль рэальныя корыстнікі сталкаюцца з адмоўкамі.
Логі — гэта спосаб дазнаць пра гэта.
Хоця б неабходныя адказы на:
When did the error happen?
Which endpoint failed?
What status code was returned?
What was the error?
How long did the request take?
Просты прыклад:
console.error({
message: error.message,
endpoint: req.originalUrl,
method: req.method,
timestamp: new Date().toISOString()
});
Для чаго-небудзь, што працуе у рэальных масштабах, структураваныя логі ў поўнай зусоўнасці з цэнтрызаваным аграгуванням логаў дапаможуць набагато больш, чым розбросаныя вызовы console.log() у вашам коде.
13. Следзіце не толькі за адмоўкамі
Абсэнцыя адключэнняў не значыць, што ваша система здаровая.
Вам таксама неабходна інформацыя пра такія рэчы, як:
CPU
Memory
Disk
Request latency
Error rate
Database performance
Redis health
Traffic
Напрыклад:
Requests → 1,500/min
Average latency → 180ms
Error rate → 0.4%
CPU → 42%
Memory → 61%
Такі показнікі даюць вам набагато болей цяласобныя інформацыі пра тое, як насправдзе функцыонуе ваша система.
14. Архіўаванне мае большое значэнне, чым развяртанне
Усё ж такі ёсць ситуацыя, пра якую большасць разработчыкаў волелі бы не думаць:
Production database
↓
Something goes wrong
↓
Data disappears
Вы завжды можете зноў развярнуць код свайго прыемлена.
Аднак ваша база дадзеных можа мець даны, якія проста не можна восстанавіць, калі яны зникнуць.
Самэльга таму архіўаванне таксама не ёсць неабавязковым.
Вам патрэбны планы архіўавання для всьго важнага ў прыемленні, і не менш важнае — вы патрэбуеце розумець, як насправдзе восстанавіць даны з гэтых архіўаў.
Архіў, які вы ніколі не пробавалі восстанавіць, — гэта той архіў, якому не варта даваць доверле.
15. Развяртанне без перыяду зупінкі — гэта аднае пытанне
У певны момент кароткая зупінка вашага прыемлена для развяртання стае непрыйняцальной.
Разглядзім такую сцэнарыю:
Old version running
↓
New version deployed
↓
Traffic gradually moves
↓
Old version removed
Залежна ад таго, як установлена ваша інфраструктура, вам можа знадобіцца:
- Адчынэнне калькі коўпакоў процеса Node.js паралельна
- Вбудованы режым кластэра PM2
- Балансір навантажэння, які распадзяе трафік між інстанцамі
- Паступовая аддача апдэйтаў, по аднаму вузлу за раз, замест таго, каб усе адразу
- Перакрыцча трафіку между старым і новым сераверам (стыль blue-green)
- Упакоўкі прыёмніка ў контэйнеры
- Оркестрацыя всага за дапамогою Kubernetes
Тым не менш, наявнасць API на базе Node.js не значыць автаматычна, што вам патрэбны Kubernetes.
Спачатку залучайце простасць, а архітэктуру развивайце толькі тады, калі вашы практычныя выкарыстанні гэта захоць.
16. Мой чэк-ліст для прыёмнай среды
Перш чым прыняць рашэнне, што прыёмнік на базе Node.js гатовы для выкарыстання, вось што варта пераглянуць:
[ ] Production environment configured
[ ] Secrets stored securely
[ ] Database connection configured
[ ] Redis configured if required
[ ] Production build tested
[ ] Process manager configured
[ ] Application restart tested
[ ] Nginx configured
[ ] HTTPS configured
[ ] Firewall configured
[ ] Logs available
[ ] Error monitoring configured
[ ] Database backups configured
[ ] Backup restoration tested
[ ] Deployment process documented
[ ] CI/CD configured if needed
[ ] Health check endpoint available
17. Архітектура, яку я маю на увазе
Базавая наладка для системы Node.js зазвычай выглядае працоўна так:
┌─────────────┐
│ Internet │
└──────┬──────┘
│
▼
┌─────────────┐
│ Nginx │
│ SSL / Proxy│
└──────┬──────┘
│
┌─────────┴─────────┐
▼ ▼
┌────────────┐ ┌────────────┐
│ Node.js │ │ Node.js │
│ Instance 1 │ │ Instance 2 │
└─────┬──────┘ └─────┬──────┘
│ │
└─────────┬─────────┘
│
┌───────────┼───────────┐
▼ ▼ ▼
PostgreSQL Redis External APIs
А навакол гэтага ядра, як правіло, хочацца:
Monitoring
Logging
Backups
CI/CD
Security
Заключныя меркі
Выпуск прылады на базе Node.js у працоўную среду ніколі не ёсць проста:
npm start
Праця ў працоўной средзе значыць планаванне всіх рэштаў, якія выйдзяць пасля запуску процэсу.
Які у вас план, якщо ўсё зламаецца нечакана?
Як будзе працаваць система пасля перезапуску сервера?
Якая будзе рэакцыя, калі колькасць запытоў раптам зросте?
Што будзе, калі база дадзеных стане недоступной?
Як васпамінуцца пасля выпуску нештабельнай версіі?
Які працэдура, якшо парольныя даны будуць апублікованы па чырвонай трохце?
Гэта і є розніца межы:
"Ён працуе на маймовым комп’ютеры.
і
"Ён надзеяна працуе ў рэальных умовах.
Вам не трэба величазны комплекс інфраструктуры з самага пачатку.
Пачніце з малага.
Зразумейце кожны элемент, які вы дадаўте.
Автаматызуйце тое, што павторяецца.
Следзіце за показнікамі, якія справаўна маюць значэнне.
Даўайце сложнасць толькі тады, калі система справаўна гэтага патрабуе.
Размешчэнне не ёсць канец парадку разработкі. Цэ гэта момент, калі пачынаецца асаблівая эксплуатацыя вашага програмнага забезпечэння.
Супакойлена літэратура
- Node.js Command Reference for Local Development and Production Servers — Кансэйнабельны паводлык команд, які охопляе калектываванне версый Node.js, менеджэры пакетаў, налажоўкі сяродавысці, адлучэнне бягаў, PM2 і размешчэння на Linux без перыяда апускання.