Speed, security and simplicity - Creating Container Images with Cloud Native Buildpacks

Buildpacks are a pluggable, modular, language-agnostic tool that takes application source code and in turn give you an OCI (Open Container Initiative) image which you can run using Docker, Kubernetes or your OCI Runtime of choice.

Developers: You no longer need to worry about tedious tasks like finding trusted images, installing/updating packages, adding agents and monitoring tools and writing Dockerfiles. You write code and buildpacks take care of the rest.

The higher-level abstraction of buildpacks allows you, as a developer, to focus less time on building containers and more time being productive, writing code and providing value for your employer.

Too good to be true? Don't believe it? Come check out this session! It will explore how Cloud Native Buildpacks work, you'll see examples of how you can use them to create images from source code in your favorite languages, and you'll learn how to integrate buildpacks into common development workflows.

Demo Instructions: https://gist.github.com/dmikusa-pivotal/67eb684ea3d3606cee6db5995ba4c4e3

Transcript

1. © Copyright 2019 Pivotal Software, Inc. All rights Reserved. Cloud Native Buildpacks Speed, security and simplicity: Creating Container Images with Cloud Native Buildpacks Daniel Mikusa <dmikusa@pivotal.io>
2. Goals I hope you will learn about... Problems CNB’s Solve How To Use Them Developer Workflow Demos!
3. Cloud Native Buildpacks, why?
4. Dockerfile Challenges Base Images • Do you trust them? • Are your images reproducible? • Which ones are you using again?
5. Dockerfile Challenges • Every project has its own Dockerfile • A single change has to be made everywhere • Promotes work by copy & paste • The best Dockerfile is the one you just wrote • Subtle nuances cause undesired behaviors • OK for a small number of projects, doesn’t scale. How do you audit them? • Want to make a change? You would have to edit many Dockerfiles across many projects. Did you forget one? • Not going to create them from scratch every time, so copy & paste mistakes & all. • New Dockerfiles tend to get some love and attention. Maybe a fix or new technique. That doesn’t tend to be ported back to all the other Dockerfiles • Like using build layers for smaller images and all these “best practices”
6. Dockerfile Challenges • Where is the value line? • Is time spent managing your fleet of Dockerfiles providing value? • Is that productive time?
7. How Cloud Native Buildpacks Can Help • No more Dockerfiles • Very small number of base images, provided by trusted authorities • Built images are tagged with metadata so you know what’s in them • Cloud Native Build packs are versioned, so you can reproduce them • Consistency is provided by the CNB, not copy and paste • Cloud Native Buildpack codify best practices, no need to remember them • Automated and easy to integrate into CI or Kubernetes • Speed! ◦ Cloud Native Buildpacks aggressively cache ◦ Prevent unnecessary rebuilds ◦ Can rebase an application when the base image change
8. Concepts
9. A Buildpack The official definition...
10. More about Buildpacks Two Types: • Classic Buildpack ◦ Consists of three files: buildpack.toml, bin/detect and bin/build ◦ A unit of work that inspects your app source code and formulates a plan to build and run your application ◦ Modular so the unit of work may require other buildpacks to be functional • Meta Buildpack ◦ Consists of one file: buildpack.toml ◦ References other buildpacks and orders them into a cohesive set ◦ Provides more complicated sets of functionality by defining groups buildpack.toml bin/detect bin/build = Buildpack
11. The Lifecycle The lifecycle orchestrates buildpack execution, then assembles the resulting artifacts into a final app image. Phases • Detection – Finds an ordered group of buildpacks to use during the build phase. • Analysis – Restores files that buildpacks may use to optimize the build and export phases. • Build – Transforms application source code into runnable artifacts that can be packaged into a container. • Export – Creates the final OCI image. Defined by two standards • Buildpack Interface • Platform Interface
12. Stacks A stack provides the buildpack lifecycle with build-time and run-time environments in the form of images. Four Stacks (at this time) • heroku-18 - The official Heroku stack based on Ubuntu 18.04 • io.buildpacks.stacks.bionic - A minimal Cloud Foundry stack based on Ubuntu 18.04 • org.cloudfoundry.stacks.cflinuxfs3 - A large Cloud Foundry stack based on Ubuntu 18.04 • org.cloudfoundry.stacks.tiny - A tiny Cloud Foundry stack based on Ubuntu 18.04, similar to distroless Build image Run Image = Stack
13. Builders A versioned image that pulls everything together, providing the lifecycle, buildpacks and stacks. There are three builders: • cloudfoundry/cnb:bionic - Ubuntu bionic base image with buildpacks for Java, NodeJS and Golang • cloudfoundry/cnb:cflinuxfs3 - cflinuxfs3 base image with buildpacks for Java, .NET, NodeJS, Python, Golang, PHP, HTTPD and NGINX • heroku/buildpacks:18 - heroku-18 base image with buildpacks for Ruby, Java, Node.js, Python, Golang, & PHP • Or you can create your own
14. Workflow
15. Local / Developer Forward • Local development is the same, use your IDE of choice • pack & publish image to registry • Deploy image Two Common Workflows Remote / Automated • Local development is the same, use your IDE of choice • Check code into source control and push • Kpack / Pivotal Build Service or CI watches and automatically builds your images • Deploy image
16. Usage
17. • Run `pack build` and indicate app plus a builder • Builder indicates the build image, which provides the environment to build • Each buildpack runs inside the build image & inspects the app • For each group of buildpacks, if all the non-optional buildpacks pass detection then the buildpacks in that group will execute • If no group of buildpacks passes, then building will fail Build
18. Rebase • Given an app image… ◦ Is there a newer run image available? ◦ If so, update app image’s layer metadata to reference newer image ◦ Otherwise, it’s a no-op
19. Run • There is no `pack` command to run your app • You simply use your tool of choice ◦ `docker run image-name` ◦ `cf push -o image-name` ◦ `kubectl create deployment` • We’re just building standard OCI images so nothing special going on here
20. Demos!
21. Questions?