My Blooooody Jenkins-X ...
I always had on my agenda maintaining
Jenkins as code as an example my custom jenkins role, which was also used in a few production scenarios …
I still felt I had something missing … so with all the new buzz I gave it a few days to read about the different options, and once done gave them all the
hello world spin. I have to say it was surprisingly a
walk in the park. Some things worked better than the other and once I chose
my bloody Jenkins, with in 1.5 hours of work i had a production grade Jenkins building and pushing my image to docker hub.
The result looks like this:
my bloody Jenkins looked to me like the easiest path, the setup was quite easy accept one little annoying issue which is that I need to pass the host ip address as an argument (so the Jenkins slaves based on JNLP can connect to the master).
My bloody Jenkins does to Jenkins exactly what
Jenkins-X does to it, upon startup a bunch of Groovy script stake over the setup of Jenkins / restarting once complete etc etc. Jenkins-X is aimed at running on
Kubernetes + brings a lot of additional components which aren’t just Jenkins such as Nexus, Chartmuseum and Monocular which are awesome but for my use case it was too much (+ from what my colleagues tell me Jenkins-X isn’t 100% there yet) nonetheless it looks very promising and I am surely going to give it another try in the near future.
I have Dockerfile within a git repo, let’s:
- git clone repository
- Build the Dockerfile
- Push it to DockerHub (or ECR what ever your using) [ which is exactly our build steps in this example]
My bloody Jenkins setup
The setup was quite simple following one of the examples available in the repo.
Please note: we don’t really want passwords and certs in your config.yaml … I expect somthing like vault to help encrypt / decrypt during deployment using a token, but for now let’s keep it simple.
What was that all about ? …
Setup your security realm in Jenkins: more options like LDAP / Active Directory are available … You probebly want to customize the password to suit your needs.
Setup a Docker cloud with a fleet named ‘generic’: In the example above our slave instances will be based on the odavid/jenkins-jnlp-slave:latest image but you can use your own of course … In addition you could use other “clouds” such as Kubernetes (will be trying that next) / ECS.
Setup git ssh key for git clone / pull / merge etc and Docker Hub credentials we can push and pull images from -> you will see the
credential id’s in use within the Jenkinsfile (attached below).
Seed jobs (Optional) - setup jobs you want laying around via code [ we can’t allow our pipeline to be disturbed ] …
My Jenkinsfile on the docker-gitbook repo:
6.1 environment setup:
6.2 stage 1 - build preparations
6.3 stage 2 - build image 6.4 stage 2 - build push to docker hub
Stitching it all together with docker-compose:
All you have left to do here is change the
JENKINS_ENV_HOST_IP environment variable and
docker-compose up -d in a few minuets, (first time image pull) - you should get the screenshot shown above.
Something good is happening around Jenkins, we see it evolve. And although quite hard to maintain compared to SaaS offering such as travis-ci, drone.io, Jenkins is much more flexible and IMHO worth the effort.
This type of “opinionated” Jenkins installations are making Jenkins very similar to using a SaaS solution, whilst keeping the flexibility in-house, with advanced usage for secret encryptions such as HasiCorp vault or alternatively Kubernetes secret store (just for passwords / certs) / ConfigMap (entire config.yml).
Hope to have time to use this scenario straight on Kubernetes kompose didn’t deliver as easy as I thought … will update this post when I do that.
Yours sincerely, HP