Commit Graph

6 Commits

Author SHA1 Message Date
James E. Blair d48667a3c5 use-buildset-registry: Add podman support
Change-Id: I41718073962c8e7eb3d8810276e550fb84bd6e99
2019-12-05 11:44:15 -08:00
James E. Blair a321a8270d Make the buildset registry port configurable
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
2019-10-28 15:42:29 -07:00
James E. Blair 8766890012 Use zuul-registry as buildset registry
The proxy functionality is no longer needed so it is removed.

Change-Id: I29ff75d331b433ea4ad3b66ed723eee14a90b404
Depends-On: https://review.opendev.org/689829
2019-10-28 15:42:26 -07:00
James E. Blair 9c0d25f349 Fix buildset registry
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
2019-03-01 15:52:01 -08:00
James E. Blair e7a0f0da8b run-buildset-registry: run a dual registry
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
2019-02-21 13:49:49 -08:00
James E. Blair 2292ce9aed Add a role to run a buildset registry
Part of a system to interact with an intermediate registry.

Change-Id: I2f4662cc587f9379e9ba3b7b705c85793a41864e
2019-02-01 13:25:11 -08:00