DevSpace + Next.js: Как перестать ждать деплой и разрабатывать сразу в Kubernetes

Недавно, в одном Kubernetes-проекте мы начали использовать DevSpace, чтобы сделать локальную разработку максимально близкой к реальному окружению.

Цель была простая: чтобы приложение, его зависимости и взаимодействие с другими сервисами работали в той же среде, что и в Kubernetes-кластере. Это помогает избежать расхождений между локальной разработкой и реальным поведением в инфраструктуре, в том числе ситуации, когда «локально всё работает, а на staging — нет».

То есть, DevSpace - это инструмент, который позволяет запускать dev-режим приложения прямо внутри Kubernetes, но с привычным опытом локальной разработки. По сути, ты продолжаешь работать как обычно, но код исполняется не на локальной машине, а в кластере.

Достаточно запустить одну команду:

После этого код синхронизируется в контейнер, Next.js запускается внутри Kubernetes, работает hot reload и автоматически пробрасываются порты. По ощущениям это практически не отличается от npm run dev, но среда уже не локальная, а реальная.

Обычно запуск выглядит так:

Дальше DevSpace последовательно делает несколько шагов, и все это описывается в devspace.yaml, который лежит в корне проекта.

Конфигурация выглядит примерно так:

Здесь DevSpace использует указанный Dockerfile и текущий контекст проекта (context: .), чтобы собрать Docker-образ приложения. Этот образ затем используется для запуска приложения внутри Kubernetes-кластера.

Helm - это шаблон для развертывания приложения в Kubernetes. DevSpace берет готовый Helm-чарт, подставляет в него нужный Docker-образ и сам выполняет команду helm upgrade.

В итоге не нужно вручную запускать kubectl или команды helm - DevSpace делает это автоматически, но сам чарт при этом остается твоим и заранее должен быть настроен.

На этом этапе DevSpace находит уже запущенный pod (так в Kubernetes называется контейнер с приложением) в кластере и на лету меняет в нем контейнер: вместо production-образа подставляет dev-образ, в котором есть Node.js, пакетный менеджер и все необходимое для разработки.

Изменения, которые происходят локально, мгновенно попадают в контейнер, и Next.js автоматически перезапускается.

Запуск приложения внутри контейнера делегируется скрипту (devspace_start.sh должен быть добавлен в корень проекта):

Внутри этого файла находятся стандартные шаги: установка зависимостей, настройка окружения и запуск npm run dev. Это позволяет унифицировать поведение dev-среды для всей команды.

DevSpace делает kubectl port-forward, и приложение, работающее внутри Kubernetes, становится доступным локально через localhost или через выделенный IP.

Таким образом, DevSpace фактически меняется сам цикл работы. Ты больше не зависишь от CI, чтобы проверить изменения. Достаточно сохранить файл, и результат сразу виден в браузере. При этом ты работаешь не в изолированной локальной среде, а сразу в Kubernetes с теми же зависимостями, сервисами и сетевыми условиями. Ошибки проявляются там, где они действительно возникают, а не обнаруживаются после деплоя.

Интеграция не требует серьезных изменений в кодовой базе и сводится к добавлению нескольких конфигурационных файлов:

- devspace.yaml, который описывает сборку Docker-образа, деплой и поведение в dev-режиме;
- devspace_start.sh, который отвечает за инициализацию и запуск приложения внутри контейнера.

После этого нужно установить DevSpace CLI:

Настроить пространство (один раз):

Дальше вся работа сводится к запуску команды:

Для более детальной настройки можно использовать официальный гайд DevSpace:

Помимо devspace dev, есть еще несколько команд, которые пригодятся в работе:

Также стоит добавить, что есть еще одна удобная возможность - изолированные окружения для каждого разработчика. Каждый работает в своем собственном пространстве (namespace) и не мешает остальным. Это особенно полезно, когда несколько человек одновременно ведут разработку в одном Kubernetes-кластере.

DevSpace фактически делает локальную разработку максимально приближенной к Kubernetes: код пишется, запускается и отлаживается прямо внутри кластера. Это ускоряет процесс разработки и делает его ближе к реальной продакшн-среде.

Если в проекте микросервисная архитектура и используется Kubernetes, DevSpace обеспечивает удобный баланс между привычным локальным dev-опытом и реальной инфраструктурой.

И если раньше деплой был отдельным шагом в цикле разработки, необходимым, чтобы проверить, как изменения будут работать в реальной среде, то с DevSpace он становится частью этого процесса: изменения можно сразу проверять в кластере без лишних переключений контекста и ручных действий.

А вы уже сталкивались с DevSpace или похожими инструментами для разработки в Kubernetes?