Эволюция dev-окружений: как NGENIX перешел от «виртуалок» к vCluster
В NGENIX мы постоянно совершенствуем процессы разработки, чтобы новые фичи быстрее доходили до пользователей. Несколько лет назад мы столкнулись с проблемой: существующая система dev-окружений не выдерживала требований по масштабируемости, удобству для разработчиков и безопасности. Как мы решили эти задачи с помощью Kubernetes и vCluster, рассказал заместитель технического директора по эксплуатации NGENIX Павел Козлов на DevOpsConf 2025. В этом материале — основные выводы.
Делимся с вами основными тезисами Павла Козлова:
➡️ почему мы решили перестроить dev-окружения;
➡️ эпоха виртуальных машин: в чем были ограничения;
➡️ переход на Kubernetes: первый шаг к автоматизации;
➡️ как vCluster помог нам упростить управление окружениями;
➡️ что мы получили от нового подхода;
➡️ запись выступления Павла с DevOpsConf 2025.
Почему мы задумались о перестройке dev-окружений
Мы стали развивать крупнейшую в России распределенную облачную платформу для защиты и ускорения сайтов и веб-приложений задолго до того, как глобальные игроки столкнулись с ограничениями на российском рынке.
Наши сервисы и технологии создавались с фокусом на локальные особенности: русскоязычную документацию, оперативную техническую поддержку и широкую географию узлов инфраструктуры в России и СНГ.
Сегодня платформа NGENIX — по сути российский аналог Cloudflare. Чтобы обеспечивать доступность, безопасность и высокую скорость загрузки сайтов и веб-страниц, наша команда регулярно выпускает новые продукты и улучшает их. В то же время мы придерживаемся высоких стандартов информационной безопасности в процессах разработки.
Несколько лет назад мы столкнулись с проблемой: существующая инфраструктура dev-окружений затрудняла быстрый выпуск обновлений. Разворачивание окружений занимало слишком много времени, а сами окружения часто отличались от продакшена — в результате могли возникнуть проблемы на этапе деплоя. Стандарты ИБ становились всё строже, и мы хотели применять такие же практики для dev-инфраструктуры.
Чтобы устранить эти ограничения, мы полностью пересмотрели подход к подготовке dev-окружений. Ниже — наш путь.
Шаг 1. Эпоха виртуальных машин: главные ограничения
Изначально мы использовали виртуальные машины (виртуалки) на bare-metal-серверах. Они применялись для создания временных окружений, где разработчики могли безопасно тестировать изменения перед релизом. Каждое dev-окружение представляло собой набор виртуалок, которые вручную настраивались под конкретные задачи.
Проблемы этого подхода:
- Слабая воспроизводимость — если один разработчик менял что-то в окружении, другой уже не мог им пользоваться без сбоев.
- Очереди и календари — инженеры заранее «бронировали» виртуалки, что замедляло работу.
- Ошибки на продакшене — из-за различий между dev и prod окружениями баги выявлялись слишком поздно.
Мы пытались автоматизировать процессы с помощью собственных скриптов и шаблонов, но этот подход лишь частично решал проблему. Требовалась более гибкая и масштабируемая архитектура.
Шаг 2. Переход на Kubernetes
Следующим этапом стал переход на Kubernetes. Он дал нам возможность унифицировать dev-окружения и существенно сократить время их развертывания. Однако сам переход оказался непростым.
До этого разработчики работали с виртуалками напрямую по SSH: подключались к стендам, вручную устанавливали нужные версии ПО, тестировали изменения. Kubernetes требовал совершенно иного подхода. Теперь для развертывания окружений и приложений нужно было готовить декларативные манифесты, управлять инфраструктурой как кодом. Такой процесс был менее привычен для части команды.
Параллельно мы стремились повысить уровень информационной безопасности в рамках текущих возможностей и ограничений. Например, в Kubernetes права доступа необходимо было настраивать более гибко и точно, чтобы ограничить возможность влиять на хостовый кластер или соседние окружения. Появились вопросы изоляции сетей и управления конфиденциальными данными внутри кластера. Все это требовало перестройки как технических решений, так и привычных практик работы команды.
Мы начали использовать «гибридные» контейнеры: в образы добавляли SSH-серверы, shell-клиенты и копии баз данных. Это позволило сохранить привычный интерфейс для разработчиков. Разработали собственный инструмент stagectl, который автоматизировал создание namespace’ов, деплойментов и проброс SSH-портов. Создали внутреннюю платформу StageX — надстройку над Kubernetes, где каждое окружение представляло собой отдельный namespace с предустановленными сервисами.
Мы увидели положительные сдвиги, прибегнув к этому решению. Время развертывания стендов сократилось до 5–6 минут, а dev-окружения стали ближе к продакшену — ошибок при деплое стало меньше.
Но оставались вопросы масштабируемости и безопасности. Мы поняли, что требуется более строгий контроль прав и изоляции в соответствии с политиками ИБ.
Шаг 3. vCluster: изоляция, безопасность и экономия ресурсов
Чтобы обеспечить полную изоляцию окружений, повысить безопасность и при этом сохранить скорость разработки, мы внедрили vCluster — инструмент для запуска виртуальных Kubernetes-кластеров внутри одного физического.
Технически vCluster разворачивается в отдельном namespace и состоит из виртуального API-сервера (например, на базе K3s или K8s) и компонента синхронизации (syncer), который отслеживает изменения и синхронизирует их с хостовым кластером. В результате разработчики получают полные права администратора внутри своего собственного vCluster. При этом они не могут влиять на другие окружения или на общий (хостовый) кластер. Дополнительно мы ограничили сетевые взаимодействия между vCluster’ами с помощью сетевых политик, что позволило ещё больше повысить изоляцию и безопасность.
Для управления и интеграции vCluster мы стали использовать ArgoCD. При создании vCluster автоматически генерируется kubeconfig, который регистрируется в ArgoCD. Управление окружениями осуществляется через ApplicationSet, что позволяет централизованно и удобно развертывать и обновлять dev-окружения.
После внедрения vCluster мы получили ряд важных результатов:
- добились полной изоляции dev-окружений без ущерба для скорости работы разработчиков;
- сохранили баланс между удобством разработки и строгими требованиями информационной безопасности;
- значительно снизили нагрузку на инфраструктуру по сравнению с прежним подходом на базе виртуальных машин.
Итоги: что мы получили от нового подхода
Переход от виртуальных машин к Kubernetes и внедрение vCluster стали для нас важными шагами в развитии внутренних процессов разработки. За несколько лет мы смогли полностью изменить подход к созданию dev-окружений: от ручной настройки и очередей к автоматизированной, изолированной и безопасной инфраструктуре, которая помогает командам быстрее выкатывать новые фичи.
При этом нам удалось сохранить высокий уровень информационной безопасности — требования ИБ были одним из ключевых факторов при проектировании новой архитектуры. Сегодня каждая команда разработки может работать в собственном виртуальном кластере, не влияя на «соседей» и не нарушая стандарты безопасности. Интеграция с ArgoCD позволяет централизованно управлять окружениями и ускорять delivery.
Мы постоянно совершенствуем наши процессы, чтобы заказчики NGENIX могли получать улучшения сервиса и новые возможности как можно быстрее, при этом сохраняя высокий уровень стабильности и защиты.
Если хотите глубже разобраться, как мы решали эти задачи и какие технические нюансы пришлось учесть, смотрите полную запись выступления Павла Козлова на DevOpsConf 2025.
🧑💻 Больше полезных материалов — в нашем блоге:
«Защита без раскрытия: с какими рисками и ограничениями может столкнуться бизнес»: что такое «защита без раскрытия» и почему компания не может передать свой SSL-сертификат; какие ограничения и риски существуют, если не раскрывать HTTPS-трафик; почему стоит доверить свой сертификат провайдеру.
«Атаки в обход провайдера: как сервис Origin Direct Connect поможет защитить сайт»: как атакуют в обход провайдера защиты; как устроено прямое физическое подключение; как организовать прямое физическое подключение с платформой NGENIX.