This changeset integrates the AccessController into the main registry app. This
includes support for configuration and a test implementation, called "silly"
auth. Auth is only enabled if the configuration is present but takes measure to
ensure that configuration errors don't allow the appserver to start with open
access.
Routes and errors are now all referenced from a single v2 package. This
packages exports are acceptable for use in the server side as well as
integration into docker core.
This simply moves the registry app to be using the urls package and its
exported route names. This supports locking down exported route definitions for
use in client packages.
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.
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 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.
