Open dduportal opened 1 year ago
First pass of analysis shows that we might want to keep Apache (httpd) for this webservice to avoid introducing too much changes:
pkgrepo
describes a classic Apache setup (virtualhost, log with rotation, TLS termination with HTTPS redirect) => no strict pinning to Apache over Nginx pkgrepo
puppet profiles calls 3 other profiles which are generating custom .htaccess
files (Apache only) with custom rules:
=> It means we'll need an Apache helm chart, not sure if we can reuse the existing "files" service in our custom mirrorbits helm chart (chart inheritance/split seems quite needed here)
Continuing prerequisites analysis to determine:
The Core release of Jenkins have a packaging pipeline defined here: https://github.com/jenkins-infra/release/blob/master/Jenkinsfile.d/core/package
Each kind of package is generated by a call to release.bash
script with the flag --packaging
set to the kind of expected package to generate.
privatek8s
cluster, as part of the release.ci.jenkins.io controller (ref. https://github.com/jenkins-infra/kubernetes-management/blob/774040c2f139be0a60f6c2f8b84761ddacf1d3fb/clusters/privatek8s.yaml#L79-L104 => 3 Helm Releases for release.ci.jenkins.io: 1 for controller, 1 for agents and 1 for the persistent volumes used to store packages)The release.bash
script in jenkins-infra/release is only a pass-trough to jenkinsci/packaging's Makefile
as per https://github.com/jenkins-infra/release/blob/5afd723749659bf38ac3f5fcfb760eae55877587/utils/release.bash#L327-L330 which calls each "kind of packaging"'s build and publich shell scripts
The publish.sh
script all have the same pattern: they generate the package as part of their "Build" stage and then their "Release" stage publishes the generated package into a "staging" directory
.deb
, .rpm
, etc.) is copied to 2 destinations:binary-core-packages
which is not used by the webservice pkg.jenkins.io (Wild guess: it's for get.jenkins.io). Example with debian: https://github.com/jenkinsci/packaging/blob/2da9b53b83c878d82b39ea8f753a3c0edd0cc3ac/deb/publish/publish.sh#L93.$PKGSERVER
SSH/Rsync URL. Example for debian: https://github.com/jenkinsci/packaging/blob/2da9b53b83c878d82b39ea8f753a3c0edd0cc3ac/deb/publish/publish.sh#L102.website-core-packages
. Example with Debian: https://github.com/jenkinsci/packaging/blob/2da9b53b83c878d82b39ea8f753a3c0edd0cc3ac/deb/publish/publish.sh#L118.$PKGSERVER
SSH/Rsync URL. Example for debian: https://github.com/jenkinsci/packaging/blob/2da9b53b83c878d82b39ea8f753a3c0edd0cc3ac/deb/publish/publish.sh#L126PKGSERVER
's webdir and the binary Azurefile (as it is served by get.jenkins.io) but not to the website-core-packages
(minor issue that can be easily fixed)Once the whole package generation process is run with success, the last stage is to promote the content of the "staging directory" to the "production directory".
PKGSERVER
VM) execution of the following script:/var/www/pkg.jenkins.io.staging
to /var/www/pkg.jenkins.io/
): https://github.com/jenkins-infra/mirror-scripts/blob/bebd7675616a2073173b241ddf5021d098c5f2b4/sync.sh#L64-L69Considering https://github.com/jenkins-infra/helpdesk/issues/3636, https://github.com/jenkins-infra/helpdesk/issues/3338 and https://github.com/jenkins-infra/helpdesk/issues/3183, it looks like that the strategy of splitting index and package creates unexpected problems:
Package Indexes are only served from one location in the world. => We might want to use a mirror service to project the indexes to other regions such as China or Asia (which have quite a network latency when readhing an us-east based webservice).
We want a "reference" mirror for download to act as a fallback for the binary files of pkg.jenkins.io. As archives.jenkins.io is designed for this, we could use the webservice pkg.origin.jenkins.io for this.
Service(s)
pkg.jenkins.io
Summary
The service pkg.jenkins.io serves the Jenkins distribution packages: Linux, Windows, WAR files.
It's merely a webserver serving the package manager index (or HTML index files which are listing directories):
We want to move the service pkg.origin.jenkins.io out from AWS:
The obvious choice is to set up the webservice in Azure:
publick8s
would host the webservice with the azure file mounted in read-only => it would allows adding HA to the serviceReproduction steps
No response