In today’s cloud native world, Docker Images are the lingua franca for platform portability. Unfortunately, there’s no clear direction for developers to turn their Spring applications into those Docker Images. The most likely tool for Docker Image creation, Dockerfile, has serious Day 2 limitations that make it a poor choice for many situations. This session will explore how to use the Cloud Native Buildpacks (CNCF) project and its integrations into the Spring ecosystem. It will cover the use of Spring Boot’s Maven and Gradle plugins, the pack CLI, the kpack Kubernetes service, and more.
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Spring to Image
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
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
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
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