Adam Williamson
bd6b7ab0b2
This adds support for publishing container images to registries.
It is intended to replace the sync-latest-container-base-image.sh
and sync-ostree-base-containers.sh scripts we currently use for
this purpose.
It finds "docker" or "ociarchive" type images in the compose and
matches them against a list of known "repos" (fedora-toolbox,
fedora-silverblue etc.) Images that match are pushed to the
registry using `skopeo copy`. Then a manifest is produced from
the published images, and published itself; if the compose is a
Rawhide compose, or a compose of the current stable release, a
manifest is also published under an alias ("rawhide" or "latest",
respectively).
This initial implementation is intentionally closely based on the
sync-latest-container-base-image.sh approach. The other script
uses a somewhat different approach where the release numbered
manifest is created from the local image files and then pushed
with `--all`, which also causes the image files to be pushed,
then the manifest is copied to the 'aliased' name. I think the
eventual outcome is really the same in both cases, though.
The container support can be activated by configuring at least
one registry in the consumer config. If this is not done,
container images will not be handled.
As part of this, we move to trying every handler against every
image in the compose, and filter out non-cloud and non-container
images in the handlers themselves. This avoids having two levels
of filtering and makes the code a bit cleaner. We also drop the
`CantHandle` and `NotHandled` exceptions and concepts, as we've
decided the model is "any number of handlers might potentially
all handle a given image", so it's not really possible for an
individual handler to declare that an image is "not handled" by
this project at all. This means there's no need to distinguish
between different cases when a handler bails early, so it can
just `return` and we can drop the exception handling.
We also set an environment variable that disables caching
of filelists and PDC queries in fedfind (5.3.0+), as this can
cause things to be left out of pyvcr cassettes.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
1.5 KiB
cloud-image-uploader
An AMQP consumer that automatically uploads Cloud and container images to their respective homes.
Configuring
The fedora-messaging service is the container entrypoint and is also used to provide most of the configuration. An example configuration file is included and the full list of options are in fedora-messaging's configuration documentation. The FEDORA_MESSAGING_CONF environment variable should be set to the configuration file's location.
In addition to fedora-messaging, the Azure Ansible collection needs Azure credentials provided. It supports using environment variables, a credentials file at ~/.azure/credentials or the azure-cli credentials. For example, to authenticate via environment variables using an app registration in the Microsoft Entra ID service with a client secret, setting the AZURE_TENANT, AZURE_CLIENT_ID, and AZURE_SECRET along with the AZURE_SUBSCRIPTION_ID will be picked up by the Ansible playbook. The app registration needs to be configured in the given subscription's access control settings.
Container image upload to registries uses the skopeo and buildah commands, so for this to work, the system must be in a state such that these commands have the necessary credentials to upload to the registries configured, non-interactively. If no container registries are configured, container images will not be handled.