Cloud Native Buildpacks allows you to transform your source code into container images that can run on any cloud. This allows a dedicated team to take care of all build-related tasks, instead of having the application developers write their own Dockerfiles.
Concepts
Before we can get started, a few core concepts need to be explained.
Buildpack: software that transforms the source code into a runnable artifact. Builder: an OCI image that runs buildpacks to produce the runnable artifact.
Getting started
Pack is an implementation of the Cloud Native Buildpacks Platform Specification that requires both Pack and Docker to be installed.
The sample application didn’t even work on my workstation. The error indicated an issue with my container being out of memory. In order to figure out why this is happening we need to find the Dockerfile of the builder in the first place.
Strengths
Using Buildpacks you can specify a specific builder image that makes sure that every security requirement is met. Developers no longer need to think about building container images.
Weaknesses
I would rather keep it simple by having a clear Dockerfile defined in your repository so that you actually see what is happening. In theory the idea is nice, in practice there will be use-cases where exceptions for certain projects are required. You don’t want to create multiple build images for the same language, so instead these exceptions will probably be included inside the builder image, which can lead to a lot of bloat.