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

41–50 of 91 posts

Re: Buildpacks vs. Dockerfiles

#41

Post by ojhughes »

ransom1538 wrote: post #35

0) Dockerfile is amazing 1) Let's make something else so we can commit it, and get famous 2) buildpacks.

That's quite a cynical and uninformed view point. Buildpacks have been around since 2011 in Heroku and Cloud Foundry.

The core goal of the Paketo Buildpacks project is to improve corporate control and compliance when building OCI images. This is driven from the needs of large enterpise with many disconnected teams all pushing images.

How can an enterpise ensure all those images are built using standardised base images? How can they rebase the base image of running containers without needing every team to rebuild their image using the latest security fix? Buildpacks solves these problems. "Look, no Dockerfile" is a bit of a distraction from the projects main purpose.

Re: Buildpacks vs. Dockerfiles

#42

Post by samhuk »

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-level build chain solutions, it is absolutely necessary for many software industries that require stricter software validation.

Re: Buildpacks vs. Dockerfiles

#43

Post by ojhughes »

codefinger wrote: post #38
koeng wrote: post #36

Can 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

Skaffold also has first class support making it really easy to deploy to k8s https://skaffold.dev/docs/pipeline-stages/builders/buildpack...

Re: Buildpacks vs. Dockerfiles

#44

Post by speedgoose »

codefinger wrote: post #37
politelemon wrote: post #34

I'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…

Wow, that's a lot of bash boilerplate.

Re: Buildpacks vs. Dockerfiles

#45

Post by ojhughes »

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…

I see your point but there is nothing to stop organisations maintaining their own set of "trusted builders".

`FROM node` etc is still relying on external communities, the buck has to stop somewhere

Re: Buildpacks vs. Dockerfiles

#46

Post by nerdjon »

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 and being forced to rewrite it as a DockerFile anyways.

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. If they need more flexibility they can switch to pulling a standard image (or you have the control to improve your base image) but you are sticking with Docker Syntax.

Is there something I am missing here?

Re: Buildpacks vs. Dockerfiles

#47

Post by bfrog »

kevincox wrote: post #29
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…

I use Nix to do something similar: https://gitlab.com/kevincox/feed-test/-/blob/8b217add5fc11bb...

Same, with cross compiles! Its wonderful

Re: Buildpacks vs. Dockerfiles

#48

Post by codefinger »

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…

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

Re: Buildpacks vs. Dockerfiles

#49

Post by codefinger »

speedgoose wrote: post #44
codefinger wrote: post #37

Earlier quoted context omitted.

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…

Wow, that's a lot of bash boilerplate.

where?

Re: Buildpacks vs. Dockerfiles

#50

Post by ojhughes »

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…

Paraphrasing some of my other comments - "no Dockerfile" isn't the core benefit, it's the ability to control what base images are used and rebase the base images of running containers without needing to rebuild. It's very easy to create a Dockerfile that builds an image with vulnerabilities and it's hard to discover which containers are using the compromised image. Buildpacks provides a framework to ensure your fleet of containers use compliant images and a easy way to patch vulnerabilities without needing to involve the development team
Post reply on HN