Skip to main content

План миграции сайта на новую инфраструктуру и репозиторий

1. Текущее положение вещей (as-is)​

Инфраструктура​

  • 2 ВМ с внешними адресами.

  • Nginx настроен на backend-сервере и является точкой входа для фронта и API:

    • site.uz → frontend
    • api.site.uz → backend

  • Frontend обращается к backend по внешнему домену (api.site.uz).

  • База MySQL находится на backend-сервере.

CI/CD​

  • GitLab CI/CD “полумёртвый”: фактически выполняет git pull, npm install, restart.
  • Контейнеризация отсутствует в проде.
  • Локально уже собраны Dockerfile и есть docker-compose (через костыли).

Проблемы​

  • Деплой не воспроизводим.
  • Нет нормального разделения ролей (edge/app/db).
  • Наблюдаемость слабая или отсутствует.
  • Трудно безопасно масштабировать и сопровождать.

2. Переработка репозитория (to-be)​

Цель​

  • Перейти на GitHub (организация).
  • Сделать monorepo: backend + client в одном репозитории.
  • Сохранить простоту, но обеспечить правильный фундамент.

Решение​

  • Laravel и Next в одном репозитории, но в отдельных папках.
  • Перенести Next в подпапку frontend/.
  • Добавить infra/ для docker-compose, nginx-конфигов, скриптов деплоя.
  • Настроить GitHub Actions + GHCR.

Плюсы​

  • Единый источник правды: код + инфраструктура + документация.
  • Воспроизводимые сборки (через контейнерные образы).
  • Атомарные изменения API + UI.
  • Готовность к будущему Kubernetes без необходимости переписывать приложение.

3. Структура monorepo (рекомендуемая)​

Ключевой принцип: backend и client изолированы, инфраструктура рядом, но не смешана с кодом приложения.

repo/
  backend/
    app/
    bootstrap/
    config/
    database/
    public/
    resources/
    routes/
    storage/
    tests/
    composer.json
    artisan
    Dockerfile

  frontend/
    src/
    public/
    package.json
    next.config.*
    tsconfig.json
    Dockerfile

  infra/
    compose/
      docker-compose.dev.yml
      docker-compose.prod.yml
    nginx/
      edge/
        site.conf
        api.conf
      app/
        laravel.conf
    scripts/
      deploy_prod.sh
      migrate_prod.sh
      rollback_prod.sh
    env/
      backend.env.example
      client.env.example
      prod.env.example

  .github/
    workflows/
      build_backend.yml
      build_client.yml
      deploy_prod.yml

  docs/
    architecture.md
    runbook.md
    deploy.md

  README.md

Примечания​

  • В production-репозитории не хранить реальные .env.prod.
  • Хранить только .env.example и шаблоны.
  • Теги образов в registry должны быть по git sha.

4. Переработка инфраструктуры (to-be)​

Цель​

Сделать минимально правильную схему, не усложняя её HA, балансировщиками и Kubernetes.

Выбранная топология: вариант C (3 ВМ)

  • VM1: edge

    • Nginx reverse proxy
    • TLS termination
    • Роутинг по доменам
    • Кеширование и сжатие статики

  • VM2: app

    • Docker Compose production
    • Next.js runtime (SSR)
    • Laravel (php-fpm)
    • Worker (очереди)
    • Scheduler
    • Redis (опционально)

  • VM3: db

    • MySQL нативно на хосте (не в Docker)
    • Бэкапы на VM3 в отдельный каталог
    • Offsite-перенос бэкапов через rsync pull на удалённые хосты

Сеть​

  • Приватная сеть выделенная под prod subnet.
  • Снаружи доступна только VM1 (edge).
  • VM2 и VM3 не имеют публичных сервисов.

5. CI/CD (минимально правильный)​

GitHub Actions​

  • Сборка Docker-образов backend и client.
  • Пуш в GHCR.
  • Деплой на VM2 через pull образов + docker compose up -d.
  • Миграции Laravel выполняются как отдельный шаг в деплое.

Особенность, важная для вашего режима (downtime ok)

  • Деплой можно делать простым рестартом сервисов.
  • Но миграции и рестарт worker лучше выполнять контролируемо и в фиксированном порядке.

6. Наблюдаемость​

Минимальный набор, который окупается

  • AppSignal для Laravel (APM, ошибки, метрики).
  • AppSignal (или альтернативный error monitoring) для Next.
  • Базовые метрики по хостам (CPU, RAM, disk, IO) для VM1/VM2/VM3.

7. Финальная схема инфраструктуры​

План действий (high-level)​

1. Репозиторий​

  • Создать GitHub org repo (monorepo).
  • Перенести Laravel в backend/.
  • Перенести Next в client/.
  • Добавить infra/ (compose, nginx, scripts, env examples).
  • Привести README + docs/ (architecture, deploy, runbook).

2. Контейнеризация​

  • Довести Dockerfile backend и client до production-готовности.
  • Сделать docker-compose.prod.yml под VM2 (app) и docker-compose.dev.yml для локалки.
  • Убедиться, что все сервисы пишут логи в stdout/stderr.

3. Nginx​

  • Подготовить edge-конфиги (VM1): site.uz и api.site.uz → прокси на VM2 по private IP.
  • Подготовить app-конфиг (VM2) для Laravel (nginx → php-fpm).
  • Добавить кеширование/заголовки для Next статики на edge.

4. База данных​

  • Развернуть MySQL нативно на VM3.
  • Настроить создание пользователя, базы, доступ только из private сети.
  • Перенести данные со старого MySQL (dump/restore).

5. Бэкапы​

  • На VM3 настроить backup job (mysqldump или xtrabackup) в отдельную директорию.
  • Настроить rsync pull на удалённый хост (offsite).

6. GitHub Actions + registry​

  • Настроить GHCR.
  • Добавить workflow сборки backend и client образов с тегом git sha.
  • Добавить workflow деплоя на VM2: pull → compose up -d → migrate → restart worker.

7. Прод окружение​

  • Поднять VM1 (edge), VM2 (app), VM3 (db) в отдельной prod subnet.
  • Закрыть публичные порты на VM2/VM3, наружу оставить только VM1.

8. Мониторинг​

  • Подключить AppSignal в Laravel.
  • Подключить мониторинг ошибок/метрик для Next (AppSignal или альтернативу).
  • Поставить простой агент метрик на VM1/VM2/VM3 + алерты по диску на VM3.

9. Переключение трафика​

  • Прогнать тестовый деплой.
  • Переключить DNS на новый edge.
  • Зафиксировать runbook “как деплоим / как откатываем / где бэкапы”.

10. После стабилизации​

  • Упростить/укрепить деплой (path-фильтры, кеши, smoke checks).
  • Только если появится реальная потребность: думать про k8s, HA, балансировку.