3 ms·

Is there an easy way of changing the default repository that's pulled from when you issue a 'docker pull <whatever>' command, or do you always have to make sure

Is there an easy way of changing the default repository that's pulled from when you issue a 'docker pull <whatever>' command, or do you always have to make sure to execute 'docker pull <mycustomrepo.io/whatever>' explicitly?

wkat4242 2y ago
As far as I know you do always have to specify it. But I tend to script this all anyway. It's not a big deal to me.
c0balt 2y ago
Not for docker AFAIK, https://github.com/moby/moby/issues/33069 https://github.com/moby/moby/issues/33069, however for podman, see https://docs.podman.io/en/latest/markdown/podman.1.html https://docs.podman.io/en/latest/markdown/podman.1.html (registries.conf under configuration files).
hedora 2y ago
No. Docker has refused patches that add such an option for anti-competitive reasons.
donmcronald 2y ago
> do you always have to make sure to execute 'docker pull <mycustomrepo.io/whatever>' explicitly I started using explicit repository names for everything including Docker Hub 5+ years ago and I don't regret it. I haven't thought about mirrors since, and I find it easier to reason about everything. I use pull-through caches with dedicated namespaces for popular upstream registries. - hub.example.com/ubuntu --> ubuntu from Docker Hub - ghcr.example.com/org/projectA --> project from GHCR I tried using mirrors at first, but it was a disaster with the shorthand notation because you can have namespace collisions. Consider: - docker.io/org/projectA (owner 1) - ghcr.io/org/projectA (owner 2) What happens below? What do you get? How do you know where the mirror admin is pulling from? - docker pull org/projectA That only works if you have single source of truth or if you keep a mapping somewhere. Ex: - org/projectA --> docker.io - org/projectB --> ghcr.io That's not useful because your definitions are still ambiguous unless you go look at the mappings, so all you've done is add external config vs explicitly declaring the namespace. Plus, you can set up a pull-through cache everywhere it makes sense. - locationA - hub.example.com = 192.0.2.1 - locationB - hub.example.com = 192.0.2.2 I'd be interested to hear about scenarios where mirrors are more than a workaround for failing to understand the power of Docker's namespacing and defaulting to the shorthand notation for everything.

wkat4242 2y ago

As far as I know you do always have to specify it. But I tend to script this all anyway. It's not a big deal to me.

c0balt 2y ago

Not for docker AFAIK, https://github.com/moby/moby/issues/33069 https://github.com/moby/moby/issues/33069, however for podman, see https://docs.podman.io/en/latest/markdown/podman.1.html https://docs.podman.io/en/latest/markdown/podman.1.html (registries.conf under configuration files).

hedora 2y ago

No. Docker has refused patches that add such an option for anti-competitive reasons.

donmcronald 2y ago

> do you always have to make sure to execute 'docker pull <mycustomrepo.io/whatever>' explicitly I started using explicit repository names for everything including Docker Hub 5+ years ago and I don't regret it. I haven't thought about mirrors since, and I find it easier to reason about everything. I use pull-through caches with dedicated namespaces for popular upstream registries. - hub.example.com/ubuntu --> ubuntu from Docker Hub - ghcr.example.com/org/projectA --> project from GHCR I tried using mirrors at first, but it was a disaster with the shorthand notation because you can have namespace collisions. Consider: - docker.io/org/projectA (owner 1) - ghcr.io/org/projectA (owner 2) What happens below? What do you get? How do you know where the mirror admin is pulling from? - docker pull org/projectA That only works if you have single source of truth or if you keep a mapping somewhere. Ex: - org/projectA --> docker.io - org/projectB --> ghcr.io That's not useful because your definitions are still ambiguous unless you go look at the mappings, so all you've done is add external config vs explicitly declaring the namespace. Plus, you can set up a pull-through cache everywhere it makes sense. - locationA - hub.example.com = 192.0.2.1 - locationB - hub.example.com = 192.0.2.2 I'd be interested to hear about scenarios where mirrors are more than a workaround for failing to understand the power of Docker's namespacing and defaulting to the shorthand notation for everything.