codefinger
Joined 14 years ago
Karma
135
Submissions
22
Member since
Jan 10
Recent submissions
Comment · 2 years ago
Comment · 5 years ago
where?
Comment · 5 years ago
Give this a watch, and I think it may change your mind on some these points: https://www.youtube.com/watch?v=ofH9_sE2qy0
Comment · 5 years ago
I think this is exactly why people should use Buildpacks over Dockerfiles. I've seen so many Dockerfiles that are wrong, or even introduce security problems.
Comment · 5 years ago
Yes. The output of buildpacks is an OCI image (Docker image) that works with the container runtime(s) in Kubernetes
Comment · 5 years ago
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://github.com/paketo-buildpacks
Comment · 7 years ago
The Ruby buildpack shown in the example installs Node.js for you. A developer doesn’t even need to be aware that it’s required to precompile assets.
The point we're at now reminds me a lot of Java in 2010. Everything was complex--too complex--and the "best practices" led to operational toil. The 12-factor manifesto ushered in a period of simplification that brought us out of big enterprise web servers, and into containers with executable jar files.
Similarly, the cloud-native ecosystem is brimming with complexity. It's time to establish patterns that result in more scalable, portable, and maintainable apps. Updating the 12-factor is how we'll do it.