Live data from Hacker News

Buildpacks vs. Dockerfiles

technology.doximity.com

11–20 of 91 posts

Re: Buildpacks vs. Dockerfiles

#11

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…

Performance is the challenge. Caching node_modules in Docker is a little tricky. The alternative is adding minutes to your build and deploy vs seconds.

Re: Buildpacks vs. Dockerfiles

#12
post #8

What are some hosting providers providing build packages support? Google and Heroku were mentioned in the article. I've also had a good experience with self-managed Dokku deployment. Are there any managed service providers that support buildpack deployment?

NodeChef. https://www.nodechef.com/ - Supports all Cloud Foundry and Heroku build packs.

Re: Buildpacks vs. Dockerfiles

#13

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…

Sounds similar to podman [1] which also doesn't require a daemon (though you can run it with one if you like).

[1] https://podman.io/getting-started/

Back to the original article, I prefer dockerfile-based builds as it allows me to run my own tests easily on the image locally before uploading.

Can this be done with buildkits?

Re: Buildpacks vs. Dockerfiles

#14

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…

There is plenty of terrible Dockerfile out there. I would vastly prefer to see images or Dockerfile generated by some well written buildpacks. I like to think about buildpacks as reasonably written Docker templates.

Yours is 5 lines long, but many are others are more complex and could benefit from having a multistage (base stage with common dependencies, build phase with build dependencies, run time with the result of the previous plus some extra runtime dependency), setting up a custom user/group for extra security, optimizing execution order which vastly affect the time to build the image, etc.

I am considering using them to make easier for my colleagues which are not used to Docker to containerize their application as well as using them as template system for Dockerfile handled centrally, which do not need any kind of manual merge/alignment afterwards.

Re: Buildpacks vs. Dockerfiles

#15

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…

Another advantage of buildpacks is the ability to easily “rebase” an image layer to update dependencies (eg JDK) without rebuilding the whole image. https://buildpacks.io/docs/concepts/operations/rebase/

The Java buildpack also calculates optimal JDK memory flags based on available resources

Re: Buildpacks vs. Dockerfiles

#16
post #9

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)

I think there is rarely a reason to choose this over just a standard Dockerfile, which is usually not that complicated and probably wont change much over time once it has been implemented. If generating Dockerfiles needs to be scaled up somehow, I can understand why this would be useful. Sounds exactly like a problem someone like Heroku would have.

Heroku actually invented buildpacks

Re: Buildpacks vs. Dockerfiles

#17
Compliance is a big reason for enterprises to adopt buildpacks. It’s hard for organisations to assure all code is built using only approved or up to date dependencies. Dockerfile makes it very easy to package vulnerable libraries and difficult to verify which containers are vulnerable. Scanning works but better to not push vulnerable code in the first place

Re: Buildpacks vs. Dockerfiles

#18

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

You can always start from the generated image (which contains the steps used to build it) and extend it in your custom Dockerfile if your project gets so big, right?

Re: Buildpacks vs. Dockerfiles

#20
I’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 thing.

I’m not trying to say I know everything or that the article is wrong or bad, but it’s an observation I’ve made.

Post reply on HN