У чому різниця між `docker-compose build` і` docker build`?

Question 1

У чому різниця між docker-compose buildі docker build?

Припустимо, у докеризованому шляху до проекту є docker-compose.ymlфайл:

docker-compose build

І

docker build

Question 2

docker-composeможна вважати обгорткою навколо докера CLI (насправді це ще одна реалізація в python, як зазначено в коментарях ), щоб виграти час і уникнути рядків довжиною 500 символів (а також запустити кілька контейнерів одночасно). Він використовує файл, викликаний docker-compose.ymlдля отримання параметрів.

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

Отже, в основному 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

Question 3

docker-compose buildпобудує служби у docker-compose.ymlфайлі.

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

docker build побудує зображення, визначене Dockerfile.

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

Question 4

В основному, docker-compose є кращим способом використання docker, ніж просто команда docker.

Якщо питання тут полягає в тому, чи команда docker-compose build створить файл типу zip, що містить кілька зображень, які в іншому випадку були б побудовані окремо за допомогою звичайного файлу Docker, тоді мислення неправильне.

Збірка Docker-compose створить окремі зображення, перейшовши до окремого запису служби в docker-compose.yml.

За допомогою команди docker images, ми можемо бачити всі окремі зображення, які також зберігаються.

Справжня магія - це складання докера.

Це в основному створить мережу взаємопов’язаних контейнерів, які можуть спілкуватися між собою з назвою контейнера, подібною до імені хосту.

Question 5

Додавання до першої відповіді ...

Ви можете вказати ім’я зображення та ім’я контейнера під визначенням служби.

наприклад, для служби, що називається "web" у наведеному нижче прикладі складання докера, ви можете явно вказати ім'я зображення та ім'я контейнера, так що docker не повинен використовувати за замовчуванням.

В іншому випадку ім'я зображення, яке буде використовувати докер, буде об'єднанням папки (Каталог) та іменем служби. наприклад myprojectdir_web

Тому краще явно вказати бажане ім’я зображення, яке буде генеровано при виконанні команди збірки docker.

наприклад, зображення: 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

Question 6

Кілька додаткових слів про різницю між 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)