But let’s start with possible ways of updating Jenkins plugins.
The offline aka manual scenarioIf you aren’t allowed to communicate with the internet from within your productive Jenkins environment at all, you still have some options to choose from:
- Don’t update: Not a good idea. Period.
- Manually check and download all your plugins with the plugin index https://plugins.jenkins.io/. Obviously, you don’t want to do this for a typical Jenkins setup with likely more than 70 plugins.
- Run a second Jenkins in a zone where you DO have Internet access. Check for updates and download the desired plugins. Then copy all the .hpi files to your productive Jenkins.
The corporate proxy scenario
If you’re allowed to communicate through a corporate proxy with the Internet, your half-way. But many corporate proxies force you to white-list all required domains or IP’s in order to control access to external resources.
At first, you might think “yeaahhhh… no problem!” and you ask your network security colleagues to enable:
But then, the Jenkins mirroring features hits you.
The meta-data JSON https://updates.jenkins.io/update-center.json provides binary URLs like this: http://updates.jenkins-ci.org/download/plugins/slack/2.10/slack.hpi
But if you call this URL, you get first redirected to http://mirrors.jenkins-ci.org/plugins/slack/2.10/slack.hpi and then another redirect is done depending on your geographic location. In my case, I get redirected to http://ftp-chi.osuosl.org/pub/jenkins/plugins/slack/2.10/slack.hpi
As the status of the mirrors might change, the possibility of returned domains change as well and you’ll find yourself talking to your network security guy quite often.
If you’re allowed to communicate through a corporate proxy with the Internet, your half-way. But many corporate proxies force you to white-list all required domains or IP’s in order to control access to external resources.
At first, you might think “yeaahhhh… no problem!” and you ask your network security colleagues to enable:
- https://updates.jenkins.io for getting the plugins meta-data and
- https://updates.jenkins-ci.org for getting the binaries
But then, the Jenkins mirroring features hits you.
The meta-data JSON https://updates.jenkins.io/update-center.json provides binary URLs like this: http://updates.jenkins-ci.org/download/plugins/slack/2.10/slack.hpi
But if you call this URL, you get first redirected to http://mirrors.jenkins-ci.org/plugins/slack/2.10/slack.hpi and then another redirect is done depending on your geographic location. In my case, I get redirected to http://ftp-chi.osuosl.org/pub/jenkins/plugins/slack/2.10/slack.hpi
As the status of the mirrors might change, the possibility of returned domains change as well and you’ll find yourself talking to your network security guy quite often.
By-pass mirroring by rewriting meta-data JSON
One possible solution to go round this mirroring feature is to download the update-center.json, rewrite all links and then use the rewritten JSON.
One possible solution to go round this mirroring feature is to download the update-center.json, rewrite all links and then use the rewritten JSON.
Download and rewrite JSON
Downloading and rewriting the official update-center.json could be done with many technologies. But I choose Jenkins for this as well. Therefore I created a simple Jenkins job name “update-center”, which is scheduled to run once every day.
The following declarative pipeline does the job:
Some notes regarding the above pipeline:
Downloading and rewriting the official update-center.json could be done with many technologies. But I choose Jenkins for this as well. Therefore I created a simple Jenkins job name “update-center”, which is scheduled to run once every day.
The following declarative pipeline does the job:
pipeline {
agent any
stages {
stage('Download and modify Update-Center Data') {
steps {
httpRequest(
url: "https://updates.jenkins.io/update-center.json?id=default&version=" + Jenkins.instance.version,
consoleLogResponseBody: false,
acceptType: 'APPLICATION_JSON',
httpProxy: 'http://my.corporate.proxy:8080',
outputFile: 'update-center.json'
)
script {
updateCenterJson = readFile file: 'update-center.json'
updateCenterJson = updateCenterJson.replaceAll("http:\\/\\/updates\\.jenkins-ci\\.org\\/download\\/", "http://archives.jenkins-ci.org/")
}
writeFile text: updateCenterJson, file: 'update-center-updated.json'
archiveArtifacts 'update-center-updated.json'
}
}
}
}
- You need to replace my.corporate.proxy:8080 with your actual proxy.
- We read the current installed Jenkins version with Jenkins.instance.version. This needs to be explicitly approved: https://jenkins.io/doc/book/managing/script-approval/. If this isn’t an option, the version has to be hard-coded.
- The https://plugins.jenkins.io/http_request plugin is used to download the JSON. You could achieve a similar thing with a simple curl if you don’t want this plugin.
- You still need to white-list those two domains in your corporate proxy:
- Instead of using archives.jenkins-ci.org, you should use a mirror as the official archives server doesn’t provide great performance.
Use the rewritten JSON
Proxy configuration
Go to the advanced Plugin Manager configuration http://localhost:8080/pluginManager/advanced (or Jenkins > Manage Jenkins > Manage Plugins > Advanced) and configure your corporate proxy:
Go to the advanced Plugin Manager configuration http://localhost:8080/pluginManager/advanced (or Jenkins > Manage Jenkins > Manage Plugins > Advanced) and configure your corporate proxy:
No comments:
Post a Comment
If you have any doubts or questions, please let us know.