Deploy Spring Boot with confidence by using the enterprise-level artifacts found in our Certified Open Liberty Spring Cloud Pak

It’s a well-known fact that Open Liberty supports Spring and provides customers with a single platform to run all of their enterprise Java applications, including Java EE, MicroProfile, and Spring Boot.

We went a step further and created a Certified Open Liberty Spring Cloud Pak, which ensures that you get the same reliable, portable, and secure experience with your Spring applications that are running on supported Kubernetes platforms.

Curated Open Liberty images optimized to run your Spring Boot apps

Our Docker images are publicly available from our Docker Hub page. Use the springBoot1 or springBoot2 tags, depending on the version of Spring Boot that your application relies on.

Deploying Spring Boot Application as-is

Let’s say you have built a fat jar with the popular Spring Pet Clinic application. How do you deploy that with Open Liberty?

The most straightforward way is to just copy that application into the image. It’s as simple as a two-line Dockerfile:

FROM openliberty/open-liberty:springBoot2-ubi-min
COPY --chown=1001:0 spring-petclinic-2.1.0.BUILD-SNAPSHOT.jar /config/dropins/spring/

You can build and run this image, which is using Red Hat’s minimum Universal Base Image as the operating system, with the following commands:

docker build -t springimage .
docker run -d --name springcontainer -p 8080:9080 springimage

After the CWWKF0011I message is displayed in the logs, you can enter localhost:8080 in your browser to see your fully functional application, like the one in the following example:

Optimized deployment with the springBootUtility

In the “Using Spring Boot Images” section of our Docker Hub page, you’ll learn how to achieve an optimized application image that uses Open Liberty’s springBootUtility. In this image, the layer containing Spring libraries is pushed between the Open Liberty layer and your application’s layer, allowing for much faster continuous development and build flow since the layer that changes most frequently (the app code) is at the top.

This is different than the approach we took in the previous section, where the application code was packaged together with all the Spring Boot libraries—including an embedded server.

In addition to the improved build time, by using the springBootUtility tool, you will build a smaller image that spawns containers with a faster startup. It’s a triple-win situation!

To showcase this approach, we re-built the Pet Clinic image with this modified Dockerfile:

1.   ARG IMAGE=openliberty/open-liberty:springBoot2-ubi-min
2.   FROM ${IMAGE} as staging
3.   COPY --chown=1001:0 spring-petclinic-2.1.0.BUILD-SNAPSHOT.jar /staging/myFatApp.jar
4.   RUN springBootUtility thin \
5.    --sourceAppPath=/staging/myFatApp.jar \
6.    --targetThinAppPath=/staging/myThinApp.jar \
7.    --targetLibCachePath=/staging/lib.index.cache
8.
9.   FROM ${IMAGE}
10.  COPY --from=staging /staging/lib.index.cache /lib.index.cache
11.  COPY --from=staging /staging/myThinApp.jar /config/dropins/spring/myThinApp.jar

Lines 1-2 specify which image we want to start with. In our case, we picked the Open Liberty tag that uses Red Hat’s minimum Universal Base Image, but you could also use other tags, such as openliberty/open-liberty:springBoot2-java11-openj9 (to run with Java 11 + OpenJ9), by simply specifying that as an ARG during the docker build invocation.

Line 3 copies the previously built Spring Boot fat jar into the image. 

Lines 4-7 use the Open Liberty springBootUtility to separate the composed fat jar into smaller pieces; namely, the thin application jar and the library cache.

Line 9 starts a new Docker image (second stage of our multi-stage Dockerfile).

Lines 10-11 simply copy the artifacts from the first stage, creating an optimized image that has the application artifacts as the top layer. This allows for iterative development of the application without having to rebuild all the layers below.

We have pushed this optimized image our Docker Hub Samples registry, so if you just want to run the image you can do so:

docker run -d --name springApp -p 8080:9080 openliberty/samples:springPetClinic

Enterprise deployments that are ready to go

Once your application is tightly layered with Open Liberty, you’ll want to deploy it into a Kubernetes environment. We have created a new Helm chart, available in our public repository, which helps you deploy your new Spring Boot application with enterprise settings such as Ingress, Auto-scaling and Pod Security Policy.

Just like the other Application Cloud Paks, the Open Liberty Spring Helm chart contains a complete set of hooks to configure all aspects of the deployments (including annotations, labels, init containers, etc) via a single overrides.yaml.

Here’s an example of an overrides file which installs the sample Pet Clinic application with Ingress enabled and three replica pods:

image:
  repository: openliberty/samples
  tag: springPetClinic

replicaCount: 3

ingress:
  enabled: true
  rewriteTarget: "/"
  path: "/petclinic"

You can then install this fully configured deployment with the following commands:

helm repo add ibm-charts https://raw.githubusercontent.com/IBM/charts/master/repo/stable/
helm install -f overrides.yaml ibm-charts/ibm-open-liberty-spring --tls

Within seconds, your deployment is up and running in Kubernetes. The following screenshot illustrates the successful deployment on IBM Cloud Private.

By using the kubectl command you can drill down into new Kubernetes resources that were created: Ingress, Service, Deployment, Role, Service Account, etc.

Reach out to our open source community to let us know your thoughts, or connect directly with Arthur.