Blue-green deployment: как переключать версии сайта и сохранять возможность отката
Blue-green deployment, или сине-зелёное развёртывание, — стратегия выпуска, при которой новую версию сайта готовят рядом с работающей, а затем переключают на неё пользовательский трафик. Предыдущая версия остаётся доступной для предусмотренного возврата. Это позволяет отделить установку приложения от момента, когда изменение увидят посетители.
Для бизнеса преимущество понятно: новую сборку можно проверить до переключения, а возврат не обязательно требует повторной установки старых файлов. Но два окружения не обеспечивают сохранность заказов автоматически. Если они используют несовместимые данные, разные сессии или одновременно запускают одну рассылку, проблема возникнет независимо от выбранного цвета.
Ниже разберём практическую схему для сайта услуг, магазина и веб-приложения: где проходит граница окружений, что проверять до выпуска, как учитывать фоновые задачи и при каких условиях можно вернуть трафик. Пример условный; конкретный механизм переключения зависит от инфраструктуры проекта.
Как устроен blue-green деплой сайта
В описании blue-green deployment AWS две среды содержат разные версии приложения: текущая обслуживает посетителей, а следующая подготавливается и проверяется параллельно. После подтверждения готовности меняется направление трафика. Названия blue и green условны; в следующем цикле роли могут поменяться.
В карточке выпуска указывайте не только цвет, но и точную версию, набор настроек и текущую роль. Запись «переключить на green» без идентификатора сборки опасна: название окружения сохраняется, а его содержимое меняется. Ответственный должен видеть, какая версия сейчас рабочая и какая подготовлена для следующего шага.
Новая среда отличается от обычного тестового стенда готовностью принять реальные обращения. На стенде допустимы учебные ключи и искусственная база. У кандидата на production должны быть проверены производственные подключения и разрешённые режимы, а проверочные действия должны оставаться контролируемыми. Перенос тестовой конфигурации вместе с кодом способен сломать выпуск.
В базовом варианте после приёмки команда меняет основной маршрут на новую среду. В других схемах часть трафика направляют раньше для дополнительной оценки. Такое сочетание возможно, но вопросы сравнения групп и постепенного расширения относятся к canary-процессу. Для blue-green основа — наличие подготовленных сред и управляемый переход между ними.
Что входит в два окружения, а что остаётся общим
Сначала нарисуйте границу выпуска. В простом варианте дублируются веб-приложение и его вычислительные ресурсы, а база, пользовательские файлы и очередь остаются общими. В более сложном варианте меняется сразу несколько сервисов. Чем шире граница, тем больше связей необходимо согласовать до переключения.
| Компонент | Возможная организация | Главный вопрос |
|---|---|---|
| Приложение | Два независимо запускаемых комплекта | Какие версии фактически установлены |
| База данных | Общее хранилище с совместимой схемой | Понимают ли обе версии текущие записи |
| Файлы пользователей | Общее доступное хранилище либо отдельная согласованная схема | Будет ли загруженный документ доступен после перехода |
| Сессии | Совместимое хранение и обработка состояния | Сохранится ли допустимая работа уже вошедшего пользователя |
| Фоновые процессы | Отдельно управляемые обработчики и расписания | Кто получает задания и кто имеет право запускать регулярную работу |
Общие компоненты сохраняют общие точки отказа. Две версии веб-приложения с одной базой не образуют полноценный план аварийного восстановления базы. Здесь решается задача регулярного выпуска приложения; пределы защиты от инфраструктурной аварии оцениваются отдельно.
Одинаковая архитектура окружений также не означает одинаковую производительность. Кандидат должен выдерживать предназначенную ему нагрузку, а совместная работа двух комплектов — укладываться в возможности общих ресурсов. Учтите подключения к базе, потребление памяти и обращения к внешним сервисам.
Подготовьте воспроизводимую сборку и конфигурацию
Выпускайте определённый проверенный артефакт: архив, образ или иной комплект с устойчивым идентификатором. Если после тестирования приложение заново собирается из изменившихся зависимостей, результат проверки относится уже не к тому содержимому. Сохраните связь между исходниками, сборкой и фактически запущенной версией.
Разделите настройки, которые принадлежат версии, и настройки, закреплённые за окружением. Например, флаги поведения могут меняться вместе с выпуском, а служебные адреса и права — определяться отдельно. В документации Azure App Service о переключении слотов явно различаются параметры, которые перемещаются при swap, и параметры, которые остаются привязанными к слоту. У своей платформы нужно проверить конкретные правила.
Не записывайте значения секретов в карточку релиза. Достаточно указать их назначение, источник получения и версию набора там, где это поддерживается. Проверьте права нового окружения: оно может успешно запускаться и одновременно не иметь доступа к нужному хранилищу или очереди.
Укажите, что изменяется при переключении маршрута, а что требует отдельного действия. Нельзя считать переносом всей конфигурации одну команду балансировщика. Это особенно важно для расписаний, фоновых обработчиков, вебхуков и сервисных аккаунтов.
Как обращаться с общей базой и новыми заказами
При общей базе обе версии читают и изменяют текущее состояние. Поэтому старая версия должна понимать данные, созданные новой, пока сохраняется возможность возврата. Проверка запуска на прежней копии базы этого не доказывает: нужно испытать предусмотренное взаимодействие с новыми записями и состояниями.
Например, если новый код сохраняет статус заказа, которого прежний обработчик не знает, обратный маршрут не вернёт работоспособность такого заказа. Аналогичный риск возникает при изменении формата документа, значения поля или сообщения в очереди. Совместимость касается не только названий таблиц.
Подход expand-and-contract, описанный Prisma, позволяет разделить добавление совместимых структур и последующее удаление старых. Для blue-green важен принцип: разрушительные изменения не совмещают с периодом, когда прежняя версия ещё должна работать. Подробный порядок миграции зависит от базы и приложения.
Две независимые копии базы не устраняют эту задачу. Если посетители продолжают создавать заказы на текущем сайте, подготовленная ранее копия устаревает. После переключения данные начинают меняться уже на другой стороне, и возврат требует согласованного переноса состояния. Это отдельная архитектура переключения данных, которую нельзя заменить копированием каталога сайта.
Не восстанавливайте прежний снимок поверх текущей базы ради возврата приложения. Новые обращения должны остаться доступными и получить корректную обработку. Если совместимость потеряна, обычный обратный маршрут блокируется, а команда выбирает подготовленный способ исправления.
Что произойдёт с сессиями, корзинами и открытыми страницами
Проверьте путь посетителя, который начал работу до выпуска и продолжает после него. Его браузер может хранить старый JavaScript, cookie и содержимое корзины. Новый сервер должен корректно обработать предусмотренный запрос либо предложить понятное безопасное продолжение, не теряя уже подтверждённых действий.
Сессии должны быть доступны и понятны обеим версиям в согласованной области. Если состояние хранится только в памяти старого процесса, переход может завершить вход пользователя. Привязка клиента к одному экземпляру иногда отложит проблему, но не заменяет проверку перехода и завершения работы старой стороны.
Не удаляйте старые статические ресурсы сразу после выпуска. Уже открытая страница может запросить файл прежней сборки позже. Для файлов с версионированными именами определите срок доступности, подходящий жизненному циклу клиента и политике кеширования. Это отдельное условие завершения релиза.
Загрузка пользовательского документа также должна переживать допустимый переход. Проверьте место хранения, права и видимость результата новой версией. Копия приложения без актуальных загруженных файлов не является готовой заменой рабочей среды.
Почему воркеры и расписания переключаются отдельно
Маршрут HTTP-запросов не определяет, какой процесс читает очередь или запускает ежедневную задачу. Если оба окружения включат одно расписание, рассылка или выгрузка может выполниться дважды. Если оба отключат обработчики, новые заказы будут сохраняться без дальнейшего исполнения.
Составьте перечень фоновых задач и назначьте для каждой допустимого исполнителя. Для регулярного запуска нужен согласованный механизм единственного владельца либо другая предусмотренная защита от повторного эффекта. Два одинаковых названия cron-задач в разных окружениях такой защитой не являются.
Если старые и новые воркеры временно читают общую очередь, они должны понимать допустимые форматы сообщений. Новая версия не должна отправлять задания, которые ещё работающий старый потребитель не способен обработать. Укажите, когда прекращается получение новой работы старой стороной и как завершается уже полученная.
Отдельно учитывайте долгие операции и входящие события поставщиков. Обратное переключение сайта не отменит внешнее письмо, платёж или созданную запись. Устойчивые идентификаторы и сверка результата нужны независимо от цвета окружения.
Как проверить новую среду до переключения посетителей
Подтвердите точную версию, готовность приложения, производственные подключения в разрешённых границах и ключевой пользовательский путь. Проверка должна адресно попадать в кандидата: успешный ответ публичного домена, который всё ещё ведёт на старую среду, не проверяет новый выпуск.
Разделите подробные испытания на изолированном стенде и проверку производственного кандидата. Последняя не должна случайно отправлять сообщения клиентам или создавать реальные списания. Используйте предусмотренные тестовые записи, контролируемые получатели и проверки чтения там, где полноценное действие пока недопустимо. Границы покрытия запишите явно.
Прогрейте необходимые ресурсы: загрузку приложения, соединения и предусмотренные кеши. Затем подтвердите готовность всех экземпляров, которые будут принимать трафик. Один отвечающий процесс не доказывает, что остальные запустились с нужными настройками. Прогрев тоже потребляет общие ресурсы, поэтому его проводят с согласованной интенсивностью.
Заранее назначьте критерии продолжения и остановки. Например, выпуск нельзя переключать, если новая версия не сохраняет допустимое обращение в разрешённом сценарии, не подтверждена совместимость данных или неизвестно, какие воркеры запущены. Открытый порт не закрывает эти условия.
Как выполнить переключение трафика
Выберите точку маршрутизации: балансировщик, прокси или штатный механизм платформы. Сохраните текущие правила и убедитесь, что ответственный понимает область изменения. Если используются несколько входных путей, проверьте каждый: основной домен, API, входящие уведомления и другие маршруты могут переключаться разными механизмами.
Изменение правила для новых запросов не обязательно завершает существующие соединения. Долгий запрос, потоковая передача или WebSocket могут продолжить работу на старой стороне. Предусмотрите период завершения, новые подключения и поведение клиента при необходимости переподключиться. DNS как точка переключения дополнительно зависит от кеширования записей и не обеспечивает одновременного перехода всех посетителей.
Не считайте отсутствие нового трафика разрешением немедленно уничтожить старые процессы. Измерьте активные операции и выполните предусмотренное завершение. Конкретные свойства платформы тоже важны: документация Azure App Service предупреждает, что перезапуск прежних экземпляров после swap может прервать долгие операции. Поэтому готовая кнопка переключения не снимает требования к приложению.
После изменения маршрута проверьте публичный путь, фактическую версию на ответивших экземплярах и контрольный результат. Сравните наблюдения с исходным уровнем. Снижение ошибок старой среды ничего не доказывает, если она просто перестала получать обращения, а новая ещё не наблюдается.
Сохраняйте точное время изменения маршрута и идентификатор выпуска рядом с результатами проверок. Периодическое наблюдение подтверждает состояние в моменты запусков и может пропустить короткую ошибку между ними. Журналы запросов и результаты пользовательских операций дополняют эту картину, особенно для перехода уже открытых сессий.
Когда возврат на прежнюю версию остаётся допустимым
В материале AWS о безопасности rollback подчёркивается совместимость чтения и записи между версиями. Для blue-green это определяет реальное окно возврата: старая среда должна уметь обслуживать текущее состояние, а не только оставаться включённой.
Заранее зафиксируйте условия обратного переключения: наблюдаемый дефект, исправность прежней среды, совместимость данных и доступность нужных зависимостей. Если эти условия выполняются, команда возвращает согласованные маршруты, проверяет фактическую версию и отдельно оценивает операции, затронутые новым кодом.
Если новая версия записала несовместимые состояния, обычное обратное переключение блокируют. Уже совершённые внешние действия требуют сверки и, при необходимости, отдельного исправления. Они сами по себе не запрещают возврат совместимой версии для ограничения новых ошибок, если остальные условия безопасности выполнены. Не следует продолжать переключения туда и обратно только потому, что оба окружения отвечают на health check.
У окна возврата должны быть владелец и условие окончания. Например, его закрывают после принятия выпуска и перед удалением прежнего формата данных. Срок определяется характером изменений и наблюдений. Произвольное ожидание нескольких минут не доказывает отсутствие редко проявляющегося дефекта.
Учебный пример выпуска новой формы заявки
Представим сайт услуг. Среда А обслуживает версию R17, а среда Б подготовлена для R18. Обе версии используют общую базу и понимают одинаковые состояния обращения. Изменяется форма, а формат сохранённой заявки и интерфейс фонового обработчика остаются совместимыми. Это условие учебного примера, которое в реальном проекте необходимо проверить.
| Этап | Состояние | Подтверждение |
|---|---|---|
| Подготовка | R17 принимает посетителей; R18 доступна для контролируемой приёмки | Известны версии, настройки, права и владельцы фоновой работы |
| Приёмка | R18 проходит разрешённый сценарий формы и проверку совместимости | Зафиксированы результат, тестовые ID и ограничения покрытия |
| Переход | Новый основной трафик направлен на Б; текущие операции А завершаются по правилу | Публичный маршрут обслуживает нужную версию, данные продолжают сохраняться |
| Наблюдение | А сохраняется как подготовленный вариант возврата | Проверены ошибки, задержки и завершение обработки обращений |
| Завершение | R18 принята, дальнейшая судьба А определена | Окно возврата закрыто явно, журналы и комплект релиза сохранены |
Допустим, после перехода обнаружена ошибка отображения формы на согласованном мобильном сценарии. Если R17 по-прежнему совместима с текущими данными, команда может вернуть маршрут на А. Обращения, уже сохранённые R18, остаются в общей базе и должны обрабатываться корректно; возвращать базу к состоянию до выпуска не требуется.
Если же выяснилось, что R18 создала несовместимые данные, предпосылка этого сценария нарушена. Та же команда переключения перестаёт быть безопасным решением. В журнале фиксируют нарушение условия, затронутые операции и выбранный план исправления. Такая остановка полезнее формального выполнения заранее написанной команды.
Как принять релиз и освободить старое окружение
После перехода сохраните период наблюдения, подходящий критичным функциям и обычному потоку обращений. Оценивайте результат пользователей, а не только число работающих процессов. Отложенная передача заявки или выпуск документа могут проявить проблему позже открытия страницы.
- Нужная версия фактически обслуживает согласованные публичные маршруты.
- Контрольные действия имеют подтверждённый результат в допустимых границах проверки.
- Новые записи доступны, фоновые операции выполняются, повторные действия не обнаружены.
- Сессии и открытые до выпуска страницы проходят предусмотренный переход.
- Известно, какие запросы и задачи ещё остаются на прежней стороне.
- Условия возврата остаются действительными либо их завершение явно принято.
- Настройки наблюдения, получатели и рабочие инструкции соответствуют новой роли сред.
Старое окружение удаляют или подготавливают к следующему выпуску после выполнения условий завершения. При этом сохраняют нужный артефакт, конфигурационную информацию и журнал выпуска. Наличие исходников не гарантирует возможность быстро собрать тот же комплект с теми же зависимостями.
Проверьте также стоимость ожидания: две активные среды, лишние подключения и фоновые процессы не должны оставаться включёнными без владельца. Период сохранения старой стороны должен иметь обоснование и точку пересмотра, а не автоматически превращаться в постоянное удвоение инфраструктуры.
Когда стратегия полезна и с чего начать
Blue-green особенно полезен, когда подготовка приложения занимает заметное время, выпуски повторяются и маршрутизацией можно управлять отдельно от установки кода. Решение стоит оценивать вместе с поддержкой данных и стоимостью двух готовых сред. Для небольшого сайта со множеством несогласованных локальных правок первым шагом может стать воспроизводимая сборка и понятный процесс выпуска.
Начните с одного ограниченного изменения и учебного переключения. Попросите подрядчика показать, какая версия отвечает, где находятся новые данные, кто выполняет фоновые задачи и какое конкретное условие запрещает возврат. Эти ответы позволяют оценить готовность процесса лучше, чем наличие двух одинаковых панелей управления.
Подключите SiteGuard для внешнего HTTP-контроля доступности сайта после переключения. Версию приложения, сохранность данных и результат операций подтверждайте средствами своей инфраструктуры.