Docker Bake: современный подход к сборке контейнеров

[alexey_melezhik]

Неплохой обзор.

Отличная интеграция с CI/CD-пайплайнами

Вот это не раскрыто

[idsulik]

В рамках одной статьи не покроешь все кейсы, если будет спрос, то напишу новую статью для конкретного кейса

[alexey_melezhik]

Да - можно было коротко указать - почему . Так-то о любом коде можно сказать что он «отлично интегрируется в …» - просто пишешь в общем случае свою обертку на чем угодно и вставляешь в пайплайн . Тут наверно имелось ввиду что есть готовые плагины для стандартных ci/cd систем ?

[idsulik]

Вместо сложных docker build команд можно описать сборку в одном конфиге и переиспользовать его в CI/CD, параллельная сборка, использование переменных

[alexey_melezhik]

Теперь понятно

[yarkov]

2 раза прочитал, но преимуществ так и не увидел. Ещё один новый формат конфигурационного файла. А зачем?

[alexey_melezhik]

Ну типа HCL чуть гибче чем просто yaml , плюс проще многокомпонентные сборки. Хотя для меня лично что HCL , что YAML - одна малина )

[idsulik]

docker buildx bake упрощает и ускоряет процесс сборки, особенно если нужно собирать несколько образов одновременно. Вместо того, чтобы писать несколько команд docker build, всё можно описать в одном конфигурационном файле и запускать одной командой. Это также позволяет легко переопределять параметры (например, теги) и использовать параллельную сборку для ускорения процесса. 

- docker-compose используется для управления контейнерами и их взаимосвязями (например, запуск нескольких сервисов в одном проекте).
- docker buildx bake используется для сборки Docker-образов, причем он позволяет собирать несколько образов одновременно, ускоряя процесс.
Таким образом, docker-compose — для запуска контейнеров, а docker buildx bake — для сборки образов.

[yarkov]

Воооооот! Вот теперь всё встало на свои места. Спасибо огромное.

[Apokalepsis]

А я вот из статьи не совсем понял, есть ли разница между buildx и с bake ?

docker:
    name: Publish Docker image
    needs: goreleaser
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Extract version from tag
        id: get_version
        run: echo "VERSION=${GITHUB_REF#refs/tags/}" >> $GITHUB_OUTPUT

      - name: Set up QEMU
        uses: docker/setup-qemu-action@v3

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_HUB_USERNAME }}
          password: ${{ secrets.DOCKER_HUB_ACCESS_TOKEN }}

      - name: Build and push Docker image
        uses: docker/build-push-action@v6
        with:
          context: .
          file: ./docker/Dockerfile
          platforms: linux/amd64,linux/arm64
          push: true
          tags: |
            nemirlev/zenexport:latest
            nemirlev/zenexport:${{ steps.get_version.outputs.VERSION }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

У меня так джоба выглядит. Несколько команд build не использую.

[idsulik]

А я вот из статьи не совсем понял, есть ли разница между buildx и с bake ?

bake - это часть buildx, для сборки вызываем docker buildx bake

[idsulik]

попросил ИИ перевести в bake эту конфигурацию:

group "default" {
  targets = ["zenexport"]
}

target "zenexport" {
  context    = "."
  dockerfile = "./docker/Dockerfile"
  platforms  = ["linux/amd64", "linux/arm64"]
  cache-from = ["type=gha"]
  cache-to   = ["type=gha,mode=max"]
}

docker:
    name: Publish Docker image
    needs: goreleaser
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Extract version from tag
        id: get_version
        run: echo "VERSION=${GITHUB_REF#refs/tags/}" >> $GITHUB_OUTPUT

      - name: Set up QEMU
        uses: docker/setup-qemu-action@v3

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_HUB_USERNAME }}
          password: ${{ secrets.DOCKER_HUB_ACCESS_TOKEN }}

      - name: Build and push using Docker Bake
        run: |
          docker buildx bake --file docker/docker-bake.hcl --set *.tags=nemirlev/zenexport:latest --set *.tags=nemirlev/zenexport:${{ steps.get_version.outputs.VERSION }} --set *.push=true

[kvendingoldo]

А Bake решает вопрос зависимостей?

Условно, если у меня есть образы A, B, C, D: D зависит от C, а C и B от А. Сможет ли данный тул построить правильную цепочку сборки?

[idsulik]

Насколько я знаю нет, но нашел такой механизм https://github.com/docker/buildx/blob/v0.8.0-rc1/docs/reference/buildx_bake.md#using-a-result-of-one-target-as-a-base-image-in-another-target
это было в решение issue по зависимостям bake https://github.com/docker/buildx/issues/447

[idsulik]

https://docs.docker.com/build/bake/reference/#targetcontexts - да, мне кажется, что это то, что вам нужно

[Nikokolo]

Было бы ещё интересно узнать подробнее про интеграцию с CI/CD

[idsulik]

А что именно интересует?

[dvglab]

В своих проектах использую werf. Не увидел преимуществ перед werf и stapel. Было бы интересно сравнение с разными инструментами сборки. Да и docker-compose уже интегрировался в докер и стал docker compose. Но werf и необходимость в compose закрывает.

[idsulik]

В конец статьи добавил сравнение docker compose и docker bake, это разные инструменты и сейчас docker compose работает над полной поддержкой bake

а про werf слышал, но не пользовался, гляну и постараюсь обновить статью, чтобы добавить сравнение

[francyfox]

Больше похоже на фичу для фанатов distroless

[idsulik]

Distroless образы - это образы, состоящие из минимального количества исполняемых файлов и библиотек необходимых для их запуска. В них нет полноценных пакетов со всеми файлами, присутствующими в обычной системе.

если это правильная информация, то вроде как фичи не похожи никак.
docker bake - если сильно упростить, помогает избегать длинных написание длинных команд, вместо этого ты описываешь, как ты хочешь создать образ с помощью bake файла.

Команда:

 docker build -f Dockerfile -t myapp:latest .

Bake альтернатива:

target "myapp" {
  context = "."
  dockerfile = "Dockerfile"
  tags = ["myapp:latest"]
}

[Tony-Sol]

Bake альтернатива:

Оно классно, что на hcl, но все еще не ясно в чем выигрыш относительно

services:
  myapp:
    context: "."
    dockerfile: "Dockerfile"
    tags:
      - "myapp:latest"

С последующим вызовом `docker compose build myapp` вместо `docker buildx bake myapp`

[idsulik]

для таких примитивных кейсов разницы нет.

[Tony-Sol]

Да вот как будто для 95% кейсов разницы нет. Оставшиеся 5% это случаи когда функции внутри hcl будут красивее якорей в yaml

Но это сугубо имхо

[idsulik]

как только добавится еще один сервис в docker-compose, разница уже появится, т.к. сборка будет происходить параллельно.

вы привели самый примитивный пример и натянули это на 95% кейсов, хотя большинство кейсов, когда код деплоится куда-то - это уже несколько образов в рамках одного проекта, теги разные для разных стейджов и т.д.

[Tony-Sol]

как только добавится еще один сервис в docker-compose, разница уже появится, т.к. сборка будет происходить параллельно.

Так сами же в статье пишите:

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

Или к тому что с compose не будет параллельной сборки? ЕМНИП - будет

вы привели самый примитивный пример и натянули это на 95% кейсов

Потому что не увидел примера того, что может bake и не может compose

большинство кейсов, когда код деплоится куда-то - это уже несколько образов в рамках одного проекта, теги разные для разных стейджов и т.д.

Это никак не противоречит

[idsulik]

я в конце статьи написал сравнение docker compose и docker bake, цели у этих инструментов разные.

[idsulik]

{deleted}