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.
Atomist feed showing build of delivery from commit to Kubernetes deploy
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 Runningstatus 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:

Atomist feed showing the build and deploy goals

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/machinefolder 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 in pom.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 with versionand autofix.
  • On a push to a Maven-based project, we schedule BuildGoals. This runs the build goal after version and autofix.
  • If our project has a Dockerfile, we schedule the DeployGoals with dockerBuild and kubernetesDeploy.
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?