An overview of the Cloud Native Buildpack, a sandbox project from CNCF. We discuss here what is the shortcomings of dockerfile, how buildpacks are used in general, intro to Cloud Native Buildpacks, Demo & Usecases
Cloud Native Buildpacks
Turn Your Code into Docker Images without Dockerfile
Suman Chakraborty - Senior Devops
Engineer @SAP Labs
Community member & Speaker -
Docker Bangalore, CNCF Bangalore
Tech Blogger on PaaS, Cloud-Native
Dockerfile and its short-comings
Intro to Buildpacks
Deep-dive into Cloud-Native Buildpacks (CNB)
Demo & Use-Case
Why should we use CNB over traditional Dockerfiles
Dockerfile & it’s pitfalls
• Dockerfile has been developer’s best friend to “dockerize” applications written in
polyglot runtime development frameworks
• Dockerfile maintains a set of runnable instructions that tells Docker Daemon how
to build the image that will be used to create containers.
Dockerfile best practices :
Reduce image size
Speed up incremental builds
Pickup the base image
A simple Dockerfile is enough to run an application in production, but the image
will be bloated with extraneous cache directories.
When there is an application code change, extra layers of dependency gets added
to the docker image execution.
The bottleneck comes here is in speed builds, as a Dockerfile can’t properly make
use of those cache directories because a rebuild takes everything or nothing.
Selectively adding the relevant files would mitigate the problem , but replicating
the solution for every app that needs a Dockerfile is tedious and time-consuming.
Maintenance is another bottleneck for Dockerfile while managing multiple
versions of an app as this leads maintainers/Devops engineers to copy-pasting
code which can be error-prone and introduces the low-level concerns on the
quality of the image produced.
Dockerfile Shortcomings !!!!
Not application aware - Without context about the application or the frameworks being use, there's a
giant mismatch between how a developer builds an application and the tools they use to deploy that
Composability – Building multiple docker images, where the binary/depencies from primary image
need to be copy to second image. Using multi-stage builds, it is achievable, but again susceptible to
> No environment variables.
> Doesn’t follow symlinks
> Only copying FS layers manually (can’t copy arbitrary layers/files/dir)
Leaky Abstraction -
a) Poor tool for app developers who want to write code
b) Authoring a good Dockerfile needs good amount of knowledge on underlying mechanism
c) Mix of operation and application developer concerns
Intro to Buildpacks
Buildpacks are pluggable, modular tools
that translate source code into OCI (Open
Container Initiative) native format
Provides a higher-level abstraction for
building apps compared to Dockerfiles.
Uses builder to bundle all the bits and
information against the source code to
create the final artifact (droplet/slug)
Buildpacks were first conceived by Heroku
in 2011. Since then, they have been
adopted by Cloud Foundry and other
PaaS such as Gitlab, Knative, Deis, Dokku,
Cloud Native Buildpacks
Cloud Native Buildpack (CNB) project was initiated by Pivotal and Heroku in
January 2018 and joined the CNCF Sandbox project in October 2018.
The project serves as a vendor neutral body to unify the buildpack ecosystems
with a platform-to-buildpack contract that is well-defined and embrace modern
container standards, such as the OCI image format.
CNB allows cross-repository blob mounting and image layer "rebasing" on Docker
API v2 registries
A builder is an image that bundles all the bits and information on how to build apps
such as buildpacks and build-time image.
Executes the buildpacks against the app source code
It is a unit of work that inspects app source code and formulates a plan to build and
run your application
Buildpack comprises three files for execution
buildpack.toml : provides metadata about the buildpack
bin/detect: determines whether buildpack should be applied
bin/build: executes buildpack logic
The lifecycle orchestrates buildpack execution, then assembles the resulting artifacts
into a final app image.
Here an optimal selection of
compatible buildpacks are chosen and
a build plan is created
Where metadata about OCI layers
generated during previous build are
made available to buildpacks
Where buildpacks use that metadata
to generate only the OCI layers that
needs to be replaced
Where the remote layers are replaced
by the generated layers
A stack provides the buildpack lifecycle with build-time and run-time
in the form of images.
Stacks are used by builders and are configured through a builder’s configuration
Buildpacks are compatible with one or more stacks. A stack designates a build
image and a run image. During the build process, a stack’s build image becomes
the environment in which buildpacks are executed and its run image becomes
base for the final app image.
Rebase allows app developers or operators to rapidly update an app image when
its stack's run image has changed. By using image layer rebasing, this command
avoids the need to fully rebuild the app.
Rebasing detects an app image and determines whether or not a newer version of
the app’s base image exists (either locally or in a registry). If so, rebase updates the
app image’s layer metadata to reference the newer base image version.
Building Cloud Native App
Selecting a builder (pack
Building the app image
(pack build sample-app --builder
Run the application
( docker run –d …. )
Why use Buildpacks when Dockerfile in
** Separation of Concerns **
Dockerfile approach Buildpack approach
Developer takes full responsibility to
define the whole application stack
Buildpack enhances developer efficiency by
allowing developers to focus on the application
alone by examining the app to determine what
dependencies to download and how to
configure the apps to communicate with
Day 2 Operations / Security Patching
Existing OS Updated OS
Here, the developer needs to get involved and the container image needs rebuilt. All of the assets that were
used to build the image need to be re-used with updates applied, even if they effect multiple container images
The admin applies the update to build process in platform that can happen without having to sidetrack
Advantages of Buildpacks
Provide a balance of control that reduces the operational burden on developers
and supports enterprise operators who manage apps at scale.
Ensure that apps meet security and compliance requirements without developer
Provide automated delivery of both OS-level and application-level dependency
upgrades, efficiently handling day-2 app operations that are often difficult to
manage with Dockerfiles
Rely on compatibility guarantees to safely apply patches without rebuilding
artifacts and without unintentionally changing application behavior.
Only re-builds and uploads layers when necessary. Support cross-repository
block mounting on Docker Registry v2
Fast Builds, minimal data transfer, layer “rebasing” directly on the container