e7a0f0da8b
The docker registry daemon can either act as a private registry, or as a pull-through proxy, but not both. Yet we need to be able to serve private (speculative buildset) images as well as plain upstream images. Our registry is used as a mirror and requires authentication, therefore docker's normal behavior of falling back on docker.io won't work because it will attempt to use our credentials. However, the registry daemon stores all of its state in the filesystem, therefore we can run two instances of the registry service, both pointing at the same data store. The first acts as a pull-through proxy and will serve whatever files are already in the local storage, or will fetch them from docker.io. The second can be used to upload images into the local storage. To make a long story short, whenever we push into the buildset registry, we will use the second endpoint. Whenever the docker daemon pulls from the buildset registry, it will use the first. Change-Id: I296029068b5ef28ee56543741fe8c8deeefb5dfa |
||
|---|---|---|
| .. | ||
| defaults | ||
| tasks | ||
| README.rst | ||
Runs a docker registry for the use of this buildset.
This may be used for a single job running on a single node, or it may be used at the root of a job graph so that multiple jobs running for a single change can share the registry. Two registry endpoints are provided -- one is a read-only endpoint which acts as a pull-through proxy and serves upstream images as well as those which are pushed to the registry. The second is intended only for pushing images.
Role Variables
Return Values
Information about the registry.
The host (IP address) of the registry.
The port on which the registry is listening.
The host (IP address) to use when pushing images to the registry.
The port to use when pushing images to the registry.
The username used to access the registry via HTTP basic auth.
The password used to access the registry via HTTP basic auth.
The (self-signed) certificate used by the registry.