Using Buildpacks for cloud native deployments presented at our meetup by Suman Chakraborty

1. Making Cloud Native Deployments easy
with BUILDPACKS
Suman Chakraborty (He/Him)
VMware

2. $whoami
★ Senior Cloud Native Architect @VMware
★ Speaker at Open Source Summit (LF),
Hashitalks(HashiCorp), Devops India Summit, Docker
India Conferences
★ Involved in tech community meet-ups and talks around
DevOps, Cloud-Native tools, Kubernetes & Serverless
technologies
★ Big foodie & traveller 😊

3. What are container images ?
Container images are just layers + config files ..

4. How container image build typically
works ?
Dockerfile
• Executed as a set of runnable instructions by the docker daemon creating
the final build image
• Considered as developer’s best friend to “dockerize” polyglot application
Dockerfile native advantages :
● Faster app development
● Easier management and scaling of containers
● Speeding up incremental builds

5. Sample Dockerfile for nginx

6. Shortcomings !!
❖ Application image is bloated with extraneous cache directories.
❖ Performance bottleneck comes in speed builds
❖ Composability – Building multiple docker images, where the binary/dependencies from primary
image need to be copied 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) Not application aware
c) Mix of operation and application developer concerns
❖ Maintenance is a problem in managing multiple versions of an app as this leads to
copy-pasting code which can be error-prone and introduces the low-level concerns on the
quality of the image produced. Moreover this is tedious and time-consuming.

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

8. Cloud Native Buildpacks
Cloud Native Buildpack (CNB) project was initiated by Pivotal (now part of
Vmware Tanzu) and Heroku in January 2018. Currently it’s a CNCF
incubating project
The project serves as a vendor neutral body to unify the buildpack
ecosystems with well-defined platform-to-buildpack contract that
embraces modern container standards such as the OCI image

9. Buildpack Components
Builder :
A builder is an image that bundles all the bits and information on how to build
apps such as buildpack and build-time image.
Executes the buildpack against the app source code

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

11. 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
The metadata about OCI layers generated during
previous build are made available to buildpacks
Buildpacks use the available metadata to
generate only the OCI layers that needs to be
replaced
The remote layers are replaced by the
generated layers
Restore
This runs to fetch cache information from
previous build

12. Stack:
▪ Provides a buildpack lifecycle with build-time and run-time environment in
the form of images.
▪ Stacks are used by builders and configured through it’s configuration file

13. Image Rebase
Rebasing updates the app image’s layer metadata to reference the newer
base image whenever a new version of the app’s base image exists without
rebuild the app.

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

15. Myth: Docker daemon is required to use Buildpacks Fact: it is optional!
analyze
restore
detect
build
export
daemon or
registry access
required
15

17. kpack - Kubernetes Native Container Build Service
❖ Extends Kubernetes and utilizes unprivileged k8s primitives to provide builds of OCI images as a platform implementation of CNB
❖ Provides a declarative builder resource that configures a Cloud Native Buildpacks build configuration with the desired buildpack
order and operating system stack.
❖ In addition creates a declarative image resource that builds an OCI image and schedules rebuilds on source changes and from
builder buildpack and builder stack updates.
❖ Provides a build type to execute a single Cloud Native Buildpack OCI image build.
❖ Maintained by VMware under the VMware Tanzu project!

19. Advantages of Cloud Native Buildpacks
➔ Ensures that app meet security and compliance requirements without
developer intervention.
➔ Provide automated delivery of both OS-level and application-level
dependency upgrades.
➔ Efficiently handles day-2 app operations that are often difficult to manage
with Dockerfile
➔ Boost security and reduce risk from CVE
➔ Only re-builds and uploads layers when necessary.
➔ Supports cross-repository block mounting on Docker Registry v2

20. Thank You !!!
……Questions Please??
https://www.linkedin.com/in/schakraborty007/
@itsmesumanc