Kuby-core: Использование buildx

Привет!

Можно использовать buildx прямо сейчас, если вы установите его как сборщик по умолчанию .

Вот пример действия Github, использующего buildx и его возможности кэширования: https://github.com/anycable/anycable_rails_demo/pull/25/files#diff -28802fbf11c83a2eee09623fb192785e7ca92a3f40602a517c011b947a1822d3R28-R44.

См. также https://evilmartians.com/chronicles/kubin-rails-stressless-kubernetes-deployments-with-kuby#deploying-continuously-with-kuby-and-github-actions .

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

Большое спасибо за полезные ссылки 👍 Теперь я слежу за ними, чтобы увидеть, помогут ли они мне пересечь линию!

Мне также определенно не хватало функции по умолчанию setup-buildx-action ( install: true )

Кажется, теперь это работает! Я только что видел, как сборка образа приложения была завершена менее чем за 10 секунд. Есть и другие проблемы, которые у меня есть сейчас, возможно, регрессия, которую я обнаружил, когда RAILS_MASTER_KEY не экспортируется должным образом, но я собираюсь пойти и прочитать источник, чтобы выяснить это сейчас.

Если я использую install: true как в этом коммите, то метод build из lib/kuby/docker/cli.rb вызывает buildx , и я могу передавать конструкции buildx, такие как --cache-to после -- , чтобы получить их в массиве *docker-args 👍, чтобы это можно было закрыть, за исключением того, что kuby-core может документировать, как его можно использовать с buildx, это строго не проблема куби

С примером в:

https://github.com/kingdonb/kuby_test/commit/d74bf51e04253359b0d54aae7ddd6723ea6fd41d#diff -e2ad06bfd6b3aefc2d5f4fe8f60e0015b16947abc16764adef02e4339ac07a42R17-R20

Я могу использовать buildx, поэтому этот вопрос можно закрыть.

Это действительно круто, спасибо, что разобрались с buildx! У меня сложилось впечатление, что вы можете установить переменную среды, и она будет Just Work™, это то, что делает это действие docker/setup-buildx-action@v1 ? Кажется, что buildx поставляется с Docker Desktop и более новыми версиями, установленными через пакеты deb/rpm, поэтому мне интересно, может ли Kuby просто использовать его по умолчанию. Однако, если это настраивается с помощью env var, может быть, вызов docker buildx build не нужен? Может быть, Kuby сможет обнаружить это и вернуться к нормальному docker build ?

Да, это возможно (и именно это делает install: true в GitHub Action): https://docs.docker.com/buildx/working-with-buildx/#set -buildx-as-the-default- строитель

Хорошо, если docker build — это просто псевдоним для docker buildx , то я не вижу необходимости в том, чтобы Kuby делал что-то особенное. Пользователь должен сам настроить конструктор, который ему нужен.