Изначально я пилил инструмент совершенно под другие задачи — закрывать админки и внутренние сервисы от ботов и посторонних глаз. Но в процессе работы над архитектурой меня осенило. Встроенный механизм переопределения DNS (DNS Override) можно применить для тестирования миграции сайтов. И главное — это закрывает постоянную «головную боль». Как дать протестировать новый сервер нетехническим людям (клиентам, маркетологам, контент-менеджерам) без танцев с бубном вокруг их компьютеров.
В чём обычно проблема с проверкой перед переездом
Сценарий классический, сайт скопирован на новый сервер, база перенесена, конфиги настроены. Прежде чем менять DNS-записи и пускать живых пользователей, нужно убедиться, что всё работает. На бумаге легко, а на практике начинается выбор между неудобным и рискованным.
Если прописывать новый IP в /etc/hosts, то всё честно. Домен настоящий, SSL валиден, абсолютные ссылки не ломаются. Но попробуйте объяснить клиенту или контент-менеджеру, как открыть «Блокнот» от имени администратора на Windows или подправить файл через терминал на Mac, а потом ещё сбросить кэш DNS. На мобильных устройствах это вообще практически невозможно без рут-прав.
Альтернатива — временный поддомен вроде new.example.com. Но тут мы тестируем совсем не то, что поедет в прод. Лезут проблемы с абсолютными ссылками, отваливаются OAuth-авторизации, а CMS вроде WordPress или Bitrix могут начать выдавать редиректы и mixed content.
Можно ещё поднять локальный DNS в офисе, настроить прокси вроде Charles или переключать Origin в CDN, но всё это упирается либо в сложность настройки для обычного пользователя, либо в риск задеть живой трафик. Ни один привычный метод не даёт одновременно боевой домен, простую передачу доступа всей команде и полную безопасность для прода.
Как сработала идея с DNS Override
Архитектура нашего сервиса устроена просто. Шлюз с встроенным DNS-резолвером и компактное браузерное расширение у пользователей. Расширение перенаправляет трафик указанных доменов через шлюз (используя стандартные API браузеров), а весь остальной интернет пускает напрямую.
Идея оказалась простой, если в настройках шлюза указать «для домена example.com использовать IP нового сервера», мы получаем идеальный изолированный стенд.
При этом домен остаётся настоящим, SSL-сертификат работает, CMS не путается в адресах, а обычные посетители сайта продолжают спокойно ходить на старый сервер. Более того, расширение выключается в один клик. Можно буквально за секунду переключаться между старой и новой версией, сравнивая вёрстку и поведение (даже F5 нажимать не нужно, страница автоматически перегружается).
Главный профит тут достаётся именно нетехническим участникам процесса. Разработчику больше не нужно проводить созвоны, объясняя клиенту, QA или маркетологу, как подменить IP в системе или поставить корневой сертификат. Человеку просто передаётся короткий токен. Он вставляет его в расширение — и в его браузере боевой домен мгновенно начинает открываться с нового сервера.
Итог
Иногда вспомогательные функции дают функционал, заслуживающий отдельного самостоятельного юзкейса. Мы сделали резолвер для доступа к внутренним сервисам, а получили удобный «тумблер реальности» для миграций, который не пугает клиентов и нетехнарей.
Сегодня мы как раз запустились с L7 Admin Guard на Product Hunt. Проверить, насколько это удобно, вы можете на нашей демо-странице — без регистрации, достаточно просто установить расширение из стора Chrome/Firefox и ввести демо-токен.
ссылка на оригинал статьи https://habr.com/ru/articles/1068042/