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 vulnerabilities, but I fail to see how exactly BuildPack magically addresses this issue other than claiming that it just isn't an issue because it is "better".
IMO in the beginning it sounds like you are determined to make managing a Dockerfile as hard as possible when it really is not.
If one of your arguments is that having the choice of images (different applications have different needs even if they are the same language) is an issue your argument is fundamentally flawed. Yes there are a lot of tags for images, but they are fairly well organized for most of them and should not take long to find what you want to use.
It is great that BuildPack produces a standard Docker Image. 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. I don't see what benefit this has to an internally built docker image that we use in our applications so the Dockerfiles in the dev's repos are 10 lines max.
Using a "From" image for DockerFile is just as reusable as Buildpack, so that is not an advantage. Again near the end you claim BuildPack is "safe" but why and how?
If you are using Docker and your mitigation of something like heart bleed is "years" (for your images at least) your not using Docker properly and is likely a flaw in your CI pipeline and not something that this tool will magically fix since the issue is somewhere else in your pipeline (including people in that pipeline).
> 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."
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.
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.
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.
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 ?
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).
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 vulnerabilities, but I fail to see how exactly BuildPack magically addresses this issue other than claiming that it just isn't an issue because it is "better".
IMO in the beginning it sounds like you are determined to make managing a Dockerfile as hard as possible when it really is not.
If one of your arguments is that having the choice of images (different applications have different needs even if they are the same language) is an issue your argument is fundamentally flawed. Yes there are a lot of tags for images, but they are fairly well organized for most of them and should not take long to find what you want to use.
It is great that BuildPack produces a standard Docker Image. 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. I don't see what benefit this has to an internally built docker image that we use in our applications so the Dockerfiles in the dev's repos are 10 lines max.
Using a "From" image for DockerFile is just as reusable as Buildpack, so that is not an advantage. Again near the end you claim BuildPack is "safe" but why and how?
If you are using Docker and your mitigation of something like heart bleed is "years" (for your images at least) your not using Docker properly and is likely a flaw in your CI pipeline and not something that this tool will magically fix since the issue is somewhere else in your pipeline (including people in that pipeline).