This will allow us to run the role twice on the same host. This
will be useful when we test changes to this role.
Change-Id: I97baeb3172298648bcfef26c5be635ad4be036f0
The proxy functionality is no longer needed so it is removed.
Change-Id: I29ff75d331b433ea4ad3b66ed723eee14a90b404
Depends-On: https://review.opendev.org/689829
The approach of having the proxy serve the local data as well as
the remote wasn't working -- it seems that the proxy would always
check upstream and prefer that data even if it had been pushed
locally.
To correct this, separate the data stores of the two registries,
and add both of them to the registry_mirror setting for the
docker daemon. Now we will pull from our buildset registry first,
and fall back on the proxy to talk to upstream if an image is not
found locally.
The proxy is still required in order to mask out the username and
password which dockerd will otherwise use when talking to upstream.
Change-Id: Iab11954a4b5431d3b1a4d4753f519b6b71f64094
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