The CLI currenly calls the `/info` endpoint to get the address
of the default registry to use.
This functionality was added as part of the initial Windows implementation
of the engine. For legal reasons, Microsoft Windows (and thus Docker images
based on Windows) were not allowed to be distributed through non-Microsoft
infrastructure. As a temporary solution, a dedicated "registry-win-tp3.docker.io"
registry was created to serve Windows images.
As a result, the default registry was no longer "fixed", so a helper function
(`ElectAuthServer`) was added to allow the CLI to get the correct registry
address from the daemon. (docker/docker PR's/issues 18019, 19891, 19973)
Using separate registries was not an ideal solution, and a more permanent
solution was created by introducing "foreign image layers" in the distribution
spec, after which the "registry-win-tp3.docker.io" ceased to exist, and
removed from the engine through docker/docker PR 21100.
However, the `ElectAuthServer` was left in place, quoting from that PR;
> make the client check which default registry the daemon uses is still
> more correct than leaving it up to the client, even if it won't technically
> matter after this PR. There may be some backward compatibility scenarios
> where `ElectAuthServer` [sic] is still helpful.
That comment was 5 years ago, and given that the engine and cli are
released in tandem, and the default registry is not configurable, we
can save the extra roundtrip to the daemon by using a fixed value.
This patch deprecates the `ElectAuthServer` function, and makes it
return the default registry without calling (potentially expensie)
`/info` API endpoint.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
With this change all `inspect` commands will output a compact JSON
representation of the elements, the default format (indented JSON) stays the
same.
Signed-off-by: Djordje Lukic <djordje.lukic@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
including all the directives and a link to the documentation.
Signed-off-by: Silvin Lubecki <silvin.lubecki@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Once upon a time, there was a website named ["The Docker index"][2]; a complimentary
service for users of Docker, provided by dotCloud. The Docker Index was the place
to find and explore pre-made container images, and allowed you to [share your
images and download them][1]. The Docker Index evolved rapidly, and gained new
features, such as [Trusted Images][3], and "stars" to rank your favorite images.
The website also provided an API, which allowed you to search images, even from
the comfort of your `docker` CLI. Things moved fast in container-land, and while
there was an API to use, it was still a work in progress. While the Docker Index
allowed users to "star" images, the search API did not rank results accordingly.
As any engineer knows, there's no problem that can't be solved with some elbow-
grease and a piece of Duct tape, so while the Docker Index team worked on making
the search API better, the `docker` engine [fixed the problem on the client side][4]
Years went by, and the Docker Index API became the "registry V1" specification,
including search. The registry got a major "v2" rewrite and became the [OCI Distribution
Spec][5], and Docker Index became Docker Hub, which included V2 and V3 search APIs.
The V1 search API continued to be supported, as it was the only documented API
for registries, but improvements were made, including ranking of search results.
Duct tape is durable, and even though improvements were made, the Docker client
continued to sort the results as well. Unfortunately, this meant that search
results on the command-line were ranked different from their equivalent on the
registry (such as Docker Hub).
This patch removes the client-side sorting of results, using the order in which
the search API returned them to (finally) celebrate the work of the engineers
working on the search API, also when used from the command-line.
[1]: https://web.archive.org/web/20130708004229/http://docker.io/
[2]: https://web.archive.org/web/20130623223614/https://index.docker.io/
[3]: https://web.archive.org/web/20140208001647/https://index.docker.io/
[4]: 1669b802cc
[5]: https://github.com/opencontainers/distribution-spec
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This has now been implemented in buildkit#2116, so this note can
be removed (once integrated into Docker).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
With this change it is now possible to give a relative path to the --volume and
--mount flags.
$ docker run --mount type=bind,source=./,target=/test ...
$ docker run -v .:/test ...
Fixes#1203
Signed-off-by: Djordje Lukic <djordje.lukic@docker.com>
Changed `matcher.Matches(file)` to `matcher.MatchesOrParentMatches(file)`:
cli/command/image/build/context.go:95:9: SA1019: matcher.Matches is deprecated: This implementation is buggy (it only checks a single parent dir against the pattern) and will be removed soon. Use either MatchesOrParentMatches or MatchesUsingParentResults instead. (staticcheck)
return matcher.Matches(file)
^
And updated a test to match the JSON omitting empty RootFS.Type fields (in
practice, this field should never be empty in real situations, and always
be "layer"). Changed the test to use subtests to easier find which case
is failing.
full diff: 343665850e...83b51522df
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The information in this struct was basically fixed (there's
some discrepancy around the "DefaultVersion" which, probably,
should never vary, and always be set to the Default (maximum)
API version supported by the client.
Experimental is now always enabled, so this information did
not require any dynamic info as well.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This was there for historic reasons (I think `goimports` expected this,
and we used to have a linter that wanted it), but it's not needed, so
let's remove it (to make my IDE less complaining about unneeded aliases)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Not a fan of aliases, but unfortunately they're sometimes needed. We import both
docker/docker/registry and docker/registry and api/types/registry, so I looked
for which one to continue using an alias, and this was the one "least" used,
and which already used this alias everywhere, except for two places.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
