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

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

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

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

Каждый build: может указывать 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 - лучший способ использовать 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-composev1.25.0 (18.11.2019) представляет экспериментальную функцию COMPOSE_DOCKER_CLI_BUILD, так что docker-compose использует собственный конструктор докеров (поэтому образы, созданные docker build, могут использоваться в качестве кеша слоев для docker-compose build)