In the previous blog on Jenkins, we already covered how to set up a Jenkins pipeline, and the pros and cons of Jenkins for CI/CD pipelines for Kubernetes environments. In this blog, we will dive deep into potential challenges that can be faced if Continuous Deployments (CD) are managed through Jenkins. We will also take a look at how we can execute robust Continuous Deployments in complex Kubernetes environments keeping Jenkins for Continuous Integration (CI) and integrating Jenkins with Devtron for complete CI/CD experience.
Continuous Deployment Pipelines with Jenkins
We recommend to avoid Jenkins for Continuous Deployments.
Jenkins was originally designed for Continuous Integration (CI). Still, with the level of flexibility, Jenkins has been used for Continuous Deployments. It comes with multiple Jenkins plugins that can be integrated within the pipelines to execute Continuous Deployments through Jenkins. The CD pipelines through Jenkins can be managed in two ways:
Integrating as a Stage into Jenkins CI Pipeline: With this approach, you can add a new stage to your existing build pipeline which will execute deployment to the Kubernetes environments. Typically, you will have to write your custom scripts to apply the configurations on the target environment.
Setting a Dedicated Jenkins Agent: Configure a separate Jenkins agent on your target Kubernetes environment. This agent will be responsible for executing deployments to target environments.
Disadvantages of Jenkins for Continous Deployments (CD) on Kubernetes
Even though Jenkins has been used widely for Continuous Integration (CI) and Continuous Deployment (CD), there are certain pitfalls where you would not want to use Jenkins. Here are some of the disadvantages of Jenkins for Continuous Deployment on Kubernetes.
Extensive Scripting
Jenkins pipelines are executed through groovy scripts, when it comes to deploying applications/services to multiple environments it becomes tedious and error-prone to write and manage these scripts. Additionally, there is a learning curve to understand Groovy and write those scripts.
Complex Configurations
Managing crucial configurations through Jenkins scripts poses risks of misconfigurations and potential leaks of sensitive information. It also makes it challenging to audit and track configuration changes effectively. It heavily relies on plugins, and managing a large number of plugins can become challenging as they need to be frequently updated to avoid compatibility issues.
Security Issues
In Jenkins, every process/step gets handled through a Jenkins pipeline which is in the form of a script and as the scale increases it becomes more complex to manage those scripts and might impose human errors. Additionally, Jenkins has a complicated permission and access control system, especially when working with large teams. Managing fine-grained access control across multiple teams and projects is not as straightforward as in some other modern Continuous Deployment (CD) tools like ArgoCD or Devtron. Since Jenkins relies heavily on third-party plugins, it can introduce security vulnerabilities, especially if plugins are not regularly updated, and managing the complex web of plugins itself is a big challenge. Here are some references to previous zero-day vulnerabilities in Jenkins because of the vast web of plugin ecosystem.
- https://www.jenkins.io/security/advisory/2024-01-24/
- https://www.trendmicro.com/en_in/research/24/c/cve-2024-23897.html
- https://www.bleepingcomputer.com/news/security/jenkins-discloses-dozens-of-zero-day-bugs-in-multiple-plugins/
- https://nordicdefender.com/blog/critical-jenkins-vulnerability-cve-2024-23897
Lack of Production Capabilities
Jenkins was originally designed for Continuous Integration (CI), but it has been extended to continuous deployment with some hacks and plugins. Even with custom scripts and plugins, it lacks built-in production capabilities which are highly important for a stable production pipeline such as policy-driven pipelines, approval workflows, prod configuration protection, DR mechanisms, configuration drifts, release management, and much more.
Absence of Production-Grade Capabilities
Jenkins was originally designed for Continuous Integration, but it has limitations in deployment capabilities. It lacks built-in approval workflows and gates for production deployments, as well as native support for advanced deployment strategies like canary releases or blue-green deployments. Jenkins also lacks to provide visibility and rollback capabilities for production deployments.
Maintenance Overhead
Executing CI/CD pipeline operations using Jenkins is handled by multiple plugins and extensive scripts. These plugins and pipelines need to be verified from time to time to make sure that the current version is supported. With time and scale, this becomes a tedious process and an overhead work to keep everything up to date. Additionally, Jenkins can become resource-intensive, especially in larger setups with multiple pipelines and concurrent builds. It often requires dedicated servers and frequent performance tuning as performance degrades over time because of concurrent builds and jobs.
Lack of Advanced Deployment Strategies
Jenkins doesn’t natively support advanced deployment strategies such as canary releases, blue-green deployments, or rolling updates. Achieving these requires custom scripting or integrating third-party tools.
No Native Monitoring or Observability
Jenkins does not come with advanced monitoring, logging, or observability features out of the box. To gain insight into deployment health or performance, you need to integrate external monitoring tools and create your custom dashboard in maybe Grafana. For your workloads deployed on Kubernetes, you can’t see the real-time status of the workloads, if it is deployed or in a pending state, which again is one of the important aspects of any continuous deployment which is available in modern continuous deployment (CD) tools like ArgoCD or Devtron.
Not Native to Kubernetes
Jenkins is not designed specifically for Kubernetes, so managing Kubernetes deployments can be clunky and inefficient compared to Kubernetes-native tools like ArgoCD, FluxCD, or Devtron. For Kubernetes deployment, Jenkins often requires additional tools or scripts for integration, leading to more complex configurations. Additionally, Jenkins is not cloud-native. It was originally designed for on-premise setups. While it can be adapted for cloud environments, it doesn’t offer the seamless integration, autoscaling, and cost optimization features of cloud-native CD tools designed specifically for Kubernetes environments. In cloud-native environments, Jenkins often needs manual scaling for build agents and resources, unlike modern CD tools that automatically scale based on load.
Limited GitOps Support
Jenkins doesn’t natively support GitOps workflows, which are increasingly popular for continuous deployment in Kubernetes environments. This requires the integration of additional layers of configuration and tools to achieve a GitOps model which introduces the management of different tools, thus increasing the complexity. Additionally, it doesn’t have an automated/ SLO-based rollback mechanism which is highly critical for continuous deployment pipelines
What is the ideal Continuous Deployment Platform checklist for Kubernetes?
A Continuous Deployment platform is a crucial system in modern software delivery that enables rapid and reliable deployments while ensuring production stability. The platform must provide robust safeguards since any deployment can potentially impact service availability and user experience. An ideal Continuous Deployment platform should act as a gatekeeper, automatically enforcing deployment standards and safety checks without compromising efficiency. The ideal checklist for a continuous deployment platform can be:
Robust Access Management (RBAC)
Having a robust RBAC is crucial for the deployment process, as it ensures that only authorized stakeholders can take crucial actions, such as triggering deployments at production servers.
Policy-Driven Pipelines
Enforcing certain policies ensures that the best practices are being followed before executing the deployments. For instance, the policies can be like a mandatory scan of Docker images before deployments, on which if vulnerabilities are detected, the deployment will be aborted.
Approval-Based Deployments
The approval process reduces the chances of the wrong deployment going to the production environments and disrupting the services across regions. Setting up an approval process where the stakeholders need to approve the deployment reduces the chances of service disruptions.
Controlled Deployments
It helps you gain control over deployments, ensuring stability and preventing disruptions during peak hours. Define time slots for planned deployments or block deployments entirely for critical business hours.
Reduce Maintenance Overhead
A Continuous Deployment platform should fundamentally reduce maintenance overhead rather than create it. The ideal platform operates with minimal maintenance burden, avoiding reliance on external plugins and complex script management that require constant updates and compatibility checks. Moreover, the platform should maintain consistent performance, and handle concurrent deployments efficiently.
NOTE: Devtron supports a robust CI, which is precisely crafted for Kubernetes environments and offers multiple features and flexibility. However, in this blog, we will focus exclusively on Devtron's CD capabilities.
Continuous Deployments with Devtron
The CD capabilities of Devtron include features such as choosing the deployment type Automatic or Manual, way of deployment Helm or GitOps, multiple deployment strategies, approval-based deployments, and pre-post deployment stages. Let’s get our hands on the Devtron dashboard and deploy the application.
For this blog, we will use Jenkins in collaboration with Devtron to build, deploy, and manage our Kubernetes application. In the previous blog where we built an image and pushed it to the Docker hub, we will be using the same image (built by Jenkins) and deploying it through Devtron using all CD capabilities of the dashboard.
Step 1: Installation of Devtron
To install Devtron the only prerequisite is to have a running Kubernetes cluster. Devtron can be installed with the following commands:
helm repo add devtron https://helm.devtron.ai
helm repo update devtron
helm install devtron devtron/devtron-operator \
--create-namespace --namespace devtroncd \
--set components.devtron.service.type=NodePort --set installer.arch=multi-arch
Step 2: Creating Application Workflows
Once we have installed Devtron, we can start by creating a new application and configuring the CI/CD workflows. Before setting CI/CD pipelines we need to set some configurations i.e. Git Repository, Build Configurations, and Base Configurations to know how to set them up you can follow Devtron’s documentation. Now that we are done with all the required configurations, let’s make our workflows i.e. CI/CD pipelines. As for this blog, we are going to use Jenkins as our CI pipeline Devtron offers two ways to execute deployments. Let’s check them one by one. The first one is Deploy Image from External Service here, Devtron provides us an External Webhook to execute the deployments. Another one is Deployment Using JobCI, which will be executed using the Devtron JobCI of Devtron and Devtron’s plugin.
Step 3: Configuring External Webhook
Once the configurations are done choose the type of pipeline for deployment, for this instance, we are choosing, Deploy Image from External Service as we already have a docker image built through jenkins.
After selecting the type pipeline i.e. Deploy Image from External Service, we are redirected to configurations of the CD pipeline. At the CD pipeline configuration, we need to provide the Environment, and Namespace, and choose the execution type Automatic or Manual. Moreover with Devtron we also get the capability to execute advanced deployment strategies i.e. Rolling, Recreate, Canary, and Blue-Green.
On completing the above configurations cliche Create Pipeline, now we will be able to visualize the application workflow i.e. the CI/CD pipeline for the application. The CI part will be executed on the Jenkins server and the generated Docker image will be fetched by the webhook. The CD pipeline of Devtron will help us perform robust CD operation
Let’s do some configurations for our External Webhook we need to use a cURL request in our Jenkins pipeline which will let Devtron know that the image is built by an external service.
On Workflow Editor click External Source (Webhook) > Select or auto-generate token with required permissions > Auto-generate token > {Enter the name for token} > Generate token.
Click Sample cURL request > copy the Sample cURL request and integrate it into your Jenkins pipeline along with the Auto-generate token and tag for Docker Image.
Step: 4 Devtron’s CD through External Webhook
Now that we have configured the External webhook for CI, let’s set the CD pipeline through Devtron.
Click Deploy (deployment pipeline), and you will be navigated to the Edit deployment pipeline, where you can configure a robust CD pipeline.
To make sure that the deployment going to the critical environments is vulnerability-free, you can navigate to the Pre-Deployment stage. At this stage, you can configure Devtron’s plugins for scanning the Docker image, in case any vulnerabilities are detected you can stop the deployments.
Devtron also allows you to set an approval process, where before the execution of each deployment approval from relevant stakeholders is required. To set an approval navigate to the Deployment stage > Approval for deployment, here you can select the number of approvals required before executing the deployment to specific environments.
Also, you can select the way you want to execute the deployment pipeline, i.e. Automatic or Manual.
To set the notifications on completion of the deployment process, you can navigate to the Post Deployment stage and configure the plugins like Custom Email Notifier. Which will be sending notifications for the completion of the deployment process.
Once every configuration is done click Update Pipeline, and trigger your application pipeline accordingly. Once the application is deployed you can manage your applications through Devtron’s dashboard where you can leverage multiple other features like Deployment Window for controlled deployments, configuration management across environments, robust user access management, and many more. You can follow Devtron’s documentation to explore this further.
Conclusion
While Jenkins is a powerful CI/CD tool, it has notable disadvantages as a continuous deployment tool, particularly for modern, cloud-native, and Kubernetes-centric environments. Alternatives like ArgoCD, FluxCD, or Devtron offer better out-of-the-box integrations for advanced deployment strategies, GitOps workflows, and Kubernetes management, making them more suitable for many organizations looking for scalable and automated CD solutions. In this blog, we have covered the potential disadvantages of Jenkins when it comes to continuous deployment (CD) for Kubernetes, capabilities for an ideal CD pipeline, and how Devtron helps us to set up a robust CI/CD pipeline integrating with Jenkins.
Devtron stands out as a complete solution when it comes to managing Kubernetes and has the capabilities to handle robust continuous deployment (CD) operations like robust RBAC, approval-workflows, Devtron’s plugins, vulnerability scanning, configuration drift management, release orchestration, and team collaborations. When it comes to managing the multiple Kubernetes cluster resources and day 2 operations like managing multiple applications spread across multiple Kubernetes clusters, Devtron comes as a savior
If you have any queries, don't hesitate to connect with us. Join the lively discussions and shared knowledge in our actively growing Discord Community.
