За что отвечает опция "`services.SERVICE_NAME.build`" в docker-compose.yml?
Анализирую учебный пример:
version: '3'
services:
webpack:
build: ./docker/webpack
volumes:
- ./src:/my_webpack/src
- ./dist:/my_webpack/dist
- ./docker/webpack/package.json:/my_webpack/package.json
- ./docker/webpack/webpack.config.js:/my_webpack/webpack.config.js
ports:
- 2000:2000
Первое, что непонятно - какой смысл имеет services.webpack.build?
- Это ссылка на локальные файлы, контейнер или volume?
- Какой процесс выполняется благодаря этой настройке?
- Можно ли без неё обойтись?
Ответы (1 шт):
Для запуска контейнера в docker-compose нужно указать образ (image) с которого, контейнер будет создаваться. Например, это делают так:
services:
db:
image: "redis:alpine"
Это создаст контейнер на основе redis:alpine при docker-compose up.
Опция build используется тогда, когда у вас нет базового образа или вы его хотите собрать сами из Dockerfile (подробнее). В build указывается папка в которой будет находиться Dockerfile и потом при помощи docker-compose build вы можете собрать образ и docker-compose up запустить.
Это удобно когда у вас в docker-compose несколько сервисов и для них нужно собирать свои образы. Тогда чтобы не бегать по папкам и выполнять docker build ... вы можете настроить все раз и выполнять одну команда, которая соберет вам все.
Это ссылка на локальные файлы, контейнер или volume?
Это путь с папке с Dockerfile. Можно провести аналогию:
services:
webpack:
build: ./docker/webpack
это
docker build ./docker/webpack (имя образа оно быберет само).
services:
webpack:
build: ./docker/webpack
image: web:1.1
это
docker build -t web:1.1 ./docker/webpack
А "разширенный" вариант этой комманды:
services:
webpack:
image: web:1.1
build:
context: ./docker/webpack
dockerfile: Dockerfile-alternate
это
docker build -t web:1.1 -f Dockerfile-alternate ./docker/webpack
Можно ли без неё обойтись?
Да, можно собирать образы руками и просто указывать image: <name>:<tag>.