Использование Dev Containers для локальной разработки

Вы наверняка сталкивались с такой ситуацией: в вашу команду приходит новый разработчик, и через два дня он всё ещё борется с конфликтами версий Node, отсутствующими зависимостями и переменными окружения, которые работают на машинах всех остальных, кроме его. А тем временем сам проект остаётся нетронутым.

Dev Containers решают эту проблему, упаковывая всю вашу среду разработки — runtime, инструменты, расширения и конфигурацию — в контейнер, который работает одинаково на каждой машине. В этой статье объясняется, как Dev Containers создают воспроизводимые среды разработки для frontend-команд без необходимости глубоких знаний Docker.

Что на самом деле делают Dev Containers

Dev Containers — это Docker-контейнеры, специально настроенные для работы над разработкой. В отличие от production-контейнеров, которые запускают ваше приложение, Dev Containers запускают всю вашу среду разработки. Ваш редактор подключается к контейнеру, и все ваши инструменты выполняются внутри него.

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

Такой подход к контейнеризованной локальной разработке полностью устраняет проблему «на моей машине работает». Ваш файл devcontainer.json становится единственным источником истины о том, как вести разработку в вашем проекте.

Основные концепции, которые нужно понимать

Файл devcontainer.json

Каждая конфигурация Dev Container начинается с файла devcontainer.json, обычно хранящегося в папке .devcontainer в корне вашего проекта. Этот файл сообщает вашему редактору, как собрать или загрузить контейнер и что настроить внутри него.

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

{
  "name": "Frontend Dev Environment",
  "image": "mcr.microsoft.com/devcontainers/typescript-node:20",
  "forwardPorts": [3000],
  "customizations": {
    "vscode": {
      "extensions": ["dbaeumer.vscode-eslint", "esbenp.prettier-vscode"]
    }
  }
}

Эта конфигурация загружает готовый образ Node 20 с поддержкой TypeScript, пробрасывает порт 3000, чтобы вы могли получить доступ к dev-серверу из браузера хоста, и автоматически устанавливает расширения ESLint и Prettier в VS Code.

Образы vs. Dockerfiles

У вас есть два варианта определения базы вашего контейнера. Использование готового образа (как в примере выше) проще и быстрее — контейнер запускается быстро, потому что нечего собирать. Использование Dockerfile даёт полный контроль, но добавляет время сборки.

Для большинства frontend-проектов хорошо подходят готовые образы из репозитория образов Dev Container от Microsoft. Вы можете расширить их с помощью Features — модульных дополнений, которые устанавливают конкретные инструменты без необходимости создавать собственные Dockerfiles.

Docker Compose для сложных конфигураций

Когда вашему frontend нужны backend-сервисы во время разработки — база данных, API-сервер или Redis-кеш — интеграция с Docker Compose позволяет определять многоконтейнерные окружения. Ваш devcontainer.json ссылается на Compose-файл, и все сервисы запускаются вместе.

{
  "name": "Full Stack Dev Environment",
  "dockerComposeFile": "docker-compose.yml",
  "service": "app",
  "workspaceFolder": "/workspace"
}

В этой конфигурации свойство service указывает, к какому контейнеру в Compose-файле должен подключиться ваш редактор, в то время как остальные сервисы (базы данных, кеши, API) работают параллельно.

Переменные окружения: containerEnv vs. remoteEnv

Это различие важно и вызывает путаницу. containerEnv устанавливает переменные при запуске контейнера — они доступны всем процессам. remoteEnv устанавливает переменные только для процессов, запускаемых вашим редактором. Используйте containerEnv для переменных, необходимых вашим инструментам сборки, и remoteEnv для настроек, специфичных для редактора.

{
  "containerEnv": {
    "NODE_ENV": "development",
    "API_URL": "http://localhost:4000"
  },
  "remoteEnv": {
    "EDITOR_THEME": "dark"
  }
}

Аналогично, containerUser определяет, кто владеет процессами в контейнере, а remoteUser контролирует, под каким пользователем подключается ваш редактор. Неправильная настройка этих параметров вызывает ошибки прав доступа, которые раздражают разработчиков. В большинстве случаев установка remoteUser в "node" (для образов на базе Node) позволяет избежать проблем с владением файлами от root.

Что Dev Containers не гарантируют

Установка расширений и настройки рабочего пространства не идеально воспроизводимы между пересборками. Расширения обновляются, а некоторые настройки зависят от локального состояния. Конфигурации, встроенные в образы, также могут измениться при пересборке с обновлёнными базовыми образами.

Примите тот факт, что Dev Containers обеспечивают согласованность, а не неизменность. Фиксируйте версии образов (например, используйте конкретный SHA-дайджест или датированный тег вместо latest) и периодически тестируйте вашу конфигурацию.

Компромиссы, которые стоит учитывать

Dev Containers добавляют время запуска — контейнеры должны быть собраны или загружены, прежде чем вы сможете работать. Они занимают дисковое пространство для образов. И вашей команде нужно базовое знакомство с концепциями Docker, даже если они никогда не пишут Dockerfiles.

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

Новые рабочие процессы, за которыми стоит следить

Команды всё чаще интегрируют AI-помощников по программированию и агентные сервисы через конфигурацию Dev Container. Контейнер становится не просто вашей средой разработки, но средой, в которой автоматизированные инструменты работают с вашим кодом. Этот паттерн быстро развивается, но основа — определение среды как кода — остаётся стабильной.

Начало работы

VS Code предлагает наиболее плавный опыт работы с Dev Container. Установите Docker Desktop, добавьте расширение Dev Containers и выполните команду Dev Containers: Add Dev Container Configuration Files из палитры команд. Выберите шаблон, соответствующий вашему стеку, и через несколько минут вы работаете в контейнере.

Другие редакторы также поддерживают Dev Containers. IDE от JetBrains (такие как IntelliJ и WebStorm) предлагают встроенную поддержку Dev Container, а открытый Dev Container CLI позволяет использовать Dev Containers из любого терминала или CI-пайплайна.

Заключение

Инвестиция в настройку Dev Container окупается в первый раз, когда новый член команды начинает вносить вклад в первый день вместо третьего. Определяя вашу среду разработки как код в одном файле devcontainer.json, вы заменяете хрупкую документацию по настройке воспроизводимой, разделяемой конфигурацией. Компромиссы — время запуска, дисковое пространство и базовое понимание контейнеров — скромны по сравнению с часами, потерянными на отладку дрейфа окружений. Начните с готового образа, добавьте расширения, на которые полагается ваша команда, и итерируйте дальше.

Часто задаваемые вопросы

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.