© Copyright 2019 Pivotal Software, Inc. All rights Reserved. Cloud Native Buildpacks Speed, security and simplicity: Creating Container Images with Cloud Native Buildpacks Daniel Mikusa

Goals I hope you will learn about... Problems CNB’s Solve How To Use Them Developer Workflow Demos!

Cloud Native Buildpacks, why?

Dockerfile Challenges Base Images ● Do you trust them? ● Are your images reproducible? ● Which ones are you using again?

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”

Dockerfile Challenges ● Where is the value line? ● Is time spent managing your fleet of Dockerfiles providing value? ● Is that productive time?

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

Concepts

A Buildpack The official definition...

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

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

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

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

Workflow

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

Usage

● 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

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

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

Demos!

Questions?