英文:
The different account types on Docker Hub registry... how it works?
问题
我无法理解Docker Hub注册表中不同的“级别”或账户类型如何工作。我将解释我的意思。
第一种情况：许多没有“前缀”标记为Official Docker Images的软件包，例如php、nginx、mariadb等。这些存储库的URL在路径中以/_/为前缀，如hub.docker.com/_/php。
第二种情况：许多“已知”的软件包，带有前缀，并标记为Sponsored OSS，例如pihole/pihole。这些存储库的URL在路径中以/r/为前缀，如hub.docker.com/r/pihole/pihole。
常规用户情况：相反，当我推送到Docker Hub时，我被迫指定我的用户名作为前缀。因此，我的镜像最终变成了<username>/foo:latest。我的页面前缀是/u/，如hub.docker.com/u/<username>。
这在Docker Hub上代表什么？常规用户能够推送没有前缀的镜像吗？
英文:
I can't understand how the different "levels" or account types work in Docker Hub registry. I'll explain what I mean.
First case: lot of packages without a "prefix" labeled as Official Docker Images like php, nginx, mariadb etc. The URL for those repositories is prefixed with /_/ in the path, like hub.docker.com/_/php.
Second case: lot of packages "known", with a prefix and labeled as Sponsored OSS like pihole/pihole. The URL for those repositories is prefixed with /r/ in the path, like hub.docker.com/r/pihole/pihole.
Regular user case: on the contrary, when I push to Docker Hub, I'm forced to specify my username as prefix. So my images ends up to be: <username>/foo:latest. My page prefix is /u/ like hub.docker.com/u/<username>
What this represents on Docker Hub? Will a regular user able to push images without a prefix?
答案1
得分: 3
简短回答：不
你必须区分网站上数据的表示方式和 URL，以及面向人类的 URL，例如在 Docker Hub 上的 hub.docker.com/r/pihole/pihole，以及你可以拉取的图像的地址，例如在命令行界面（在本例中是 Docker）上的 docker pull pihole/pihole。
你在 UI 和 CLI URL 中看到的关联并非连锁。例如，.../r/... 几年前并不存在。
Docker 做了相当多的魔术来解析图像名称。允许你编写类似以下的内容：
docker pull nginx，它会被 Docker 运行时解析为 docker.io/library/nginx:latest。
并非所有容器运行时都表现相同，在某些情况下，你必须明确指定类似于 docker.io/library/nginx:latest 的完整限定名称（FQN），以完全标识图像位置。
如果你正在使用不同的容器运行时，比如 Podman，你可以自定义解析逻辑以满足你自己的需求，以便运行时将：
podman pull my_app 解析为 podman pull my.container-registry.com/library/my_app:latest
英文:
Short answer: NO
You have to differentiate between how data is represented on the website & URLs for humans e.g. on Docker Hub as hub.docker.com/r/pihole/pihole and the address of the images that you can pull. e.g. on the CLI with your container runtime (Docker in this case). docker pull pihole/pihole
The correlation you see in the URL of the UI and CLI is not chained together. For example, .../r/... didn't exist a few years back.
Docker does quite a bit of magic to resolve image names. Allowing you to write something like:
docker pull nginx which gets resolved by the Docker runtime to docker.io/library/nginx:latest
Not all container runtimes behave the same, in some you have to explicitly specify a FQN like docker.io/library/nginx:latest in oder to fully address the image location.
If you are using a different container runtime like Podman, you could, however, customize the resolution logic to your own needs so that the runtime turns:
podman pull my_app to resolve into podman pull my.container-registry.com/library/my_app:latest
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论