GitLab’s Auto Devops: Java spring boot with quality control to production in minutes (using Kubernetes)
Updated: November 2018 / Updated to actual status of Auto DevOps.
This blog explains how to use GitLab’s Auto DevOps for a spring boot application. I will give a quick tour through it’s features and will explain when I would use it.
So..you just started developing a brand new application using spring boot, this awesome new app delivers the feature which is most wanted by all internet users…. “Hello World!”.
What it does? Well it says “ Hello” to the whole “World!”, awesome, now let’s bring this puppy to the public. But this app requires;
- The best written code
- Fully tested code
- No vulnerabilities
- Horizontal scalable
Of course the world cannot wait for you to figure this all out, this is where GitLab’s feature Auto DevOps comes to play.
What is Auto DevOps according to GitLab:
“With Auto DevOps, the software development process becomes easier to set up as every project can have a complete workflow from build to deploy and monitoring, with minimal to zero configuration.”
And the fun part it actually does work.. automagically!
Some context
If you’re reading this blog, some of the software I used may already be outdated. So in this blog I’m using;
- GitLab.com
I assume version 11.4 some screenshots are made with version 10.5, which was the actual version of the initial blogpost. So screens may differ a bit, but are still look-a-like. - cloud.google.com to use Kubernetes
- SpringBoot version 2.0.0
- MacOs with Git installed
I assume you already signed up for both GitLab and cloud.google.com.
I won’t explain every small detail since I assume you can find you way around GitLab, git and other “basic tools”.
Setup google cloud
Let’s setup google cloud to use Kubernetes, If you already have access to another cluster… that will probably work to.
- signup, sign-in and create a new project (will take a couple of minutes).
- Go to “ Kubernetes Engine” -> “Kubernetes clusters”.
- While opening this page Google cloud will prepare Kubernetes. When this is finished, GitLab is able to create a cluster.
Setup Kubernetes in your GitLab project
Although GitLab already has template project we will start from scratch since this template doesn’t have all the cool Auto DevOps feature.
- Create a new project in GitLab
- From main project page add Kubernetes cluster
- Fill in the name of the desired cluster, I went cheap and modified “numbers of node” and “Machine type” (creation of the cluster will take a couple of minutes).
- Auto DevOps includes a couple of services which can be added to your cluster (I’ve added them all);
* Helm tiller (needs to be installed first and actually allows GitLab to easily deploy the other services), Ingres (to setup a load balancer), Prometheus (add monitoring of your app) and GitLab runner (to execute runner jobs on your cluster).
- When finished a public IP adres appears
- Point a wildcard DNS to this IP
Done! We’re close to the real magic!
Setup Auto DevOps
- Go back to the main page of your GitLab project and click “Enable Auto DevOps”
- A huge settings page appears, don’t be scared, just fill in the domain name you’ve appointed as wildcard DNS entry and select “Enable Auto DevOps”.
Done! Getting closer…
Now create a project and push it!
Let do this quickly (I assume you know git and spring boot), create project, put spring boot maven app in project and commit;
cd /yourprojectfolder/
git clone git@gitlab.com:wBlogs/blog-springboot-autodevops.git
git clone https://github.com/spring-guides/gs-spring-boot.git
cp gs-spring-boot/complete/pom.xml blog-springboot-autodevops
cp -r gs-spring-boot/complete/src blog-springboot-autodevops
cd blog-springboot-autodevops
git add -A
git commit -m “Go Auto Devops”
git push
Please note that “blog-springboot-autodevops” is my GitLab project and should be replaced by yours.
MAGIC IS HAPPENING… MAGIC IS HAPPENING..!
The result
Now quickly go to your project page.
Click on the pipeline / commit icon..
Click on the pipeline instance number
You wil see a full pipeline containing several build jobs:
- build execute maven build and dockerize the application using docker image gliderlabs/herokuish
- codequality do a code analysis on the code using codeclimate
- sast execute security scan on code using gemnasium
- sast:container execute vulnerabilities scan on docker using clair
did look succesful but actually failed when opening the log :-( - test execute test part of your code
- production deploy the application towards production
- performance do basic performance test
In all these jobs GitLab uses (external) docker images which quickly analyses your project to determine which build, test or scan tool it should use.
What else comes with Auto DevOps
Committing to a merge request executes the build and tests, creates a preview environment. After preview you’re able to clean up this preview environment.
When Promethius is added to the K8s cluster, GitLab will also monitor the performance of your application.
Advanced features for production releases like Canary releases, down-side; these are now premium (paid) features.
Conclusion & my advice
GitLab did a great job in helping engineers increasing the quality of their application and running the, application in containers. I’m impressed!
If you follow these steps your setup is ready within the hour!
Would I use it? ….It depends.
GitLab Auto DevOps is nice way to bootstrap a project. You can easily create dynamic test environments for each of your branches maybe you will even release to production. Auto DevOps add all kind of quality checks which I normally wouldn’t add for a new experimental project (especially small pet projects). But when using Auto DevOps you start from the get-go with quality in mind, like you should ;-).
But boy… magic really happens, magic is nice for fairy tails… but not for building and releases application on which your business depends.
If you’re running applications on which your business depends you should know what happens.
Auto DevOps really saves a load of tedious research and configuration, thats for sure. But I do have some concerns;
- What does happen with your code before it gets added to the container, does it get altered?
- Do these scan tools share your code to external parties?
- Does the exact same thing happen the next time?
- What is the quality of the build chain, container base images, scanning libraries?
With these automagically created steps you never know for sure, you simply have to trust all involved parties. Which is actually the same for dependencies (external software components) you use in your code when building software… but for that reason the SAST and SAST:container scanning tools steps where added.
My personal advice;
- Start with auto DevOps, bootstrap your project and play around.
- Gain knowledge on the steps which get executed by Auto DevOps. Know the tools which are used, and verify if they suit your needs.
- Build your own build definitions (gitlab-ci.yaml) and remove the magic.
- Make sure all the magic is gone before you add confidential code and before you release application to production.
Updates
This post was initially written in March 2018 and is updated November 2018.
Changes:
- AutoDevOps isn’t in beta stage anymore.
- During the initial post there were some bug which caused the pipeline to fail. GitLab did fix this (actually triggered by this blogpost) and things now work great.
- GitLab added a bunch of tests to the pipeline, for example license scans.
- Some screenshots are updated (only the ones where the interface differs a lot).