Mostly, we've made superficial changes to the storage package to start using
the Digest type. Many of the exported interface methods have been changed to
reflect this in addition to changes in the way layer uploads will be initiated.
Further work here is necessary but will come with a separate PR.
The Digest type will be fairly central for blob and layer management. The type
presented in this package provides a number of core features that should enable
reliable use within the registry. This commit will be followed by others that
convert the storage layer and webapp to use this type as the primary layer/blob
CAS identifier.
To bring the implementation inline with the specification, the names and
structure of the API routes have been updated.
The overloaded term "image" has been replaced with the term "manifest", which
may also be known as "image manifest". The desire for the layer storage to be
more of a general blob storage is reflected in moving from "layer" api prefixes
to "blob". The "tarsum" path parameter has been replaced by a more general
"digest" parameter and is no longer required to start uploads. Another set of
changes will come along to support this change at the storage service layer.
This only works for a specific whitelist of error types, which is
currently all errors in the storagedriver package.
Also improves storagedriver tests to enforce proper error types are
returned
This change contains the initial implementation of the LayerService to power
layer push and pulls on the storagedriver. The interfaces presented in this
package will be used by the http application to drive most features around
efficient pulls and resumable pushes.
The file storage/layer.go defines the interface interactions. LayerService is
the root type and supports methods to access Layer and LayerUpload objects.
Pull operations are supported with LayerService.Fetch and push operations are
supported with LayerService.Upload and LayerService.Resume. Reads and writes of
layers are split between Layer and LayerUpload, respectively.
LayerService is implemented internally with the layerStore object, which takes
a storagedriver.StorageDriver and a pathMapper instance.
LayerUploadState is currently exported and will likely continue to be as the
interaction between it and layerUploadStore are better understood. Likely, the
layerUploadStore lifecycle and implementation will be deferred to the
application.
Image pushes pulls will be implemented in a similar manner without the
discrete, persistent upload.
Much of this change is in place to get something running and working. Caveats
of this change include the following:
1. Layer upload state storage is implemented on the local filesystem, separate
from the storage driver. This must be replaced with using the proper backend
and other state storage. This can be removed when we implement resumable
hashing and tarsum calculations to avoid backend roundtrips.
2. Error handling is rather bespoke at this time. The http API implementation
should really dictate the error return structure for the future, so we
intend to refactor this heavily to support these errors. We'd also like to
collect production data to understand how failures happen in the system as
a while before moving to a particular edict around error handling.
3. The layerUploadStore, which manages layer upload storage and state is not
currently exported. This will likely end up being split, with the file
management portion being pointed at the storagedriver and the state storage
elsewhere.
4. Access Control provisions are nearly completely missing from this change.
There are details around how layerindex lookup works that are related with
access controls. As the auth portions of the new API take shape, these
provisions will become more clear.
Please see TODOs for details and individual recommendations.
A layer can only be pushed/pulled if the layer preceding it by the
length of the push/pull window has been successfully pushed.
An error returned from pushing or pulling any layer will cause the full
operation to be aborted.
These methods rely on an ObjectStore interface, which is meant to
approximate the storage behavior of the docker engine. This is very much
subject to change.
After discussion, it was found that one of the proposed regular expressions
incorrectly limited separator delimited compoonents to two characters. The
desired restriction is to have repository name components limited to two
characters minimum. This changeset accomplishes this by wrapping the regular
expressions in a validation function, returning detailed feedback on the
validation error.
With this change, the repository name regular expressions are no longer enough
to respond with 404s on invalid repo names. Changes to the router will need to
be added to support this.
We've added a path mapper to support simple mapping between path objects used
in the storage layer and the underlying file system. The target of this is to
ensure that paths are only calculated in a single place and their format is
separated from the data that makes up the path components.
This commit only includes spec implementation to support layer reads. Further
specs will come along with their implementations.
To be able to support multi-level repository names, the API has been adjusted
to disabiguate routes tagged image manifest routes and tag list routes. With
this effort, the regular expressions have been defined in a single place to
reduce repitition and ensure that validation is consistent across the registry.
The router was also refactored to remove the use of subrouters, simplifying the
route definition code. This also reduces the number of regular expression match
checks during the routing process.
This commit adds regular expression definitions for several string identifiers
used througout the registry. The repository name regex supports up to five path
path components and restricts repeated periods, dashes and underscores. The tag
regex simply validates the length of the tag and that printable characters are
required.
Though we define a new package common, these definition should land in docker
core.
This changeset defines the application structure to be used for the http side
of the new registry. The main components are the App and Context structs. The
App context is instance global and manages global configuration and resources.
Context contains request-specific resources that may be created as a by-product
of an in-flight request.
To latently construct per-request handlers and leverage gorilla/mux, a dispatch
structure has been propped up next to the main handler flow. Without this, a
router and all handlers need to be constructed on every request. By
constructing handlers on each request, we ensure thread isolation and can
carefully control the security context of in-flight requests. There are unit
tests covering this functionality.
This has Errors implement the error interface, allowing it to pose as an error
itself. Use of this in the server may be minimal, for now, but it's useful for
passing around opaque client errors.
A method, PushErr, has also been add to allow arbitrary errors to be passed
into the Errors list. This keeps the errors list flexible, allowing the app to
collect and errors before we have codes properly mapped.
