<p>There is no single "best" practice.  Use whatever approach you and your team feel comfortable with and fits well with the rest of your infrastructure.</p>

<p>If you want to do the Docker approach, you might find <a href="https://coderanger.net/jenkins/" rel="nofollow noreferrer">this person's writeup</a> worthwhile.</p>

<p>To answer your questions:</p>

<ul>
<li><blockquote>
  <p>If you were to use a Docker container, I know you can save all the jobs and configurations on external volumes. How would you go about keeping the updated plugins so you won't have to reinstall them if it falls?</p>
</blockquote>

<p>Depends.  You may want to write a script or configuration management recipe that installs all your plugins for you and/or configures your jobs.  You can also create a custom Docker image containing Jenkins, all of your plugins, and all of your job configuration.  You can also combine these two approaches, using the aforementioned scripts as part of an automated image build process. Whatever you do, you should definitely ensure whatever files (e.g. Dockerfiles) and build steps (e.g. scripts) are part of the process are stored in configuration management in order to make deploys repeatable.</p></li>
<li><blockquote>
  <p>Is there a better way than Docker commits/images/saves? Those feel like they could quickly become clunky.</p>
</blockquote>

<p>Again, it's really just a matter of what you're comfortable with, there's no such thing as "best"; instead aim for "it does what I need it to do".</p></li>
</ul>

CC BY-SA 4.0
2019-02-27T09:25:40.463Z
"You can also create a custom Docker image containing Jenkins, all of your plugins, and all of your job configuration." -- That would lose you all changes made through the interface of the running Jenkins. While okay-ish for plugins and updates, I don't think that's feasible for job configuration. Those will have to go in a volume.
Raphael
CC BY-SA 4.0
2019-02-27T16:54:24.237Z
The point of that setup is that your configuration isn't made through the web interface at all; it's in files and scripts that live in version control so that you can rebuild or upgrade your jenkins instance in a repeatable manner.  If you still want to make changes through the web interface, you can do that and then copy the config files over to config management.
jayhendren
CC BY-SA 4.0
2019-02-27T18:23:13.683Z
I see. From my experience with Jenkins, this seems unlikely to be an effective strategy (it's UX reg. configuration is very odd) but I've never looked into this, specifically. Thanks for the idea!
Raphael
CC BY-SA 4.0
2019-02-28T14:05:10.003Z
[JEP-201: Jenkins Configuration as Code](https://github.com/jenkinsci/jep/tree/master/jep/201) is probably going to help this approach along quite a bit. If it's ever implemented fully.
Raphael
CC BY-SA 4.0
2019-02-17T03:49:17.573Z
2019-02-17T03:49:17.573Z
jayhendren
<p>To my way of thinking "Docker" is a better option. See for example this ebook <a href="https://goo.gl/s4z9TX" rel="nofollow noreferrer">https://goo.gl/s4z9TX</a>.
So, if you don't have serious reasons for VM, go Docker.</p>

CC BY-SA 4.0
2019-02-18T10:43:30.493Z
2019-02-18T10:43:30.493Z
BT3
<p>When creating a fresh new Jenkins server is it better to install it on a VM or Docker?</p>

<p>I know that for most situations when you want just one bit of software on a server the answer would be Docker. Because of all it's plugins and their updates it is a rapidly changing piece of software so it feels like this is the exception. </p>

<p>If you were to use a Docker container, I know you can save all the jobs and configurations on external volumes. How would you go about keeping the updated plugins so you won't have to reinstall them if it falls? Is there a better way than Docker commits/images/saves? Those feel like they could quickly become clunky.</p>

<docker><jenkins>
Best practice for installing new jenkins server
Uberhumus
# Best practice for installing new jenkins server

(Asked by: username_0 on 2019-02-16)

When creating a fresh new Jenkins server is it better to install it on a VM or Docker?

I know that for most situations when you want just one bit of software on a server the answer would be Docker. Because of all it's plugins and their updates it is a rapidly changing piece of software so it feels like this is the exception.

If you were to use a Docker container, I know you can save all the jobs and configurations on external volumes. How would you go about keeping the updated plugins so you won't have to reinstall them if it falls? Is there a better way than Docker commits/images/saves? Those feel like they could quickly become clunky.

**Tags:** docker, jenkins


---

## 2 answers

### Answer by username_1 on 2019-02-17. Score: 3

There is no single "best" practice. Use whatever approach you and your team feel comfortable with and fits well with the rest of your infrastructure.

If you want to do the Docker approach, you might find [this person's writeup](https://coderanger.net/jenkins/) worthwhile.

To answer your questions:

* > If you were to use a Docker container, I know you can save all the jobs and configurations on external volumes. How would you go about keeping the updated plugins so you won't have to reinstall them if it falls?

  Depends. You may want to write a script or configuration management recipe that installs all your plugins for you and/or configures your jobs. You can also create a custom Docker image containing Jenkins, all of your plugins, and all of your job configuration. You can also combine these two approaches, using the aforementioned scripts as part of an automated image build process. Whatever you do, you should definitely ensure whatever files (e.g. Dockerfiles) and build steps (e.g. scripts) are part of the process are stored in configuration management in order to make deploys repeatable.
* > Is there a better way than Docker commits/images/saves? Those feel like they could quickly become clunky.

  Again, it's really just a matter of what you're comfortable with, there's no such thing as "best"; instead aim for "it does what I need it to do".

> **Comments:**
> **username_2**: "You can also create a custom Docker image containing Jenkins, all of your plugins, and all of your job configuration." -- That would lose you all changes made through the interface of the running Jenkins. While okay-ish for plugins and updates, I don't think that's feasible for job configuration. Those will have to go in a volume.  
> **username_1**: The point of that setup is that your configuration isn't made through the web interface at all; it's in files and scripts that live in version control so that you can rebuild or upgrade your jenkins instance in a repeatable manner.  If you still want to make changes through the web interface, you can do that and then copy the config files over to config management.  
> **username_2**: I see. From my experience with Jenkins, this seems unlikely to be an effective strategy (it's UX reg. configuration is very odd) but I've never looked into this, specifically. Thanks for the idea!  
> **username_2**: [JEP-201: Jenkins Configuration as Code](https://github.com/jenkinsci/jep/tree/master/jep/201) is probably going to help this approach along quite a bit. If it's ever implemented fully.  

---

### Answer by username_3 on 2019-02-18. Score: 0

To my way of thinking "Docker" is a better option. See for example this ebook <https://goo.gl/s4z9TX>.
So, if you don't have serious reasons for VM, go Docker.


---

