В чем разница между docker-compose build и docker build?

В чем разница между docker-compose buildи docker build?

Предположим, что в пути к документированному проекту есть docker-compose.ymlфайл:

docker-compose build

И

docker build

docker-composeможет рассматриваться как оболочка для интерфейса командной строки докера (на самом деле это еще одна реализация на Python, как сказано в комментариях ), чтобы выиграть время и избежать строк длиной 500 символов (а также запустить несколько контейнеров одновременно). Он использует файл с именемdocker-compose.yml для получения параметров.

Вы можете найти ссылку на Докер-Compose формат файла здесь .

Таким образом, в основном docker-compose buildбудет читать ваш docker-compose.yml, искать все службы, содержащие build:оператор, и запускать docker buildдля каждого из них.

Каждыйbuild: может указать a Dockerfile, контекст и аргументы для передачи докеру.

В заключение приведем пример docker-compose.ymlфайла:

version: '3.2'

services:
  database:
    image: mariadb
    restart: always
    volumes:
      - ./.data/sql:/var/lib/mysql

  web:
    build:
      dockerfile: Dockerfile-alpine
      context: ./web
    ports:
      - 8099:80
    depends_on:
      - database 

При вызове docker-compose buildтолько webцель будет нуждаться в построении изображения. Команда docker buildбудет выглядеть так:

docker build -t web_myproject -f Dockerfile-alpine ./web

docker-compose buildсоздаст службы в docker-compose.ymlфайле.

https://docs.docker.com/compose/reference/build/

docker build создаст образ, определенный Dockerfile.

https://docs.docker.com/engine/reference/commandline/build/

По сути, docker-compose - лучший способ использовать docker, чем просто команда docker.

Если вопрос здесь в том, будет ли команда сборки docker-compose build создавать zip-архив, содержащий несколько изображений, которые в противном случае были бы созданы отдельно с помощью обычного Dockerfile, то это неверное мнение.

Сборка Docker-compose будет создавать отдельные образы путем перехода к отдельной записи службы в docker-compose.yml.

С помощью команды docker images, мы также можем видеть все сохраняемые отдельные изображения.

Настоящая магия - это docker-compose up.

Это в основном создаст сеть взаимосвязанных контейнеров, которые могут взаимодействовать друг с другом с именем контейнера, аналогичным имени хоста.

Добавляем к первому ответу ...

Вы можете указать имя изображения и имя контейнера под определением службы.

например, для службы с именем 'web' в приведенном ниже примере создания докеров вы можете явно указать имя изображения и имя контейнера, чтобы докеру не нужно было использовать значения по умолчанию.

В противном случае имя изображения, которое будет использовать докер, будет объединением папки (каталога) и имени службы. например, myprojectdir_web

Поэтому лучше явно указать желаемое имя изображения, которое будет сгенерировано при выполнении команды docker build.

например, изображение: mywebserviceImage имя_контейнера: my-webServiceImage-Container

пример файла docker-compose.yml:

version: '3.2'
services:
  web:
    build:
      dockerfile: Dockerfile-alpine
      context: ./web
    ports:
      - 8099:80
    image: mywebserviceImage
    container_name: my-webServiceImage-Container
    depends_on:
      - database

Несколько дополнительных слов о разнице между docker buildи docker-compose build. Оба имеют возможность создавать изображения с использованием существующего изображения в качестве кеша слоев.

• с docker build, опция--cache-from <image>
• с docker-composer, cache_fromв buildразделе есть тег .

К сожалению, до сих пор на этом уровне изображения, созданные одним из них, несовместимы с другим в качестве кеша слоев ( идентификаторы несовместимы ). Однако в docker-compose v1.25.0 (2019-11-18) представлена ​​экспериментальная функция COMPOSE_DOCKER_CLI_BUILD, которая docker-composeиспользует собственный конструктор докеров (поэтому изображения, созданные с помощью, docker buildмогут использоваться в качестве кеша слоев для docker-compose build)