Пошаговая настройка VPS под разработчика и CI/CD с нуля

MAATRIX

Взяли сервер под разработку, но не знаете, как превратить его в рабочий конвейер? Пошаговая настройка VPS под разработчика и CI/CD с нуля укладывается в понятную последовательность: защитить сервер, поставить Docker, поднять раннер, описать пайплайн и настроить автодеплой на стейджинг. Пройдём весь путь по порядку, чтобы в конце пуш в репозиторий сам запускал сборку, тесты и выкладку свежей версии.

Шаг 1. Заказ сервера и первое подключение

Начните с выбора конфигурации и локации. Для лёгкого проекта с тестами и небольшим стейджингом достаточно 2 ядер и 4 ГБ памяти; под тяжёлые сборки фронтенда и Docker берите 4 ядра и 8 ГБ с быстрым SSD. Локацию выбирайте по работе: если конвейер тянет зарубежные пакеты — US или Европа, если демо смотрят из России — RU. У MAATRIX сервер оформляется за минуты, оплата картой РФ, по СБП, криптой или токеном MAAT.

Прежде чем нырять в команды, коротко о том, что мы собираем и зачем. Итоговый сервер будет выполнять несколько ролей: раннер, который по каждому пушу забирает код, гоняет тесты и собирает проект; стейджинг — работающую копию приложения, куда автоматически уезжает свежая версия для показа заказчику. Смысл всей затеи в том, чтобы убрать ручной труд и человеческий фактор: вы больше не собираете проект на ноутбуке и не выкатываете код руками через SSH, рискуя забыть шаг. Вместо этого пуш в репозиторий запускает выверенную цепочку, а вы видите результат в интерфейсе CI. Именно к этому состоянию мы и придём за шесть шагов.

Возьмите свежую Ubuntu и подключитесь по SSH, используя выданные данные. Первое подключение — момент, когда сервер уже смотрит в интернет, поэтому сразу переходите к защите, не откладывая её на потом. Обновите систему, чтобы закрыть известные уязвимости:

ssh root@ВАШ_IP
apt update && apt upgrade -y

Шаг 2. Базовая защита

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

ufw allow 22/tcp
ufw allow 80,443/tcp
ufw enable

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

Шаг 3. Установка Docker

Docker — основа воспроизводимого конвейера. Он запускает сборки в чистых контейнерах, исключая влияние мусора в системе, и удобно упаковывает стейджинг-приложение. Поставьте Docker и плагин Compose:

curl -fsSL https://get.docker.com | sh
docker compose version

Docker-исполнитель избавляет от классической проблемы «на моей машине работает»: пайплайн всегда стартует из заданного образа, и результат не зависит от того, что осталось на сервере. Стейджинг вы тоже сможете держать в контейнере, а его данные — в отдельном томе, чтобы не терять при обновлениях. Это делает и сборку, и деплой предсказуемыми и повторяемыми.

Отдельно стоит сказать, почему воспроизводимость так важна именно для команды. Когда каждый разработчик собирает проект в своей локальной среде, различия версий инструментов и системных библиотек рано или поздно приводят к тому, что код проходит у одного и падает у другого. Единый сборочный сервер с фиксированным окружением снимает этот класс споров: сборка идёт в одинаковых условиях для всех, и её результат становится общим источником правды. Это экономит команде часы, которые иначе уходят на разбор «почему у меня не собирается», и делает зелёный статус пайплайна действительно надёжным сигналом.

Шаг 4. Установка и регистрация раннера

Теперь поднимите исполнителя CI/CD. На примере GitLab подключите официальный репозиторий и установите раннер:

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | bash
apt install -y gitlab-runner

После установки зарегистрируйте раннер в вашем проекте, взяв токен в настройках CI/CD проекта. В процессе регистрации укажите тип исполнителя docker, образ по умолчанию и теги, по которым задания будут направляться на этот раннер. После успешной регистрации раннер появится в проекте как активный. Раннеру не нужны открытые входящие порты — он сам опрашивает платформу и забирает задания, инициируя исходящие соединения.

Шаг 5. Пайплайн и автодеплой на стейджинг

Опишите конвейер в файле конфигурации репозитория. Задайте этапы: установка зависимостей, тесты, сборка, деплой на стейджинг. Простой каркас пайплайна выглядит так:

stages: [test, build, deploy]
test:
  script:
    - npm ci
    - npm test
build:
  script:
    - npm run build
deploy:
  script:
    - ./deploy-staging.sh

Настройте кеш зависимостей, чтобы пакеты не скачивались при каждом прогоне заново, — это резко ускоряет пайплайн. Этап деплоя запускает скрипт, который выкладывает свежую сборку на стейджинг-окружение: обновляет контейнер приложения или копирует собранные файлы туда, откуда их отдаёт веб-сервер. Продумайте порядок так, чтобы стейджинг обновлялся только после успешных тестов и сборки, а не до них. Тогда сломанная версия не доедет до демонстрации.

Шаг 6. Обслуживание и проверка

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

Дальше настройте обслуживание, чтобы сервер не деградировал. Добавьте регулярную очистку неиспользуемых Docker-образов, иначе диск забьётся и пайплайны встанут: docker system prune -af по расписанию решает это. Проверьте, что раннер и стейджинг стартуют после перезагрузки сервера — политика автоперезапуска контейнеров и автозапуск раннера обеспечат это. Следите за ресурсами: если сборки упираются в процессор или память и выстраиваются в очередь, это честный сигнал нарастить конфигурацию или разнести раннер и стейджинг на отдельные серверы. У MAATRIX и то, и другое делается без переезда, оплатой из России. Так с нуля собирается конвейер, где пуш запускает сборку, тесты и деплой сам, а вы лишь смотрите на результат.

Частые вопросы