Jenkins Configuration as Code Plugin
Go to file
Praqma Release User 2bd4f0357a Clarified demo examples, clearly marking unclassified as a root element to avoid confusion 2018-06-04 11:46:50 +02:00
.ci 124 add release automate for first alpha release jenkins release job (#125) 2018-02-23 10:46:13 +01:00
.mvn [JEP-305] Make CasC incrementals-ready 2018-05-14 22:35:38 +02:00
demos Clarified demo examples, clearly marking unclassified as a root element to avoid confusion 2018-06-04 11:46:50 +02:00
docs Correct the URL to the configuration-as-code page 2018-03-13 20:46:30 +01:00
src Added a bit of info about plugin root dir and shrinkwrap. For #243 2018-06-04 11:08:37 +02:00
.dockerignore Add Dockerfile 2018-02-05 14:09:13 +01:00
.gitignore Plugins installation (#175) 2018-05-30 08:51:04 +02:00
CONTRIBUTING.md Rename /docs/howToContribute.md to /CONTRIBUTING.md (#147) 2018-03-13 07:42:12 +01:00
IMPLEMENTATION.md Propose fix some typos (#117) 2018-02-20 07:38:12 +01:00
Jenkinsfile enable CI 2018-01-23 13:23:54 +01:00
PLUGINS.md typos in PLUGINS.md (#171) 2018-04-13 09:24:57 +02:00
README.md Added a small getting started note 2018-05-31 15:25:32 +02:00
pom.xml fix incrementals after 0.7-alpha release (#239) 2018-05-30 09:43:49 +02:00
sample_form.png some more user-friendly README 2017-12-20 15:01:28 +01:00

README.md

Build Status Gitter

Jenkins Configuration as Code Plugin

Release information

Release notes of the latest release can be found here: https://wiki.jenkins.io/display/JENKINS/configuration+as+code+plugin

Introduction

Setting up Jenkins is a complex process, as both Jenkins and its plugins require some tuning and configuration, with dozens of parameters to set within the web UI manage section.

Experienced Jenkins users rely on groovy init scripts to customize jenkins and enforce desired state. Those scripts directly invoke Jenkins API and as such can do everything (at your own risk). But they also require you know Jenkins internals, and are confident in writing groovy scripts on top of Jenkins API.

Configuration-as-Code plugin has been designed as an opinionated way to configure jenkins based on human-readable declarative configuration files. Writing such a file should be feasible without being a Jenkins expert, just translating into code a configuration process one is used to executing in the web UI.

So, we are trying to replace this :

configuration form

with this :

jenkins:
  securityRealm:
    ldap:
      configurations:
        - server: ldap.acme.com
          rootDN: dc=acme,dc=fr
          managerPasswordSecret: ${LDAP_PASSWORD}
      cache:
        size: 100
        ttl: 10
      userIdStrategy: CaseSensitive
      groupIdStrategy: CaseSensitive

In addition, we want such a file to have a well documented syntax, and tooling to assist in writing and testing, so end-users have full guidance in using this toolset and don't have to search stackoverflow for samples.

Have a look at this presentation for more details.

Getting started

To get started you must have a running Jenkins instance with the plugin installed.

The only other requirement is that your Jenkins instance has an environment variable set that points to the current configuration location for configuration as code. So the plugin requires the environment variable CASC_JENKINS_CONFIG to be set. The variable can point to the following:

  • Path to a folder containing a set of config files I.E /var/jenkins_home/casc_configs
  • A full path to a single file I.E /var/jenkins_home/casc_configs/jenkins.yaml
  • A URL pointing to a file served on the web I.E https://mysite.com/jenkins.yaml

If everything was setup correctly you should now be able to browse the Configuration as Code management link in Manage Jenkins -> Configuration as Code.

Jenkins Enhancement Proposal

As Configuration-as-code is demonstrated to be a highly requested topic in Jenkins community, we have published JEP 201 as proposal to make this a standard component of the Jenkins project.

Current status : proposal accepted.

Examples

This configuration file includes root entries for various components of your jenkins master installation. the jenkins one is for the root jenkins object, and other ones are for various global configuration elements.

jenkins:
  securityRealm:
    (...)

  nodes:
    slave:
      name: "static-slave"
      remoteFS: "/home/jenkins"
      launcher: "jnlp"

  slaveAgentPort: 50000
  agentProtocols:
    - "jnlp2"
tool:
  git:
    installations:
      - name: git
        home: /usr/local/bin/git
unclassified:
  mailer:
    adminAddress: admin@acme.org
    replyToAddress: do-not-reply@acme.org
    smtpHost: smtp.acme.org
    smtpPort: 4441
credentials:
  system:
    domainCredentials:
      credentials:
        - certificate:
            scope:    SYSTEM
            id:       ssh_private_key
            keyStoreSource:
              fileOnMaster:
                keyStoreFile: /docker/secret/id_rsa

Also see demos folder with various samples.

Full documentation

The configuration file format depends on the version of jenkins-core and installed plugins. Documentation is generated from a live instance, as well as a JSON-schema you can use to validate configuration file with your favourite yaml tools.

How to create initial "seed" job

Configuration is not just about setting up jenkins master, it's also about creating an initial set of jobs. For this purpose, we delegate to the popular job-dsl-plugin and run a job-dsl script to create an initial set of jobs.

Typical usage is to rely on a multi-branch, or organization folder job type, so further jobs will be dynamically created. So a multi-branch seed job will prepare a master to be fully configured for CI/CD targeting a repository or organization.

Job-DSL plugin uses groovy syntax for it's job configuration DSL, so you'll have to mix yaml and groovy within your configuration-as-code file:

jenkins:
  systemMessage: "Simple seed job example"
jobs:
  - >
      multibranchPipelineJob('configuration-as-code') {
          branchSources {
              git {
                  remote('https://github.com/jenkinsci/configuration-as-code-plugin.git')
              }
          }
      }      

How to provide initial secrets for Configuration-as-Code

Currently you can provide initial secrets to Configuration-as-Code that all rely on <key,value> substitution of strings in configuration. Just like in Jenkins: ${some_var}. We can provide these initial secrets in the following ways:

  • Using environment variables
  • Using docker-secrets, where files on path /run/secrets/${KEY} will be replaced by ${KEY} in configuration
  • Using vault, see instructions in section below

Using Vault initial secrets

Prerequisites

  • The environment variable CASC_VAULT_PW must be present (Vault password)
  • The environment variable CASC_VAULT_USER must be present (Vault username)
  • The environment variable CASC_VAULT_PATH must be present (Vault key path, I.E /secrets/jenkins)
  • The environment variable CASC_VAULT_URL must be present (Vault url, including port)

If all those 4 are present, Configuration-as-Code will try to gather initial secrets from Vault. Requires read access for the configured user.

TODO provide a dockerfile to 'build' this documentation from specified jenkins-core release and plugins.

Supported plugins

Here is a list of plugin we have successfully tested to support configuration-as-code approach :