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