3 ms·

It's worth noting that this behavior is also a sticking point with some users and distros, and I believe was at least part of the reasoning behind podman being

It's worth noting that this behavior is also a sticking point with some users and distros, and I believe was at least part of the reasoning behind podman being developed by Red Hat. Sometimes you don't want some third party controlling and blessing what's okay, you want to explicitly control that by only allowing sources you control so you can't even accidentally use that third party. Different groups have different use cases and it's hard to support them all well.

marcosdumay 5y ago
You mean you want to override or replace the global name registry? I can't imagine that getting any harder by the global vs. scoped name distinction. It's just an extra feature.
- kbenson 5y ago
  It's a feature docker refused to implement, and is one of the reasons Red Hat created podman, which is a drop in docker replacement (you can alias it to docker for the most part), but it allows full control over what repos are checked. For docker, as I understand it to get something functionally similar you have to define a mirror for docker.io that's not really a mirror and then prefer that mirror and/or disallow traffic to docker.io in some fashion.
  - infogulch 5y ago
    I've heard this argument a million times, but I really don't get it. If you want to control which images are deployed, you want to be running your own image registry anyway. So you already have full control: just limit images to ones in your private registry with its fully qualified name. Why do you also insist on being able to deploy with 'short' names? Arguably it's better because users can't confuse "enterprise customized ubuntu:20.04" with the public one and bother open source maintainers with internal issues.
    - kbenson 5y ago
      Nobody is insisting on being able to deploy with short names (or at least not the people that actually care about this). They are insisting that someone screwing up and using a short name when they shouldn't doesn't go out to a third party that's not explicitly trusted. Making this about short names is completely missing the point. Requiring docker to be run with a "mirror" which isn't actually a mirror of docker.io and making it use your non-mirror mirror so docker.io can't be reached and everything still works is just a hacky way to trick docker into working in what many people think is a very valid way - where no external resources can be used as a container not just as a matter of policy, but as a matter of capability. Put simply, it's not about replacing the default repo, it's about excluding all external repos. Requiring they all use long names would be a perfectly acceptable trade off for most orgs I think, if that was an option offered.
      - infogulch 5y ago
        Ah thanks for clarifying. I think this issue gets muddled by people who do want to override the default repo to get short names, to which I roll my eyes. But it seems there is a real issue in that this: > just limit images to ones in your private registry ... is actually not possible for a basic docker install. (Every time I use the word "just" it turns on me, and this is not an exception.) There are some implementations that have this feature (k8s, podman, etc), but the fact that it's not possible in the industry default container solution is an issue.
mikepurvis 5y ago
I definitely see both of sides of it— on the one hand, it's nice that "docker pull nginx" is always shorthand for "docker pull docker.io/_/nginx" and whether or not it is isn't dependent on some config file somewhere telling you what your primary registry is. We solved this for ourselves internally by just always using fully qualified names (containers.corp.com/foo) and not worrying too much about it. But I can also see how this is absolutely a power grab by Docker Inc. For a company which has given away almost everything and has basically no moat in terms of technology, ecosystem, or thought-leadership, I can understand them wanting to at least retain the final say on which containers are which. And of course, given that perspective, it's clear why a company like Red Hat would chafe against this, particularly when it's clear from the architectural differences in Podman (daemonless, rootless) that they were looking for an excuse to do it over anyway.

marcosdumay 5y ago

You mean you want to override or replace the global name registry? I can't imagine that getting any harder by the global vs. scoped name distinction. It's just an extra feature.

kbenson 5y ago
It's a feature docker refused to implement, and is one of the reasons Red Hat created podman, which is a drop in docker replacement (you can alias it to docker for the most part), but it allows full control over what repos are checked. For docker, as I understand it to get something functionally similar you have to define a mirror for docker.io that's not really a mirror and then prefer that mirror and/or disallow traffic to docker.io in some fashion.
- infogulch 5y ago
  I've heard this argument a million times, but I really don't get it. If you want to control which images are deployed, you want to be running your own image registry anyway. So you already have full control: just limit images to ones in your private registry with its fully qualified name. Why do you also insist on being able to deploy with 'short' names? Arguably it's better because users can't confuse "enterprise customized ubuntu:20.04" with the public one and bother open source maintainers with internal issues.
  - kbenson 5y ago
    Nobody is insisting on being able to deploy with short names (or at least not the people that actually care about this). They are insisting that someone screwing up and using a short name when they shouldn't doesn't go out to a third party that's not explicitly trusted. Making this about short names is completely missing the point. Requiring docker to be run with a "mirror" which isn't actually a mirror of docker.io and making it use your non-mirror mirror so docker.io can't be reached and everything still works is just a hacky way to trick docker into working in what many people think is a very valid way - where no external resources can be used as a container not just as a matter of policy, but as a matter of capability. Put simply, it's not about replacing the default repo, it's about excluding all external repos. Requiring they all use long names would be a perfectly acceptable trade off for most orgs I think, if that was an option offered.
    - infogulch 5y ago
      Ah thanks for clarifying. I think this issue gets muddled by people who do want to override the default repo to get short names, to which I roll my eyes. But it seems there is a real issue in that this: > just limit images to ones in your private registry ... is actually not possible for a basic docker install. (Every time I use the word "just" it turns on me, and this is not an exception.) There are some implementations that have this feature (k8s, podman, etc), but the fact that it's not possible in the industry default container solution is an issue.

mikepurvis 5y ago

I definitely see both of sides of it— on the one hand, it's nice that "docker pull nginx" is always shorthand for "docker pull docker.io/_/nginx" and whether or not it is isn't dependent on some config file somewhere telling you what your primary registry is. We solved this for ourselves internally by just always using fully qualified names (containers.corp.com/foo) and not worrying too much about it. But I can also see how this is absolutely a power grab by Docker Inc. For a company which has given away almost everything and has basically no moat in terms of technology, ecosystem, or thought-leadership, I can understand them wanting to at least retain the final say on which containers are which. And of course, given that perspective, it's clear why a company like Red Hat would chafe against this, particularly when it's clear from the architectural differences in Podman (daemonless, rootless) that they were looking for an excuse to do it over anyway.