rzaripov.kz

Развертывание Node.js-приложения на VPS местного хостинга

VPS от местного провайдера подходит для размещения веб-сервисов, API, интернет-магазинов и личных кабинетов, когда обычного виртуального хостинга уже недостаточно. В отличие от shared-хостинга, виртуальный сервер дает отдельные ресурсы, root-доступ и возможность самостоятельно выбрать операционную систему, веб-сервер и набор инструментов.

Для проектов на Node.js обычно используется связка Ubuntu, Nginx, Node.js и PM2. PHP-приложения разворачиваются немного иначе: им требуются PHP-FPM, Nginx или Apache и база данных. Оба варианта можно разместить на VPS в Казахстане, получив небольшой сетевой отклик для пользователей из Алматы и других городов региона.

Успешный запуск зависит не только от загрузки файлов на сервер. Нужно подготовить операционную систему, настроить пользователя, домен, HTTPS, автоматический запуск процесса и резервное копирование. Такая схема подходит для небольших коммерческих проектов, мобильного backend-сервиса и тестовых сред.

Выбор тарифа и подготовка сервера

Для одного небольшого Node.js-приложения обычно достаточно VPS с одним или двумя виртуальными ядрами, 1–2 ГБ оперативной памяти и SSD-диском. Если сервис обрабатывает изображения, выполняет фоновые задачи или использует сборку фронтенда на сервере, лучше сразу выбрать тариф с 2 ГБ памяти и запасом дискового пространства.

При выборе местного хостинга стоит проверить расположение дата-центра, доступность IPv4, скорость канала, возможность создания снимков диска и способ подключения к серверу. Дата-центр в Казахстане уменьшает задержку для локальных пользователей, а наличие площадок в соседних регионах может быть полезно для резервной инфраструктуры.

После создания VPS провайдер обычно выдает IP-адрес, имя пользователя и временный пароль. Подключение выполняется по SSH:

ssh root@IP_АДРЕС_СЕРВЕРА

Сразу после входа желательно обновить пакеты и создать отдельного пользователя для приложения:

apt update && apt upgrade -y
adduser deploy
usermod -aG sudo deploy

Постоянная работа под root увеличивает риск случайного удаления системных файлов или компрометации сервера. Для пользователя deploy можно настроить вход по SSH-ключу, а авторизацию по паролю отключить после проверки подключения.

Установка Node.js и загрузка проекта

Для Node.js-приложения лучше использовать актуальную LTS-версию. Ее можно установить через NodeSource, менеджер NVM или пакетный менеджер операционной системы. NVM удобен, если на одном сервере нужно запускать несколько проектов с разными версиями Node.js.

После установки проверяются версии среды и менеджера пакетов:

node -v
npm -v

Код проекта можно получить из Git-репозитория. На сервере создается каталог приложения, затем выполняется клонирование и установка зависимостей:

sudo mkdir -p /var/www/app
sudo chown -R deploy:deploy /var/www/app
cd /var/www/app
git clone https://github.com/user/project.git .
npm ci

Команда npm ci устанавливает зависимости по lock-файлу и дает более предсказуемый результат, чем обычный npm install. Переменные окружения не следует хранить в открытом репозитории. Для них создают файл .env, где указывают порт, строку подключения к базе данных, секреты JWT и ключи внешних сервисов.

Если проект собирается TypeScript-компилятором или содержит серверный интерфейс на Next.js, Nuxt или другом фреймворке, перед запуском выполняется команда сборки. После этого приложение должно слушать локальный порт, например 127.0.0.1:3000, а внешний доступ будет передаваться через Nginx.

Запуск через PM2 и настройка Nginx

Запуск процесса непосредственно в SSH-сессии неудобен: после выхода из терминала приложение остановится. PM2 работает как менеджер процессов, автоматически перезапускает сервис после сбоя и сохраняет его состояние после перезагрузки VPS.

Установка и запуск выполняются так:

npm install -g pm2
pm2 start npm --name my-app -- start
pm2 save
pm2 startup systemd

Последняя команда выводит дополнительную команду, которую нужно выполнить с правами администратора. В рабочей среде полезно настроить журналирование, ограничение размера логов и отдельный файл конфигурации PM2. Секреты и параметры окружения должны передаваться приложению без публикации в Git.

Nginx принимает запросы на 80-м и 443-м портах, а затем передает их Node.js-сервису. Пример виртуального хоста:

server {
    listen 80;
    server_name example.kz www.example.kz;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Конфигурация сохраняется в /etc/nginx/sites-available/my-app, после чего для нее создается символическая ссылка в sites-enabled. Перед перезапуском выполняется nginx -t. Если проверка прошла успешно, применяется команда systemctl reload nginx.

Такой reverse proxy скрывает внутренний порт приложения, обеспечивает обработку домена и создает основу для подключения HTTPS. При необходимости через Nginx можно раздавать статические файлы, ограничивать размер загрузки и задавать кэширование.

Развертывание PHP-проекта на том же VPS

PHP-приложения используют другой способ обработки запросов. В типовой конфигурации Nginx принимает соединение и передает PHP-файлы службе PHP-FPM через Unix-сокет. Для Laravel, Symfony и самописного проекта дополнительно устанавливаются Composer, расширения PHP и выбранная база данных.

После установки пакетов создается каталог сайта и загружается код:

apt install nginx php-fpm php-mysql php-curl php-mbstring php-xml unzip
apt install composer
cd /var/www/php-app
composer install --no-dev --optimize-autoloader

Корнем сайта Laravel обычно назначается каталог public, а не вся директория проекта. Это защищает файлы конфигурации и исходный код от прямой выдачи веб-сервером. После загрузки .env выполняются миграции базы данных и команды кэширования, если они предусмотрены конкретным фреймворком.

Конфигурация Nginx для PHP может выглядеть следующим образом:

server {
    listen 80;
    server_name example.kz;
    root /var/www/php-app/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }
}

Версия сокета зависит от установленного PHP. Права на каталоги кэша и загрузок должны позволять запись пользователю веб-сервера, но не следует без необходимости делать весь проект доступным для изменения. Для Node.js и PHP можно использовать один VPS, однако отдельные пользователи, каталоги и базы данных упрощают контроль доступа.

Домен, безопасность и дальнейшее обслуживание

Для привязки домена в DNS создается A-запись, указывающая на IPv4-адрес VPS. Если используется поддомен для API, например api.example.kz, для него также добавляется отдельная запись. Обновление DNS может занять некоторое время, поэтому проверять домен лучше после распространения записей.

Бесплатный сертификат Let's Encrypt устанавливается через Certbot. Для Nginx распространенный вариант выглядит так:

apt install certbot python3-certbot-nginx
certbot --nginx -d example.kz -d www.example.kz

Certbot может автоматически изменить конфигурацию и включить перенаправление с HTTP на HTTPS. Автоматическое продление следует проверить командой certbot renew --dry-run. Помимо шифрования, HTTPS необходим для защищенных cookie, авторизации и корректной работы современных браузеров.

Минимальный набор мер безопасности включает настройку UFW, установку Fail2ban, регулярное обновление пакетов и отключение ненужных сетевых портов:

ufw allow OpenSSH
ufw allow 'Nginx Full'
ufw enable

База данных не должна быть открыта всему интернету, если приложение и СУБД находятся на одном сервере. Резервные копии базы и файлов нужно хранить отдельно от VPS: снимок диска помогает быстро восстановить сервер, но не заменяет независимую копию. Для контроля состояния проверяются логи Nginx, PM2 или PHP-FPM, загрузка процессора, память, свободное место и срок действия сертификата.

Параметр Node.js PHP
Основной процесс Приложение, запущенное через PM2 или systemd PHP-FPM
Веб-сервер Обычно Nginx как reverse proxy Nginx или Apache
Установка зависимостей npm ci или pnpm install composer install
Типичный внутренний порт 3000, 4000 или другой Unix-сокет PHP-FPM
Перезапуск после сбоя PM2, systemd или контейнер PHP-FPM и веб-сервер
Подходящие задачи API, WebSocket, фоновые сервисы CMS, Laravel, Symfony, классические сайты
Особое внимание Переменные окружения и управление процессом Версия PHP, права каталогов и расширения

После развертывания полезно выполнить проверку главной страницы, API-методов, авторизации, загрузки файлов и подключения к базе данных. Затем стоит зафиксировать конфигурацию в документации проекта: версия ОС, Node.js или PHP, команды обновления, расположение логов и порядок восстановления из резервной копии. Такой регламент делает VPS предсказуемой частью инфраструктуры и упрощает дальнейшее сопровождение приложения.