Moogsoft Observability Cloud
Submitted By Jenkins User Joshua Zangari
Moogsoft has long used Jenkins, but never optimized it. They needed to find a new way that would shorten release turnaround time and improve release quality.
Organization: Moogsoft, www.moogsoft.com
Project Website: app.moogsoft.ai
Moogsoft Team: Timothy Go / DevOps Engineer, Jacob Laverty / Sr. Devops Engineer, Thom Duran / Director of SRE
Industry: Software as a Service
Programming Language: Java, Node.js, Rust
Platform: Docker or Kubernetes, Linux, Windows
Version Control System: GitLab
Build Tool: Gradle
Community Support: Jenkins Users Google Group or IRC Chat, Jenkins.io websites & blogs, Spoke with colleagues and peers
Launching Jenkins in Kubernetes allowed for worker agents
to be launched as pods with the exact containers needed
to complete different stages of pipelines.
Background: Founded in 2012, Moogsoft is an AI-driven observability company that provides intelligent monitoring solutions for smart DevOps. We deliver an advanced cloud-native, self-service platform for software engineers, developers and operators to instantly see everything, know what’s wrong and fix things faster.
When I started with the organization we were using Jenkins, but not in a great way, with an EC2 instance as a controller using two other static EC2 instances as worker agents. Our deployment model using helm and individual customer instances means other tools for CD were a mess to configure without expensive 3rd party enhancement or direct support.
Goals: We apply AI & machine learning algorithms to your log, metric, trace and alert data. This results in less noise and effective correlation of actionable alerts, reducing the number of incident tickets created and delivering deep contextual insights that enable teams to solve IT problems faster than those relying on rules-based or manual approaches.
Solution & Results: We ended up moving our Jenkins deployment to Kubernetes and building out a Jenkins Shared Library. Jenkins in Kubernetes allows us to dynamically launch worker agents as pods with the exact containers we need to complete different stages of our pipelines.
DRY’ing out our pipelines with the shared library resulted in most of our pipelines / jenkins jobs being simple function calls to it. This allowed us to abstract the convolution of our pre-existing deploy model behind simple interfaces that were less intimidating for our developers to use/maintain.
The library scripts are also infinitely more testable because of an internal policy we have of “shell/bash/native at the last mile”. This means we put as much of our logic into groovy as possible and only use ‘sh’ or ‘bash’ steps where most of the needed parameters are supplied from Groovy logic and the withEnv function.
Plugins we used:
- Kubernetes Cloud Plugin – Dynamically create, use, and destroy Jenkins workers.
- Jenkins Shared Libraries – Vary the implementation of the functionality being used in pipelines using git branches. parallel step.
- Gitlab Plugins – The original one was bad, but there are newer multibranch options we are moving to.
- Junit Plugin – Reports.
- Gatling Plugin – Reports.
- Selenium Plugin – Reports.
- Sonar Plugin – Reports and build blocking.
- We shortened our service change release cycles from weekly to ad-hoc based on merges to master.
- QA team managed pipelines and improved quality of our releases.
- Automated customer instance provisioning.