Cloud native buildpacks_collabnix

Cloud Native Buildpacks
Turn Your Code into Docker Images without Dockerfile

$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

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

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

The Pitfalls !!!!
Sample docker file for nginx

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

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

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

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

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

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

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.

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.

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 …. )

Cloud native buildpacks_collabnix

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

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

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.

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

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

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

Cloud native buildpacks_collabnix

More Related Content

What's hot (20)

Similar to Cloud native buildpacks_collabnix (20)

More from Suman Chakraborty (11)

Recently uploaded (20)

Cloud native buildpacks_collabnix