1.
Spring to Image
Ben Hale, Java on Cloud Platforms Lead
@nebhale
#session-spring-to-image on Slack
1

2.
Modern Application Distribution
• As languages and frameworks proliferate within development teams, it is
becoming harder to treat application artifacts (e.g. JARs) as the immutable
artifact passing through systems
• Many common languages are interpreted rather than compiled, requiring
distribution of source repositories
• Developers want to be able to both test their applications in the environment
that they'll run in and...
• Control the environment that their applications run in, rather than relying on
another team to configure it for them
2

3.
Docker (OCI) Images Are
the Linga Franca for
Platform Portability
3

4.
Docker Images
• Immutable artifacts containing
• Operating System Filesystem
• Application Filesystem
• Command to start application
• Self-contained environment
• Runs the same everywhere
• Laptop, Data Center, Public Cloud, Docker Daemon, Kubernetes, ...
4

5.
Creating Docker Images
• Dockerfiles are the most common way of
creating Docker Images
• Their flexibility is their power
• Run any command, mutate any file
• Their flexibility is their weakness
• Keeping consistent, ensuring security
• Takes a lot of effort for "good" Dockerfiles
5

6.
Buildpacks
• Raise the value line and meet developers where
they are
• Heroku invented (2011) and Cloud Foundry (2013)
mainstreamed
• Cloud Native Buildpacks
• CNCF Sandbox Project
• Specification for turning applications into
Docker Images
• Paketo Buildpacks
• Implementations for major language groups
• Maintained by the same teams as always
6

7.
Demo
7

8.
Spring Boot Maven/Gradle Plugins
• Built on Cloud Native Buildpacks and Paketo Buildpack implementations
• Automated Configuration
• Java version (from build configuration)
• Image name (application name)
• Image tag (application version)
• Buildpacks contribute
• JRE
• Command Line
• Spring Boot-specific knowledge
8

9.
Demo
9

10.
pack CLI/Java Buildpacks
• Contributes JDK (for building) and JRE (for runtime)
• Helpers like active processor count, link-local DNS, memory calculator,
OpenSSL certificate loader
• Spring Boot-specific image labels
• Metadata attached as Docker Image Labels
• Spring Boot configuration metadata
• pack CLI used to inspect images, including Bill-of-Materials
• Contributed dependencies, application dependencies
• Buildpacks are modular so you can swap out a JRE (and more!)
10

11.
Demo
11

12.
kpack Build Server
• Kubernetes-based platform that uses the same CNB foundation and Paketo
buildpacks
• Vanilla Kubernetes-compatible
• Declarative configuration pointing at buildpacks, stacks, and source (or JAR)
• Automatically creates a stream of images when changes occur
12

13.
Spring to Image
• Docker Images are the Linga Franca for platform portability
• Dockerfiles can create those images, but good Dockerfiles are difficult
• Buildpacks provide an application (and application developer) oriented
abstraction
• Spring Boot integrates Cloud Native Buildpacks and Paketo Buildpacks
• Builds can be created
• From within your build (Maven/Gradle)
• At small scale (pack)
• For an entire enterprise (kpack)
13

14.
Spring to Image
• Paketo Buildpacks provide lots of goodies
• JDKs and JREs
• Including helpers like link-local DNS, memory calculator, OpenSSL
certificate loader
• Robust command lines for multiple deployment types (JAR, WAR, distZip)
• Queryable image labels
• Boot configuration properties
• Bill-of-Materials
• Contributed dependencies
• Application dependencies
14

15.
Thank You
@nebhale
#session-spring-to-image
#springone@s1p