Это пошаговое объяснение двух простых стратегий деплоя — Blue‑Green и Canary — и зачем они нужны интернет‑магазину на белорусском VPS: минимизировать простой, снизить риск ошибок и сохранить продажи во время обновлений.
Что такое Blue‑Green и когда использовать
Blue‑Green — держать две рабочие версии приложения: текущую (blue) и новую (green). При проверке новой версии весь трафик оставляют на старой, затем плавно переключают весь трафик на новую. Подходит для небольшого интернет‑магазина одежды в Минске с пиковыми продажами в выходные.
Как сделать:
- Подготовьте на VPS две директории или два контейнера: /var/www/blue и /var/www/green, или контейнеры app_blue и app_green.
- Настройте прокси (nginx или HAProxy) с upstream на оба варианта, но с приоритетом на blue.
- Разверните новую версию в green, прогоните тесты и проверку платёжных сценариев на тестовой подсети.
- Переключите proxied‑upstream на green одним конфиг‑коммитом и reload прокси. Для отката — вернуть upstream на blue и опять reload.
Canary‑деплой: менять для части пользователей
Canary — давать новую версию небольшой доле пользователей и наблюдать метрики. Хорошо для салона красоты в Гомеле, который тестирует новый интерфейс онлайн‑записи: ошибки увидят меньше клиентов и исправление быстрее повлияет на всех.
Как сделать:
- Запустите новую версию на отдельном порту или контейнере.
- Настройте прокси так, чтобы 5–10% трафика шло на canary. Это можно сделать по cookie, по IP‑диапазону или с помощью weight в upstream.
- Собирайте логи и метрики: время ответа, ошибки 5xx, отказы платежей. Держите мониторинг минимум 24–72 часа.
- Если метрики в порядке — увеличьте долю трафика шагами 25% до 100%. Если нет — быстро переключите назад.
Деплой базы данных и схемы: как избежать простоя
Обновления схемы БД — самая частая причина простоя. Представим небольшой интернет‑магазин электроники в Бресте, где база на VPS. Неправильный миграционный скрипт может остановить приём заказов.
Как сделать:
- Разделите миграции на безопасные (создание таблиц, добавление колонок с NULL) и небезопасные (удаление колонок, изменение типов).
- Выполняйте безопасные изменения заранее. Небезопасные — делать в окне низкой нагрузки с возможностью быстрого отката.
- Используйте версионирование миграций и тест на копии БД перед применением в проде. Для аварийного отката имейте свежую резервную копию и план восстановления.
Автоматизация деплоя и ролевая интеграция
Чтобы уменьшить ручной труд и ошибки, автоматизируйте деплой. Пример: магазин косметики в Могилёве, где раз в неделю выпускают новые промо‑страницы. Автоматизация ускорит выпуск и снизит риск человеческой ошибки.
Как сделать:
- Настройте простой CI: сборка, тесты, деплой на green/canary. Для сайтов без DevOps подойдёт проверенный сценарий «CI → SFTP/SSH».
- Используйте готовые инструкции по деплою через GitHub Actions и SFTP, если нет команды DevOps: деплой через GitHub Actions и SFTP.
- Добавьте автоматические smoke‑тесты: проверка корневой страницы, корзины и оплаты после переключения.
Сценарий миграции без простоя
Если переносите магазин с другого хостинга на белорусский VPS (пример: магазин сувениров из Гродно), спланируйте DNS‑cutover и тестирование. Следуйте пошаговому плану миграции и имейте обратный путь: переезд проекта на хостинг в Беларуси без простоя.
Как сделать:
- Подготовьте окружение на новом VPS и держите старое включённым до проверки.
- Перенесите данные и прогоните тесты на внутреннем IP. Не меняйте DNS до готовности.
- В момент переключения установите короткий TTL у записей DNS заранее, чтобы ускорить обновление. После проверки верните TTL нормальным.
Типичные ошибки
- Переключение трафика без предварительных smoke‑тестов и мониторинга.
- Применение миграций БД без резервной копии и теста на копии данных.
- Отсутствие health‑checks в прокси; приложение считается живым, но возвращает ошибки.
- Большой шаг в Canary (с 0% сразу на 50%) вместо постепенного увеличения.
- Игнорирование времени кэширования CDN и браузеров при откате.
3 шага, которые можно сделать сегодня/на неделе:
- Настройте в nginx или HAProxy upstream с двумя бэкендами и health‑check; разверните копию приложения на отдельном порту.
- Добавьте в репозиторий простые smoke‑тесты и автоматический шаг в CI, который запускает их после деплоя.
- Проверьте процесс отката: выполните переключение на старую версию и прогоните сценарий восстановления базы на тестовой копии.
Полезные ссылки: деплой через GitHub Actions и SFTP, переезд проекта на хостинг в Беларуси без простоя.