Blue/Green через DNS: безотказные деплои для веб‑проектов

Blue/green deploy уже давно стал базовым паттерном для серьёзных веб‑проектов: вы держите две версии приложения (blue и green) и переключаете трафик между ними почти без простоя. Чаще всего в примерах фигурируют балансировщики уровня L7 или сервис‑меши, но на практике многим проще и дешевле сделать переключение через DNS.

У такого подхода есть как плюсы (простота, минимум инфраструктуры), так и подводные камни: кеши резолверов, долгоживущие TCP‑соединения, особенности мобильных сетей. В этой статье разберём, как аккуратно организовать blue/green deploy через DNS для веб‑приложений и статических сайтов, на что смотреть в настройках зон и как готовить план отката.

Что такое blue/green deploy и зачем тут DNS

В классическом blue/green у вас есть два независимых окружения:

• Blue — текущая «живая» версия продакшена.
• Green — новая версия, которую вы готовите к вводу в строй.

Переезд трафика с blue на green осуществляется атомарно с точки зрения пользователя: за минимальное время, без долгого окна недоступности и с возможностью откатиться назад.

Когда нет своего балансировщика, Kubernetes, Envoy, Nginx с хитрым конфигом и прочих радостей, очевидный рубильник — DNS. Запись A/AAAA или CNAME указывает на blue‑окружение, а после релиза вы меняете её на green. Визуально схема выглядит просто:

Пользователь → DNS → IP (blue/green) → веб‑сервер → приложение или статический контент.

Вопрос в том, как сделать так, чтобы:

• часть клиентов не застряла надолго на старом blue;
• не получить микс версий (половина запросов — на старую API, половина — на новую) на чувствительных эндпойнтах;
• иметь понятный и быстрый откат, если green внезапно ломается под боевой нагрузкой.

Основные паттерны blue/green через DNS

На уровне DNS можно реализовать несколько вариантов blue/green. Они отличаются сложностью и степенью контроля.

1. Переключение A/AAAA‑записи (простое)

Самый прямолинейный подход: у домена есть одна A (и/или AAAA) запись, указывающая на IP blue‑окружения. При релизе вы меняете IP на адрес сервера green. Примерно так:

example.com.  60  IN  A  203.0.113.10   ; blue
; после релиза
example.com.  60  IN  A  203.0.113.20   ; green

Плюсы:

• минимум сущностей, легко объяснить и поддерживать;
• подходит для маленьких проектов и статических сайтов.

Минусы:

• резолверы и локальные кеши могут держать старый IP дольше ожидаемого;
• сложно устроить поэтапный перевод трафика (канареечный rollout).

2. Переключение CNAME (рекомендуемый базовый вариант)

Более гибкая схема — вынести blue/green на поддомены и переключать CNAME верхнего домена. Логика:

• blue.example.com → IP текущей прод‑версии;
• green.example.com → IP новой версии;
• www.example.com CNAME → либо на blue.example.com, либо на green.example.com.

DNS‑зона может выглядеть так:

www.example.com.   60  IN  CNAME  blue.example.com.
blue.example.com. 300  IN  A      203.0.113.10
green.example.com.300 IN  A      203.0.113.20

При переключении вы меняете только одну строку:

www.example.com.   60  IN  CNAME  green.example.com.

Преимущества:

• можно держать blue и green в одной зоне и заранее прогревать green;
• откат — это обратно поменять CNAME;
• легче автоматизировать в CI/CD (одна запись для изменения).

Минус: на самом apex‑домене (example.com) далеко не все DNS‑провайдеры позволяют CNAME, поэтому для корневого домена нужно думать отдельно (ALIAS/ANAME или несколько A‑записей).

3. Многозначные A‑записи с разным весом (псевдо‑канарейка)

В самом базовом DNS нет понятия веса, но поведение клиентов при наличии нескольких A‑записей получается похоже на распределение трафика:

example.com.  60  IN  A  203.0.113.10   ; blue
example.com.  60  IN  A  203.0.113.20   ; green

Большинство резолверов вернёт оба IP в случайном или «перемешанном» порядке, а клиенты возьмут первый адрес. Получается нестрогий split‑traffic между blue и green, зависящий от DNS‑стека пользователей.

Обычно этот приём используют:

• для плавного ввода green под частью нагрузки;
• как промежуточный этап перед полным переключением CNAME/A;
• вместе с мониторингом ошибок, чтобы успеть заметить проблемы.

Минусы серьёзные: нет детального контроля долей трафика по регионам, кеширование сильно влияет на поведение, и «канареечный» эффект выходит довольно размытым.

Если ваш проект живёт на одном сервере или паре машин, blue/green через DNS отлично сочетается с отдельными окружениями на VDS: можно держать две независимые прод‑версии и тестировать новую сборку без риска для боевого трафика.

Роль TTL: как не застрять на старой версии

TTL DNS‑записей — ключевой параметр для blue/green через DNS. Ошибка №1 — менять IP или CNAME, оставив TTL в час или сутки, а потом удивляться, что половина мира продолжает ходить в старый прод.

Важно понимать:

• TTL — это рекомендация для кешей, а не жёсткая гарантия;
• некоторые резолверы минимизируют TTL (например, всё <60 секунд поднимают до 60);
• некоторые корпоративные DNS и провайдеры наоборот не уважают TTL и могут держать записи дольше.

Практический подход:

1. В обычной жизни держать TTL достаточно большим (примерно 300–1800 секунд), чтобы снизить нагрузку на DNS и ускорить первую загрузку сайта.
2. Перед релизом blue/green за 1–2 часа (или больше) уменьшить TTL для конкретных записей, которые будете переключать, до 30–60 секунд.
3. Подождать время большее, чем старый TTL, чтобы старые кеши гарантированно обновились.
4. Выполнить переключение и понаблюдать какое‑то время.
5. Вернуть TTL обратно на более комфортное значение.

То есть работа с TTL — это заранее спланированная двухэтапная операция, а не «ой, давайте прямо сейчас перед релизом уменьшим TTL с суток до минуты».

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Дизайн зоны под blue/green: что продумывать заранее

Чтобы blue/green через DNS не превратился в хаос, зону лучше спроектировать так, чтобы:

• переходы blue → green и обратно были минимальными по числу правок;
• можно было проверить новую версию по тем же доменам или почти тем же;
• отдельные сервисы (API, админка, статика) могли переключаться асинхронно.

Именование поддоменов

Хорошая практика — явно закодировать цвет окружения в имени:

• blue.example.com, green.example.com;
• blue-api.example.com, green-api.example.com;
• blue-admin.example.com, green-admin.example.com.

При этом пользователи ходят на стабильные имена:

• www.example.com → CNAME на blue/green;
• api.example.com → CNAME на blue/green для API;
• admin.example.com → CNAME на blue/green для админки.

Такой подход позволяет:

• переключать фронтенд отдельно от API;
• оставить админку на старой версии чуть дольше, если нужно;
• делать релиз только одной части системы.

Отдельные домены для окружений

Для более сложных систем иногда имеет смысл разнести окружения по разным доменам или подзонам:

• prod.example.com — текущая версия;
• next.example.com — новая версия;
• пользовательский домен example.com CNAME → на один из них.

Плюс в том, что вы можете в любой момент открыть next.example.com для QA, клиента или тестовой аудитории, не мешая основному трафику.

Если используете много доменов под разные регионы или бренды, продумайте стратегию blue/green для них заранее. Здесь полезно совместить DNS‑паттерны с аккуратной регистрацией доменов для продакшена и тестовых окружений, чтобы не путаться и не терять важные имена.

Связка DNS blue/green и приложений: сессии, кеши, БД

DNS переключает только то, куда приходят запросы. Но чтобы blue/green был действительно безболезненным, приложение и инфраструктура под ним должны быть к этому готовы.

Сессии и авторизация

Если пользователи при переключении оказываются то на blue, то на green, важно, чтобы:

• сессии были общими (хранились в общем Redis/БД) либо stateless (JWT, подписи в cookie);
• секреты для подписи JWT и cookie были синхронизированы между версиями;
• один и тот же пользователь мог безболезненно открыть страницу, созданную на blue, и догрузить ресурсы с green.

Если это не так, при DNS‑переключении вы получите массовые разлогины, сломанные корзины в интернет‑магазине и прочие приятные сюрпризы.

База данных и миграции схемы

Ещё один важный момент — миграции схемы БД:

• если blue и green одновременно работают с одной БД, миграции должны быть обратимо совместимыми (поддерживать и старый, и новый код в течение переходного окна);
• если green использует другую БД (например, реплику с другими настройками), нужно продумать синхронизацию и момент переключения записи;
• совместимость API и схемы данных критична, так как часть клиентов может ещё ходить на старые эндпойнты.

Частая DevOps‑практика: сначала накатываются миграции, которые не ломают старую версию (добавление полей/индексов, nullable‑колонки), потом включается новая версия, и лишь после того, как вы уверены в успехе, проводится «чистка» схемы.

Кеши и CDN

Blue/green через DNS сильно усложняется, если сверху у вас стоит CDN с агрессивным кешированием:

• CDN часто держит свои IP и кеши независимо от TTL в вашей зоне;
• даже после DNS‑переключения CDN может продолжать ходить в старый бэкенд ещё какое‑то время;
• кешируемые ответы могут смешиваться между версиями, если вы не меняете версии ассетов или статических путей.

Решения:

• использовать версиирование статики (например, /static/v42/...), чтобы новая версия сразу шла по новым URL;
• на время релиза уменьшать TTL и в настройках CDN, либо явно инвалидацировать кеши;
• по возможности сначала проверить переключение на меньшем поддомене или отдельном PoP.

Пошаговый сценарий blue/green через DNS

Соберём всё вместе и опишем типовой процесс, который применим и для небольших PHP‑сайтов, и для сложных веб‑приложений.

1. Подготовка green‑окружения

До любого изменения DNS вы должны иметь полностью работающее green‑окружение:

• сервер(а) с веб‑приложением подняты и настроены;
• сертификаты TLS установлены и проверены (если используете HTTPS);
• доступ к БД отлажен, миграции применены;
• доступны отдельные технические домены, например green.example.net или green.example.com — чтобы QA и разработчики могли прогнать smoke‑тесты.

2. Уменьшение TTL заранее

Выбираете записи, которыми будете управлять при релизе (чаще всего это CNAME для www и A/AAAA для apex), и:

• за 1–2 часа (или больше, в зависимости от текущего TTL) снижаете TTL до 30–60 секунд;
• фиксируете время, когда было сделано изменение, и ожидаете не меньше, чем старый TTL, прежде чем делать само переключение.

3. Финальное тестирование green

Пока TTL «прогревается», вы можете:

• прогнать интеграционные тесты по тех.домену green;
• часть команды использовать зашифрованное имя в /etc/hosts, указывая основной домен на IP green для ручного тестирования;
• сравнить логирование и метрики green с blue под тестовой нагрузкой.

4. Переключение записи

Когда время вышло и вы уверены в green, меняете запись. Для CNAME это одна строка, для A/AAAA — IP‑адреса. Лучше делать это через API DNS‑провайдера или автоматизированный скрипт, чтобы избежать ошибок руками.

После этого в течение времени, равного новому TTL (30–60 секунд), большая часть клиентов уже должна начать попадать на green‑окружение.

5. Мониторинг переходного периода

После переключения:

• наблюдаете за метриками ошибок (5xx, таймауты, специфичные бизнес‑ошибки) на green;
• следите за временем отклика и нагрузкой на базу данных;
• смотрите логи blue, чтобы понять, сколько трафика там ещё осталось (по IP или Host‑заголовку).

Обычно информативно построить графики «количество запросов на blue и green» по часу после релиза. Как только трафик на blue упадёт до небольших значений, можно думать об отключении.

6. Возврат TTL в норму

Если всё стабильно, через какое‑то время (30–60 минут, возможно, больше) можно вернуть TTL на переключённых записях в более крупное значение, чтобы снизить нагрузку на DNS и улучшить общую производительность.

7. Отключение blue

Не торопитесь сразу выключать blue‑окружение: часть медленных клиентов может ещё какое‑то время стучаться по старым IP, особенно если где‑то есть жёстко прописанные адреса, старые мобильные сети и т.п.

Обычно оставляют blue ещё на несколько часов или даже дней, но:

• отключают с него фоновую обработку задач, чтобы не дублировать cron/очереди;
• обновляют конфиг так, чтобы активные пользовательские сессии могли нормально завершиться;
• на уровне приложений добавляют метку в логи, что это «старое окружение».

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

Откат: что делать, если green не выдержал

Главный плюс blue/green — быстрый и понятный rollback. При DNS‑подходе откат — это такое же изменение записей, только в обратную сторону:

• если вы переключали CNAME, возвращаете его на blue.example.com;
• если меняли IP, возвращаете старый IP blue;
• TTL на время отката также стоит держать минимальным.

Однако возможны эффекты:

• часть клиентов в течение какого‑то времени будет ходить и на green, и на blue;
• если green успел изменить данные в БД в несовместимом формате, откат может быть уже не столь тривиален.

Поэтому для критичных систем важно заранее продумать:

• «безопасные» миграции БД, допускающие откат к старому коду;
• версионирование API (например, /v1 и /v2), чтобы старые клиенты могли жить отдельно;
• дополнительные проверки перед тем, как вообще начинать тянуть основной трафик на green.

Частые ошибки и грабли

Сводка типичных проблем, с которыми сталкиваются при blue/green через DNS:

• Не тронули TTL. Переключили IP, а значительная часть трафика ещё часами ходит на старое окружение.
• Смешали версии API. Клиенты получают старый фронтенд, который стучится в новый API или наоборот. Если протоколы несовместимы, всё падает.
• Не учли CDN и кеши. DNS переключили, а CDN ещё полдня ходит на старые бэкенды.
• Отключили blue слишком рано. Есть остаточные запросы, особенно из мобильных приложений, IoT и других «долго живущих» клиентов.
• Ручные правки без контроля версий. Зону меняют в веб‑панели руками, никто не помнит, как было «до». Откат превращается в квест.

Автоматизация blue/green через DNS

Хотя принцип прост, делать всё руками при каждом релизе — путь к ошибкам. Стоит автоматизировать хотя бы базовые операции:

• изменение TTL перед релизом и после него;
• переключение CNAME или A/AAAA через API DNS‑провайдера;
• создание служебных blue и green записей с нужными IP;
• запись факта переключения в лог или чат команды (кто, когда, с какого на какой цвет переключил).

В CI/CD‑пайплайне это обычно выглядит как отдельный шаг «Switch DNS blue → green» с возможностью вручную запустить обратный шаг «Rollback DNS to blue». Важно предусмотреть защиту от дурака: например, запретить запускать несколько переключений одновременно или требовать подтверждения.

Когда DNS‑blue/green подходит, а когда лучше балансировщик

DNS‑подход хорош, когда:

• инфраструктура простая: один‑два сервера, нет сложных балансировщиков;
• нет строгих требований к мгновенному (в пределах секунд) переключению;
• система в целом толерантна к тому, что некоторое время часть клиентов будет на старом окружении.

Лучше использовать L7‑балансировщик или Ingress‑контроллер, если:

• нужно точное управление долями трафика (10%, 20%, 50% на новую версию и т.д.);
• надо быстро вернуть всё обратно в течение секунд при малейшей проблеме;
• приложение критично к смешению версий и требует строгого роутинга по cookie, заголовкам, регионам;
• у вас десятки доменов и поддоменов, и крутить DNS для каждого неудобно.

Тем не менее для огромного количества «обычных» веб‑проектов DNS blue/green остаётся самым простым и достаточным способом организовать zero‑downtime релизы, особенно если вы заранее продумали TTL, подготовили зону и позаботились о возможном откате.

Итоги

Blue/green deploy через DNS — это не магия, а аккуратная работа с зонами, TTL и инфраструктурой приложения. Ключевые идеи:

• выделяйте отдельные имена для blue и green и переключайте над ними CNAME или A/AAAA;
• управляйте TTL заранее, а не в момент релиза;
• готовьте приложение (сессии, БД, кеши) к временному сосуществованию двух версий;
• автоматизируйте изменения DNS и фиксируйте историю переключений;
• всегда имейте план rollback, который реально протестирован.

С таким подходом даже без сложных балансировщиков можно построить надёжный процесс обновлений, минимизировать даунтайм и перестать бояться релизов «в часы пик».