Pet‑проект на VDS: как не превратить домашнего зверька в боевой продакшн

Pet‑проекты для большинства админов и разработчиков — это и учебный полигон, и песочница для технологий, и иногда весьма полезные сервисы, которыми потом начинают пользоваться коллеги, друзья или даже реальные клиенты. Логичный выбор площадки для такого «домашнего зверька» — облачный VDS: достаточно свободы, чтобы пробовать всё, и достаточно ответственности, чтобы не расслабляться.

Но именно с pet‑проектами на VDS чаще всего случаются самые неприятные истории: внезапно кончилось место, внезапно кончился трафик, внезапно всё упало после «быстрого апдейта ночью» и, конечно, внезапно пропали бэкапы, которых никто не делал.

В этом разборе я попробую систематизировать подход к pet‑проектам на VDS так, чтобы:

• не превратить сервер в свалку из трёх десятков полумёртвых сервисов;
• не потерять данные после первой же переустановки ОС;
• максимально использовать pet‑проект как тренировку перед реальным продакшном;
• и при этом не тратить лишние деньги и время.

Что такое pet‑проект на VDS и чем он отличается от боевого

Под pet‑проектом я буду понимать не только «игрушечный» сервис, а любой экспериментальный проект:

• личные сайты, блоги, лендинги;
• телеграм‑боты, мелкие REST/gRPC‑сервисы;
• dashboard для себя и команды;
• прототипы будущих SaaS и внутренних инструментов;
• лаборатории для изучения новой технологии (k3s, очереди, очередной фреймворк).

Ключевое отличие от продакшна не в том, что «можно всё ломать», а в том, что уровень ожидаемой надёжности и SLA ниже, а вот свобода экспериментов — выше.

Правильный pet‑проект — это маленький продакшн с пониженной ценой ошибки, а не хаотичная свалка контейнеров и конфигов.

От этого и будем отталкиваться: даже если сервис живёт на одном небольшом VDS, подходы к архитектуре, деплою и бэкапам должны быть «на вырост».

Как выбирать VDS под pet‑проект

Самая частая ошибка: взять минимально возможный тариф, поставить туда всё подряд, а потом удивляться, почему «всё тормозит» и «mysql жрёт всю память».

Ресурсы: сколько нужно pet‑проекту

Разумеется, зависит от стека, но есть несколько практичных ориентиров для старта одного pet‑проекта:

• 1 vCPU, 1 ГБ RAM — годится только для совсем минималистичных задач: статический сайт, маленький бот без БД, маленький API на Go/Node без тяжёлых зависимостей.
• 1–2 vCPU, 2 ГБ RAM — комфортный минимум для классического веб‑стека (Nginx + PHP‑FPM / Node / Python, БД на том же сервере).
• 2–4 vCPU, 4+ ГБ RAM — если планируете несколько pet‑проектов, рантайм + БД + очереди/кеш + мониторинг.

По диску: для большинства pet‑проектов на старте 20–40 ГБ SSD более чем достаточно. Важнее сразу смотреть на возможность расширения и наличие быстрых снапшотов/бэкапов у провайдера.

Если вы планируете тестировать тяжёлые СУБД, time‑series и аналитику, посмотрите в сторону отдельного VDS для баз данных — это и чище по архитектуре, и ближе к боевым сценариям.

Система и дистрибутив

Для pet‑проектов я обычно рекомендую:

• Debian/Ubuntu LTS — привычная экосистема, много документации, простой apt.
• AlmaLinux/Rocky — если вы живёте в RHEL‑мире и хотите отрабатывать те же подходы.

Главный критерий: используйте тот же дистрибутив, что и в «боевой» среде (если она у вас есть или планируется). Тогда pet‑проект будет реально отрабатывать продакшн‑сценарии, а не «играть в линукс».

Одно VDS на всё или отдельный VDS на каждый pet‑проект

Тут возможны два базовых подхода.

1. Один VDS как «лаборатория». На одном сервере живут несколько проектов: каждый в своём systemd‑сервисе или контейнере, одна или несколько БД.

• Плюсы: дешевле, проще администрировать, централизованный мониторинг.
• Минусы: проекты влияют друг на друга по ресурсам, сложнее экспериментировать с «ломающими» изменениями в системе.

2. Отдельный VDS под каждый проект. Особенно удобно при очень разных стеках (например, PHP‑монолит, k3s‑кластер, heavy Postgres + time‑series‑надстройки).

• Плюсы: изоляция по ресурсам и конфигам, легко снести и пересобрать.
• Минусы: дороже, растёт зоопарк машин.

На практике чаще всего стартуют с одной «лаборатории», а потом выносят тяжёлые или критичные проекты в отдельный VDS. Хороший пример эволюции single‑node‑стендов — разбор по метрикам и time‑series на отдельном сервере: см. статью о развёртывании VictoriaMetrics на одном VDS.

Архитектура pet‑проекта: не плодим хаос

Pet‑проекты развиваются волнами: сначала MVP «за вечер», потом внезапно появляются пользователи, потом «а давай прикрутим ещё Redis, Prometheus и очередь». Если не задать минимальные правила игры, через полгода вы получите VDS, в котором страшно делать apt upgrade.

Минимальные принципы организации

• Явная структура каталогов. Например:

/srv/project1
/srv/project2
/var/lib/postgresql
/var/lib/redis
/opt/tools

Не размазывайте проекты по /root, /home/user, /tmp и случайным директориям — потом сами себя проклянёте.

• Отдельный системный пользователь на проект. Это не только безопасность, но и удобство по правам и логам:

adduser --system --group --home /srv/project1 project1

• systemd‑юнит на каждый сервис. Не запускайте ничего «вручную в screen/tmux и пусть крутится».

[Unit]
Description=Project1 API
After=network.target

[Service]
User=project1
WorkingDirectory=/srv/project1
ExecStart=/usr/bin/node server.js
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Те же принципы справедливы, если вы используете Docker: отдельный docker‑compose файл на проект, внятная структура и теги образов, а не «latest откуда‑то из GitHub Actions чужого репо».

Окружения: dev, stage, prod — даже в pet‑проекте

Даже если у вас всего один VDS, можно и нужно имитировать разные окружения:

• разные домены или поддомены: dev.example.test, demo.example.test;
• разные БД и конфиги: project1_dev, project1_prod;
• отдельные systemd‑юниты: project1-dev.service, project1-prod.service.

Это полезно по двум причинам:

• вы отрабатываете рабочие практики (тесты, деплой через git/tag, миграции БД не напрямую на прод);
• вы не убиваете «полупродакшн» пользователей, когда хотите просто «поиграться с фичой».

Деплой pet‑проекта: хватит SSH‑pull вручную

Хотя pet‑проект кажется «несерьёзным», именно на нём удобно наработать привычку к нормальному деплою. Рано или поздно вы перенесёте эти практики в боевой прод.

Минимальная схема деплоя через git

Даже без CI/CD можно настроить адекватный git‑деплой:

1. Создаём bare‑репозиторий на VDS, например /srv/project1.git.
2. Настраиваем post‑receive hook, который обновляет рабочую копию и перезапускает сервис.

git init --bare /srv/project1.git

Простой пример хука /srv/project1.git/hooks/post-receive:

#!/bin/sh
set -e
GIT_WORK_TREE=/srv/project1 git checkout -f main
cd /srv/project1
npm install --production
systemctl restart project1.service

Дальше с локальной машины:

git remote add vds ssh://user@vds.example/srv/project1.git
git push vds main

Это уже лучше, чем «scp + ручной перезапуск».

Лёгкий CI/CD для pet‑проекта

Следующий шаг — подключить простой CI/CD:

• сборка и тесты в CI (GitHub Actions, GitLab CI, любой другой сервис);
• при успешной сборке — деплой на VDS через ssh/rsync или выкладка docker‑образа и обновление контейнера.

Главная идея: pet‑проект — отличное место, чтобы отточить пайплайн, который потом можно почти без изменений тащить в прод.

Если интересно отработать не только деплой, но и полное восстановление стенда, загляните в разбор о CI, бэкапах и тестовых средах — многие идеи прямолинейно переносятся и в pet‑сценарии.

Безопасность: pet‑проект — не повод открывать всё подряд

Многие относятся к pet‑VDS как к «личной песочнице», забывая, что публичный IP ничем не отличается от любого боевого сервера: боты и сканеры придут к вам в первые же часы после выдачи адреса.

Базовая гигиена VDS под pet‑проекты

• SSH только по ключу. Отключите парольный логин в /etc/ssh/sshd_config:

PermitRootLogin prohibit-password
PasswordAuthentication no

• Ограничьте SSH по порту и фаерволу. Не обязательно менять порт (это не безопасность), но можно снизить шум в логах.
• Файрвол по умолчанию deny. Открыты только 22/80/443 и реально нужные порты.

Если дополнительно публикуете админки, API или dev‑окружения наружу, позаботьтесь о TLS: нормальные SSL-сертификаты нужны не только «боевым» проектам, но и тренажёрам, особенно если там логинятся живые пользователи.

Изоляция сервисов

Даже в pet‑окружении старайтесь не запускать всё под root. Минимум:

• отдельные пользователи для приложений;
• минимальные права на файлы (конфиги БД, переменные окружения с секретами);
• ограничения в systemd (ProtectSystem, PrivateTmp, NoNewPrivileges и т.п., если есть желание погрузиться глубже).

Это решает сразу две задачи: повышает безопасность и даёт опыт, который пригодится в боевых системах.

Данные pet‑проекта: не теряем, даже если «это всего лишь игрушка»

Pet‑проекты часто внезапно выстреливают: к ним привыкает вся команда, там накапливаются важные данные (заметки, отчёты, дашборды). Потеря такого сервиса — не катастрофа, но очень болезненный и, главное, бессмысленный опыт.

Что именно нужно считать «данными»

• Базы данных (Postgres, MySQL/MariaDB, SQLite, Redis с персистентностью).
• Загруженные пользователями файлы, медиа, экспорт отчётов.
• Конфигурация сервисов, без которой тяжело быстро всё поднять.
• Секреты и ключи (access‑tokens внешних сервисов, API‑ключи).

Git‑репозиторий — не бэкап данных, максимум бэкап кода.

Минимальная схема бэкапов pet‑проекта

Нетривиальные backup‑решения часто откладывают «на потом», но есть несколько простых подходов, которые можно внедрить за пару часов и потом просто поддерживать.

• Дамп БД + rsync/облако. Раз в сутки делаете дамп, раз в день/несколько часов — синхронизация на внешний сторидж.

pg_dump --format=custom project1 > /var/backups/project1-$(date +%F).dump

• Снапшоты диска от провайдера. Очень удобно как «страховка перед экспериментами». Главное — не считать их заменой регулярным логическим бэкапам БД.

Золотое правило: бэкап существует только после проверенного восстановления. Хоть раз в квартал поднимите «песочный VDS» и попробуйте восстановить pet‑проект с нуля по бэкапам и документации.

Мониторинг pet‑проекта: зачем он вообще нужен

На pet‑проектах очень соблазнительно жить без мониторинга: «упадёт — так упадёт». Но именно здесь проще всего примерить разные подходы и инструменты без давления SLA.

Минимальный набор наблюдаемости

• Системные метрики VDS. CPU, RAM, диск, сеть. Можно начать даже с простого top/htop, но лучше использовать какой‑нибудь лёгкий агент с web‑мордами или интеграцией в Prometheus/Grafana.
• Доступность HTTP‑сервиса. Простейший health‑check снаружи: ping‑мониторинг, который шлёт уведомления, если сайт недоступен.
• Логи ошибок. Сбор ошибок приложения (Sentry или аналоги), хотя бы для одного pet‑проекта — отличная тренировка.

Даже такой минимальный набор даст вам полезный опыт: где реально «узкие места», когда начинаются проблемы с памятью, как выглядит oom‑kill и как реагировать.

Типичные анти‑паттерны pet‑проектов на VDS

Ниже — набор шаблонных «граблей», которые стоит заранее осознать и избегать.

«Свалка технологий» на одном VDS

Node 18, Node 20, три разных Java‑рантайма, две версии PHP, несколько интерпретаторов Python, плюс пара случайных бинарей из curl | bash — классика лабораторного зверинца.

Что с этим сделать:

• по возможности использовать контейнеризацию для конфликтующих стеков;
• минимизировать число глобально установленных рантаймов — остальное держать в контейнерах или через version‑менеджеры (nvm/pyenv и т.п.);
• вести хотя бы короткий README по серверу, чтобы понять, зачем установлен тот или иной софт.

«У меня всё в Docker, бэкапы не нужны»

Контейнер — это не бэкап. Если вы храните БД и данные в docker‑volume и не синхронизируете его никуда наружу — потеря диска VDS = потеря всего. То же самое с конфигами, которые вы правите на лету на сервере.

Решение: относитесь к volume‑ам как к обычным данным, а не к магии Docker. Бэкапить нужно:

• дампы БД;
• персистентные директории приложений (uploads, storage и т.д.);
• docker‑compose файлы и инфраструктурные конфиги (лучше хранить в git).

«Сейчас быстро обновлюсь» через SSH в прод

Самый популярный способ положить pet‑проект — зайти на VDS вечером и обновить пару пакетов/зависимостей «по‑быстрому», без тестов и без бэкапа перед обновлением.

Лучше всего выработать такой рефлекс:

• любое существенное обновление — сначала в dev/stage окружении, даже если оно на том же сервере;
• перед апдейтом БД или существенных пакетов — дамп/снапшот;
• фиксировать изменения в конфигурации в git или хотя бы в текстовом журнале (changelog сервера).

Как извлечь максимум пользы из pet‑проекта на VDS

С точки зрения карьеры и развития, pet‑проект можно использовать как полноценный тренажёр:

• отработать развёртывание нового стека (например, перейти с LAMP на LEMP или добавить reverse‑proxy перед приложением);
• потренироваться в настройке TLS, шифров, заголовков безопасности;
• поднять простой мониторинг, алертинг и протестировать сценарии деградации;
• отладить процессы деплоя и отката версий;
• попробовать разные схемы логирования и ротации логов.

Главная мысль: относитесь к pet‑проекту как к «маленькому продакшну», тогда и ошибки, и опыт будут почти настоящими, а цена — в разы ниже.

Когда pet‑проекту пора «повзрослеть»

Иногда pet‑проект перерастает свой статус: им начинают пользоваться коллеги, заказчик, внешний мир. В этот момент стоит честно ответить на несколько вопросов:

• Если сервис упадёт на сутки — это будет просто неприятно или уже больно?
• Есть ли хоть кто‑то, кроме вас, кто рассчитывает на доступность этого сервиса?
• Важны ли данные внутри (финансы, документы, история действий)?

Если хотя бы на один вопрос ответ «да, важно» — пора:

• пересмотреть архитектуру (отделить БД, вынести критичные части на отдельный VDS);
• настроить регулярные проверенные бэкапы и мониторинг с уведомлениями;
• формализовать процесс деплоя (ветки, теги, миграции, откат);
• задокументировать инфраструктуру и доступы, чтобы проект не был «личной игрушкой одного админа».

На этом этапе pet‑проект перестаёт быть просто тренировкой и становится ещё и хорошим кейсом в портфолио: «ручной VDS с игрушкой» превращается в аккуратную продакшн‑инфраструктуру, к которой уже можно смело подключать продакшн‑домены и полноценные SSL-сертификаты.

Итог

VDS для pet‑проектов — отличный инструмент, если относиться к нему не как к бесплатной песочнице, а как к уменьшенной копии продакшна. Грамотный выбор ресурсов, внятная структура сервисов, базовая безопасность, простые бэкапы и минимальный мониторинг превращают ваш «домашний зверёк» в настоящий учебный стенд.

Со временем именно такие вылизанные pet‑проекты чаще всего становятся вашими лучшими практическими кейсами: и для собеседований, и для внутренних командных стандартов, и для реальных боевых систем, которые вы будете строить уже не «в одиночку на VDS», а в составе сложной инфраструктуры.