Jaka jest różnica między „kompilacją docker-compose” a „kompilacją docker”?

Jaka jest różnica między docker-compose buildi docker build?

Załóżmy, że w zadokowanej ścieżce projektu znajduje się docker-compose.ymlplik:

docker-compose build

I

docker build

docker-composemożna uznać za wrapper wokół CLI dockera (w rzeczywistości jest to kolejna implementacja w Pythonie, jak wspomniano w komentarzach ), aby zaoszczędzić czas i uniknąć linii o długości 500 znaków (a także uruchomić wiele kontenerów w tym samym czasie). Używa pliku o nazwie docker-compose.ymlw celu pobrania parametrów.

Informacje na temat formatu pliku docker-compose można znaleźć tutaj .

Więc w zasadzie docker-compose buildprzeczytam twoje docker-compose.yml, poszuka wszystkich usług zawierających build:instrukcję i uruchomi docker builddla każdego z nich.

Każdybuild: może określić Dockerfile, kontekst i argumenty do przekazania do docker.

Na zakończenie przykładowym docker-compose.ymlplikiem:

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 

Podczas wywoływania docker-compose buildtylko webcel będzie potrzebował zbudowania obrazu. docker buildKomenda będzie wyglądać następująco:

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

docker-compose buildzbuduje usługi w docker-compose.ymlpliku.

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

docker build zbuduje obraz zdefiniowany przez Dockerfile.

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

Zasadniczo docker-compose jest lepszym sposobem korzystania z docker niż tylko polecenie docker.

Jeśli pytanie brzmi, czy polecenie kompilacji docker-compose zbuduje coś w rodzaju zip zawierającego wiele obrazów, które w przeciwnym razie zostałyby zbudowane osobno za pomocą zwykłego pliku Dockerfile, to myślenie jest błędne.

Kompilacja Docker-compose, utworzy indywidualne obrazy, przechodząc do indywidualnego wpisu usługi w docker-compose.yml.

Dzięki obrazom docker, command, możemy również zobaczyć wszystkie zapisywane pojedyncze obrazy.

Prawdziwą magią jest docker-compose up.

Ten w zasadzie stworzy sieć połączonych ze sobą kontenerów, które mogą rozmawiać ze sobą o nazwie kontenera podobnej do nazwy hosta.

Dodawanie do pierwszej odpowiedzi ...

Możesz podać nazwę obrazu i nazwę kontenera w definicji usługi.

np. dla usługi o nazwie „web” w poniższym przykładzie docker-compose, możesz jawnie podać nazwę obrazu i kontenera, aby docker nie musiał używać ustawień domyślnych.

W przeciwnym razie nazwa obrazu, której będzie używał docker, będzie połączeniem folderu (katalogu) i nazwy usługi. np. myprojectdir_web

Dlatego lepiej jest jawnie podać żądaną nazwę obrazu, która zostanie wygenerowana po wykonaniu polecenia docker build.

np. obraz: mywebserviceImage nazwa_kontenera: my-webServiceImage-Container

przykładowy plik 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

Kilka dodatkowych słów o różnicy między docker builda docker-compose build. Oba mają opcję tworzenia obrazów przy użyciu istniejącego obrazu jako pamięci podręcznej warstw.

• z docker buildopcją jest--cache-from <image>
• z docker-composer, cache_fromw buildsekcji znajduje się tag .

Niestety, do tej pory na tym poziomie obrazy wykonane przez jeden nie są zgodne z drugim jako pamięć podręczna warstw ( identyfikatory nie są kompatybilne ). Jednak docker-compose wersja 1.25.0 (2018-11-18) wprowadza eksperymentalną funkcję COMPOSE_DOCKER_CLI_BUILD , która docker-composewykorzystuje natywny kreator docker (w związku z tym obrazy utworzone przez docker buildmogą być używane jako pamięć podręczna warstw dla docker-compose build)