Docker выполняет сложную настройку файловой системы при запуске контейнера. У вас есть изображение , которое содержит код вашего приложения; контейнерная файловая система , которая теряется при выходе из контейнера;и тома , которые постоянно хранятся вне контейнера. Тома разбиты на два основных варианта: bind mounts определенных каталогов хоста и именованных томов , управляемых демоном Docker.
Стандартный шаблон проектирования состоит в том, что образполностью автономен. Получив образ, я смогу отправить его в реестр и запустить его на другом компьютере без изменений.
git clone git@github.com:me/myapp
cd myapp
docker build -t me/myapp . # requires source code
docker push me/myapp
ssh me@othersystem
docker run me/myapp # source code is in the image
# I don't need GitHub credentials to get it
При использовании томов для хранения вашего приложения возникают три большие проблемы. ваш каталог node_modules:
Он нарушает шаблон "код идет в образе". В реальной производственной среде вам не нужно выдвигать свое изображение, а также отдельно выдвигать код;это побеждает одно из больших преимуществ Docker. Если вы скрываете каждый последний байт кода в изображении во время цикла разработки, вы никогда не выполняете то, что отправляете.
Docker считает, что тома содержат жизненно важных пользователей. данные, которые он не может безопасно изменить. Это означает, что если ваше дерево node_modules находится в томе и вы добавляете пакет в файл package.json, Docker будет продолжать использовать старый каталог node_modules, поскольку он не может изменять важные пользовательские данные, которые вы ''мы сказали, что он есть.
В частности, на MacOS монтирование привязки происходит очень медленно , и если вы монтируете большое приложение в контейнер, оно будет просто сканироваться.
Как правило, я нашел три хороших варианта использования томов: хранение реальных пользовательских данных при выполнении контейнеров;внедрение файлов конфигурации во время запуска;и чтение файлов журнала. Код и библиотеки не годятся для хранения в томах.
В частности, для интерфейсных приложений не представляется большой пользой попытаться запустить их в Docker. Поскольку фактический код приложения выполняется в браузере, он не может получить прямой доступ к любым ресурсам, размещенным в Docker, и нет никакой разницы, работает ли ваш сервер разработки в Docker или нет. Типичные цепочки сборки, включающие такие инструменты, как Typescript и Webpack, не имеют дополнительных зависимостей от хоста, поэтому ваша установка Docker действительно просто превращается в обходной путь запуска Node с исходным кодом, который находится только на вашем хосте. Рабочий путь создания приложения в статические файлы и последующего использования веб-сервера, такого как nginx, для их обслуживания по-прежнему прямо в Docker. Я бы просто запустил Node на хосте для разработки такого рода вещей, и мне не приходилось думать о таких вопросах, как этот.