June 4, 2019 By Arthur De Magalhaes 4 min read

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
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:

  repository: openliberty/samples
  tag: springPetClinic

replicaCount: 3

  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.

Was this article helpful?

More from Cloud

Enhance your data security posture with a no-code approach to application-level encryption

4 min read - Data is the lifeblood of every organization. As your organization’s data footprint expands across the clouds and between your own business lines to drive value, it is essential to secure data at all stages of the cloud adoption and throughout the data lifecycle. While there are different mechanisms available to encrypt data throughout its lifecycle (in transit, at rest and in use), application-level encryption (ALE) provides an additional layer of protection by encrypting data at its source. ALE can enhance…

Attention new clients: exciting financial incentives for VMware Cloud Foundation on IBM Cloud

4 min read - New client specials: Get up to 50% off when you commit to a 1- or 3-year term contract on new VCF-as-a-Service offerings, plus an additional value of up to USD 200K in credits through 30 June 2025 when you migrate your VMware workloads to IBM Cloud®.1 Low starting prices: On-demand VCF-as-a-Service deployments begin under USD 200 per month.2 The IBM Cloud benefit: See the potential for a 201%3 return on investment (ROI) over 3 years with reduced downtime, cost and…

The history of the central processing unit (CPU)

10 min read - The central processing unit (CPU) is the computer’s brain. It handles the assignment and processing of tasks, in addition to functions that make a computer run. There’s no way to overstate the importance of the CPU to computing. Virtually all computer systems contain, at the least, some type of basic CPU. Regardless of whether they’re used in personal computers (PCs), laptops, tablets, smartphones or even in supercomputers whose output is so strong it must be measured in floating-point operations per…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters