Как впервые загрузить статический сайт на VPS вручную

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

Инструкция относится к статическому сайту: после сборки получается каталог с HTML, CSS, JavaScript, изображениями и другими готовыми файлами. На VPS не запускается серверная часть приложения и не требуется база данных.

В примерах локальный результат находится в каталоге dist, пользователь VPS называется admin, домен — example.org, а Nginx читает /var/www/example.org/html. Замените эти значения на свои.

Чем исходный проект отличается от готового сайта

В каталоге проекта могут находиться шаблоны, исходный JavaScript, настройки сборщика, тесты и список зависимостей. Браузеру эти рабочие файлы не нужны. Команда сборки преобразует их в готовый результат — обычно каталог dist, build, public или другой путь, заданный проектом.

Не угадывайте название каталога. Найдите команду build в документации проекта или файле package.json и посмотрите сообщение после её выполнения. Если сборщик создаёт dist, именно его содержимое должен читать Nginx.

Node.js, npm и исходный репозиторий не обязательно переносить на VPS. Сборка на компьютере уменьшает число программ на сервере и не помещает рабочие файлы в публичный каталог.

Соберите сайт штатной командой проекта

Откройте терминал в каталоге проекта на своём компьютере. Для проекта на npm типичная последовательность выглядит так, но приоритет имеют команды из его README и настроек:

npm ci
npm run check
npm run build

npm ci устанавливает точно те версии зависимостей, которые записаны в lock-файле проекта. npm run check запускает предусмотренные проверки, а npm run build создаёт готовый сайт. Если любая команда завершилась ошибкой, не загружайте старый или частично созданный каталог как новый выпуск.

Проект на другом генераторе может использовать иные команды. Смысл остаётся тем же: зависимости воспроизводимо установлены, проверки пройдены, сборка завершена без ошибки.

Откройте результат до передачи

Убедитесь, что каталог результата существует и содержит главную страницу. На macOS или Linux можно выполнить:

find dist -maxdepth 2 -type f | sort | head -n 30
du -sh dist

Первая команда показывает первые тридцать файлов не глубже двух уровней, вторая — общий размер. В PowerShell похожий список даёт Get-ChildItem .\dist -File -Recurse | Select-Object -First 30, а размер можно посмотреть в свойствах каталога.

Наличие файлов ещё не подтверждает работу сайта. Запустите локальный предварительный просмотр штатной командой проекта и откройте главную, внутреннюю страницу, несуществующий адрес, изображения и основные ссылки. Ошибка, замеченная здесь, не требует отката на сервере.

Убедитесь, что в результате нет закрытых файлов

В dist должны находиться только данные, которые можно отдать любому посетителю. Не загружайте туда:

• .env с паролями и токенами;
• закрытые SSH-ключи и сертификаты с приватным ключом;
• каталог .git с историей проекта;
• резервные копии и дампы базы данных;
• журналы разработки и временные архивы.

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

Если секрет уже попал в сборку, простого удаления файла недостаточно: значение нужно отозвать или заменить в системе, где оно действует, а затем собрать сайт заново.

Передайте сборку во временный каталог пользователя

Не копируйте файлы сразу поверх каталога, который читает Nginx. Во время передачи посетитель может получить новый HTML со старыми стилями или запросить изображение, которое ещё не загрузилось.

Следующая команда выполняется на вашем компьютере. Она копирует содержимое dist по защищённому соединению SSH в новый каталог site-upload в домашней папке пользователя VPS:

scp -r dist admin@203.0.113.10:site-upload

scp передаёт файлы через SSH, а -r разрешает копирование каталога вместе с содержимым. Замените IP-адрес, пользователя и имя локального каталога. Если site-upload уже существует после предыдущей попытки, удалять или перезаписывать его вслепую не следует: войдите на VPS, проверьте путь и выберите новое имя.

После завершения подключения к VPS перейдите в домашний каталог пользователя и выполните find ~/site-upload -maxdepth 2 -type f | head. В списке должна быть главная страница и ожидаемые ресурсы. Команда du -sh ~/site-upload позволяет сравнить общий размер с локальным результатом.

Подготовьте новый публичный каталог

На VPS создайте рядом с работающим каталогом новое пустое место и скопируйте туда проверенную загрузку:

sudo install -d -o admin -g admin -m 755 /var/www/example.org/html-new
sudo cp -a /home/admin/site-upload/. /var/www/example.org/html-new/

Первая команда создаёт html-new с владельцем admin. Вторая копирует внутрь всё содержимое загрузки; точка после site-upload/ означает «содержимое каталога», а не дополнительную вложенную папку.

После копирования примените к каталогам и файлам модель из статьи о правах Nginx. Затем проверьте главную страницу от имени Nginx:

sudo -u www-data test -r /var/www/example.org/html-new/index.html && echo "Главная страница доступна Nginx"

Сообщение появится только при успешном чтении. Дополнительно сравните количество и размер файлов в html-new с локальным результатом. Не переходите к замене, если index.html отсутствует или права ещё не понятны.

Замените тестовую страницу готовым сайтом

Предыдущий урок настроил Nginx на каталог /var/www/example.org/html. Сначала сохраните его под отдельным именем, затем поставьте на его место полностью подготовленный html-new:

sudo mv /var/www/example.org/html /var/www/example.org/html-before-first-publish
sudo mv /var/www/example.org/html-new /var/www/example.org/html

mv здесь переименовывает каталоги внутри одной файловой системы. Содержимое нового сайта уже скопировано, поэтому посетители не наблюдают постепенную передачу отдельных файлов.

Команда предполагает, что резервного каталога html-before-first-publish ещё нет. Перед запуском проверьте ls -ld /var/www/example.org/html*. Если имя уже занято, выберите другое понятное имя и не удаляйте существующие данные без проверки.

Конфигурация Nginx не менялась: директива root по-прежнему указывает на путь html. Поэтому перезапуск или reload не нужен. Nginx сразу начнёт читать файлы нового каталога.

Проверьте страницу внутри VPS и снаружи

Сначала запросите сайт у Nginx внутри VPS. Заголовок Host сообщает, конфигурацию какого домена нужно использовать:

curl -I -H 'Host: example.org' http://127.0.0.1/

Ожидается код 200 или настроенное перенаправление на HTTPS. Если ответ 403, снова проверьте владельцев и права пути. 404 обычно означает, что Nginx не нашёл index.html в каталоге root либо выбрал другой блок домена.

Затем на своём компьютере откройте сайт в браузере и выполните внешний запрос:

curl -I https://example.org/

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

Верните прежний каталог, если проверка не прошла

Если новый сайт не работает, сначала сохраните его под отдельным именем для разбора, а затем верните прежний каталог:

sudo mv /var/www/example.org/html /var/www/example.org/html-failed
sudo mv /var/www/example.org/html-before-first-publish /var/www/example.org/html

Снова выполните локальный и внешний запросы. Конфигурация Nginx не менялась, поэтому служба по-прежнему читает путь html, но теперь там находится прежняя страница.

Не запускайте эти команды, если соответствующих каталогов нет или их имена отличаются. Сначала проверьте точные пути через ls -ld /var/www/example.org/html*. После исправления новой сборки можно повторить публикацию с новыми временными именами.

Чему должна научить первая публикация

После этого этапа должно быть понятно:

• какой каталог создаёт локальная сборка;
• почему на VPS передаются готовые файлы, а не весь проект;
• где находится временная загрузка и какой каталог читает Nginx;
• как проверить чтение до замены;
• как вернуть прежнюю страницу.

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

Первоисточники

• OpenSSH: руководство scp
• GNU Coreutils: копирование каталогов
• NGINX: раздача статических файлов