Jenkins Best Practices for Pipelines, Shared Library & Security
Jenkins Best Practices for Pipelines, Shared Library & Security. Primarily, Jenkins-written in Java and intended as part of the Java ecosystem. As such, it functions under the same ethos. It’s open-source and highly flexible. Also very easy to install. However, sometimes the problem with freedom is that it offers very little structure or rules.
Consequently, users are often forced to develop their own approaches. But how do you know if you’ve built your pipeline as efficiently as possible? This guideline sets you in the right direction and shorten the time it takes to build your pipeline. Keep on reading to explore the best practices and guidelines for Jenkins pipelines, shared libraries, and security.
Let’s start with Jenkins Best Practices for Pipelines, Shared Library & Security.
Best Practices for Building Pipelines in Jenkins
With Jenkins having a user base of over 1.6 million developers. With CI/CD and DevOps approaches becoming so widespread, many have picked it as their go to orchestration tool. Nevertheless, there are certain things you must watch out for as a Jenkins beginner. The following section covers the best practices for Jenkins pipelines.
1. Use a Declarative Pipeline Syntax
Well, Jenkins gives you two ways to configure your pipeline. Either use declarative or scripted syntax. Highly recommended that you use a declarative syntax to define and configure your pipeline. It’s more recent and has more features than scripted pipelines. Some developers find that it’s also more intuitive as it follows the JSON schema approach.
Additionally, declarative pipelines allow you to create what is known as a matrix section. Which allows you to add more nuance to your pipeline configurations. For instance, you use a matrix to create pipelines that are compatible with multiple web browsers and platforms.
2. Use Scripting Wisely
In this instance, Jenkins originally revolved around Groovy script. It has since evolved and doesn’t require as much scripting. However, with building complex orchestrations, it’s hard to complete escape scripting. Please use Groovy and shell scripts to trigger multiple steps. Again, avoid making script based pipelines. But, use scripts to combine multiple stages/steps into one.
Add external scripts using the sh command and -cp argument. This allows you to modify some of the behaviours of the pipeline without modifying the job/pipeline configuration or declaration files.
Albeit, you must avoid using resource-heavy Groovy operations or functions. For instance, DOM parsers such as XMLSlurper.parseText() and JsonSlurper.parseText() are unkind to system resources. Avoid such operations should as much as possible.
3. Use Timeouts
In order to prevent your pipeline or workflow from becoming stuck during a workflow, add what is known as a timeout. Mostly used for builds. However, using it for other step types such as inputs is also recommended. In fact, most Jenkins architects and developers especially recommend that you add timeouts to inputs. Sometimes a user may not be available to provide input. Thus, causing to workflow to stop until someone provides the necessary input to make it continue. Adding a timeout to these types of steps prevents this. Additionally, use the build timeout plugin to define timeouts for builds through the Jenkins user interface.
4. Use Shared Libraries
Early stages of pipeline declaration are simple. However, as you add more complex steps and build more workflows, things get a bit complicated. As with other programming kits, interfaces, and languages, Jenkins allows you to create reusable packages known as shared libraries. In turn, it allows you to make common or redundant steps reusable instead of declaring them repeatedly in all your new pipelines. Instead of using scripts or creating a new plugin, you simply define a shared library.
Best Practices for Shared Libraries in Jenkins
This section of the Jenkins best practices for pipelines, shared library & security covers shared libraries. As with classes and packages, shared libraries are designed to maintain the DRY integrity of code. Shared libraries ultimately allow you to reuse and transfer parts of different established pipelines in different projects. The first thing you must remember is that shared library repositories have very specific and strict directory structures. If you don’t follow this directory structure, you won’t be able to access the shared library. Other notable share libraries practices include:
1. Do Not Overuse Shared Libraries
If you want the best performance out of Jenkins, you must be able to discern between what work should be carried out by and on the Jenkins controller and what should be done by agents. The agent should be performing much of the heavy lifting. Create Jenkins agent containers using docker to help you optimize your workflows.
While Jenkins’ features may fool you into thinking that it’s a programming language or development environment, it isn’t. You use Jenkins declarative statements to implement and orchestrate your CI/CD pipeline. Thus, your declarative code should be focused and concise.
In nutshell, this means not overusing shared libraries as this may cause performance issues. You must also avoid performing tasks that should be carried out by actual software applications. While shared libraries are comparable to classes, packages, or programming libraries, they should not be treated as such. Use them sparingly. Do not use unnecessary arbitrary pipeline operations to create shared libraries. If there is an available public plugin that already do what you intend a shared library to do, use it instead.
2. Avoid Large Shared Libraries and Global Declaration Files
Using large shared libraries – especially for concurrent tasks – is a drain on system resources. This applies to pipeline/global variable declaration files. You must be mindful of how you construct and use these tools. It would be preferable to create/define smaller variable files.
3. Avoid Overwriting/Overriding built-in Pipeline Steps
Again, Jenkins is not a fully fledged all purpose integrated development environment. While you may be tempted to use shared libraries to expand on the capabilities of built in API. However, you may end up essentially confusing Jenkins and running into errors because of scope.
The system won’t be able to tell the difference between calls to functions defined in the shared library or Jenkins API. This of course results in errors. Additionally, overwriting or overriding Jenkins’ built in steps makes your workflow harder to debug.
Best Practices for Jenkins Security
Many take CI/CD pipeline security for granted. They don’t realize that unsecured config files or orchestrations have damaging consequences. If a bad actor was to infiltrate your workflow, they could alter your orchestrations and infiltrate other parts of your system. Implementing sound security practices early in the development cycle is the best way to prevent cyberattacks. It’s no different for Jenkins. This section explores the best practices for Jenkins security.
1. Disable SSH(D)
The vulnerabilities of SSH have long been documented. Jenkins uses OpenSSH’s listener (aka SSHD) to handle SSH connections or communications. In most cases, Jenkins automatically downloads the SSHD plugin. It’s also likely that you may have downloaded and installed the plugin unknowingly. Nevertheless, it is highly recommended that you disable the SSHD. This ensures that your Jenkins workflows do not fall prey to cyber attacks that take advantage of SSH and SSHD’s vulnerabilities. Disable SSHD under the SSH Server option in Jenkins Global Security configuration options (“Configure Global Security”).
2. Avoid Installing Plugins Outside of the Jenkins Plugin Manager
Highly advised that you avoid installing plugins outside of the Jenkins Plugin Manager. If you must install a custom built plugin of your own creation, you must do so using the Jenkins web user interface. Furthermore, avoid installing plugins that are not included in the official Jenkins repository. Basically, if utilizing a plugin from an external source is essential, then at least make sure it is GitHub verified.
3. Always Keep a Backup of the Jenkins Home Directory
Basically, the Jenkins home directory contains all the vital information and data needed for your orchestrations and workflows. Thus, it’s important that you do not lose it. Besides, Jenkins makes creating backups easy through a plugin. While you have a few options to pick from, ThinBackup is arguably the best. Nevertheless, it is argued that this is the most important Jenkins practice for pipeline security.
Jenkins Best Practices for Pipelines, Shared Library & Security Conclusion
The above guide explores Jenkins best practices for pipelines, shared library & security. There are a total of ten recommendations here. Should you want to learn more about Jenkins, we recommend reading our guide on the top 20 Jenkins interview questions. Follow the basics and keep your pipeline configurations as concise as possible, you’re already on your way to creating the most optimal pipeline. In addition to the above practices, you must always ensure that you’re using the latest version of Jenkins and its plugins.
Do explore more of our Jenkins content by navigating to this section of our blog.
