Современная фронтенд-разработка совсем не похожа на то, что было десять лет назад. Вы больше не просто пишете HTML и CSS. Типичный проект теперь поставляется с определенным рантаймом Node.js, зафиксированной версией пакетного менеджера, запутанным набором инструментов сборки и конвейерами развертывания (deployment pipelines), которые требуют идеального соответствия всех компонентов. Где-то между первым npm install и финальной сборкой для продакшена начинают проскальзывать мелкие различия. Коллега использует Node 20. Вы используете Node 18. Глобальный CLI-инструмент на вашей машине скрывает отсутствие зависимости на его компьютере. И вот звучит фраза, которую никто не хочет слышать: «На моей машине всё работает».

Docker заслуженно занимает место в арсенале фронтенд-разработчика, потому что он устраняет эту неопределенность. Он упаковывает ваше приложение вместе с нужным рантаймом, системными библиотеками и зависимостями. Независимо от того, пишете ли вы код на Windows, собираете проект на macOS или развертываете его в облачном инстансе Linux, поведение приложения остается идентичным.

Почему фронтенд-разработчикам стоит обратить на это внимание

Проблемы, которые решает Docker, не абстрактны. Они проявляются в каждом спринте.

Конфликты версий отнимают время. Одному старому клиентскому проекту нужен Node 18, вашему пет-проекту — Node 20, а работе в новом стартапе требуется Node 22. Без контейнеров вы управляете этим с помощью менеджеров версий. Это работает до поры до времени. Незначительное несовпадение версий npm может изменить способ разрешения peer-зависимостей, что приведет к сломанной сборке, которая при этом отлично работает у кого-то другого. Когда фреймворк анонсирует новый релиз, цикл обратной связи не должен состоять из двух часов переустановок. Он должен сводиться к изменению одного файла и перезапуску контейнера.

Глобальные пакеты — еще один источник скрытых проблем. У вас могут быть установлены Angular CLI, Expo или Prisma еще полгода назад. Новый разработчик устанавливает тот же инструмент с нуля и получает другую версию. Внезапно ваши скрипты сборки выдают предупреждения, которые нигде больше не появляются. Docker решает эту проблему, делая всё локальным для проекта. Вы определяете версию Node в своем Dockerfile. Зависимости устанавливаются внутри контейнера, изолированно от вашей основной операционной системы. Ваш ноутбук может быть на macOS, Windows или Ubuntu; приложение каждый раз видит одну и ту же среду.

Преимущества для онбординга трудно игнорировать. Новым сотрудникам не нужен трехстраничный README с инструкциями по установке Homebrew, настройке nvm aliases и исправлению глобальных прав доступа. Они устанавливают Docker, клонируют репозиторий и запускают одну команду. Настройка, которая раньше занимала целый день, теперь сокращается до нескольких минут. А когда они переключаются на другие проекты, ничего не остается. Никаких «осиротевших» глобальных инструментов. Никаких менеджеров версий, сражающихся за приоритет в PATH. Их локальная машина остается чистой.

Образы и контейнеры: основы

Если вы новичок в Docker, терминология окажется проще, чем кажется. Docker-образ — это чертеж. Он содержит ваш исходный код, рантайм Node.js, lock-файл и все зависимости, необходимые для запуска приложения. Контейнер — это запущенный экземпляр, созданный на основе этого образа. Представьте, что образ — это рецепт, а контейнер — само блюдо. Вы можете испечь один и тот же торт сто раз по одному рецепту. Вы можете запускать идентичные контейнеры из одного образа, не беспокоясь о том, что установлено на хост-компьютере.

Практический Dockerfile

Давайте рассмотрим конкретный пример. Если вы