Jenkins has been around for a long time, it’s a powerful tool which claims to offer a simple way to set up continuous integration (CI) and some teams also use it for continuous delivery (CD).
While Jenkins is arguably still one of the most popular tools to use for continuous integration, many organizations have started to use different dedicated tools for CD use cases, one of which is Rundeck.
Jenkins and Rundeck can be used to complement each other, but is it really worth it to maintain a different tool for CI, while it seems like you can still accomplish the same goal with Jenkins? And is it possible to use Rundeck as a Jenkins alternative for CI use cases?
Rundeck vs Jenkins – Brief Summary
| Jenkins
|
Rundeck
|
|
| Installation | Both package & Docker based installations | Both package & Docker based installations |
| Scalability | Deploy agents on remote nodes to use it as an executor | Register nodes as job executors or deployment targets |
| Plugins | 1,800+ | 120+ |
| Ease of Use | Need to learn the Groovy language | Use shell command / script people are already familiar with |
| Community | Very strong community support | Active but smaller community |
| Execution Performance | Slight delay on executing tasks on remote nodes | Able to execute tasks on remote nodes almost instantly |
| GitOps Support | Yes | Yes |
| Pipelines | Yes | Yes |
| Orchestration | Yes | Yes |
| Ad-hoc capabilities | No | Yes |
| Build Reruns | Yes | Yes |
| Environment Aware | No | Yes |
| Customizability | Yes | Yes |
| Agents | Yes | No |
| Cost | Offers a free community edition | Offers a free community edition |
| Main Purposes | CI | CD |
Popularity Index – Google Trends
1. Installation
Both Jenkins & Rundeck are built on Java, so basically both tools can run in most systems where the Java Runtime is installed.
Both tools also offer easy installation using package managers from many Linux distributions and also Windows. For an even more hassle free installation, Docker based installations are also supported for both tools, which is the preferred way by many teams.
If you want to avoid setting up and maintaining your own infrastructure for either of these tools, both Jenkins and Rundeck offer paid cloud options.
On a vanilla installation, Rundeck can be used out-of-the-box to do many tasks right away as a continuous delivery tool, while for Jenkins, you need to install and configure some plugins and configure some build tools first before it is able to do its job.
2. Scalability
You can distribute jobs across multiple remote machines on both Jenkins & Rundeck. This is great for scalability and high availability. The main difference is you need to install an agent to run a job remotely on Jenkins, while Rundeck is completely agentless. You only need ssh to run a Rundeck job remotely which make it faster and easier to manage hundreds of nodes at your disposal.
3. Plugins
Jenkins currently has over 1,800 community contributed plugins to support many use cases from managing source code, building apps, storing build artifacts, automated testing to deployment. While Rundeck currently has around 123 plugins which mostly focus on operation-centric and deployment use cases only.
4. Purposes
It’s important for us to understand what to expect from each tool.
Just because you can create CD pipelines using Jenkins, doesn’t mean you should. Jenkins relies a lot on plugins to build CD pipelines. And each plugin will usually have dependencies to a bunch of other plugins – increasing complexity and risk of failure.
Jenkins plugins repository page
Things could get messy with Jenkins, as there’s no guarantee that your setup will work in the future as the plugins keep changing, unless you’re the one who maintains the plugin which is probably the last thing you want to do. Also, the more plugins you install to support a bunch of different deployment scenarios, the more bloated your jenkins server, and it’s just not as scalable.
Another thing is, Jenkins doesn’t have native capability to be infrastructure & environment aware, it simply returns whatever the script outputs, without additional context or error handling.
Rundeck on other hand, while doesn’t have native capabilities as build tools, will be able to do many CD tasks out-of-the-box in a way that is difficult to accomplish in Jenkins. In fact, Rundeck capabilities extend beyond just a CD server. Rundeck is built to solve operation problems, so aside from app deployment, it is also usually used for things like infrastructure provisioning, OS patches, restarting servers, fetching logs, running remediation scripts for known issues and many other operation tasks.
5. Ease of use
From the perspective of IT operations or people with little programming experience, Rundeck might be easier to use. On Rundeck, you will mainly rely on command line syntax you’re already familiar with. Various easy to use plugins are also available on Rundeck where you will only need to fill out some forms according to your environment parameters.
On Jenkins, you will need to learn the Groovy language. Even if you’re using Jenkins plugins, you will still need to learn each plugin’s syntax which will certainly lead to a more challenging learning curve.
6. Community
As Jenkins have been around for quite a long time, Jenkins has a large and very strong community support. Rundeck as the newer player also has an active and growing community, while it might not be as large as Jenkins for the time being.
7. Execution Performance
By design, Jenkins agent might be idle before scheduled to run a job. While this might be good to save resource utilization so you only use compute resources only when you need them, this might result in slower performance to start a job. Rundeck doesn’t have this mechanism so the execution will be more straightforward.
8. Pipeline Support
You can create pipelines on both Rundeck and Jenkins to control your jobs execution workflow.
9. GitOps Support
You can store your pipeline script on any Git servers, and then pull it to use directly on both Jenkins and Rundeck. This is very handy, as if anything were to happen to your CI/CD server, you can quickly spin up a new one and then easily import the jobs and pipeline from your Git repository.
10. Orchestration
Both Jenkins & Rundeck will grant you the benefit of orchestration tools, which will let you automate various aspects of the software deployment lifecycle, and also let you do that continuously without human intervention in between cycles. However, both tools will focus on the different aspects.
11. Ad-hoc capabilities
Sometimes we might need to execute an arbitrary command. We might need to check a bunch of systems to find out if they are running correctly, see their load, check resources or perhaps collect information.
On Rundeck GUI, we can quickly run commands to a single or multiple target nodes to do this.
Jenkins on the other hand, doesn’t have this capability as it’s not built for this purpose.
12. Build Reruns
If we have a long running pipeline and a certain job fails because of a minor misconfiguration we made, or if you just want to debug a build, you might don’t want to restart the build from the start. Both Rundeck & Jenkins offer the capability to rerun a job where it last failed.
Rundeck also offers out of the box capability to automatically try to rerun a failing job until it succeeds. This can also be done on Jenkins, but we will need to rely on third party plugins to do this.
13. Environment Aware
Because Rundeck is built for operation purposes, Rundeck is aware of the details of your environment (nodes, configuration, health, etc.). Rundeck lets you describe your infrastructure and environments, giving you a view and control to all managed hosts in your environment. You can combine data from multiple sources (such as Amazon EC2, Puppet, an Ansible inventory, and Device42) to allow a single view of all the information available in your environment, without needing to adopt a new standard to maintain your CMDB. Jenkins on other hand, doesn’t have this capability.
14. Customizability
You can customize some display aspects of both Jenkins and Rundeck GUI. This feature is not a part of the Jenkins core, but you can do this through some plugins. To add more capability, obviously you can also build custom plugins for both Jenkins and Rundeck.
15. Cost
Both Jenkins and Rundeck offer a free community edition. The free option usually can accommodate most small to medium team needs. The enterprise edition will give you added value such as Enterprise Support (Priority-Based Support, Account Management, SLA Response, etc), High Availability Clusters, more fine tuned team control and access to premium / enterprise grade plugins.
16. Main Purpose
In short, Jenkins is designed for the primary purpose of doing CI tasks, such as building and testing software artifacts. Rundeck is designed for the purpose of doing operation tasks, which make it great CD tools. We will cover more details about this later in the article.
Comparing Jenkins and Rundeck in Action
Rundeck was built for operation purposes. It doesn’t have any native capability or plugins for managing source code, scanning code quality and also doesn’t offer any integration to build & testing tools, something that is very important for a decent CI tool.
I think we can agree that we shouldn’t use Rundeck as a CI server / build tool.
But should we still consider using Jenkins as an all-purpose CI/CD tool?
We will try to create a typical CI/CD pipeline, but as the purpose of this section is to compare the CD capabilities of Jenkins & Rundeck, we will skip the CI part, and assume the build artifact is already created and ready to use.
- Deploy to Dev: We will run a simple web application as a Docker container in a Development environment
- Test: We will run a simple test, to ensure the webapp is running normally
- Promote to Prod: We will push the Docker image from the Development repository to the Production repository.
- Deploy to Prod: Finally we will use the image that becomes available in the Production repository, to run the web application on the Production environment.
We will see how much effort needs to be done to accomplish the goal both using Jenkins and Rundeck
Comparison on creating the same pipeline in Rundeck vs Jenkins
1. Setting up worker nodes
While it’s certainly possible to run jobs in the Jenkins or Rundeck server itself, it’s recommended to run jobs in worker nodes. As deployments get more complex, setting up distributed jobs is necessary for scalability, high availability, and avoiding issues in deployment servers, which should become the “brain”. The last thing you want is to have your CI/CD pipeline fail leaving you unable to move forward.
Jenkins
There’s two approaches for running jobs on Jenkins.
The first approach is to set up a permanent agent on a server which will run all the time, whether there’s a job scheduled to run on that node or not. This is the simplest approach when you’re new to Jenkins. You will need to have Java runtime installed on the node, and then you will need to run the Jenkins agent on that particular node.
The second and more advanced approach is to set up a dynamic agent, which allows Jenkins to provision an agent on Docker, Kubernetes, OpenShift or cloud providers when needed, and then deprovision the worker when the job is finished. The ability to dynamically spin up containers as workers is one of the things that makes Jenkins a great CI tool, as you can spin up specific worker containers containing only the build tools you need for that particular build stage, and then destroy it after the build finishes.
Configuring Docker as Jenkins executor
Rundeck
Rundeck takes a different approach to set up worker nodes. It’s completely agentless so there’s no dependencies to worry about. All rundeck needed to control a remote node is the node ip address, username and password/ssh credential. Rundeck will leverage SSH connections to run jobs on Linux/Unix nodes and WinRM for Windows nodes. Rundeck then can utilize the node to run distributed jobs.
While Rundeck doesn’t have the capability to dynamically provision workers as Jenkins does, it does support dynamic inventory. Rundeck registers it’s worker by reading resource models from YAML and other supported file formats. You can maintain this file separately or use scripts so you will always have the updated inventory from your configuration management database (CMDB), without needing to manually add the new worker/target node on your Rundeck server. This is very helpful especially to an organization that manages hundreds of servers. Imagine you want to use 100 nodes to run distributed jobs, if the solution is not agentless you might need to install the agent manually on each of those servers, which is very time consuming. Because rundeck is agentless, all you need is a csv file containing the ip address of those 100 nodes.
adding a node on Rundeck
2. Creating Jobs
After we have worker nodes ready to run our jobs, next we can start creating our jobs to deploy container workloads to our target environments. There’s two methods of running jobs in both Jenkins and Rundeck. We can either execute Linux Shell commands on the worker node (after installing and configuring the required tools in the work nodes)) or we can use plugins.
Jenkins
Jenkins provides two different syntaxes for pipelines. Scripted pipelines and declarative pipelines. Briefly, the difference is with scripted pipelines we’re providing step by step sequential instructions for how to reach our end state while declarative pipelines allow us to describe the end state without the step by step process. Both scripted and declarative pipelines require users to understand the Jenkins Groovy language. Groovy is a JVM-based programming language, which is something most Ops people aren’t familiar with. Learning Groovy can be quite a learning curve and is something newcomers should consider..
The following is an example Jenkins job syntax for deploying a pod / container to a OpenShift Kubernetes cluster and then running a testing script using Jenkins:
Jenkins pipeline script to deploy a container to Openshift using shell commands.
By using plugins, we might be able to simplify and standardize some things like credentials management, however each plugin we use will add to the learning curve, as we will need to find out which functions are available on that plugin, and what are the syntax to call that functions.
Registering an Openshift cluster credentials using Jenkins plugin.
Jenkins pipeline script to deploy a container to Openshift using plugin.
Rundeck
Creating a job in Rundeck is very easy. You don’t need to learn a new syntax and can just directly use what most Ops people already use. Whether it’s a simple one liner command, bash / shell scripts or Ansible playbooks for more advanced users, you can choose whatever is familiar
Rundeck task to deploy a container to Openshift using shell commands.
Even if you choose to use a plugin, unlike in Jenkins, you usually don’t need to learn how to use the plugin, because it will usually come as a form based input that you need to fill in based on your environment information, which is pretty self explanatory.
Rundeck task to deploy a container to Openshift using a plugin.
3. Defining the pipeline
In most deployment scenarios, you will need to execute multiple steps. This sequence of steps is usually called a workflow or pipeline.
Jenkins
As mentioned above, there’s 2 different syntax models available for Jenkins. Declarative pipelines and scripted pipelines. It would require a full article to explain the difference between these two models, but basically while scripted pipeline is very powerful in a way you can manually code many complex logic in your pipeline, it’s not very recommended to use in many scenarios anymore as it requires someone with strong Java and Groovy skills. In the scripted model, people tend to write pipelines that are hard for others to understand, especially for someone with little experience in the language. This is not good as CI/CD pipelines should be easy to read and easy to manage for everyone in the DevOps team and even amongst developers.
The best practice is to go with a declarative pipeline, which is the one that we used in our previous example. One of the benefits is you will be able to rerun a pipeline from a stage which failed due to some circumstances, without any additional configuration on your declarative pipeline. Accomplishing this with a scripted approach is impossible.
Jenkins “restart from stage” page.
One other thing that makes Jenkins a not-so-good deployment tool is, Jenkins only treats worker nodes as “build executors” and not “deployment targets”.
“build executor” means the node will only be temporarily used to achieve a certain goal. For example “compile a source code” or “scan a source code”. It doesn’t make sense to run a single task like “compile a source code” on multiple/groups of servers in parallel. So the concept of treating nodes as build executors doesn’t have this capability. While “deployment targets” mean we’re expected to make changes on the target node itself, because it’s the node were we want to deploy our application. It makes sense to run tasks like “install apache web server” or “open a firewall port” on multiple/groups of servers. So the concept of treating node as deployment target offer this capability
Jenkins is designed as CI tools, which focus on the capability needed to build software artifact, so it doesn’t have any needs or native capability to run a task in a group of servers. So in a scenario where you have distributions or replicas of applications that need to be deployed on a group of servers, you need to explicitly write your code to run the task on each of the servers.
Rundeck
Rundeck is well equipped with many capabilities to control the workflow of your deployment.
You can choose what to do “If a step fails” :
- Stop at the failed step: Fail immediately
- Run remaining steps before failing: Continue to next steps and fail the job at the end.
The default is to fail immediately, but you can choose whatever suits your requirement more.
You can control the order of execution of steps and commands executed to nodes whether using a node oriented or step oriented strategy.
- Node First: Executes the full workflow on each node before the next node. (default)
- Sequential: Executes each step on all nodes before the next step.
- Parallel: Run all steps in parallel.
Workflow control on Rundeck
In addition to the ability to manually retry a failed job, you can also control how many times Rundeck will automatically retry a failed job.
Controlling automatic retry on Rundeck
And one of the most important abilities that makes Rundeck a great deployment tool is the ability to set a group of servers as deployment targets. So you can deploy replicas of your applications without needing to make additional changes to your workflow.
You can easily control the targeted node on Rundeck
Conclusions
If your team consists mainly of full stack engineers and you don’t want the complexity of learning and maintaining two different tools for CI and CD, you can start with Jenkins as in addition to being a great CI tool, Jenkins can also be a makeshift option to use as a CD tool. But as your team gets bigger and you have different specialists for operation and deployment, it’s very recommended to consider using dedicated CD tools like Rundeck. Both tools will complement each other so you will get the best of both worlds.
