Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Buildpacks vs. Dockerfiles

technology.doximity.com

Post reply on HN
Print view View original

61–70 of 91 posts

Re: Buildpacks vs. Dockerfiles

#61

Post by goodoldneon »

kkapelon wrote: post #52
codefinger wrote: post #48

Earlier quoted context omitted.

Give this a watch, and I think it may change your mind on some these points: https://www.youtube.com/watch?v=ofH9_sE2qy0

Since this is 30mins, could you please provide at TL;DW ?

Buildpacks has some nice features, at the expense of deviating from an industry standard (Dockerfiles). The speaker implies that Dockerfiles are fine if they're fine, but Buildpacks is attractive if you want more control over your Docker image build process.

Composite images. Don't need a Dockerfile for each app. Rebase layers when OS layer changes (Dockerfiles would require rebuilding the whole image).

Re: Buildpacks vs. Dockerfiles

#62

Post by MuffinFlavored »

an_d_rew wrote: post #32
EdSchouten wrote: post #5

During 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 file…

> But if you stray off that path even a tiny bit, you’re often in for a surprisingly inexplicable, unavoidable, far-reaching pain.

Not to go off on a tangent, but I feel like this is true for most packages/alternatives to mainstream solutions (at least in node.js)

Re: Buildpacks vs. Dockerfiles

#63

Post by jacques_chester »

EdSchouten wrote: post #5

During 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…

> What's pretty nice about these rules is that they don't rely on a Docker daemon.

Neither do Cloud Native Buildpacks. The lifecycle can run as a regular process inside a container. The `pack` CLI tool uses docker as a convenient way to run those containers on a local environment. But if something else creates the containers, that's fine, the lifecycle works exactly the same.

FWIW there is a lot of cross-pollination of ideas between ko, Jib, rules_docker and CNB folks.

Re: Buildpacks vs. Dockerfiles

#64

Post by jacques_chester »

nerdjon wrote: post #46

Reading the article I am still struggling to understand why exactly you would transition away from something that has a ton of community support and a lot of people use (you are more likely to find a developer with Docker experience than Buildpack). This just seems like a more opinionated DockerFile that doesn't give you the power to change things that you may need. You will end up being stuck somewhere down the road…

> Reading the article I am still struggling to understand why exactly you would transition away from something that has a ton of community support and a lot of people use (you are more likely to find a developer with Docker experience than Buildpack).

Cloud Native Buildpacks (CNBs) are supported by fulltime teams at both VMware and Salesforce/Heroku. Google now chips in, I expect more folks will join as time goes on. Buildpacks are already a CNCF project and Paketo buildpacks are a CFF project, openly governed and not owned by any company.

Dockerfiles, by contrast, are defined by one company.

> This just seems like a more opinionated DockerFile that doesn't give you the power to change things that you may need.

You can extend CNBs pretty easily, they are designed to compose. Joe Kutner from Heroku has been particularly active in demonstrating extensions:

https://github.com/jkutner/web-tty-buildpack

https://github.com/jkutner/no-secrets-buildpack

https://github.com/jkutner/ngrok-buildpack

These are features composable with any other set of buildpacks. Java, Ruby, NodeJS, etc. You won't need to implement N ecosystems * M features. You implement N + M instead and get to enjoy N * M value.

> If you really want to make it easier for your engineers, stick with a DockerFile and have a couple common internal images that they pull from instead and just put their code in.

I've seen this done at large scale. Enormous, elaborate build systems, strict rules (which incidentally negate "flexibility" as a feature), linters, pipelines for updating things. It's slow, brittle, expensive and basically ... you reinvent what buildpacks already gives you. Except that they require more rebuilds vs layer rebasing and will require more disk space to be used for almost-but-not-quite-identical layers.

Disclosure: I've worked on 2 generations of buildpack technology. I've worked on large Dockerfile setups. Buildpacks are legit.

Re: Buildpacks vs. Dockerfiles

#65

Post by jacques_chester »

nerdjon wrote: post #55
codefinger wrote: post #48

Earlier quoted context omitted.

Give this a watch, and I think it may change your mind on some these points: https://www.youtube.com/watch?v=ofH9_sE2qy0

Watching this now. Some comments while watching. I disagree with using the Python Image as an example of an issue with DockerFiles. Since that is something that as me pulling the Python image I don't need to take care of and that would be the same as any "gynastics" that Buildpack may be taking care of behind the scenes (If I understand what you were showing correctly). You mention issues with images and vulnerabilit…

> But nothing about this changes my opinion that this is an opinionated builder that when you get to the point that you need to do something a bit funky or weird in your application or build process you will end up needing to ditch it and build a Dockerfile anyways.

"Sometimes there's a power outage, so I am forced to use candles anyhow. Therefore I should only use candles for lighting."

Re: Buildpacks vs. Dockerfiles

#66

Post by jacques_chester »

speedgoose wrote: post #60
codefinger wrote: post #49

Earlier quoted context omitted.

where?

https://github.com/paketo-buildpacks/go/search?l=shell for example. But the situation on many Dockerfile may not be better I have to admit.

These are for Github actions, taken from a shared repo: https://github.com/paketo-buildpacks/github-config

Re: Buildpacks vs. Dockerfiles

#67

Post by jacques_chester »

jillesvangurp wrote: post #6
Lucasoato wrote: post #3

Which advantages does buildpacks offer vs Dockerfiles? > Familiarity with Docker and Dockerfile syntax is not universal. Even those with experience may not be equipped to write a Dockerfile that can quickly build (and rebuild) a small and secure image. Are there any others besides writing a dockerfile? (which can be non-trivial, I'm not underestimating it)

This sounds like just moving the problem. The author makes it seem like writing a Dockerfile is somehow such a burden on development teams when in reality it's a rounding error on the overall development time spent on a project. Ours is about five lines long. Copy the files, define some environment variables and a port, done. Not exactly rocket science. Part of the problem stems from trying to roll CI into the Docker…

> This sounds like just moving the problem. The author makes it seem like writing a Dockerfile is somehow such a burden on development teams when in reality it's a rounding error on the overall development time spent on a project. Ours is about five lines long. Copy the files, define some environment variables and a port, done. Not exactly rocket science.

Dockerfiles appear trivial and they usually start trivial, but they don't remain trivial for long[0]. In particular it is very, very easy to inadvertently write a Dockerfile that is insecure, or wasteful of space, or promotes build churn, or most frequently: all three.

All the tips and tricks that folks need to know in order to write production grade Dockerfiles are given for free in a buildpack. You don't need to think about the efficient ordering and contents of layers, the buildpack does it. You don't need to worry about mystery dependencies arriving via `wget`, buildpacks control what dials out to the outside world. Build churn is dropped to the minimum necessary changes, rather than the minimum possible changes. Disk space and network traffic is saved because far more layers are identical.

[0] See "Problem" of this document I wrote a few years ago: https://docs.google.com/document/d/1M2PJ_h6GzviUNHMPt7x-5POU...

Re: Buildpacks vs. Dockerfiles

#68

Post by jacques_chester »

samhuk wrote: post #42

One of the purported benefits is security, however from my experience in the financial software industry, I have to say - good luck getting your software validated where a major part of it's build chain is from an external "community". politelemon here is spot-on in this regard: dockerfiles provide a higher level of transparency. Although they do have a higher developer-error surface area compared to more higher-leve…

> One of the purported benefits is security, however from my experience in the financial software industry, I have to say - good luck getting your software validated where a major part of it's build chain is from an external "community".

Paketo buildpacks are the latest generation in a series of buildpack technogies that have made Pivotal (now VMware) hundreds and hundreds of millions of dollars from the finance industry. Heroku/Salesforce could have made much more. Google will almost certainly make as much.

Finance security and compliance folks love buildpacks. Love. If they loved them any more they would get tattoos and name their kids See Enbee.

Disclosure: I work for VMware, via the Pivotal acquisition. I've worked on buildpacks several times.

Re: Buildpacks vs. Dockerfiles

#69

Post by jacques_chester »

kohlerm wrote: post #31

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 o…

You may be thinking of earlier generations.

Cloud Native Buildpacks (1) have reproducibility as a design constraint[0][1] and (2) produce container images as their output.

[0] https://buildpacks.io/docs/reference/reproducibility/

[1] https://medium.com/buildpacks/time-travel-with-pack-e0efd8bf...

Re: Buildpacks vs. Dockerfiles

#70

Post by jacques_chester »

harpratap wrote: post #4
LukaszWiktor wrote: post #2

Finally some simplification in the development tooling!

Buildpacks have been in the industry for many years (thanks to cloud foundry) but it doesn't really scale. For simple things, sure they are good enough but more often than not you want to your application to be packed in a special way and you end up putting more efforts than using simple Dockerfiles

This was definitely true of previous generations, where each buildpack needed lots of magic to play nice with others and you needed to fork them if you wanted a particular feature.

CNBs are easily composable, partly because of that experience. No more forking necessary.

Post reply on HN