Kuby-core: 使用 buildx

创建于 2021-12-13  ·  6评论  ·  资料来源: getkuby/kuby-core

我试图添加对调用docker build作为docker buildx build的支持,但恐怕它可能比这更复杂一些

我的意图是添加这些类型的参数:

https://github.com/fluxcd/image-reflector-controller/blob/62c06ea58cd14072fde2c9ada7c6970ddf580e5/.github/workflows/build.yaml#L57 -L59

然后我们可以以更有效的方式缓存 Docker 构建层。 无论如何, --cache-to--cache-from选项仅在 Docker Buildx 中可用,就像我可能想使用的许多其他选项一样

在过去,我已经成功地为 Dockerfile 中的捆绑程序启用了缓存卷,因此对 Gemfile 和 Gemfile.lock 的更改不会导致完全重新计算映像的构建时依赖项,而是从缓存构建,这样仅重新计算了新的依赖项。

虽然这显然是一个利基优化,但还有其他更常见的用例只能用 buildx 处理。 恕我直言,buildkit 工具集现在变得非常标准。 如果可以以使用 buildx 的方式调用 Kuby build,我会很高兴的!

稍后我可能会再次尝试实现这一点,现在 0.15.0 已经稳定发布,可能会更容易。 同时,还有一个 GitHub Actions 的功能示例,它是 WIP,但目前看起来相当不错: https ://github.com/kingdonb/kuby_test

通过在最后一个位置正确配置缓存以及其他一些更改,我认为这几乎可以标记并从中制作一个示例,以供回 kuby-core 或生活在 getkuby 项目中的某个地方👍

最有用的评论

好吧,如果docker build只是docker buildx的别名,那么我认为 Kuby 不需要做任何特别的事情。 应该由用户来设置他们想要的构建器。

所有6条评论

嘿!

如果您将它设置为默认 builder ,现在可以使用 buildx 。

这是一个使用 buildx 及其缓存功能的示例 Github Action: https ://github.com/anycable/anycable_rails_demo/pull/25/files#diff -28802fbf11c83a2eee09623fb192785e7ca92a3f40602a517c011b947a1822d3R28-R44

另请参阅https://eilmartians.com/chronicles/kubing-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 ,那么 $#$ lib/kuby/docker/cli.rb $#$ 中的build方法会调用buildx ,我可以传入像--cache-to这样的 buildx 结构--之后将它们放入*docker-args数组中 👍 所以可以关闭它,但 kuby-core 可能会很好地记录它如何与 buildx 一起使用,这绝对不是 kuby 的问题

以以下示例为例:

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

是的,这是可能的(这就是 GitHub Action 中的install: true所做的): https: //docs.docker.com/buildx/working-with-buildx/#set -buildx-as-the-default-建设者

好吧,如果docker build只是docker buildx的别名,那么我认为 Kuby 不需要做任何特别的事情。 应该由用户来设置他们想要的构建器。

此页面是否有帮助?
0 / 5 - 0 等级