现在大家公司 Build 镜像都喜欢用什么？ Podman？ Docker？ BuildKit？ buildpacks?

前面两个选 docker, 兼容性比 podman 好，后面 3 个没用过

公司级别的，最终还是 dockerfile 。

建议你们单独拿个系统来跑 build, 这样不用考虑 dind 和 rootless 问题，并且根据我的经验 rootless 构建出来的某些镜像可能会有问题

加一个 kaniko

dind 是什么，是已经 archived 的那个「 Docker in Docker 」的项目吗？为啥要用这个呀？
哪里解决的 Docker 难用，可以举个例子吗

@zengxs 大概会有什么问题啊

Buildah

@Nitroethane #6
表现出来的现象就是用 rootless 某些 dockerfile 构建出来的镜像用不了，运行报错 exec format error ，
同样的 dockerfile 项目，不用 rootless 就没这个问题，具体是什么原因导致的我也没搞清楚

@zengxs rootless 的容器也难用

@littlezzll 嗯嗯，但这个怎么样呢？ G 家的好不好呀？

@Nitroethane 因为实在容器里面 build 呀，就是自动化流程走 pipeline ，非本地

@zengxs 这个不该是 x86/ arm 之类的问题？你加个 platform 的 option 试试？

@sobev 这个好用吗？和 docker 比呢？

kaniko

没什么大问题

@hljjhb 和其他的比较好在哪里呢？

如果是 spring boot 我们使用 jib

kaniko

mac 上 colima
linux 上 nerdctl
windows 上 docker desktop

能选择我还是喜欢用 docker ，但是现在被迫用 kaniko 和 buildkit 在 containerd 上进行构建

用 kaniko ，不需要考虑 dind/rootless 环境问题

@aljun #15 只是为了 rootless ，构建会慢些，然后不支持交叉编译

bazel

bazel + rules_docker

buildkit 就是 docker buildx 吧，可以一下编译多个平台的很方便

kaniko

kaniko

不需要特权（ SYS_ADM,fuse,overlay ）就能跑,甚至能在 rootless 下工作,

一直都是默认的 docker ，你们更新的太快了，我快跟不上了

我们还在用 docker 且运行时也是 docker.

kaniko 还可以
从 docker build 切换到 kaniko 没啥痛点

就 docker 啊，这是已经发展到哪了，我先收藏一下

kaniko. jebkins slave 在 eci 上弹扩, kaniko 不需要 docker daemon

@zengxs 啥叫兼容性？

@Nitroethane 有些邪教徒喜欢“everything in docker”，甚至连 docker build 过程也放在 docker 内运行
所以有了 docker in docker 项目。确实解决了一些基础问题，但这需求本身其实是没啥用的

podman ，rootless 太爽了

@aljun #12 不是 platform 的问题，我在构建的机器上也运行不了

buildkit


kaniko 的痛点是慢，真的太慢了

@Bromine0x23 有什么优势呢？

@superchijinpeng 是在 docker 内跑呢，就是容器内 build

@perfectlife 为什么时被迫呢？我也是在 containerd 里，有什么区别？

@huihuimoe 那会不会有权限问题？

@abc612008 这个好像不是编译镜像的吧。。。

@Reficul bazel 好像不是编译镜像的吧，rules docker 是啥？

@yianing 是的，可以裸着用，但是日志貌似不是很方便

@clgon 有什么好处呢？

@ExplodingFKL 其他的有什么好处呢？

@loveuer 有什么好处不？

@aljun 我是在 k8s 上用 pod 去构建镜像的，运行时是 containerd 用不了挂载宿主机上 docker 的 unix socket 这种方式来，用 DinD 作为 Pod 的 Sidecar 或者使用 DaemonSet 在每个 containerd 节点上部署 Docker 这两种方式感觉都不太舒服

@BQsummer 现在都是 kaniko 吗？

@julyclyde 我是放在 containerd 里面 build ，所以需要 dind 的 image 去 run 这个

@DefoliationM 使用上方便吗？

@NaVient 感觉 buildkit 几乎就是 docker 呀

@perfectlife 我目前也差不多是这样，你有什么别的好的方案吗？

我们是在 k8s 里面构建镜像的，为了避免 dind ，用的 kaniko 。

现在用的是 docker BuildKit ，感觉还可以，就是 qemu 跨 arch 编译确实有些慢，不过这种一般都是需要编译 whl 时才涉及，还好

@aljun 各有优劣，我的需求是要能在 kubernetes 下编译镜像并且需要的权限越少越好，经过对比：

- docker/buildkit/nerdctl(containerd) : (privileged)
- podman/Buildah : (fuse) https://www.redhat.com/sysadmin/podman-inside-kubernetes
- kaniko: UID=0

所以就选了 kaniko

@aljun buildkit 使用 daemonless 可以在没有 docker 情况下构建，或者用 kaniko

@aljun #42

https://github.com/bazelbuild/rules_docker
bazel 是通用构建系统，有对应的构建规则就能构建对应的产物，没有对应的规则也可以自己编写相应的规则。

docker 镜像本质是一堆 rootfs 的分层 tar 包外加一个 manifest 文件。所以只要构建出来的文件产物符合镜像规范，就能够推送到仓库里去，而要实现这个过程 docker 环境也不是必须的，直接 curl registry 的 API 就够了。 诸如 skopeo 这种镜像工具就是类似的做法。

此外，所以如果你的程序（比如 Go 代码）支持交叉编译，交叉构建镜像也是自然支持的。因为 Dockerfile 里的 RUN 动作才是需要在当前机器的容器里跑，其他动作本质上都是在操作文件而已。

docker buildx

这么多用 kaniko 的，是没想到的

没啥特殊需求，docker buildx

@aljun https://github.com/bazelbuild/rules_docker

@Reficul @aljun
bazel rules docker 的好处是确定性。但是目前 bazel 对内存的消耗和时间效率啥的还是不如 docker 好。。。。此外要有效处理缓存机制，避免 bazel 层面 cache layer 。

这种如果不是整体做 bazel 的平台相关的话还是不推荐用

如果整体用 bazel 体系做的话会比较爽

@hxndg #62

bazel 层面 cache layer 是指的啥，按道理 layer tar 这层只会在有变化的时候发生变化，如果没有的话直接利用 bazel action 产物的缓存就够了。至于 bazel 的缓存，可以放对象存储里面，只需要启动一个 gateway 。

不过的确没有 docker 易用，需要一个人愿意花时间在里面。整体框架搭好之后，还是很爽的。

@Reficul
你们用的是 remote cache 还是 buildfarm 那一套？如果需要频繁的 integration test ，很多 bazel 的 layer 不用缓存的？
我追求效率没使用 gateway cache ，用的还是 buildfarm 本地存储之类

@hxndg

用的是 remote cache ，目前没感觉 layer 缓存有啥效率问题...