4

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.

Improve this question
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 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".

Improve this answer
4
  • "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
    Feb 27 '19 at 9:25
  • 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
    Feb 27 '19 at 16:54
  • 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
    Feb 27 '19 at 18:23
  • JEP-201: Jenkins Configuration as Code is probably going to help this approach along quite a bit. If it's ever implemented fully.
    – Raphael
    Feb 28 '19 at 14:05
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.