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

81–90 of 91 posts

Re: Buildpacks vs. Dockerfiles

#81

Post by nerdjon »

jacques_chester wrote: post #80
nerdjon wrote: post #77

Earlier quoted context omitted.

I am sorry but that that analogy does not work. Using candles does not add any complexity to your lighting situation. But if half of my applications can use docker and half can (for now) use BuildPacks that adds needless complications to my build and dev environment for minimal (if any) benefit.

I don't see it as a net increase in complexity. Buildpacks pay their freight and then some.

It is yet another thing to manage and train people on as part of a CI/CD pipeline and development workflow.

It would add the complication of, if I am looking at a given service needing to determine if it was built with a DockerFile or Buildpack.

And then when that application outgrows Buildpack it will ultimately be easier (due to knowledge that everyone already has working with Docker) to do whatever the special thing that application, tool, whatever needs in a DockerFile than try to understand BuildPack.

Opiniated tools are great, but time and time again when what we need deviates slightly from the "norm" they become overly complicated to manage and going with the standard option like a DockerFile would have been better in the first place.

Re: Buildpacks vs. Dockerfiles

#82

Post by sclevine »

jacques_chester wrote: post #69
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...

Additionally, Paketo's buildpacks build reproducible images given the same source code and buildpack versions.

Re: Buildpacks vs. Dockerfiles

#83

Post by sclevine »

jacques_chester wrote: post #70
harpratap wrote: post #4

Earlier quoted context omitted.

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.

This is especially true of Paketo's buildpacks, which tend to do exactly one thing each. E.g., Paketo Node.js buildpack is just a configuration file that's composed of other buildpacks: https://github.com/paketo-buildpacks/nodejs/blob/main/buildp...

Re: Buildpacks vs. Dockerfiles

#84

Post by jacques_chester »

nerdjon wrote: post #81
jacques_chester wrote: post #80

Earlier quoted context omitted.

I don't see it as a net increase in complexity. Buildpacks pay their freight and then some.

It is yet another thing to manage and train people on as part of a CI/CD pipeline and development workflow. It would add the complication of, if I am looking at a given service needing to determine if it was built with a DockerFile or Buildpack. And then when that application outgrows Buildpack it will ultimately be easier (due to knowledge that everyone already has working with Docker) to do whatever the special thi…

I believe I understand your argument, but my experiences lead me to allocate the balance of risks differently. I think buildpacks are net win in spite of the potential problems you are pointing out.

Agree to disagree?

Re: Buildpacks vs. Dockerfiles

#85

Post by jacques_chester »

e12e wrote: post #79
tikkabhuna wrote: post #26

Earlier quoted context omitted.

We've used Google Jib for Docker for the same reasons. It also means we don't have to think about the layout of our images. I know that if we went with Dockerfiles each team would put application code in different directories. There would be no consistency. Jib hides that away from us.

https://github.com/GoogleContainerTools/jib#what-is-jib > What is Jib? > Jib builds optimized Docker and OCI images for your Java applications Funny. Here I thought you could just build and deploy a jar if you were committed to writing Java... I suppose it does make sense that "all things come to docker/containers", though. Allowing both golang and Java services to be deployed in the same manner.

My view is that if you're an all-Java shop and have mature infrastructure based on JARs and WARs, stick with it. That technology is time-tested and reliable.

But if you have a mixture of technologies, the equation begins to shift towards using container images for everything.

Re: Buildpacks vs. Dockerfiles

#86

Post by jacques_chester »

corpMaverick wrote: post #78
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

Just watched that. It would solve a lot of the problems we have. But I don know where to start. We deploy using jenkins on AWS EC2 or ECS. I suppose we use the pack tool to create and then upload images to AWS S3 that are later deployed to ECS. Right ?

If you email my work address, I would be happy to introduce you to the relevant folks.

Re: Buildpacks vs. Dockerfiles

#87

Post by samhuk »

ojhughes wrote: post #45
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

I certainly agree with you there, but I was going off the article, which gave off a strong viewpoint of "Oh, you don't actually make these builders though, are you nuts?"

Any kind of technology like this tends to stick out when pitching software to financial industries, who like technologies that don't have many levels of abstraction (which to them, minimizes where they get to place accountability and the surface area for issues).

Regardless, you have a point and what you say is true. But "truth" and "financially compliant", are not terms to be mixed.

Re: Buildpacks vs. Dockerfiles

#88

Post by samhuk »

jacques_chester wrote: post #68
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 indu…

throwaway may have a good point. Also, kudos on joining VMware.

I'm not doubting your experience here, but financial security firms vary hugely on their opinions and eventual implementation of compliance.

In my experience, dealing with a business like Monzo and dealing with the back-office department of JPMorgan (these are not exact to me for security reasons), are worlds apart.

There are financial firms I've dealt with which will simply not sign off on something like the highest-of-high level build chain tools.

Re: Buildpacks vs. Dockerfiles

#89

Post by dfrey1 »

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…

As multiple people have noted, Buildpacks now are focused on creating reproducible builds. I wrote a blog post on it: https://medium.com/buildpacks/time-travel-with-pack-e0efd8bf...

Re: Buildpacks vs. Dockerfiles

#90

Post by jacques_chester »

samhuk wrote: post #88
jacques_chester wrote: post #68

Earlier quoted context omitted.

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

throwaway may have a good point. Also, kudos on joining VMware. I'm not doubting your experience here, but financial security firms vary hugely on their opinions and eventual implementation of compliance. In my experience, dealing with a business like Monzo and dealing with the back-office department of JPMorgan (these are not exact to me for security reasons), are worlds apart. There are financial firms I've dealt w…

> I'm not doubting your experience here, but financial security firms vary hugely on their opinions and eventual implementation of compliance.

I agree! That was my point: finance folks are not universally in favour of X or Y. Within any firm there is vast heterogeneity. Just as some will never accept buildpacks, some will never accept anything less.

Post reply on HN