One of the awesome things about Jenkins is you can use it to do anything in any way you like. e.g. you can add/configure any Jenkins server via the UI which then modifies the state on disk. This can make things harder to manage at scale; tracking who changes what and to diagnose issues and perform backup and restore etc.
We have been using the GitOps approach to managing things in production for the last few years on the Jenkins X project and it has lots of benefits:
- every change is audited so you can see exactly what was changed and by who in git
- you can easily revert changes if they go bad
- all state being in git means its super easy to recreate your infrastructure in another region or using different machine types without complex backup/restore processes being in place
So we recommend trying to follow the GitOps approaches for your Jenkins servers too. e.g.
- try store in git all of the Jenkins servers with their configuration
- try use the Job DSL in git to import projects into your jenkins servers then its very easy to move projects to different servers via a simple Pull Request on the
- try use Jenkins Configuration As Code as much as you can as its simpler and easier to work with via GitOps
- try use use kubernetes external secrets to manage all of your secrets in a secret store like vault or your cloud providers secret manager via Jenkins X secret support
- you can then consume the secrets managed via kubernetes external secrets using the kubernetes credentials provider plugin
- we use this mechanism to reuse the Jenkins X pipeline bot user and token we use for tekton in each Jenkins server via properly labelled Secrets created via kubernetes external secrets. e.g. here’s how we share the git token by using a kubernetes Secret with the labels for the kubernetes credentials provider plugin which is automatically populated from the vault / cloud provider secret store
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.