idea.uz Модернизация инфраструктуры
Настоящий документ описывает технические изменения в инфраструктуре веб-приложения Idea-store и их влияние на надёжность, скорость доставки и операционные затраты.
Контекст
Задача модернизации решалась исключительно на уровне инфраструктуры — без изменения кода приложения. Это означает, что бизнес-логика, пользовательский интерфейс и API-контракты остались нетронутыми, а все улучшения получены за счёт оптимизации среды выполнения и процессов доставки обновлений.
Часть 1. Серверная архитектура
До: Распределённая инфраструктура на отдельных серверах
Инфраструктура была разделена на две независимые виртуальные машины с разными доменными именами и точками входа. Фронтенд и бэкенд существовали как самостоятельные сервисы: каждый со своим Nginx, своим доменом и своей зоной ответственности. База данных располагалась на той же VM, что и бэкенд.
Ключевая проблема такой схемы: когда фронтенд запрашивал данные, он обращался к api.idea.uz — то есть запрос уходил в публичный интернет и возвращался обратно, даже если обе машины находились в одной сети провайдера. Это делало API-коммуникацию между частями одного приложения ненадёжной и зависимой от внешних факторов.
Ключевые проблемы:
- Две независимые точки входа —
idea.uzиapi.idea.uzуправляются раздельно: отдельные SSL-сертификаты, отдельные конфиги Nginx, отдельное администрирование - API-коммуникация через публичный интернет — запрос от Next.js к Laravel уходил на
api.idea.uzчерез внешнюю сеть, что добавляет задержку, зависимость от DNS и создаёт дополнительную поверхность атаки - Ненадёжная связь между частями одного приложения — любой сбой на уровне сети, DNS или SSL между двумя VM означал деградацию или полную недоступность сайта
- База данных на публичном сервере — DB находилась на той же VM, что и бэкенд с открытым внешним доменом, что повышает риски при компрометации сервера
После: Контейнеризованная архитектура на Docker Compose
Все прикладные компоненты объединены в единый контейнерный стек на одной VM. Контейнеры общаются по изолированной внутренней Docker-сети — трафик между ними не выходит за пределы сервера. База данных намеренно вынесена на отдельный сервер для обеспечения сохранности данных вне жизненного цикла контейнеров.
Что принципиально изменилось:
- 1 внешних IP вместо 4 — единственная точка входа; все остальные компоненты недоступны из интернета напрямую
- Межсервисный трафик изолирован — Nginx, Next.js и Laravel общаются по внутренней Docker-сети (172.x.x.x), не покидая сервер
- БД недоступна из интернета — связь с базой данных идёт по приватной сети между VM, а не через публичный IP
- Воспроизводимая среда — приложение разворачивается идентично на любой машине с Docker
Сравнение архитектур
| Параметр | До | После |
|---|---|---|
| Внешних доменов / точек входа | 2 (idea.uz + api.idea.uz) | 1 (idea.uz) |
| API-коммуникация frontend ↔ backend | Через публичный интернет | Внутри Docker-сети |
| БД доступна из интернета | Косвенно (через VM бэкенда) | Нет (изолирована) |
| Стандартизация окружения | Ручная настройка каждой VM | Единый Docker-образ |
| Время первичного развёртывания | Часы | Минуты (make setup && make up) |
| Изменение кода приложения | — | Не требовалось |
Часть 2. (В планах) Процесс доставки обновлений (CI/CD)
До: Ручной деплой через SSH
Обновление приложения выполнялось скриптом, который подключался к серверу по SSH и выполнял команды напрямую. Этот подход работает, но несёт значительные операционные и бизнес-риски.
Риски и ограничения:
- Downtime при каждом обновлении — рестарт сервисов означает период недоступности для пользователей
- Нет проверок перед деплоем — изменения попадают на сервер без тестирования, сборки или валидации
- Нет возможности отката — при ошибке после деплоя нет простого механизма вернуться к предыдущей версии
- Прямой доступ к серверу — CI-система имеет SSH-доступ к продакшн-серверу, что является угрозой безопасности
После (целевое состояние): Полноценный CI/CD-пайплайн
Планируемый пайплайн устраняет все перечисленные риски и переводит деплой в управляемый, автоматизированный и безопасный процесс.
Ключевые улучшения:
- Near-zero downtime — благодаря контейнерному деплою новая версия поднимается параллельно со старой; переключение происходит мгновенно
- Качество гарантируется пайплайном — код без прохождения тестов физически не может попасть на сервер
- Быстрый и надёжный откат — при сбое система автоматически возвращается к предыдущей версии образа
- Нет прямого доступа к серверу — CI работает через Docker-механизмы, SSH-доступ к продакшну не требуется
- Прозрачность — каждый деплой логируется: что, когда и кем было задеплоено
Сравнение процессов доставки
| Параметр | До | После (цель) |
|---|---|---|
| Downtime при обновлении | Есть (рестарт сервисов) | Near-zero |
| Проверка кода перед деплоем | Отсутствует | Автотесты обязательны |
| Откат при ошибке | Ручной, долгий | Автоматический |
| Безопасность | SSH-доступ к серверу | Изолированный пайплайн |
| Прозрачность деплоев | Минимальная | Полный аудит-лог |
| Скорость доставки | Быстро, но рискованно | Быстро и надёжно |
Итоговая оценка
Проведённая модернизация — это инвестиция в управляемость и надёжность системы. Не была изменена ни одна строка бизнес-логики, при этом получены:
- Сокращение серверной инфраструктуры в 2 раза
- Стандартизированное и воспроизводимое окружение
- Основа для выстраивания зрелого CI/CD-процесса
Следующий шаг — реализация описанного пайплайна — позволит команде доставлять обновления без остановки сервиса, что напрямую влияет на доступность продукта для конечных пользователей.