Внешняя точка входа.
Собственный сервер приложений.
Разделил систему по ролям: VPS связывает проект с внешним миром, а домашний Debian выполняет вычисления и хранит данные.
VPS — принимает подключения
Nginx обслуживает внешний HTTP-вход, SSH используется для доставки версий. Обратные пробросы привязаны к 127.0.0.1:8080 и 127.0.0.1:2222. Рабочие контейнеры TaskFlow находятся на домашнем сервере.
Debian 13 · Nginx · SSHDebian — выполняет работу
На основном сервере работают Docker, интерфейс и API TaskFlow, PostgreSQL, мониторинг и резервное копирование. Он сам устанавливает соединения с VPS и поддерживает оба туннеля.
Ryzen 5 5600 · Debian 13 · 192.168.0.100Так роли компонентов остаются понятными при диагностике: внешний вход, транспорт, маршрутизатор приложения и база данных проверяются последовательно. Приложение работает на одном домашнем сервере, поэтому разделение сервисов не означает отказоустойчивость на уровне оборудования.
Два маршрута.
Каждый решает свою задачу.
- Браузер
- VPS · Nginx
- HTTP-туннель
- TaskFlow
Запрос приходит на VPS :80, проходит через 127.0.0.1:8080 и достигает Debian :80. Затем taskflow-router направляет / в интерфейс, а /api/ — в FastAPI, который обращается к PostgreSQL.
- GitHub Actions
- VPS · SSH
- SSH-туннель
- Новый выпуск
GitHub Actions подключается к VPS :22. ProxyCommand использует обратный проброс 127.0.0.1:2222 к Debian :22. Учётная запись deploy запускает taskflow-deploy; сборка и запуск окружения происходят на Debian.
Оба туннеля создаёт домашний сервер исходящими соединениями Debian → VPS. Внешний запрос проходит по уже установленному соединению в обратном направлении. Публикация приложения и доставка кода используют разные порты и службы.
Как устроена публикация приложения ↗После запуска —
наблюдение и обслуживание.
Приложение нужно не только развернуть: важно видеть его состояние, замечать сбои и сохранять данные независимо от выпуска новой версии.
Наблюдение
Prometheus собирает показатели хоста, контейнеров, HTTP и PostgreSQL. Grafana даёт обзор состояния, Alertmanager принимает события правил оповещения. Netdata дополняет эту схему отдельным наблюдением за сервером.
Метрики и ограничения оповещений ↗Сохранность данных
Ежедневный таймер systemd запускает создание архива PostgreSQL. После проверки структуры сохраняются три последние успешные копии. Отдельный таймер каждый час проверяет свежесть последнего архива.
Создание и проверка копий ↗Восстановление PostgreSQL из резервной копии работает. Проверка структуры архива и восстановление — разные операции. Копии хранятся локально; внешнее хранение не настроено.
Доступ организован
под конкретную работу.
Удалённое администрирование, рабочий стол и выпуск версий используют отдельные каналы. У каждого — своя роль и набор разрешений.
wg0 · 10.10.0.1/24
Действующий WireGuard-интерфейс для подключения к Debian.
tun0 · 10.0.0.1/30
Отдельный канал с собственной таблицей маршрутизации для удалённого рабочего стола.
deploy · reverse SSH
Разрешён конкретный сценарий выпуска через sudo. Произвольная оболочка root через общий sudo не выдаётся.
Разработчики, тестировщики и администраторы выделены в отдельные роли. Старый wg-vps остался на Debian, но не участвует в текущем выпуске: на VPS WireGuard отсутствует.
Что защищено сейчас.
Что предстоит усилить.
Контроль выпуска и состояния
Два окружения позволяют проверить новую версию до переключения. Мониторинг помогает определить уровень сбоя, локальные архивы PostgreSQL сохраняются по расписанию.
Эти механизмы решают разные задачи: возврат приложения не откатывает общую базу и не заменяет резервную копию.
Следующие проверки
- Восстановление PostgreSQL из резервной копии работает. Внешнее хранение копий не настроено.
- Отправка уведомлений Alertmanager не настроена. HTTPS отсутствует: доступ осуществляется по IP-адресу через HTTP.
- Debian и VPS остаются единичными точками отказа.
Как оценивается доступность портов
Слушающий порт сам по себе не доказывает доступность из интернета. Нужно учитывать адрес привязки, маршрутизацию, nftables и Docker NAT. Неактивный UFW не означает отсутствие фильтрации.
Технические подробности —
на нужной глубине.
Пути конфигурации, службы и зависимости собраны по задачам. Каждый раздел раскрывается отдельно.
Туннели и systemd
SSH: taskflow-tunnel.service. HTTP: taskflow-web-tunnel.service; зависит от основного туннеля. Для SSH настроены ExitOnForwardFailure, проверка ключа хоста, ServerAliveInterval=30, ServerAliveCountMax=3, Restart=always и RestartSec=10.
Маршрутизатор и окружения
Каталог /opt/company/router/ содержит docker-compose.yml, nginx.conf и active-color. На момент аудита активен green. Клиентская часть: taskflow-green-frontend:80; серверная: taskflow-green-web:8000. Blue сохранён для возврата.
Сети Docker
taskflow-prod — 172.20.0.0/16, приложение и база. taskflow-router — 172.21.0.0/16, маршрутизатор и окружения. monitoring — 172.23.0.0/16. Netdata использует отдельную сеть netdata_default. Старые сети taskflow-blue_default и taskflow-seo_default не определяют текущую схему.
Выпуск и восстановление после перезапуска
Сценарий выпуска: /usr/local/sbin/taskflow-deploy. Каталоги версий: /opt/company/releases/<commit>. Служба taskflow-reconcile зависит от Docker и сетевой готовности; её сценарий находится в /usr/local/sbin/taskflow-reconcile.
Мониторинг и копирование
Конфигурация мониторинга: /opt/company/monitoring/. Создание копий: taskflow-backup.service и taskflow-backup.timer. Проверка свежести: taskflow-backup-check.service и taskflow-backup-check.timer.