kaniko VS buildah

Kaniko Build Images in Kubernetes Without Docker For secure image builds inside CI/CD pipelines.

AFAIU this is because it manually detects changes in a given image layer by walking the directory tree. See also https://github.com/GoogleContainerTools/kaniko/issues/875

kaniko <https://github.com/GoogleContainerTools/kaniko>, ko <https://github.com/ko-build/ko>, bazel <https://github.com/bazel-contrib/rules_oci>, apko <https://github.com/chainguard-dev/apko>, or other tools.

Each of those has tradeoffs compared to Dockerfiles (I have no need for bazel, but if I did, then adding `rules_oci` might be a win-win, rather than using a Dockerfile). If I used Nix, then the Nix dockerTools would be a huge win (I don't use Nix). If I were shipping Go programs, `ko` would likely be a good baseline.

Kaniko is a tool from Google that builds container images from a Dockerfile inside a container or Kubernetes cluster without requiring privileged mode:

Buildah is another tool that can build OCI container images without requiring root privileges:

I avoid dockerfiles and prefer using buildah for building containers. Since they're all using the same specification, it doesn't matter what runtime is then used to run them: it can be docker, podman, k8s, whatever.

Here's the official example of building a lighttpd container:

https://github.com/containers/buildah/blob/92015b7f4301d7eb8...

You can eschew bash and call these commands however you want — from a python script, or Go, or even assembly.

If $PROGRAMMING_LANGUAGE = go, you might be looking for https://github.com/containers/storage which can create layers, images, and so on. I think `Store` is the main entry: https://pkg.go.dev/github.com/containers/storage#Store

Buildah uses it: https://github.com/containers/buildah/blob/main/go.mod#L27C2...

Like wayland, podman was one of those things that took a lot of "I'll give it another shot? Nope, not ready" before I could switch.

Lately the only real incompatibility I run in to with podman is that the handling of `RUN --mount=type=secret` in a Containerfile/Dockerfile is a bit broken (https://github.com/containers/buildah/issues/5282).

I wish we would rather get rid of Dockerfile in favor of something like buildah does:

https://github.com/containers/buildah/blob/main/examples/lig...

Since Dockerfile is a rather limited and (IMHO) poorly executed re-implementation of a shell script, why not rather use shell directly? Not even bash with coreutils is necessary: even posix sh with busybox can do far more than Dockerfile, and you can use something else (like Python) and take it very far indeed.

For the task of building the graph image, my first idea was to rely on buildah. In fact, our design was already heavily relying on containers/image for all things regarding copying images from one registry to the other, or from one registry to an archive. The obvious choice was to use the same suite of modules in order to keep dependencies to a minimum.

I appreciate that podman can run daemonless, but I've gotten tired of waiting for them to implement heredoc support and have continued to use docker.

You do realize that, under the hood, buildah uses a container engine (runc by default)? See https://github.com/containers/buildah/blob/main/docs/buildah...

buildah

I found this small tutorial: https://github.com/containers/buildah/blob/main/docs/tutorials/04-include-in-your-build-tool.md and it works.