Implementation of the Manifest Service API refactor.

Add a generic Manifest interface to represent manifests in the registry and
remove references to schema specific manifests.

Add a ManifestBuilder to construct Manifest objects. Concrete manifest builders
will exist for each manifest type and implementations will contain manifest
specific data used to build a manifest.

Remove Signatures() from Repository interface.

Signatures are relevant only to schema1 manifests.  Move access to the signature
store inside the schema1 manifestStore.  Add some API tests to verify
signature roundtripping.

schema1
-------

Change the way data is stored in schema1.Manifest to enable Payload() to be used
to return complete Manifest JSON from the HTTP handler without knowledge of the
schema1 protocol.

tags
----

Move tag functionality to a seperate TagService and update ManifestService
to use the new interfaces.  Implement a driver based tagService to be backward
compatible with the current tag service.

Add a proxyTagService to enable the registry to get a digest for remote manifests
from a tag.

manifest store
--------------

Remove revision store and move all signing functionality into the signed manifeststore.

manifest registration
---------------------

Add a mechanism to register manifest media types and to allow different manifest
types to be Unmarshalled correctly.

client
------

Add ManifestServiceOptions to client functions to allow tags to be passed into Put and
Get for building correct registry URLs.  Change functional arguments to be an interface type
to allow passing data without mutating shared state.

Signed-off-by: Richard Scothern <richard.scothern@gmail.com>

Signed-off-by: Richard Scothern <richard.scothern@docker.com>
This commit is contained in:
Richard Scothern 2015-08-20 21:50:15 -07:00 committed by Richard Scothern
parent 9162760443
commit cb6f002350
36 changed files with 1681 additions and 823 deletions

View file

@ -402,6 +402,28 @@ for details):
The client should verify the returned manifest signature for authenticity
before fetching layers.
##### Existing Manifests
The image manifest can be checked for existence with the following url:
```
HEAD /v2/<name>/manifests/<reference>
```
The `name` and `reference` parameter identify the image and are required. The
reference may include a tag or digest.
A `404 Not Found` response will be returned if the image is unknown to the
registry. If the image exists and the response is successful the response will
be as follows:
```
200 OK
Content-Length: <length of manifest>
Docker-Content-Digest: <digest>
```
#### Pulling a Layer
Layers are stored in the blob portion of the registry, keyed by digest.

View file

@ -402,6 +402,28 @@ for details):
The client should verify the returned manifest signature for authenticity
before fetching layers.
##### Existing Manifests
The image manifest can be checked for existence with the following url:
```
HEAD /v2/<name>/manifests/<reference>
```
The `name` and `reference` parameter identify the image and are required. The
reference may include a tag or digest.
A `404 Not Found` response will be returned if the image is unknown to the
registry. If the image exists and the response is successful the response will
be as follows:
```
200 OK
Content-Length: <length of manifest>
Docker-Content-Digest: <digest>
```
#### Pulling a Layer
Layers are stored in the blob portion of the registry, keyed by digest.