You shouldn't have to import both:
github.com/docker/distribution/context
golang.org/x/net/context
just to use the distribution tools and implement the distribution interfaces.
By pulling the Context interface from golang.org/x/net/context into the
context package within the distribution project, you no longer have to import
both packages.
Note: You do not have to change anything anywhere else yet! All current uses
of both packages together will still work correctly because the Context
interface from either package is identical.
I've also made some other minor changes:
- Added a RemoteIP function. It's like RemoteAddr but discards the port suffix
- Added `.String()` to the response duration context value so that JSON log
formatting shows human-parseable duration and not just number of nano-seconds
- Added WithMapContext(...) to the context package. This is a useful function
so I pulled it out of the main.go in cmd/registry so that it can be used
elsewhere.
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
To allow flexibility in log message context information, this changeset
provides the ability to configure static fields that are included in the
context. Such fields can be set via configuration or environment variables.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
This changeset simply adds hooks into the configuration system to support
multiple different kinds of output formats. These formatters are provided by
logrus and include options such as "text" and "json". The configuraiton
documentation has been updated accordingly.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
middleware concept.
This also breaks the dependency the storage package had on goamz
Signed-off-by: David Lawrence <david.lawrence@docker.com> (github: endophage)
This change is slightly more complex than previous package maves in that the
package name changed. To address this, we simply always reference the package
driver as storagedriver to avoid compatbility issues with existing code. While
unfortunate, this can be cleaned up over time.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
The goal is to free up the distribution/registry package to include common
registry types. This moves the webapp definitions out of the way to allow for
this change in the future.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
The goal is to maintain a specification heirarchy under doc/spec. This change
sets the example. The Makefile has also been changed update the AUTHORS file
and can now generate the specification.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
This changeset integrates contextual logging into the registry web application.
Idiomatic context use is attempted within the current webapp layout. The
functionality is centered around making lifecycle objects (application and
request context) into contexts themselves. Relevant data has been moved into
the context where appropriate. We still have some work to do to factor out the
registry.Context object and the dispatching functionality to remove some
awkward portions.
The api tests were slightly refactored to use a test environment to eliminate
common code.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
Endpoints are now created at applications startup time, using notification
configuration. The instances are then added to a Broadcaster instance, which
becomes the main event sink for the application. At request time, an event
bridge is configured to listen to repository method calls. The actor and source
of the eventBridge are created from the requeest context and application,
respectively. The result is notifications are dispatched with calls to the
context's Repository instance and are queued to each endpoint via the
broadcaster.
This commit also adds the concept of a RequestID and App.InstanceID. The
request id uniquely identifies each request and the InstanceID uniquely
identifies a run of the registry. These identifiers can be used in the future
to correlate log messages with generated events to support rich debugging.
The fields of the app were slightly reorganized for clarity and a few horrid
util functions have been removed.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
If configured, a debug http server will be started to serve default registered
endpoints, such as pprof and expvar. The endpoint should be secured carefully
and not available to external traffic. It is disabled by default but the
development config has been modified to make it available on localhost.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
This changeset provides simple tls support for a registry instance. Simply
providing a cert and key file are enough to get a tls registry running. If the
certs are trusted by the client, tls can be used throughout the push and pull
process.
If more complex TLS options are required, it is recommend that a proxy be used.
Contributions will be accepted to add more features, if necessary.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
We've added support to the registry command to report the current version of
the distribution package. The version package is generated with a shell script
that gets the latest tag and add "+unknown". This allows builds from "go get"
and "go install" to have a rough version number. Generated periodically, it
will provide a decent indication of what code built the binary. For more
accurate versioning, one can build with the "binaries" make target. Linker
flags are used to replace the version string with the actual current tag at
build time.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
Since the repo is no longer just the registry, we are moving the registry web
application package out of the repo root into a sub-package. We may break down
the registry package further to separate webapp components and bring the client
package under it. This change accomplishes the task of freeing up the repo root
for a distribution-oriented package. A stub doc.go file is left in place to
declare intent.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
This changeset provides data structures and definitions describing the routes
available in the V2 registry API. These route descriptors are structured to
provide automated registration, for creating routers, in addition to complete
documentation duty. It's also a possibility that this could be used to
enumerate test coverage for server implementation.
Using this functionality, we've also developed a template to automatically
generate and API specification for submission into docker core.
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.
To support accurate specification generation, this changeset includes a quick
and dirty tool to generate a markdown table of error codes generated by the
registry API. Equivalent supports for routes will likely follow.
Exported descriptors could be used to generate other documentation, as well.
