page_title: Registry Documentation page_description: Documentation for docker Registry and Registry API page_keywords: docker, registry, api, hub
There are three major components playing a role in the Docker ecosystem.
The Docker Hub is responsible for centralizing information about:
The Docker Hub has different components:
The Docker Hub is authoritative for that information.
There is only one instance of the Docker Hub, run and managed by Docker Inc.
The 1.0 registry has the following characteristics:
We expect that there will be multiple registries out there. To help you grasp the context, here are some examples of registries:
docker pull
those images locally.docker pull basho/riak1.3
and automatically push from the vendor registry (instead of a sponsor registry); i.e., vendors get all the convenience of a sponsor registry, while retaining control on the asset distribution.Note: The latter implies that while HTTP is the protocol of choice for a registry, multiple schemes are possible (and in some cases, trivial):
- HTTP with GET (and PUT for read-write registries);
- local mount point;
- remote docker addressed through SSH.
The latter would only require two new commands in Docker, e.g., registryget
and registryput
, wrapping access to the local filesystem (and optionally doing consistency checks). Authentication and authorization are then delegated to SSH (e.g., with public keys).
On top of being a runtime for LXC, Docker is the Registry client. It supports:
samalba/busybox
is on Registry A b. here are the checksums for samalba/busybox
(for all layers) c. tokensamalba/busybox
(all of them to the base image). Registry A is authoritative for “samalba/busybox” but keeps a copy of all inherited layers and serve them all from the same location.It's possible to run:
$ sudo docker pull https://<registry>/repositories/samalba/busybox
In this case, Docker bypasses the Docker Hub. However the security is not guaranteed (in case Registry A is corrupted) because there won't be any checksum checks.
Currently registry redirects to s3 urls for downloads, going forward all downloads need to be streamed through the registry. The Registry will then abstract the calls to S3 by a top-level class which implements sub-classes for S3 and local storage.
Token is only returned when the X-Docker-Token
header is sent with request.
Basic Auth is required to pull private repos. Basic auth isn't required for pulling public repos, but if one is provided, it needs to be valid and for an active account.
API (pulling repository foo/bar):
Headers:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== X-Docker-Token: true
Action:
(looking up the foo/bar in db and gets images and checksums for that repo (all if no tag is specified, if tag, only checksums for those tags) see part 4.4.1)
Headers:
Authorization: Token signature=123abc,repository=”foo/bar”,access=write X-Docker-Endpoints: registry.docker.io [,registry2.docker.io]
Body:
Jsonified checksums (see part 4.4.1)
Headers:
Authorization: Token signature=123abc,repository=”foo/bar”,access=write
Headers:
Authorization: Token signature=123abc,repository=”foo/bar”,access=read
Body:
<ids and checksums in payload>
Action:
(Lookup token see if they have access to pull.) If good: HTTP 200 OK Docker Hub will invalidate the token If bad: HTTP 401 Unauthorized
Action:
(for each image id returned in the registry, fetch /json + /layer)
Note: If someone makes a second request, then we will always give a new token, never reuse tokens.
Note: It's possible not to use the Docker Hub at all! In this case, a deployed version of the Registry is deployed to store and serve images. Those images are not authenticated and the security is not guaranteed.
Note: Docker Hub can be replaced! For a private Registry deployed, a custom Docker Hub can be used to serve and validate token according to different policies.
Docker computes the checksums and submit them to the Docker Hub at the end of the push. When a repository name does not have checksums on the Docker Hub, it means that the push is in progress (since checksums are submitted at the end).
API (pushing repos foo/bar):
Headers:
Authorization: Basic sdkjfskdjfhsdkjfh== X-Docker-Token: true
Action:
Body:
(The body contains the list of images that are going to be pushed, with empty checksums. The checksums will be set at the end of the push):
[{“id”: “9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f”}]
Headers:
WWW-Authenticate: Token signature=123abc,repository=”foo/bar”,access=write X-Docker-Endpoints: registry.docker.io [, registry2.docker.io]
Headers:
Authorization: Token signature=123abc,repository=”foo/bar”,access=write
Headers:
Authorization: Token signature=123abc,repository=”foo/bar”,access=write
Action:
Headers:
Authorization: Token signature=123abc,repository=”foo/bar”,access=write Cookie: (Cookie provided by the Registry)
Headers:
Cookie: (Cookie provided by the Registry)
Headers:
Cookie: (Cookie provided by the Registry)
Headers:
X-Docker-Checksum: sha256:436745873465fdjkhdfjkgh
Headers:
Cookie: (Cookie provided by the Registry)
Body:
“98765432”
Headers:
Authorization: Basic 123oislifjsldfj== X-Docker-Endpoints: registry1.docker.io (no validation on this right now)
Body:
(The image, id`s, tags and checksums) [{“id”: “9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f”, “checksum”: “b486531f9a779a0c17e3ed29dae8f12c4f9e89cc6f0bc3c38722009fe6857087”}]
Return:
HTTP 204
Note: If push fails and they need to start again, what happens in the Docker Hub, there will already be a record for the namespace/name, but it will be initialized. Should we allow it, or mark as name already used? One edge case could be if someone pushes the same thing at the same time with two different shells.
If it‘s a retry on the Registry, Docker has a cookie (provided by the registry after token validation). So the Docker Hub won’t have to provide a new token.
If you need to delete something from the Docker Hub or registry, we need a nice clean way to do that. Here is the workflow.
samalba/busybox
(authentication required with user credentials)samalba/busybox
is marked as deleted and a temporary token is returnedNote: The Docker client should present an “Are you sure?” prompt to confirm the deletion before starting the process. Once it starts it can't be undone.
API (deleting repository foo/bar):
Headers:
Authorization: Basic sdkjfskdjfhsdkjfh== X-Docker-Token: true
Action:
Body:
Empty
Headers:
WWW-Authenticate: Token signature=123abc,repository=”foo/bar”,access=delete X-Docker-Endpoints: registry.docker.io [, registry2.docker.io] # list of endpoints where this repo lives.
Headers:
Authorization: Token signature=123abc,repository=”foo/bar”,access=delete
Headers:
Authorization: Token signature=123abc,repository=”foo/bar”,access=delete
Action:
(Registry -> Docker) 200 OK
200 If success 403 if forbidden 400 if bad request 404 if repository isn't found
(Docker -> Docker Hub) DELETE /v1/repositories/foo/bar/
Headers:
Authorization: Basic 123oislifjsldfj== X-Docker-Endpoints: registry-1.docker.io (no validation on this right now)
Body:
Empty
Return:
HTTP 200
The Docker Hub has two main purposes (along with its fancy social features):
Resolve short names (to avoid passing absolute URLs all the time):
username/projectname -> https://registry.docker.io/users//repositories// team/projectname -> https://registry.docker.io/team//repositories//
Authenticate a user as a repos owner (for a central referenced repository)
Using the Registry without the Docker Hub can be useful to store the images on a private network without having to rely on an external entity controlled by Docker Inc.
In this case, the registry will be launched in a special mode (-standalone? ne? -no-index?). In this mode, the only thing which changes is that Registry will never contact the Docker Hub to verify a token. It will be the Registry owner responsibility to authenticate the user who pushes (or even pulls) an image using any mechanism (HTTP auth, IP based, etc...).
In this scenario, the Registry is responsible for the security in case of data corruption since the checksums are not delivered by a trusted entity.
As hinted previously, a standalone registry can also be implemented by any HTTP server handling GET/PUT requests (or even only GET requests if no write access is necessary).
The Docker Hub data needed by the Registry are simple:
In the scenario of a Registry running on a private network with the need of centralizing and authorizing, it's easy to use a custom Docker Hub.
The only challenge will be to tell Docker to contact (and trust) this custom Docker Hub. Docker will be configurable at some point to use a specific Docker Hub, it‘ll be the private entity responsibility (basically the organization who uses Docker in a private environment) to maintain the Docker Hub and the Docker’s configuration among its consumers.
The first version of the api is available here: https://github.com/jpetazzo/docker/blob/acd51ecea8f5d3c02b00a08176171c59442df8b3/docs/images-repositories-push-pull.md
The format returned in the images is not defined here (for layer and JSON), basically because Registry stores exactly the same kind of information as Docker uses to manage them.
The format of ancestry is a line-separated list of image ids, in age order, i.e. the image's parent is on the last line, the parent of the parent on the next-to-last line, etc.; if the image has no parent, the file is empty.
GET /v1/images/<image_id>/layer PUT /v1/images/<image_id>/layer GET /v1/images/<image_id>/json PUT /v1/images/<image_id>/json GET /v1/images/<image_id>/ancestry PUT /v1/images/<image_id>/ancestry
POST /v1/users:
Body:
{"email": "[sam@docker.com](mailto:sam%40docker.com)", "password": "toto42", "username": "foobar"`}
Validation:
Valid:
return HTTP 201
Errors: HTTP 400 (we should create error codes for possible errors) - invalid json - missing field - wrong format (username, password, email, etc) - forbidden name - name already exists
Note: A user account will be valid only if the email has been validated (a validation link is sent to the email address).
PUT /v1/users/<username>
Body:
{"password": "toto"}
Note: We can also update email address, if they do, they will need to reverify their new email address.
Does nothing else but asking for a user authentication. Can be used to validate credentials. HTTP Basic Auth for now, maybe change in future.
GET /v1/users
Return:
The Registry does not know anything about users. Even though repositories are under usernames, it‘s just a namespace for the registry. Allowing us to implement organizations or different namespaces per user later, without modifying the Registry’s API.
The following naming restrictions apply:
GET /v1/repositories/<namespace>/<repository_name>/tags **Return**: HTTP 200 [ { "layer": "9e89cc6f", "name": "latest" }, { "layer": "b486531f", "name": "0.1.1", } ]
4.3.2 Read the content of a tag (resolve the image id):
GET /v1/repositories/<namespace>/<repo_name>/tags/<tag>
Return:
"9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f"
4.3.3 Delete a tag (registry):
DELETE /v1/repositories/<namespace>/<repo_name>/tags/<tag>
For the Docker Hub to “resolve” the repository name to a Registry location, it uses the X-Docker-Endpoints header. In other terms, this requests always add a X-Docker-Endpoints
to indicate the location of the registry which hosts this repository.
4.4.1 Get the images:
GET /v1/repositories/<namespace>/<repo_name>/images **Return**: HTTP 200 [{“id”: “9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f”, “checksum”: “[md5:b486531f9a779a0c17e3ed29dae8f12c4f9e89cc6f0bc3c38722009fe6857087](md5:b486531f9a779a0c17e3ed29dae8f12c4f9e89cc6f0bc3c38722009fe6857087)”}]
You always add images, you never remove them.
PUT /v1/repositories/<namespace>/<repo_name>/images
Body:
[ {“id”: “9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f”, “checksum”: “sha256:b486531f9a779a0c17e3ed29dae8f12c4f9e89cc6f0bc3c38722009fe6857087”} ]
Return:
204
DELETE /v1/repositories//<repo_name>
Return 200 OK
This starts the delete process. see 2.3 for more details.
DELETE /v1/repositories//<repo_name>
Return 202 OK
It's possible to chain Registries server for several reasons:
When a Registry is a reference for a repository, it should host the entire images chain in order to avoid breaking the chain during the download.
The Docker Hub and Registry use this mechanism to redirect on one or the other.
Example with an image download:
On every request, a special header can be returned:
X-Docker-Endpoints: server1,server2
On the next request, the client will always pick a server from this list.
The Docker Hub supports both “Basic” and “Token” challenges. Usually when there is a 401 Unauthorized
, the Docker Hub replies this:
401 Unauthorized WWW-Authenticate: Basic realm="auth required",Token
You have 3 options:
Header:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== X-Docker-Token: true
In this case, along with the 200 response, you‘ll get a new token (if user auth is ok): If authorization isn’t correct you get a 401 response. If account isn't active you will get a 403 response.
Response:
200 OK X-Docker-Token: Token signature=123abc,repository=”foo/bar”,access=read
Header:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Header:
Authorization: Token signature=123abc,repository=”foo/bar”,access=read
The Registry only supports the Token challenge:
401 Unauthorized WWW-Authenticate: Token
The only way is to provide a token on 401 Unauthorized
responses:
Authorization: Token signature=123abc,repository="foo/bar",access=read
Usually, the Registry provides a Cookie when a Token verification succeeded. Every time the Registry passes a Cookie, you have to pass it back the same cookie.:
200 OK Set-Cookie: session="wD/J7LqL5ctqw8haL10vgfhrb2Q=?foo=UydiYXInCnAxCi4=×tamp=RjEzNjYzMTQ5NDcuNDc0NjQzCi4="; Path=/; HttpOnly
Next request:
GET /(...) Cookie: session="wD/J7LqL5ctqw8haL10vgfhrb2Q=?foo=UydiYXInCnAxCi4=×tamp=RjEzNjYzMTQ5NDcuNDc0NjQzCi4="