Cloud Native

The improvements are targeted at both existing and new Jenkins users that use, or would prefer to use, Jenkins deployed in one of the cloud providers, or using cloud services for their operation.

There are the following main areas for the SIG:

The current default approach of storing everything into the filesystem is the main reason why Jenkins does not fit the "Cloud Native" model, with features like HA, zero downtime, or pay per use. While there are plenty of plugins that implement parts of this vision, this becomes cumbersome to configure and a usability nightmare for users, as JEP-300 has pointed out. Going towards a model where cloud services are consumed where it makes sense, the overall complexity on operating Jenkins in a cloud or containerized environment is greatly reduced. Other related projects include Jenkins X and Jenkins Evergreen which would greatly benefit from a Cloud Native storage for Jenkins.

There are several clear areas open for improvement, which are summarized here and will be detailed in future documents. A mayor pain point is the usage of local disk as all-purpose storage, which causes issues running on containerized or distributed environments, requiring highly performant filesystems, and all the configuration pain like initial sizing and resizing with downtime. We believe that by using cloud provided services the overall usability, performance and scalability can be improved while enabling new demanded functionality.

See the Pluggable Storage page for more information about the projects. You can also find more information about Pluggable Storage and priorities in this blogpost.

If all the data currently stored in the filesystem is moved to external storage a replicated Jenkins service becomes possible, and the next steps are true High Availability, rolling or canary upgrades and zero downtime.

It also opens a way towards stateless Jenkins. By converting Jenkins to a "stateless" application long awaited features such as high availability and replication would help to operate Jenkins more efficiently, with zero downtime and reducing risk in upgrade operations by using canary or rolling deployments.

Currently there is no JEPs associated with this topic.

Configuration as Code related topics belong to the Cloud Native SIG. The Configuration as Code (casc) group consists of contributors and collaborators focuses on improving Jenkins configuration as code related tools and practices.

The target audience are both existing and new Jenkins users that use, or would prefer to use, different ways to configure Jenkins as code.

There is a separate Office Hours meeting conducted every second week on Wednesdays, 9am CEST. Click on a link for an invitation. Anyone can join a meeting, meetings will be recorded via Jenkins Hangouts-on-Air.

Participant links will be posted in the Configuration as Code Gitter Chat within 10 minutes before the meeting starts.

When needed the topics discussed at Office Hours meeting will be reported back at Cloud Native SIG meeting.

Jenkins Kubernetes Operator can realize the automatic operation and maintenance of Jenkins in the kubernetes cluster.

The Jenkins Operator will integrate with the CasC plugin, Groovy init scripts and more to enable configuration control、 stateful control and other possible improvements of Jenkins in the kubernetes cluster.

The operator will receive a yaml file like custom-war-packager yaml config and complete the configuration.

There will be regular SIG meetings scheduled. Initially the meetings will be conducted once per month, then they may be adapted according to the activity.

Meetings will be conducted and recorded via Jenkins Hangouts-on-Air.