Перевод статьи «Say Goodbye to Docker Volumes».
Вы когда-нибудь пытались использовать тома Docker для горячей замены (hot-reloading) в своем веб-приложении? Если вы получили такой же ужасный опыт, как и я, вам понравится новейшая функция, которую только что выпустил Docker: docker-compose watch!
В этой статье я расскажу, как обновить существующий проект, чтобы получить настройку среды разработки в Docker, которая точно понравится вашей команде.
TL;DR: Ознакомьтесь с этим файлом docker-compose и официальной документацией.
От редакции Techrocks: если вы еще не знакомы с Docker, познакомиться можно здесь — «Docker: практическое руководство для начинающих».
Приступим!
Введение
Docker только что выпустил Docker Compose Watch с Docker Compose версии 2.22. С помощью этой новой функции вы можете использовать docker-compose watch вместо docker-compose up и автоматически синхронизировать локальный исходный код с кодом в контейнере Docker без необходимости использовать тома!
Давайте посмотрим, как это работает в реальном проекте. Об этом проекте я писал ранее.
В этом проекте у меня есть монорепозиторий с фронтендом, бэкендом и некоторыми дополнительными библиотеками для пользовательского интерфейса и базы данных.
├── apps
│ ├── api
│ └── web
└── packages
├── database
├── eslint-config-custom
├── tsconfig
└── ui
Оба приложения (api и web) уже докеризованы, а Docker-файлы находятся в корне проекта (1, 2).
Файл docker-compose.yml будет выглядеть следующим образом:
services:
web:
build:
dockerfile: web.Dockerfile
ports:
– “3000:3000”
depends_on:
– api
api:
build:
dockerfile: api.Dockerfile
ports:
– “3001:3000″from within the Docker network
Файл неплох, но, как вы знаете, работать с ним во время разработки очень хлопотно. Вам придется пересобирать образы Docker при каждом изменении кода, даже если ваши приложения, вероятно, поддерживают hot-reloading из коробки (а если нет, то с помощью чего-то вроде Nodemon).
Чтобы улучшить ситуацию, Docker Compose Watch вводит новый атрибут — watch. Атрибут watch содержит список так называемых правил. Каждое правило содержит путь, за которым оно следит, и действие, которое будет выполнено, как только файл на этом пути изменится.
Синхронизация
Если вы хотите, чтобы между хостом и контейнером синхронизировалась папка, вы должны добавить следующий код:
services:
web: # shortened for clarity
build:
dockerfile: web.Dockerfile
develop:
watch:
– action: sync
path: ./apps/web
target: /app/apps/web
При изменении файла на хосте по пути ./apps/web/ он будет скопирован в ваш контейнер по адресу /app/apps/web. Дополнительный app в целевом пути необходим, потому что это наша рабочая директория WORKDIR, определенная в Dockerfile. Это главное, что вы, вероятно, будете использовать, если у вас есть приложения с возможностью hot-reloading.
Пересборка — rebuild
Если у вас есть приложения, которые нужно компилировать, или зависимости, которые нужно переустанавливать, вам поможет такое действие (action), как пересборка (rebuild). Вместо того чтобы просто копировать файлы между хостом и контейнером, оно перестроит и перезапустит контейнер. Это очень полезно для ваших npm-зависимостей! Давайте добавим это действие:
services:
web: # shortened for clarity
build:
dockerfile: web.Dockerfile
develop:
watch:
– action: sync
path: ./apps/web
target: /app/apps/web
– action: rebuild
path: ./package.json
target: /app/package.json
При каждом изменении нашего package.json мы будем перестраивать весь наш Dockerfile для установки новых зависимостей.
Sync+Restart
Помимо синхронизации и пересборки есть еще и нечто среднее, называемое sync+restart. Это действие сначала синхронизирует каталоги, а затем сразу же перезапускает контейнер без пересборки.
Большинство фреймворков обычно имеют конфигурационные файлы (например, next.config.js), которые не могут быть загружены в горячем режиме (просто синхронизировать недостаточно), но и не требуют медленной пересборки.
Ваш compose-file изменится следующим образом:
services:
web: # shortened for clarity
build:
dockerfile: web.Dockerfile
develop:
watch:
– action: sync
path: ./apps/web
target: /app/apps/web
– action: rebuild
path: ./package.json
target: /app/package.json
– action: sync+restart
path: ./apps/web/next.config.js
target: /app/apps/web/next.config.js
Оговорки
Но не все так радужно, есть и несколько предостережений.
Самая большая проблема с новым атрибутом watch заключается в том, что пути все еще очень простые. В документации говорится, что шаблоны Glob пока не поддерживаются, что может привести к огромному количеству правил.
Вот несколько примеров того, что работает, а что нет:
apps/web
Будет соответствовать всем файлам в ./apps/web (например, ./apps/web/README.md, а также ./apps/web/src/index.tsx)
build/**/!(*.spec|*.bundle|*.min).js
Глобы, к сожалению, (пока?) не поддерживаются.
~/Downloads
Все пути относительны к корню проекта!
Следующие шаги
Если вы все еще недовольны своей настройкой Docker, есть еще много способов ее улучшить!
Сотрудничество — важная часть разработки программного обеспечения, и работа в одиночку может нанести серьезный ущерб вашей команде. Медленные сборки Docker и сложные настройки не способствуют сотрудничеству! Чтобы противостоять этому, вы можете использовать расширения Docker, такие как Livecycle, для мгновенного обмена локальными приложениями docker-compose с членами вашей команды.
Поскольку вы уже используете Docker и docker-compose, все, что вам нужно сделать, — это установить расширение Docker Desktop Extension и нажать на переключатель share. После этого вы сможете поделиться уникальным URL-адресом с командой, чтобы получить отзывы!
Следите за тем, чтобы ваш Dockerfile соответствовал лучшим практикам, особенно в отношении многоступенчатых сборок и кэширования. Хотя это может усложнить написание начального Dockerfile, это сделает ваши Docker-приложения гораздо более приятными в использовании во время разработки.
Создание базового файла .dockerignore и разделение установки зависимостей и сборки кода поможет вам в этом!
Запись Docker Compose Watch: попрощайтесь с томами Docker! впервые появилась Techrocks.