- Explain why you would want to use a registry
- Explain difference between Docker Hub and Registry
- List some features of Registry
- Add table of contents for documentation - particularly "deploying a registry" call to action
- Use standard "Getting help" section from orchestration projects
Signed-off-by: Ben Firshman <ben@firshman.co.uk>
Ensure that the status is logged in the context by instantiating before the
request is routed to handlers. While this requires some level of hacking to
acheive, the result is that the context value of "http.request.status" is as
accurate as possible for each request.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
Set forward headers so the IP and scheme get sent to the registry. This allows the registry to set a proper redirect with the correct scheme when HTTPS is being used.
Signed-off-by: Derek McGowan <derek@mcgstyle.net> (github: dmcgowan)
This adds WithTrace function to the context package that allows users to trace
a time span between a trace allocation and returned function call. The
resulting context includes ids that will allow for future dapper-like analysis.
Please see the godoc addition for details.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
Registry is intended to be used as a repository service than an abstract collection of repositories. Namespace better describes a collection of repositories retrievable by name.
The registry service serves any repository in the global scope.
Signed-off-by: Derek McGowan <derek@mcgstyle.net> (github: dmcgowan)
This moves the instance id out of the app so that it is associated with an
instantiation of the runtime. The instance id is stored on the background
context. This allows allow contexts using the main background context to
include an instance id for log messages. It also simplifies the application
slightly.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
Adding new material
Adding in template chomped in error
Cover install/deploy in README
Adding in Stephen's comments
Fixing you tabs!
Updating with commentary from pr
Updating with last minute comments
Signed-off-by: Mary Anthony <mary@docker.com>
The original implementation wrote to different locations in a shared slice.
While this is theoretically okay, we end up thrashing the cpu cache since
multiple slice members may be on the same cache line. So, even though each
thread has its own memory location, there may be contention over the cache
line. This changes the code to aggregate to a slice in a single goroutine.
In reality, this change likely won't have any performance impact. The theory
proposed above hasn't really even been tested. Either way, we can consider it
and possibly go forward.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
Rather than enforce lowercase paths for all drivers, support for
case-sensitivity has been deferred to the driver. There are a few caveats to
this approach:
1. There are possible security implications for tags that only differ in their
case. For instance, a tag "A" may be equivalent to tag "a" on certain file
system backends.
2. All system paths should not use case-sensitive identifiers where possible.
This might be problematic in a blob store that uses case-sensitive ids. For
now, since digest hex ids are all case-insensitive, this will not be an issue.
The recommend workaround is to not run the registry on a case-insensitive
filesystem driver in security sensitive applications.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
