Deploy your Spring Boot application to Kubernetes in 3 mins
You’ve probably heard of Spring Boot and Kubernetes. But have you tried to deploy a Spring Boot application to a Kubernetes cluster from scratch?Even after using Kubernetes for over 3 years, it still terrifies me to think of the amount of YAML I’d need to write — or copy and modify — to get a new service running. Fortunately, Atomist can take away this pain.
In this post, I’ll show how you can take a new or existing Spring Boot application and deploy it to a Kubernetes cluster in minutes without authoring any YAML, Dockerfile or shell scripts. You’ll achieve powerful CD without any CI files.

This post assumes you have access to a Kubernetes cluster and a properly configured kubectl, and you are able to run an Atomist Software Delivery Machine (SDM) in local mode (requires Node.js >= 8.1.0 and npm). If your system meets those requirements, you can skip the next section.
Installing Minikube
The quickest way to explore Kubernetes is through Minikube, which lets you set up and run clusters on your laptop. If you don’t have a Kubernetes cluster ready to use, follow the instructions below to set one up.
Installing Minikube is different for every operating system, so I recommend following the installation guide. Here are the steps that allowed me to install Minikube on a Mac:
- Install VirtualBox or another supported hypervisor for your operating system
- Install the Kubernetes command line client kubectl
- Install Minikube with Homebrew by running
brew cask install minikube
Once the installation is complete, start Minikube to create a new
cluster:
$ minikube start
Install the ingress
addon:
$ minikube addons enable ingress
Now check the status of your local Kubernetes cluster by running:
$ kubectl get pods --all-namespaces
After a couple of minutes all system internal pods should show in Running
status with a ready count of 1/1
.
Installing the Atomist CLI
Install the Atomist CLI as follows:
$ npm install -g @atomist/cli
If you don’t already have Node.js and npm, please refer to the Node.js installation guide. More details about the Atomist CLI can be found in the developer quick start.
Create the Software Delivery Machine
The local SDM is the process that will do the heavy lifting, turning
your Spring Boot application into a Docker image and deploying it into the Kubernetes cluster. Create a new SDM with the following command:
$ atomist create sdm
Select spring to k8
from the list of possible SDM options and enter the GitHub organization and repository name you want your SDM to use. (At this point we are not actually going to commit anything to GitHub.)
Once the SDM is created, change into the directory in which it was created.
By default, it will be in $HOME/atomist/<owner>/<repository>.
Start the SDM by running:
$ atomist start --local
While the SDM compiles and starts up, open another terminal and start the Atomist feed listener which will let you follow the process of building, dockerizing and deploying your projects using the SDM that you just started:
$ atomist feed --goals
Deploy a Spring Boot sample project
Now that the new SDM is running, we can use it to create a new Spring Boot project from our Spring Boot Rest seed project:
$ atomist create spring
This command will create a Spring Boot project and commit it into a local Git repository at $HOME/atomist/<owner>/<repository>
. The SDM will react to commits on this repository, scheduling goals such as Maven build and test, docker build and deployment into the Minikube cluster.
You can follow the progress of the goals working on your project from the Atomist feed view:
After the deploy to testing
goal has completed, the Spring Boot application should be up and servicing traffic in your Kubernetes cluster. You can verify this by running:
$ kubectl get pods -n testing
Once the pod is in Running
state and shows a ready count of 1/1
, you can hit the application endpoint by navigating to the URL printed in the Atomist feed view. In this case it is:
http://spring-rest.atomist.testing.192.168.99.100.nip.io
If that url doesn’t resolve it is likely that your ISP or DNS is blocking this kind of wildcard address, in which case you have to add an entry to your local /etc/hosts
file to map the hostname to the local Minikube IP address.
spring-rest.atomist.testing.192.168.99.100.nip.io 192.168.99.100
From now on every commit to the Spring Boot application will trigger its delivery to the Kubernetes cluster if the local SDM is running.
Taking a look at the SDM
Now we’ve successfully deployed a Spring Boot application to Kubernetes, let’s look at the SDM that powers this process.
The SDM instance is created in a file called machine.ts
in the lib/machine
folder of your SDM project. A modest amount of TypeScript code drives CD for all projects.
First we define some goals that we can schedule for our projects:
- We want this project to have a consistent and up-to-date Dockerfile. The
AddDockerfile
autofix keeps the Dockerfile in sync with your standards, e.g. version of the base image. line 1 - The
version
goal is responsible for assigning a proper semantic version to the project based on the version inpom.xml
and the current git branch. line 2 - The
build
goal causes our projects to be built with Maven. line 4–7 - Because we are deploying to Kubernetes we also need to build a Docker image. This is the responsibility of the
dockerBuild
goal. We set it to not push the image to a registry to make configuring and running this sample easier. line 9–12 - Lastly we want the application to be deployed to a Kubernetes namespace called testing. line 14
After we’ve created the goals, we can schedule them appropriately for each push on any of our projects:
- For any push to any repository we schedule the
BaseGoals
withversion
andautofix
. - On a push to a Maven-based project, we schedule
BuildGoals
. This runs thebuild
goal afterversion
andautofix
. - If our project has a
Dockerfile
, we schedule theDeployGoals
withdockerBuild
andkubernetesDeploy
.
You probably need more control over the ingress rules, environment variables or secrets your service needs to have access to, etc. You can do this using the Software Delivery Machine API. Through using code rather than YAML/Bash & co, Atomist enables you to bring your programming skills to customizing your CD and entire workflow.
One SDM: Consistent, Flexible CD Across Many Services
Atomist’s event model and SDM API allows you to code consistent yet flexible and sophisticated deployment processes across hundreds or even thousands of repositories, with zero duplication.
A Software Delivery Machine is not only for Spring Boot applications; it can be used with any language, framework or deployment target you use in your organization.
In the next post, you’ll see the power of an SDM to solve problems at scale: you’ll see how to deploy and operate an SDM on Kubernetes that builds and deploys all your organization’s or team’s Spring Boot projects.
Until then, please join us at https://join.atomist.com. This is also a good place to ask for help or provide feedback on the this post. If you encounter any problems getting it to work, we’d love to help.
Everyone’s code and deployment is different. This is why we created Atomist: so that you can craft your delivery in code, not make it conform to anyone else’s YAML spec or plugin. With an SDM, you have the full power of programming, plus a framework and API to make your work fast and solid. What will you do with your SDM?