1

I've been running Jenkins in container for about 6 months, only one controller/master and no additional nodes, because its not needed in my case, I think. It works OK. However I find it to be a hassle to make changes to it, not because I'm afraid it will crash, but because it takes a long time to build the image (15+ min), installing SDK's etc. (1.3G).

My question is what is the state of the art running Jenkins? Would it be better to move Jenkins to a dedicated server (VM) with a webserver (reverse proxy)?

what-are-the-advantages-of-running-jenkins-in-a-docker-container

N. J
  • 398
  • 2
  • 13

1 Answers1

0

Is 15 mins a long time because you make a change, build, find out something is wrong and need to make another change?

I would look at how you are building the container and get all the SDKs installed in the early layers so that rebuilding the container can use those layers from cache and move your layers that change to as late as possible so as little of the container needs rebuilding.

It is then worth looking at image layer caches if you clean your build environment regularly (I use Artifactory)

Generally, I would advocate that as little building is done on the Controller and this is shipped out to agents which are capable of running Docker.
This way you don't need to install loads of SDKs and change your Controller that often etc as you do all that in containers as and when you need them.

I use the EC2 cloud plugin to dynamically spin up agents as and when they are needed. But you could have a static pool of agents if you are not working in a cloud provider.

apr_1985
  • 1,764
  • 2
  • 14
  • 27
  • _Generally, I would advocate that as little building is done on the Controller and this is shipped out to agents which are capable of running Docker._ Possible misunderstanding here @apr_1985. My issue is more when I build the Jenkins container itself, updating it, due to new jobs that I need to include in the new image, plugins or config. I see your point with introduce the SDK in earlier stages. What to you think about download & `COPY` the SDK-folder directly to the image itself? I appreciate your thoughts when it comes to building image USING Jenkins. – N. J Jan 10 '22 at 08:22
  • When I talk about building the Jenkins image it's more about that I need to wait 15-20+ minutes for it finish in order to check if it works. The building I do locally on my machine, but perhaps I should take your word and introduce a agent which does this ? I only have a nginx as proxy for the Jenkins (two containers - docker compose) Reason I mention the time is because it seems to be more efficient to run Jenkins in a dedicated server, then I do not have the hassle of using/waiting/updating a image – N. J Jan 10 '22 at 08:24
  • The way I get around most of this is to have the Jenkins Home Directory on a separate volume which has all the plugins, jobs config etc on it. This way I can destroy the container spin up a new one with the latest Jenkins version and all the config is back. I also use Jenkins Config As Code to ensure it is configured how I need it at all times and config changes can be tracked in Git. – apr_1985 Jan 10 '22 at 09:06
  • I too follow an automated version of Jenkins Config As Code. Do you periodically take backup of your Jenkins volume? I too use a volume defined in docker-compose: `volumes: jenkins_vol ... volumes: jenkins_vol:/var/jenkins_home`. I see your point, though if you were to make changes in GUI (e.g new Job) your changes (the config) will be saved in the volume, but what if you need a new Jenkins instance with the newly created job, do you copy the data from the volume to your new instance, or do you build a new image with the new Job ? – N. J Jan 10 '22 at 11:06
  • Yeah I backup the volume daily. I write all my jobs in JCasC too so where ever I go I can deploy all the jobs. I dont really use the UI at all other than for looking at Job logs or kicking off a manual build. – apr_1985 Jan 10 '22 at 11:14
  • Aah. Alright. I haven't used the JCasC. What I've done is to create declarative pipelines (`.groovy`-files) which the Jenkins instance get from a repository using Shared Groovy Libraries - Jenkins, meaning I have bunch of `.xml` files (`config.xml` etc, copied to the Image). So if I need a new pipeline I create it in the UI, takes copy of the container and build a new image, since the pipeline won't every be visible in Jenkins unless it is created via UI, i think. – N. J Jan 10 '22 at 11:47