Buildpacks IMHO suck for reproducible builds, unless you in all versions, and even then it can be hard to find out what you are really shipping. For serious (large, whatever that means) projects this is a huge problem. Docker/Containers solve this problem nicely. Developers do not have to know all the details about base images. Just build a decent base image for them once, say for JVM if that is would they need.
As others have pointed out, there I no need to use Dockers build files approach, there are plenty of better alternatives out there.
Buildpacks vs. Dockerfiles
31–40 of 91 posts
Re: Buildpacks vs. Dockerfiles
#32During the last 3 years I've had the pleasure of using Bazel's rules_docker to generate all my container images ( https://github.com/bazelbuild/rules_docker ). In a nutshell, rules_docker is a set of build rules for the Bazel build system ( https://bazel.build ). What's pretty nice about these rules is that they don't rely on a Docker daemon. They are rules that directly construct image tarballs that you can either l…
We use Bazel’s rules_docker as well, and I would caution someone evaluating it with a note from out experience.
What Bazel does well (and as well as Bazel fits your use-case) Bazel does extremely well and is a reproducible joy to use.
But if you stray off that path even a tiny bit, you’re often in for a surprisingly inexplicable, unavoidable, far-reaching pain.
For example, rules_docker is amazing at laying down files in a known base image. Everything is timestamped to the 1970 unix epoch, for reproducibility, but hey, it’s a bit-perfect reproduction.
Need to run one teensy executable to do even the smallest thing that’s trivial with a Dockerfile? Bazel mist create the image transfer it to a docker daemon, run the command, transfer it back... your 1 kb change just took 5 minutes and 36 gb of data being tarred, gzipped, and flung around (hopefully-the-local) network.
It may not be a dealbreaker, and you may not care, but be forewarned that these little surprises creep up fairly ofen from unexpected quarters!
Re: Buildpacks vs. Dockerfiles
#33Earlier quoted context omitted.
Might have been an intentional mistake ? It fits the arguments pro build-packs.
The RUN? I thought about that but I don’t see how that would work. Or is the argument that Dockerfiles are just too hard? (An argument I’m not unsympathetic to)
Yeah, argument is they might be prone to errors.
Re: Buildpacks vs. Dockerfiles
#34I've read through this but I'm not sure I'm seeing any advantages to Buildpack.
First point - I see an example of a Dockerfile in TFA, but when it comes to the example of a Buildpack there isn't one; I just see a conceptual description of an abstraction. It appears that a lot of the inference is hidden away by use of 'detection' but is there magic hidden underneath? Does it allow arbitrary hacky steps if needed, like adding a random certificate?
Second point - A Dockerfile explicitly codifies what's happening. I can look at it and know how the build will go or what I need to change. The Buildpack equivalent would be spread across many different files, does that sound about right?
Re: Buildpacks vs. Dockerfiles
#350) Dockerfile is amazing
1) Let's make something else so we can commit it, and get famous
2) buildpacks.
Re: Buildpacks vs. Dockerfiles
#36Can I use buildpacks with Kubernetes? When I look for it online, I find some stuff like the Cloud Native Buildpacks, but no good simple tutorials on how it actually works. I remember Dokku was a joy to use, wish I could interact with Kubernetes like I did with Dokku.
Re: Buildpacks vs. Dockerfiles
#37I've read through this but I'm not sure I'm seeing any advantages to Buildpack. First point - I see an example of a Dockerfile in TFA, but when it comes to the example of a Buildpack there isn't one; I just see a conceptual description of an abstraction. It appears that a lot of the inference is hidden away by use of 'detection' but is there magic hidden underneath? Does it allow arbitrary hacky steps if needed, like…
To you first point, there's probably no example of a Buildpack because (unlike Dockerfile) most Buildpack users don't write their own. They are reuseable. I'm not sure why the author didn't include an example of running a buildpack against an app though.
To your second point, Buildpacks are written in code too. But unlike Dockerfile, they use real programming languages that you can write tests for.
For example: https://github.com/paketo-buildpacks
Re: Buildpacks vs. Dockerfiles
#38Can I use buildpacks with Kubernetes? When I look for it online, I find some stuff like the Cloud Native Buildpacks, but no good simple tutorials on how it actually works. I remember Dokku was a joy to use, wish I could interact with Kubernetes like I did with Dokku.
Yes. The output of buildpacks is an OCI image (Docker image) that works with the container runtime(s) in Kubernetes
Re: Buildpacks vs. Dockerfiles
#39I’m sure it’s usually just a case of “thinking while typing”, but I find it surprising how often articles about Docker stuff get some basic details a bit wrong. In the very first code example there is a RUN instruction where the author probably meant to have a CMD instruction, and they talk about BuildKit and build cache optimisation even though that was always something to think about, way before BuildKit was a thin…
I think this is exactly why people should use Buildpacks over Dockerfiles. I've seen so many Dockerfiles that are wrong, or even introduce security problems.
Re: Buildpacks vs. Dockerfiles
#40Relying on something like paketo may or may not be a great idea. I decided to give it a go on a little PHP 8 project. I get an error saying PHP 8 isn't supported as it's using 0.1.0 of the PHP buildpack. Then I go to file an issue (especially since PHP 8 has been available for several months), only to discover it was released 4 days ago[1]. This kind of turns me off to relying on it. What if there was a vulnerability in PHP 8? Would I want my software to wait at least 4 days before I could update my dependencies?
You give up a lot of control for "simplicity" but I'm not sure simple is always better. Sometimes it is, but often it's deceptive.
[1]https://github.com/paketo-buildpacks/php-dist/releases/tag/v...