Dockerfiles are completely optional. It's just one way to build images.
You can absolutely build images with a bash script, here's an example (its vibe slop, but it works): https://github.com/andi0b/vibe-todo/blob/main/docker-build.s...
You can absolutely build images with a bash script, here's an example (its vibe slop, but it works): https://github.com/andi0b/vibe-todo/blob/main/docker-build.s...
That script is just calling docker to build layers manually via `docker create`/`docker commit`/`docker run`/etc, using a Dockerfile as a rudimentary DSL over it. It's still building images "the way docker does", but in a more error-prone way.
What GP is trying to say with "I would've been happy with a Bash script, or handing it a tarball", is that it ought to support giving it a literal tarball, like you'd get via `make install DESTDIR=./out && tar -czf image.tgz -C ./out .`. Or just tar'ing up the build artifacts of any other existing, competent build systems. There's no need to treat building an image as some "containerized" thing where you have to run inside the bottom layer of the container to build the artifacts.
In fact nowadays with the best practice of split container builds, there's no benefit of saying "the container is guaranteed to have the dependencies because it's the container you built with", because in practice nobody wants to ship their runtime containers with an entire build environment in them. So they do one container to do the building, then pick out the artifacts they need and place them in the runtime container. At that point, what's the point of using containers to build again?
Edit: or is something stopping you from doing it this way? It seems like people just don't like Dockerfiles, but instead of just doing it differently (which is possible, it's just a tar file and a manifest), they keep complaining.
And for most people, that's a bad idea. Most people don't have to know what RPATH, ldd, multiversion/simlink library discovery, etc are. And even if they did, Dockerfiles give you an easy way to do something you couldn't easily do before: multi-stage builds and a highly robust way to say "drop the parts of my transitive hull that were only relevant at build time". Dockerfile semantics kind of descend naturally from needing the behavior of stages, parallelization, cache keying for image layers, semantic layering (FROM), and making simple use-cases relatively at-a-glance/contained.
My point is that the Dockerfile is not a particularly good build system. It doesn’t solve any of the hard parts (how to build the thing, what to build when) and only solves problems it created (how to avoid re-running something on every invocation) and does it poorly (it doesn’t track dependencies, just determines cached-not-cached on every line.) It leads to awful hacks like putting every build step on an enormous chain of `cmd && \` lines to make sure you don’t produce extraneous layers.
A reasonable build system tracks dependencies for what needs to be built and has a target it’s trying to get to. Docker just says “do your build imperatively and we’ll figure out caching” and it’s extremely easy to shoot yourself in the foot leading to overly large images.
An example: there’s no way to say “build container: do this build and put the product here, runtime container: take the product and store it here” without creating a temporary layer in the build container that is not used anywhere else. So if your artifact is 1GB, you will always require 2GB to do a build: one for the runtime container (where you want it) and one for the build container (where you only needed it temporarily.) You just have to do “docker builder prune” every now and then when your disk inevitably gets full, there’s no way to simply not produce the duplicate in the first place.
(My workaround is to keep the artifact in a type=cache mount, store its SHA sum in the build container, then in the runtime container, grab the artifact from the type=cache mount and compare the SHA sum to make sure it didn’t change. Cache mounts can be GC’d at any time so it’s not even guaranteed to work.)
When I used docker at scale back in the day, the thing that worked best was always: bind-mount an artifacts dir into the build container, run the build. Then package up the artifacts dir. Then at runtime, fetch the artifacts, bind mount them into the runtime container. Then you can use a real artifact store on a plain HTTP server instead of messing with docker layers (no more worrying about pushing 100 1KB layers because you didn’t put enough &&’s in your dockerfile) and it was so, so much faster than any docker registry was in practice.
Dockerfiles are great for simple stuff but, if I already have a great build system that produces single binaries, it’s so much more pleasant to just use that.