Bake And Deploy Spring Boot App to GCP with Netflix Nebula and Spinnaker

In this blog, we will examine some of the popular enterprise deployment tools, introduce two of Netflix’s open-source deployment tools, the Nebula Gradle plugins, and Spinnaker, and we will show you how to deploy a production-ready Spring Boot application. 

We will use a fully automated CI/CD pipeline workflow using the following tools:

• The build, and bake process will be handled by Jenkins.
• The build package creation process will be handled by the Netflix Nebula Gradle Linux Packaging Plugin.
• The deployment process for test and production stages will be handled by Spinnaker. 

The high-level process will involve the following steps:

• Configure Gradle to build a production-ready fully executable application for Unix systems (executable JAR).
• Using Aptly tool GPG Suite, create a secure, signed APT (Debian) repository and publish the package (Debian) to the Aptly repository.
• Using Jenkins and the Netflix Nebula plugin, build a Debian package, containing the executable JAR and configuration files (Debian package).
• Using Spinnaker (HashiCorp Packer under the cover), bake an Ubuntu Image, replete with the executable JAR installed from the Debian package.
• Deploy an auto-scaling set instance from the baked image, behind a Load Balancer, running the Spring Boot application using both the Red/Black and Highlander deployment strategies.

The overall build, test, package, bake, deploy process will look as follows:

CI/CD pipeline for installing Java application using Spinnaker

Spinnaker can be installed and deployed on most of the private or public infrastructure, either in form of containerized (Docker) or virtualized (VM) images. I configured and deployed Spinnaker on the Google Cloud Platform (GCP). 

Using Spinnaker on GCP, Debian packages are uploaded to the APT package repository on GCP Bucket or aptly serve URL. Spinnaker also bakes Images on GCP. Spinnaker provisions the Google resources, including  VM instances, Load Balancers, Auto Scaling Groups, Launch Configurations, and Security Groups. 

Base Image

I baked a base image for Spinnaker to use. This base image is used by Spinnaker to bake (re-bake) the final image(s) used for provisioning the VM instances, containing the spring boot application. The Spinnaker base image is built from another base image, the official Ubuntu image. 

I installed the OpenJDK 8 package on the image, which is required to run the Java-based spring boot application service.

Spinnaker Setup

I added the required Spinnaker User, Policy, and Roles to GCE. Spinnaker uses this access to query and provision infrastructure on your behalf. The Spinnaker user requires service account access to perform all their necessary tasks. The GCP image setup detailed by Spinnaker in their Cloud Providers Setup for GCE. They also describe the setup of other cloud providers.

Custom profiles are configuration files that override the default configuration files for each Spinnaker service. These files are created in the Halyard path: ~/.hal/default/profiles/

So, to let Rosco know from where to read the Debian packages, you need to update the Rosco profile with a custom rosco-local.yml file. The content is mentioned below:

debianRepository:  http://aptly-publish-url:8080/ trusty main

After updating the file, apply the below command:

 hal deploy apply

Spinnaker Security Groups

I had set up Spinnaker Security Group, a Load Balancer for my application service – “PetApp”. The Load Balancer security group exposes port 80, and the PetApp service security group exposes port 8080 (It is not mandatory to use any port).

Load Balancer Security Group

Spinnaker Load Balancer

Next, I created a Spinnaker Load Balancer, corresponding to Classic Load Balancer. The Load Balancer will manage and balance the traffic of the PetApp service’s VM instances. 

Create a Spinnaker Load Balancer

Spinnaker Pipeline

The Spinnaker pipeline bakes a new Image from the Debian package generated by the Jenkins pipeline. After a manual approval stage, Spinnaker deploys a set of VM instances, behind the Load Balancer, which contains the latest version of the PetApp service. 

Spinnaker CD pipeline configuration

Configure Manual Judgement stage

Jenkins Integration

The pipeline is triggered by the successful completion of the Jenkins pipeline. This is set in the Configuration stage of the pipeline. The integration with Jenkins is managed through Spinnaker’s Igor service.

Jenkins Integration

Bake Stage

In the Bake stage, Spinnaker bakes a new image, containing the Debian package generated by the Jenkins pipeline. The stageʼs configuration contains the package name to reference.

Configure Bake Stage

The stageʼs configuration also includes a reference to which base image to use, to bake the new images. Here I have used a customized base image for Spinnaker, which I had created previously.

With the setup complete, we will do a Git push, trigger and complete the Jenkins pipeline, and finally trigger the Spinnaker pipeline. Spinnakerʼs UI lets us view the Bakery details. 

Bake stage detailed configuration

In the image below, we see Spinnaker (Rosco/Packer) locating the base Spinnaker image we configured in the pipelineʼs Bake stage. Next, we see Spinnaker SSHʼing into a new VM  instance with a temporary keypair and Security Group and starting the PetApp service Debian package installation shown in the Bakery output.

Build stage on GCP gets completed

Deploy Stage

Finally, the Deploy stage deploys the PetApp service, running on GCP instances, provisioned from the new image, which was baked in the last stage. To configure the Deploy stage, you define a Spinnaker Server Group. According to Spinnaker, the Server Group identifies the deployable artifacts, VM image types, the number of instances, autoscaling policies, metadata, load balancer, and a security group.

Configure Bake And Deploy stage in GCP

The Server Group also defines the deployment strategy. Below, I chose the Red/Black deployment strategy (also referred to as Blue/Green). This strategy will disable, but not terminate the active Server Group. If the new deployment fails, we can manually or automatically perform a Rollback to the previous, currently disabled Server Group.

Configure Deployment Strategy

Confirming the Deployment

Using the DNS address of the load balancer, we can hit the PetApp service endpoints, on a VM instance. Below, from a web browser, we see the sample images for testing and retrieved from the PetApp application’s PostgreSQL RDS database Test instance.

Deployed PetApp

If you want to know more about Spinnaker or request a demonstration, please book a meeting with us.

OpsMx is a leading provider of Continuous Delivery solutions that help enterprises safely deliver software at scale and without any human intervention. We help engineering teams take the risk and manual effort out of releasing innovations at the speed of modern business. For additional information, contact us