Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cloud native buildpacks_collabnix


Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Cloud native buildpacks_collabnix

  1. 1. Cloud Native Buildpacks Turn Your Code into Docker Images without Dockerfile
  2. 2. $whoami  Suman Chakraborty - Senior Devops Engineer @SAP Labs  Community member & Speaker - Docker Bangalore, CNCF Bangalore group  Tech Blogger on PaaS, Cloud-Native & Microservices schakraborty007/ @itsmesumanc
  3. 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. 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. 5. The Pitfalls !!!! Sample docker file for nginx
  6. 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. 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. 8. Dockerfile Alternatives
  9. 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. 10. Buildpacks Ecosystem
  11. 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. 12. CNB : An Open Standard
  13. 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. 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. 15. New Buildpack API
  16. 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. 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. 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. 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 …. )
  20. 20. 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
  21. 21. Day 2 Operations / Security Patching Droplet/Artifact App Layer BP Layers Existing OS Updated OS ABI compatible
  22. 22. 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.
  23. 23. 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
  24. 24. RESULT Fast Builds, minimal data transfer, layer “rebasing” directly on the container
  25. 25. References   
  26. 26. THANK YOU