This document introduces Cloud Native Buildpacks as an alternative to Dockerfiles for building container images. It discusses the shortcomings of Dockerfiles, such as being non-application aware, lacking composability, and mixing operational and developer concerns. Cloud Native Buildpacks provide a higher level abstraction that allows developers to focus on their code while buildpacks handle dependencies and configuration. Buildpacks examine source code and formulate a build plan. The buildpack lifecycle then assembles artifacts into a final image. Buildpacks provide advantages like separation of concerns, faster incremental builds, and automated dependency updates.

1. Cloud Native Buildpacks
Turn Your Code into Docker Images without Dockerfile

2. $whoami
 Suman Chakraborty - Senior Devops
Engineer @SAP Labs
 Community member & Speaker -
Docker Bangalore, CNCF Bangalore
group
 Tech Blogger on PaaS, Cloud-Native
& Microservices
https://www.linkedin.com/in/
schakraborty007/
@itsmesumanc

3. Agenda
 Dockerfile and its short-comings
 Dockerfile alternatives
 Intro to Buildpacks
 Deep-dive into Cloud-Native Buildpacks (CNB)
 Demo & Use-Case
 Why should we use CNB over traditional Dockerfiles

4. 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

5. The Pitfalls !!!!
Sample docker file for nginx

6.  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.

7. 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
app.
 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
following :
> 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

8. Dockerfile Alternatives

9. 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,
and Drie

10. Buildpacks Ecosystem

11. 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

12. CNB : An Open Standard

13. Buildpack Components
Builder :
 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

14. Buildpack:
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

15. New Buildpack API

16. Lifecycle :
The lifecycle orchestrates buildpack execution, then assembles the resulting artifacts
into a final app image.
Detect
Export
Analysis
Build
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

17. Stack:
 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
file
 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.

18. Image Rebase
 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.

19. Building Cloud Native App
Selecting a builder (pack
suggest-builders)
Building the app image
(pack build sample-app --builder
<builder_name>)
Run the application
( docker run –d …. )

21. Why use Buildpacks when Dockerfile in
place
** 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
bound services

22. Day 2 Operations / Security Patching
Droplet/Artifact
App Layer
BP Layers
Existing OS Updated OS
ABI
compatible

23. Dockerfile approach
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
Buildpack approach
The admin applies the update to build process in platform that can happen without having to sidetrack
development.

24. 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
intervention.
 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

25. RESULT
Fast Builds, minimal data transfer, layer “rebasing” directly on the container

26. References
 https://blog.heroku.com/docker-images-with-buildpacks
 https://buildpacks.io/docs/
 https://www.youtube.com/watch?v=WTE8iu_vnbk

27. THANK YOU