Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docker info reports an index server url as a registry url #3793

Closed
x-yuri opened this issue Sep 29, 2022 · 5 comments · Fixed by #4204
Closed

docker info reports an index server url as a registry url #3793

x-yuri opened this issue Sep 29, 2022 · 5 comments · Fixed by #4204

Comments

@x-yuri
Copy link

x-yuri commented Sep 29, 2022

Description

$ docker info | grep Registry:
 Registry: https://index.docker.io/v1/

$ curl -sS https://index.docker.io/v1/ -o /dev/null -w '%{http_code}'
404

IndexServerAddress
string
Default: "https://index.docker.io/v1/"

Address / URL of the index server that is used for image search, and as a default for user authentication for Docker Hub and Docker Cloud.

https://docs.docker.com/engine/api/v1.41/#tag/System/operation/SystemInfo

I don't see how index.docker.io is used for authentication. Can you possibly provide steps to reproduce and some links to the source code?

From what I can see docker uses registry-1.docker.io to contact the registry. And what's used for authentication is auth.docker.io:

$ curl -sS https://registry-1.docker.io/v2/ -o /dev/null -w '%header{www-authenticate}' |& less
Bearer realm="https://auth.docker.io/token",service="registry.docker.io"

Not to mention that to get the registry-1.docker.io value I had to consult the source code.

It's not clear if there's a difference between a docker registry and an index server.

Here the domain is called legacy.

This whole thing is pretty damn confusing. Particularly the fact that docker info calls an index server a registry and provides a broken URL.

Reproduce

$ docker info | grep Registry:

Expected behavior

docker info shouldn't confuse users. It should be documented what's the difference between an index server and a docker registry. And if there's a difference, docker info shouldn't call an index server a registry. Especially provide a broken URL. Is it even used these days?

docker version

Client:
 Version:           20.10.18
 API version:       1.41
 Go version:        go1.19.1
 Git commit:        b40c2f6b5d
 Built:             Thu Sep 29 08:07:17 2022
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server:
 Engine:
  Version:          20.10.18
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.19.1
  Git commit:       e42327a6d3
  Built:            Thu Sep 29 08:07:16 2022
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.6.8
  GitCommit:        9cd3357b7fd7218e4aec3eae239db1f68a5a6ec6.m
 runc:
  Version:          1.1.4
  GitCommit:        
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  compose: Docker Compose (Docker Inc., 2.11.1)

Server:
 Containers: 117
  Running: 0
  Paused: 0
  Stopped: 117
 Images: 1165
 Server Version: 20.10.18
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: false
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 9cd3357b7fd7218e4aec3eae239db1f68a5a6ec6.m
 runc version: 
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.19.11-arch1-1
 Operating System: Arch Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 15.02GiB
 Name: yuri2
 ID: GDZF:WOJX:D4NW:H545:6ACG:PLQT:M3CQ:4QKD:TD2V:T5LW:HSBG:QHBC
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Additional Info

No response

@thaJeztah
Copy link
Member

Yes, this is really confusing, and something that will be addressed at some point; there are plans to migrate some domains and update logic around this, but .. this may take some time.

For a bit of background;

index.docker.io was the name for the first "Docker Hub", which was named "the docker index" (hence index.docker.io). This registry used "v1" of the registry specification, which included "search". The Docker Index became "Docker Hub", and the registry v2 API, which was the foundation for the OCI Distribution Spec. The Docker Hub registry migrated to another domain (registry-1.docker.io), however the v2 specification (by design) does not provide search endpoints, so those endpoints still use the v1 API (accessible at https://index.docker.io/v1/search/)

Unfortunately at some point, logic was implemented in the Docker Engine and Docker CLI code to map domains to their new locations (e.g. there's mapping for docker.io/xxxx image references to registry-1.docker.io, as well as authentication mapping from index.docker.io); the same logic also made its way into all container runtimes (containerd, cri-o, kubernetes), which means that, with the Docker Engine only already having 30+ million monthly installs, it's become a bit of a challenge to change these things without breaking existing installations.

@x-yuri
Copy link
Author

x-yuri commented Oct 7, 2022

Thanks for the explanations. So the docker index used registry v1, which had a search route. Docker Hub uses registry v2 at registry-1.docker.io, but the obsolete routes are still available at index.docker.io?.. And an index server is an obsolete concept as well?

@thaJeztah
Copy link
Member

The Docker Hub registry (currently) runs at registry-1.docker.io, which is compliant with the OCI Distribution Spec.

Not sure if "obsolete" is the correct term to use for the index.docker.io search endpoints, but the OCI Specification does not include search functionality, leaving it up to implementations wether or not they provide a search feature (some of the public registries decided not to).

Given that there's no standardised replacement for search, some registries still provide the v1 search, conforming to the Docker Registry V1 "search" specification (this includes Docker Hub and many self-hosted registries that deploy the open-source CNCF distribution registry (https://github.com/distribution/distribution).

@x-yuri
Copy link
Author

x-yuri commented Oct 8, 2022

Okay, so Docker Index is the previous name of Docker Hub. They are names of the website that includes a docker registry (registry-1.docker.io) and an index server (index.docker.io). An index server is a service that allows to search the registry.

this includes Docker Hub and many self-hosted registries that deploy the open-source CNCF distribution registry (https://github.com/distribution/distribution)

At first glance it doesn't look like distribution/distribution provides a search endpoint. Am I wrong? That means they're running a separate service (an index server) that provides the search endpoint?

opello added a commit to opello/truecharts-charts that referenced this issue Feb 4, 2023
From the perspective of linking to image details on the Docker Hub web
interface, there are two types of images:

  1. Docker Official Images
  2. all of the other images, regardless of their trustworthiness

The Docker Official Images can be referenced several ways, either on the
command line when passed to docker pull, or in the FROM instruction of a
Dockerfile:

  * busybox
  * library/busybox
  * docker.io/busybox
  * docker.io/library/busybox

Furthermore, over the years there have been several domains used for the
official Docker Hub registry:

  * docker.io
  * index.docker.io
  * registry-1.docker.io
  * registry.hub.docker.com

The goal here is handling each possible case, which makes Docker Hub
images more complex than the handling for other registries.

It also makes the case block's '*' (default) case harder to find in the
sequence of glob expressions, but this is necessary to avoid repeating
the parsing or adding another helper function.

Reference:
docker/hub-feedback#2113
docker/cli#3793

Signed-off-by: Dan Christensen <opello@opello.org>
Ornias1993 pushed a commit to truecharts/charts that referenced this issue Feb 9, 2023
* style: Split long lines, follow .editorconfig

Signed-off-by: Dan Christensen <opello@opello.org>

* fix: Clarify why some sources are being excluded

The explanation is also meant to remind anyone that sees it that the
code could inadvertently remove a sources sequence entry that was
intentionally added, because it can not tell.

Signed-off-by: Dan Christensen <opello@opello.org>

* fix: Comment the image-to-URL code

Signed-off-by: Dan Christensen <opello@opello.org>

* refactor: Use case instead of if-ladder

This is a faithful move from the if-ladder to a case statement that
preserves the existing behavior, with optimization to follow.  The
behavior of the function before and after this change is the same.

Signed-off-by: Dan Christensen <opello@opello.org>

* fix: Remove dead code

No "container source" entry from description_list.md has a scheme.  The
values are parsed from the Dockerfiles and would not have one there
either.

Signed-off-by: Dan Christensen <opello@opello.org>

* fix: tccr.io image links

Parse the tccr.io prefix specifically instead of just checking for the
substring tccr which could result in a false positive.

The generated link was also going to point to a truecharts subdirectory
under mirror in the containers repository that does not exist.

Signed-off-by: Dan Christensen <opello@opello.org>

* fix: lscr.io image links

Parse the lscr.io prefix specifically instead of just checking for the
substring lscr which could result in a false positive.

The generated link would also return a 404 because the web interface
requires the image name to be passed in the query string.

Signed-off-by: Dan Christensen <opello@opello.org>

* fix: gcr.io image links

Parse the gcr.io prefix specifically instead of just checking for the
substring gcr which could result in a false positive.

Signed-off-by: Dan Christensen <opello@opello.org>

* feat: Do not add sources if no prefix is created

The intent of this code is to generate URLs to be included in
documentation to attribute inputs to the chart.  If a publicly
accessible URL can not be generated from the image name it makes sense
to not add anything and instead rely on a manual edit to the Chart.yaml.

Signed-off-by: Dan Christensen <opello@opello.org>

* fix: Disable azurecr.io image links

There does not seem to be a general purpose web index to the azurecr.io
hosted images.

Signed-off-by: Dan Christensen <opello@opello.org>

* feat: Disable mcr.microsoft.com image links

Signed-off-by: Dan Christensen <opello@opello.org>

* fix: public.ecr.aws image links

Parse the public.ecr.aws prefix specifically instead of just checking
for the substring public.ecr.aws which could result in a false positive.

Signed-off-by: Dan Christensen <opello@opello.org>

* fix: Disable ocir.io image links

There does not seem to be a general purpose web index to the ocir.io
hosted images.

Signed-off-by: Dan Christensen <opello@opello.org>

* refactor: Add Docker Hub hosted image links

From the perspective of linking to image details on the Docker Hub web
interface, there are two types of images:

  1. Docker Official Images
  2. all of the other images, regardless of their trustworthiness

The Docker Official Images can be referenced several ways, either on the
command line when passed to docker pull, or in the FROM instruction of a
Dockerfile:

  * busybox
  * library/busybox
  * docker.io/busybox
  * docker.io/library/busybox

Furthermore, over the years there have been several domains used for the
official Docker Hub registry:

  * docker.io
  * index.docker.io
  * registry-1.docker.io
  * registry.hub.docker.com

The goal here is handling each possible case, which makes Docker Hub
images more complex than the handling for other registries.

It also makes the case block's '*' (default) case harder to find in the
sequence of glob expressions, but this is necessary to avoid repeating
the parsing or adding another helper function.

Reference:
docker/hub-feedback#2113
docker/cli#3793

Signed-off-by: Dan Christensen <opello@opello.org>

* feat: ghcr.io image links

Signed-off-by: Dan Christensen <opello@opello.org>

* feat: quay.io image links

Signed-off-by: Dan Christensen <opello@opello.org>

* feat: Do not generate likely-bad links

By assuming image names that are not handled by other cases are Docker
Hub images there is a risk of generating bad links.  Minimize this risk
by not generating a link if the image name for a Docker Hub link has two
slashes.  This is a case that should not happen and would likely mean an
unsupported registry is being used.

There is still a risk of an unsupported registry being treated as Docker
Hub and an invalid link being generated.  That case is if the domain and
image name is example.com/busybox where there is only one slash.

Signed-off-by: Dan Christensen <opello@opello.org>

* refactor: Sort cases

Sort the cases from longest to shortest prioritizing any case with a
suffix only glob over any case with a prefix glob.  The intention is to
avoid having a case that can not be reached.

The combined Docker Hub and default case is last.  It might make sense
to split the default case handling off but it does not seem to be a
problem right now.

Signed-off-by: Dan Christensen <opello@opello.org>

---------

Signed-off-by: Dan Christensen <opello@opello.org>
@thaJeztah
Copy link
Member

At first glance it doesn't look like distribution/distribution provides a search endpoint. Am I wrong? That means they're running a separate service (an index server) that provides the search endpoint?

Oh, good call, I may be mistaken and distribution/distribution may indeed not be providing that endpoint. I know Docker Hub runs a separate service for it (but wasn't 100% sure if the open-source registry still included it)

I opened a PR to remove this field from the default docker info output;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants