| This blog post is part 1 of a Configuration-as-Code series |
Jenkins is highly flexible and is today the de facto standard for implementing CI/CD, with an active community to maintain plugins for almost any combination of tools and use-cases. But flexibility has a cost: in addition to Jenkins core, many plugins require some system-level configuration to be set so they can do their job.
In some circumstances, "Jenkins Administrator" is a full time position. One person is responsible for both maintaining the infrastructure, and also pampering a huge Jenkins controller with hundred installed plugins and thousands hosted jobs. Maintaining up-to-date plugin versions is a challenge and failover is a nightmare.
This is like years ago when system administrators had to manage dedicated machines per service. In 2018, everything is managed as code using infrastructure automation tools and virtualization. Need a fresh new application server as staging environment for your application? Just deploy a Docker container. Infrastructure is missing resources? Apply a Terraform recipe to allocate more on your favourite Cloud.
What about the Jenkins administrator role in this context? Should they still spend hours in the web UI, clicking checkboxes on web forms? Maybe they already adopted some automation, relying on Groovy script voodoo, or some home-made XML templating?
Early this year we announced the first alpha release of “Jenkins Configuration-as-Code” (JCasC), a fresh new approach to Jenkins configuration management, based on YAML configuration files and automatic model discovery. “JCasC” has been promoted as a top-level Jenkins project, and the corresponding Jenkins Enhancement Proposal has been accepted.
What can JCasC do for our Jenkins Administrator?
JCasC allows us to apply a set of YAML files on our Jenkins controller at startup or on-demand via the web UI. Those configuration files are very concise and human readable compared to verbose XML files the Jenkins uses to actually store configuration. The files also have user-friendly naming conventions making it easy for administrators to configure all Jenkins components.
Here’s an example:
jenkins:
systemMessage: "Jenkins managed by Configuration as Code"
securityRealm:
ldap:
configurations:
- server: ldap.acme.com
rootDN: dc=acme,dc=fr
managerPasswordSecret: ${LDAP_PASSWORD}
cache:
size: 100
ttl: 10
userIdStrategy: CaseInsensitive
groupIdStrategy: CaseSensitiveAs you can see, you don’t need long explanation to understand how this YAML file will setup your Jenkins controller.
Benefits
The most immediate benefit of JCasC is reproducibility. An administrator can now bootstrap a new Jenkins controller with the exact same configuration with a trivial setup. This allows them to create a test instance and check the impact of plugin upgrades in a sandboxed environment. This also lets them be more confident with failover and disaster recovery scenarios.
Further benefits come when administrators start managing their Jenkins’ YAML configuration files in source control, like they do with Terraform configuration. Doing so gives them auditing and reversibility of their Jenkins controller configuration. Theycan establish a sane configuration change workflow that runs a test Jenkins instance and ensures configuration is healthy before actually applying any change to their production Jenkins controller.
Last but not least, with ability to quickly setup Jenkins controllers and control them from a set of shared YAML configuration files, administrators can now offer per-team Jenkins instances, with more flexibility on installed plugins. A controller becomes more or less a transient piece of infrastructure for your team, as long as they also manage build definition with Jenkinsfiles.
With Configuration-as-Code we can stop having to treat our Jenkins controller like a pet we need to pamper, and start managing Jenkins controllers as cattle you can replace without effort nor impacts. Welcome in the “as-code” world.
Ok, so what’s next?
You can read more about the Jenkins Configuration-as-Code plugin on the project’s github repository. To chat with the community and contributors join our gitter channel, or come see us in person at link:Jenkins World to discuss the JCasC project and its future!
Also don’t miss next post from the Configuration-as-Code series, where we’ll look at how JCasC works with sensitive data like passwords and other credentials.
|
Come meet the Configuration as Code contributors, Nicolas de Loof and Ewelina Wilkosz at
Jenkins World on September 16-19th,
register with the code |
|
Nicolas De Loof
This author has no biography defined. See social media links referenced below. |