I never really used Docker much, but I really like buildah (from the same group as podman). It doesn’t have the one-command-one-layer problem that Dockerfiles do, creating layers is explicit. It also doesn’t constrain you to driving the build from a limited scripting language, you can write shell (or Python, Ruby, or whatever) scripts to drive it, which makes it easy to have parameterised container builds.
It also has a load of nice tweaks in the command language. For example, its copy command can copy from one image to another. This makes it easy to organise builds of dependencies in containers and then have them copy their output into other containers, so each build step runs in a pristine environment.
Wherever you have a DAG, you gona eventually have the need to run it distributedly… then all sorts of problems related to caching, and scheduling optimization started to come up.
Are we re-drawing circles? It feels dejavu, like we are remaking Bazel with Docker/BuildKit?
In a way – yes, but I don’t think that’s terrible. BuildKit gets things right that Bazel doesn’t: sandboxing (container vs. sandboxfs), debuggable (exec container vs. ??), imperative escape hatch (RUN vs. pre-build scripts), flexible configuration (frontends vs. starlark). While docker registries aren’t the best shared build cache layer, it’s something that’s already in widespread use (vs. a bazel build server).
I think Kaniko deserves at least an honorable mention for being a docker builder that emulates the steps (yes it does it from within the context of a running OCI container… but not “docker in docker” so I think it counts).
The process of building OCI images in ephemeral workers without strong system access is a hard one.
I actually announced the public release of kaniko in that talk (my team at Google built it). I did mention the strategy of “skipping the runtime” in the post, which is what kaniko does. Good idea at the time, but the state of the art in unprivileged builds has come a long way, so it’s no longer necessary imo.
Very cool! I do like the idea of building containers without container runtimes, but at the same time popping code into a container is a little bit nicer from an ops perspective (you get to declare your environment)
Some prior art in the form of Nixpkgs’s dockerTools: http://ryantm.github.io/nixpkgs/builders/images/dockertools/
No mention of Podman?
I never really used Docker much, but I really like buildah (from the same group as podman). It doesn’t have the one-command-one-layer problem that Dockerfiles do, creating layers is explicit. It also doesn’t constrain you to driving the build from a limited scripting language, you can write shell (or Python, Ruby, or whatever) scripts to drive it, which makes it easy to have parameterised container builds.
It also has a load of nice tweaks in the command language. For example, its copy command can copy from one image to another. This makes it easy to organise builds of dependencies in containers and then have them copy their output into other containers, so each build step runs in a pristine environment.
Wherever you have a DAG, you gona eventually have the need to run it distributedly… then all sorts of problems related to caching, and scheduling optimization started to come up.
Are we re-drawing circles? It feels dejavu, like we are remaking Bazel with Docker/BuildKit?
In a way – yes, but I don’t think that’s terrible. BuildKit gets things right that Bazel doesn’t: sandboxing (container vs. sandboxfs), debuggable (exec container vs. ??), imperative escape hatch (RUN vs. pre-build scripts), flexible configuration (frontends vs. starlark). While docker registries aren’t the best shared build cache layer, it’s something that’s already in widespread use (vs. a bazel build server).
I think Kaniko deserves at least an honorable mention for being a docker builder that emulates the steps (yes it does it from within the context of a running OCI container… but not “docker in docker” so I think it counts).
The process of building OCI images in ephemeral workers without strong system access is a hard one.
I actually announced the public release of kaniko in that talk (my team at Google built it). I did mention the strategy of “skipping the runtime” in the post, which is what kaniko does. Good idea at the time, but the state of the art in unprivileged builds has come a long way, so it’s no longer necessary imo.
Very cool! I do like the idea of building containers without container runtimes, but at the same time popping code into a container is a little bit nicer from an ops perspective (you get to declare your environment)