How to deploy an internal Jenkins Plugins Site?

Using Jenkins Ask a question
1

How can we deploy an internal plugins site to point our Jenkins instances at to control rollout of updates and also to air-gap the instances so they do not require proxy connectivity to the internet?

Within GitHub - jenkins-infra/update-center2: Jenkins Update Center backend the second sentence states

With a few modifications it could easily be used to generate your corporate update center as well.

What are those few modifications?

2

Hello @jakauppila and welcome to this community :wave:

Would this tutorial help in any way?

3

The update center2 in jenkins-infra only works with jfrog artifactory, while the one from ikedam seems to be relying on Nexus (but the main code there is very outdated it seems).
I got the one from jenkins-infra working with our artifactory instance and extended it to work with 2 artifactory instances. I also added an additional generator for creating lua configs instead of the .htaccess so I can use openresty (nginx with lua).

4

@mawinter69 I’d be interested in the configuration details if you’re willing, we do utilize Artifactory so no problem there.

5

Contains a locally running version.
Use at your own risk.

You will need a user from accounts.jenkins.io to access the jenkins artifactory and a github user. As AQL is used you will also need a user that has permission to do AQL queries in your artifactory instance.
The queries are done against the Jenkins repos and the secondary artifactory repo. All other access requests go to the secondary artifactory (downloading hpi files, reading manifests, …), so you need a repo that contains everything (your internal plugins and the Jenkins plugins).

  • Modify the init.sh script to set the url of your artifactory instance and the url of your internal update site that should be generated.
  • source the init.sh script to set the required env variable.
  • Build the project with mvn package
  • Run the script site/generate.sh ./www ./www/download (this can take a while initially, later you have a cache and runs should be fast when run regularly)
  • Run the script site/publish.sh
  • copy file tmp/lua.code to the location as specified in the nginx conf and restart openresty

The scripts will only generate update sites for LTS version 2.319 and newer (can be change in line 89), plus what you define in line 85, I needed an update site for 2.60.3)
There are some assumption as to where things are.
You will need openresty

The nginx config part (file /usr/local/openresty/nginx/conf/nginx.conf)

    # HTTPS server
    #
    server {
        listen       8443 ssl;
        server_name  localhost;

        ssl_certificate      /data/update-site/certs/update-site.crt;
        ssl_certificate_key  /data/update-site/certs/update-center.key;

    #    Allow TLS version 1.2 only, which is a recommended default these days
    #    by international information security standards.
        ssl_protocols        TLSv1.2;

        ssl_session_cache    shared:SSL:1m;
        ssl_session_timeout  5m;

        ssl_ciphers  HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers  on;

        location / {
            rewrite_by_lua_file /data/update-site/lua.code;
            root /data/update-site/www;
            autoindex on;
        }
    }

If you want to use apache with .htaccess you would need to revert the corresponding changes

1 Like
6

Appreciate it @mawinter69 ! I’ll give that a shot.