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

попросил ИИ перевести в 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

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

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

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

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

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

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

Команда:

 docker build -f Dockerfile -t myapp:latest .

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

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

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

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

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

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

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

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

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

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

Насколько я знаю нет, но нашел такой механизм 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

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

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

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

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

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

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

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

Helm CEL: Валидация Helm чартов с помощью CEL

Добавлена поддержка переиспользуемых выражений и возможность указывать severity(warning - выводит сообщение, но не exit code ==1).
https://github.com/idsulik/helm-cel?tab=readme-ov-file#writing-validation-rules

Понимание Common Expression Language (CEL): Руководство для начинающих

Добавил пример использования в бою

Один из примеров использования CEL в бою - https://github.com/idsulik/helm-cel helm плагин для валидации значний.
Статья про плагин https://habr.com/ru/articles/859166/

Понимание Common Expression Language (CEL): Руководство для начинающих

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

Helm CEL: Валидация Helm чартов с помощью CEL

Спасибо! Какие именно еще возможности интересуют?

Понимание Common Expression Language (CEL): Руководство для начинающих

Спасибо! Насчет примеров - может напишу отдельную статью, эту хотел сделать как вводную

Понимание Common Expression Language (CEL): Руководство для начинающих

CEL vs SPeL:

• CEL намеренно более ограничен и "безопасен" - нет циклов, рекурсии, побочных эффектов

• CEL оптимизирован для валидации и вычисления условий, тогда как SPeL более общего назначения

• CEL имеет строгую типизацию, SPeL - более динамичен

• SPeL тесно интегрирован со Spring и Java-экосистемой, CEL - язык-независим

CEL vs Groovy Shell:

• Groovy - полноценный язык программирования с циклами, классами и т.д.

• CEL - узкоспециализированный язык для выражений

• Groovy менее безопасен для исполнения пользовательского кода

• Groovy сложнее оптимизировать из-за динамической природы

CEL vs JSR 223:

• JSR 223 - это API для выполнения скриптов, а не язык

• Через JSR 223 можно выполнять полноценные языки (Python, JavaScript и т.д.)

• CEL предоставляет гарантии безопасности и производительности

Типы в CEL:

• Строгая типизация

• Базовые типы: bool, int, uint, double, string

• Составные типы: lists, maps

• Null-safety встроена в язык

• Поддержка пользовательских типов через интеграцию с хост-языком

Понимание Common Expression Language (CEL): Руководство для начинающих

https://github.com/orgs/google/repositories?q=cel-
Официальные репозитории есть для java/go/c++
Есть неофициальные для python/js/c# и т.д.

Helm CEL: Валидация Helm чартов с помощью CEL

можно опустить описание, тогда будет ошибка без описания:

Насчет автогенерации описания, хорошая идея, но это наверно подойдет для простых выражений, а для сложных выйдет большое описание, что наверное так себе.

Постараюсь реализовать, если у кого есть желание, то welcome в pull requests)

Решение задачи с собеседования Linked List Cycle [+ ВИДЕО]

Так более понятно, спасибо)

Решение задачи с собеседования Linked List Cycle [+ ВИДЕО]

И растояние между ними по кругу от быстрого будет L. За одну итерацию это растсояние увеличивается на 1 (медленный сделал шаг вперед) и уменьшается на 2 (быстрый его двумя шагами доганяет). Т.е. расстояние станет L+1-2 = L-1. Оно уменьшается на 1. И за ровно L итераций указатели встретятся - расстояние станет 0.