Registry not at root URL

Docker Engine General
1

This has been asked a few times over the years but nothing recent. From the documentation it really looks like Docker at some point attempted to support this, but I can’t seem to find anything that works.

I used to have my tools at https://<ToolName>.<Organization>.com, meaning I had to have a unique certificate per tool or at least use a lot of alternate names to redirect them all (since they happened to all be hosted on the same server). This was annoying and expensive pointlessly, but modern standards insist you can’t be convenient like wildcard certs or longer than a year certificate expiration.

We tried this time around to instead use https://Tools.<Organization>.com/<ToolName>, as this allows us to still use NGINX and register one certificate for everything covering https://Tools.<Organization>.com. While it was not easy with some of the NGINX and web redirection things, this ultimately works for everything else, slam dunk.

Then i tried to take my registry (https://Tools.<Organization>.com/dockerregistry) and move my old key images from my old registry to it. It failed with a 404 not found. I’ve tried everything I could find in a LOT of old forum posts which mostly said we couldn’t do this, but this just seems like a very shortsighted decision.

Is this really still the case? What does docker gain from always mashing together the registry address and the image name/repo ? Is it really broken because it determines the image name by searching for the first slash???

Hoping someone came up with a work around for this years ago and it just isn’t easy to find? I’d really like to keep this structure working, as it’s way easier to maintain, especially on the NGINX side.

2

I don’t think that is possible:

Registry addresses should not include URL path components, only the hostname and (optionally) the port.

Doc

What’s the issue with the sub-domain TLS certificates? You can get a wildcard or individual TLS certs for free with LetsEncrypt. Maybe check nginx-proxy project.

3

Yeah, i figured it was going to be that. Honestly, it’s the only thing that Docker underthought. I love the capability, it’s great, but why mash up the URL and repo/image? Every capability could have easily been handled if we separated to commands like docker pull ``www.test.com/myregistry`` imagename:1.2.3.4. I’m not really sure what they gained by forcing them together and checking for first slash…it’s kind of gross tbh. :face_vomiting:

Oh well, I’ll just do another cert. :frowning:

Certs - there’s no ISSUE with certs, but our organization for official certs doesn’t allow wildcards nor anything that lasts over a year. We tried this change because we wanted a dynamic solution that would cover new tools during a year and not have to deal with ALT/SAN names all the time. But this docker thing defeats that :slight_smile:

4

About the name and registry URL:

I guess with this approach you can always make sure every single image on your system contains the source of the image in its name and when you create your own image, you can easily push it just by referring to the name. But it was just a design decision and when Docker and the registry concept was created, it was a good way, but components slowly changed, some modules were separated from the main binary and even source code (this is how containerd was born) and people started to use these more, and they had new use cases, new requirements. So maybe the developers would choose another way today and they will possibly try to implement new ways if there are enough people that makes it more important than other features in progress. If you also found a discussion in the roadmap, you could recommend comment there, or open a new ticket if it was not discussed there yet. (I haven’t tried to find it).

For your current issue, ther emight be a solution, even if not the one you imagined first. I have a VPS and I ran a docker registry on it with a GUI on the same domain. I can’t remember what I used than, but it was not Harbor which I would use today. My problem was that I wanted to run the GUI and the registry in two separate containers but using a single domain and port on a reverse proxy. I remember I made a docker image specifically to handle the proxy configuration to run the registry and another webservice on the same domain, whihc was tricky, because the GUI I used also used the same path. Botth had APIs starting with /v2 and I had to redirect some of the URLs to the registry under /v2 and some of the requests to the GUI container.

So if it is okay to use a

https://Tools.<Organization>.com/v2

URL for the registry, you can have it on the same domain as other services.

If any of those are also using /v2 instead of /<ToolName>/v2 that would still be a problem.
I also haven’t checked whether v2 is still the correct path, but the idea should work with any path. If I am not mistaken, the registry would not use the root.

This way you would still need to name your images as tools.organization.com/imagename, without including v2 in the name. And I also realize that it doesn’t look good that it is not “dockerregisry” but v2, but it would still solve the certificate issue. And you could look at it as a domain that refers to images as tools :slight_smile:

If you don’t like it, then again, you can try the Roadmap

which would not solve it now of course.

5

I ended up giving up and just using a new cert with a root one. I don’t love the decision, but I’ll accept i don’t always get what i want :slight_smile: