In today's DevOps era, Jenkins pipelines are widely used in many enterprises as a large continuous deployment (CD) tool. Regardless of the large number of deployments, there are many private scripts, and of course, there are many problems and insecurity. While Jenkins excels in continuous integration (CI) scenarios, using it for CI CD proved to be a less-than-ideal workflow: cumbersome, inefficient, and insecure!2023 Annual Stocktake
Jenkins stands out as an open-source automation server with plugins to simplify building, deploying, and automating projects. It remains a popular tool in the DevOps space, with more than 15 million times.
Jenkins is widely admired for its maturity and proven resilience. Jenkins is designed with flexibility in mind, offering a wide range of software development kits (SDKs) that cover almost every aspect imaginable. Whether you want to oversee an AWS environment or integrate with GitHub, there's a plugin tailored for that specific purpose. While this adaptability has its drawbacks, it is a major factor in Jenkins' popularity and success among numerous organizations.
Frankly, Jenkins as a software is starting to show its contemporary. It was originally developed in 2004 and was not designed for cloud native. While developers and DevOps teams have found ways to make it work, its architecture rooted in master nodes and multiple builds** reflects the outdated model of the data center and static server era.
While this approach isn't necessarily a bad thing, dependencies on plugins can lead to additional configurations, which are often complex, cumbersome, and insecure. For example, configuring a container with the Jenkins Kubernetes plugin involves using YAML in the Groovy file, which increases the risk of errors. The diversity of plugin syntax complicates things even more.
Managing Jenkins is considered challenging, and it adds complexity to the requirements of Groovy scripting compared to more modern tools. Although Jenkins' SDK is useful, some plugins are limited and only have basic functionality. And most plugins are usually not well documented and require scripting through most use cases. On top of that, most users complain about buggy plugins that are cumbersome to manage from a dependency perspective. Due to interdependencies, some plugins cannot fix security vulnerabilities, and because many third-party plugins need to be installed, these plugins are of mixed quality, and the quality cannot be guaranteed at all, and it is even possible that they contain malicious scripts.
Because it provides a graphical interface, and needs to execute remote scripts in the interface, the business server opens ports and SSH certificate access to it, so it is a huge security risk, and many users are compromised due to Jenkins, resulting in the entire business server being compromised.
The user interface is clearly outdated and requires a lot of human resources to operate. Despite trying to reduce script dependencies, Jenkins is still script-centric. This leaves the DevOps team with the burden of maintaining infrastructure, updating plugins, and troubleshooting.
Maintaining Jenkins in a small facility usually requires the daily efforts of 2 to 5 engineers. While valuable and proficient in a variety of tasks, as operations expanded, the limitations of relying solely on Jenkins became apparent, leading to an increase in maintenance, operational challenges, and potential disruptions.
Software delivery and deployment should be separate from CI providers, which are often built specifically to run unit tests and compile build artifacts. There are some main motivations for this separation, which include:
Deployments are typically a longer running process than standard changes, including phased releases and multiple rounds of integration testing across multiple environments.
A separate CD system allows microservice dependencies to be tested in tandem and rolled back independently, making it easy to manage drift in microservice dependencies.
Detached CDs do not require a master certificate in a build service such as Jenkins or a cloud service such as Circle-CI, enhancing the overall platform security posture.
*CD services can greatly simplify the management of polymorphic infrastructure providers, as pull-based architectures can naturally scale to multi-cloud or on-premise delivery models.
Jenkins acts as a CI server and relies heavily on scripts. The Jenkins Pipeline feature consists of a set of plugins that facilitate the implementation and integration of CD pipelines in Jenkins. This situation presents a challenge to establish a smooth, comprehensive CI CD pipeline.
The Jenkins pipeline feature doesn't contain any out-of-the-box functionality. Instead, you must write custom scripts to manage or perform all of the above tasks. The Jenkins pipeline is just another way to hardcode the solution with the script.
Every member of the team's time is valuable and can't be spent maintaining the deployment pipeline. The reality is that writing pipelines together introduces more complexity, increasing the likelihood that the pipeline will fail.
Of course, it is possible to manually script a canary deployment to a kubernetes cluster by editing a few jenkins files a lot if you want, but this is not easy and will end up being a pain.
As applications and services evolve, teams should not write and maintain CD processes. The functionality of the CD needs to be based on a scalable, secure, **-based pull architecture that can be managed without direct access to any cluster it is deployed to, so that it can manage workloads in any cloud, on-premises, edge, or even on a local PC running KIND.
Many enterprises may host GitLab internally as the best management platform, and will use Jenkins for CI CD, and interact GitLab with CI CD.
GitLab Runner is used as a CI CD with GitLab to run applications that run jobs in pipelines. GitLab Runner is developed by the Golang language as lightweight and efficient, and only provides client task execution, without any graphical interface, and its management interface can only be integrated in the GitLab interface (which can filter a large number of dangerous script operations), thus greatly ensuring the security of the business platform.
The configuration of GitLab Runner is also very simple, after the configuration is connected to the GitLab server, you do not need to participate in it, you only need to configure and commit it in the GitLab interface. gitlab-ci.YML can be used to publish CD tasks, and the execution status can be viewed, monitored, and counted later.
This article analyzes the various problems and hidden dangers that exist for Jenkins in the current situation, and the reasons why it is necessary to remove the Jenkins CD process for continuous release, and finally recommends the more suitable GitLab Runner, of course, GitLab Runner is only a small part of Gitlab, and it also provides the entire Auto DevOpt stack and DevsecOpt overall solution, a better and more secure stack that is worth abandoning Jenkins is the solution.