I am evaluating nexus to see whether it would work for us. So far so good, but I have one question…
Can I create a proxy repository with multiple upstream URLs so that nexus could obtain artifacts from any of them (i.e. the upstream URLs are mirrors) ?
I have some Arch Linux servers. I have been able to proxy the Arch package repositories as raw (I haven’t seen a plugin for Arch specifically). It works, it’s just we normally put a few mirrors in our package manager config and would like to do that in nexus but the remote field seems to want only a single url.
No, it’s not possible to specify multiple upstream URLs in a single proxy repository. However, what you are looking for is a group repository. You can create multiple proxy repositories, each pointing to one upstream URL, and then combine them all together in a single group repository. In such configuration, Nexus Repository will go through each member repository until one of them returns a positive response and serve it the client. One issue with that might be repository metadata if there is any, I’m sorry I’m not familiar with Arch repository format, but if there is any kind of repository index-like metadata file then the approach I described will fail, and the only solution would be to write a format plugin for Arch repository.
I looked at repository groups but I got the impression that it’s for grouping different proxied repositories that each offer different artifacts rather than providing multiple remote locations that offer the same artifacts.
In the specific case of arch, there is an index metadata file, so I don’t think groups will fit. I may take a look at what’s involved in writing a simple plugin to do this, if it’s possible that way.
Yes, you’re right. It will not do any kind of load-balancing between the members. All requests will go after in the exact order as specified by ordering member repositories in proxy. However, if one of the members will stop responding or will be responding with errors it may be auto-blocked so your requests will be going to the next repository on the list.
Here’s an introduction on how to develop plugins for Nexus Repository: Bundle Development
Thanks. Do you think supporting multiple remotes would be considered as an enhancement?
Basically try given URLs in order to obtain the artifact from the first one that responds successfully. It doesn’t need to remember which remote it got the artifact from and load balancing would be a nice to-have but wasn’t what I was immediately after.
Thanks for the plugin dev link, I will take a look at that.
Hello, I was really following on the earlier comment about index files being a problem. I’ve since taken a look at the index file that Arch uses and it doesn’t refer to remote endpoints so it may not be a problem - I’d have to try it out. Each mirror would return the same index so as long as Nexus cached it from one mirror it should be fine.
If the recommendation is to try groups out then I’ll give it a go…
Oh right, I missed that. The deal with index files is that a raw repository will just treat them as any other file. First-class support for a given format will mean that group repositories can merge multiple index files from separate remote repositories, so that they hold the union of what’s in all the remotes.
In your use case, that won’t matter, since you expect each remote repository to have the same content, and therefore the same index. That means that the index file can be served as an opaque file by Repository, and it will still all work.