<p>The simple way to deal with this is as you have described. However, some drawbacks of it are:</p>

<ul>
<li>manual Jenkins setup. </li>
<li>No guarantee that your new Jenkins instance is one-on-one identical to the previous in terms of version, plugins, etc.</li>
</ul>

<p><em>Here's one way I have achieved this in the past.</em> This creates disposable Jenkins, that can come up with the same plugins and tools every time. </p>

<p>Note: my setup assumes </p>

<ul>
<li>Jenkins job history is backed up. Artifacts are not stored within Jenkins.</li>
<li>Your Jenkins infrastructure is on the cloud, e.g. AWS</li>
<li>Ansible used for automated provisioning of infrastructure</li>
<li>Jenkins 2.x in use with full use of Pipeline-as-Code</li>
<li>A defined set of Jenkins pipelines.</li>
</ul>

<h3>Machine/Instance Creation</h3>

<ul>
<li>Ansible provisioner creates AWS Linux instance</li>
<li>Adds it to Ansible dynamic inventory</li>
</ul>

<h3>Jenkins Install</h3>

<ul>
<li>Ansible installs Jenkins on the instance</li>
<li>Along with any ancillary tools, e.g. <code>git</code>, <code>maven</code> etc. required for Jenkins jobs to execute.</li>
<li>Start Jenkins service, wait for it to start.</li>
</ul>

<h3>Jenkins Configuration</h3>

<p>Ansible tasks for:</p>

<ul>
<li>Wait for Jenkins CLI to be available.</li>
<li>Download Jenkins CLI JAR file </li>
<li>Execute Jenkins CLI to create users, install plugins, restart Jenkins etc and create jobs.</li>
<li>Restore job history from backup.</li>
</ul>

<h3>Caveat</h3>

<ul>
<li>Works best for greenfield and simpler Jenkins setups. Is harder (not impossible) to achieve with brownfield and more complex projects.</li>
<li>A large amount of training in Infra-as-Code mindset is required with this approach, such as for example "Don't make plugin installations manually".</li>
</ul>

CC BY-SA 3.0
2018-04-30T11:34:34.003Z
2018-04-30T11:34:34.003Z
Vish
<p>Jenkins itself can be configured in many ways. The same applies for Jenkins jobs.</p>

<p>Probably the most easy way is to configure Jenkins manually and replicate its setup by backing up and restoring. Unfortunately, this means dealing with copying XML files.</p>

<p>But fortunately there are other ways.</p>

<h1><code>init.groovy.d</code> directory</h1>

<p>When Jenkins starts, it checks <code>init.groovy.d</code> directory and executes Groovy scripts there. To enforce locale I'm using a snippet.</p>

<pre><code>// Copied from /var/lib/jenkins/init.groovy.d/set-locale.groovy
def pluginWrapper = jenkins.model.Jenkins.instance.getPluginManager().getPlugin('locale')
def plugin = pluginWrapper.getPlugin()

plugin.setSystemLocale('en_US')
</code></pre>

<p>Another example of setting up Jenkins by Groovy scripts is located on <a href="https://gist.github.com/hayderimran7/50cb1244cc1e856873a4" rel="nofollow noreferrer">https://gist.github.com/hayderimran7/50cb1244cc1e856873a4</a> - I'm using that snippet to setup local Jenkins users on test machines.</p>

<h1>Generating jobs</h1>

<h2>Jenkins Job builder</h2>

<p>One approach of generating jobs is <a href="https://docs.openstack.org/infra/jenkins-job-builder/" rel="nofollow noreferrer">Jenkins Job Builder</a>, which creates XML definitions jobs from YAML configurations. I don't like this approach personally as I consider it to be a bit hackish - looks like "generation of XML files without knowing what it means". But some big players are using this approach - JJB originates from Openstack.</p>

<h2>Job DSL plugin</h2>

<p>Another approach is <a href="https://github.com/jenkinsci/job-dsl-plugin" rel="nofollow noreferrer">Job DSL plugin</a> (<a href="https://plugins.jenkins.io/job-dsl" rel="nofollow noreferrer">plugin page</a>). There is special job type called <em>seed job</em> which creates other jobs from Groovy DSL. The seed job can pull the others job description in from Git, so you can easily version them, reuse them, etc.</p>

<p>I'm using personally this approach, as it was available when I started with Jenkins. I've even found some Jenkins tool to create DSL sources from existing jobs, but I'm not able to find it again.</p>

<p>To provide a seed job, you can still use the <code>init.groovy.d</code> approach.</p>

<h2>Pipelines</h2>

<p>The currently recommended approach is probably related to <a href="https://jenkins.io/doc/book/pipeline/" rel="nofollow noreferrer">Jenkins Pipelines</a>. You can store your building pipelines in the source VCS repository next to your code.</p>

<p>I haven't explored this very much, but I'm planning to do.</p>

CC BY-SA 4.0
2018-05-02T07:25:17.557Z
2018-05-20T06:10:29.370Z
2018-05-20T06:10:29.370Z
Věroš K.
<p>I have a Jenkins setup running in production. I want to automate the Jenkins setup (installation) along with all the jobs that are set up in Jenkins.</p>

<p>One crude way I can think of is to copy the whole jobs directory to the new Jenkins setup.</p>

<p>How do I deal with this problem?</p>

CC BY-SA 3.0
2018-04-30T10:44:19.940Z
What did you try?
030
CC BY-SA 3.0
2018-04-30T10:59:53.003Z
I did a standard Jenkins setup and then put the `jobs` directory of original Jenkins setup in New Jenkins setup. It works. but I am looking for a better way.
Nagri
CC BY-SA 3.0
2018-04-30T11:03:15.407Z
https://devops.stackexchange.com/q/21/210
030
CC BY-SA 3.0
2018-04-30T15:12:37.840Z
Possible duplicate of [How do you back up Jenkins jobs & master configs?](https://devops.stackexchange.com/questions/21/how-do-you-back-up-jenkins-jobs-master-configs)
030
CC BY-SA 3.0
2018-05-01T16:15:06.490Z
https://coderanger.net/jenkins/
jayhendren
<jenkins><automation>
How do I replicate a Jenkins setup via automation?
Nagri
# How do I replicate a Jenkins setup via automation?

(Asked by: username_0 on 2018-04-30)

I have a Jenkins setup running in production. I want to automate the Jenkins setup (installation) along with all the jobs that are set up in Jenkins.

One crude way I can think of is to copy the whole jobs directory to the new Jenkins setup.

How do I deal with this problem?

**Tags:** jenkins, automation

> **Comments:**
> **username_1**: What did you try?  
> **username_0**: I did a standard Jenkins setup and then put the `jobs` directory of original Jenkins setup in New Jenkins setup. It works. but I am looking for a better way.  
> **username_1**: https://devops.stackexchange.com/q/21/210  
> **username_1**: Possible duplicate of [How do you back up Jenkins jobs & master configs?](https://devops.stackexchange.com/questions/21/how-do-you-back-up-jenkins-jobs-master-configs)  
> **username_2**: https://coderanger.net/jenkins/  

---

## 2 answers

### Answer by username_4 on 2018-05-02. Score: 7 | Accepted answer

Jenkins itself can be configured in many ways. The same applies for Jenkins jobs.
Probably the most easy way is to configure Jenkins manually and replicate its setup by backing up and restoring. Unfortunately, this means dealing with copying XML files.
But fortunately there are other ways.
init.groovy.d directory
When Jenkins starts, it checks init.groovy.d directory and executes Groovy scripts there. To enforce locale I'm using a snippet.
// Copied from /var/lib/jenkins/init.groovy.d/set-locale.groovy
def pluginWrapper = jenkins.model.Jenkins.instance.getPluginManager().getPlugin('locale')
def plugin = pluginWrapper.getPlugin()

plugin.setSystemLocale('en_US')

Another example of setting up Jenkins by Groovy scripts is located on https://gist.github.com/hayderimran7/50cb1244cc1e856873a4 - I'm using that snippet to setup local Jenkins users on test machines.
Generating jobs
Jenkins Job builder
One approach of generating jobs is Jenkins Job Builder, which creates XML definitions jobs from YAML configurations. I don't like this approach personally as I consider it to be a bit hackish - looks like "generation of XML files without knowing what it means". But some big players are using this approach - JJB originates from Openstack.
Job DSL plugin
Another approach is Job DSL plugin (plugin page). There is special job type called seed job which creates other jobs from Groovy DSL. The seed job can pull the others job description in from Git, so you can easily version them, reuse them, etc.
I'm using personally this approach, as it was available when I started with Jenkins. I've even found some Jenkins tool to create DSL sources from existing jobs, but I'm not able to find it again.
To provide a seed job, you can still use the init.groovy.d approach.
Pipelines
The currently recommended approach is probably related to Jenkins Pipelines. You can store your building pipelines in the source VCS repository next to your code.
I haven't explored this very much, but I'm planning to do.


---

### Answer by username_3 on 2018-04-30. Score: 3

The simple way to deal with this is as you have described. However, some drawbacks of it are:

* manual Jenkins setup.
* No guarantee that your new Jenkins instance is one-on-one identical to the previous in terms of version, plugins, etc.

*Here's one way I have achieved this in the past.* This creates disposable Jenkins, that can come up with the same plugins and tools every time.

Note: my setup assumes

* Jenkins job history is backed up. Artifacts are not stored within Jenkins.
* Your Jenkins infrastructure is on the cloud, e.g. AWS
* Ansible used for automated provisioning of infrastructure
* Jenkins 2.x in use with full use of Pipeline-as-Code
* A defined set of Jenkins pipelines.

### Machine/Instance Creation

* Ansible provisioner creates AWS Linux instance
* Adds it to Ansible dynamic inventory

### Jenkins Install

* Ansible installs Jenkins on the instance
* Along with any ancillary tools, e.g. `git`, `maven` etc. required for Jenkins jobs to execute.
* Start Jenkins service, wait for it to start.

### Jenkins Configuration

Ansible tasks for:

* Wait for Jenkins CLI to be available.
* Download Jenkins CLI JAR file
* Execute Jenkins CLI to create users, install plugins, restart Jenkins etc and create jobs.
* Restore job history from backup.

### Caveat

* Works best for greenfield and simpler Jenkins setups. Is harder (not impossible) to achieve with brownfield and more complex projects.
* A large amount of training in Infra-as-Code mindset is required with this approach, such as for example "Don't make plugin installations manually".


---

