e16b83df7f
Some checks failed
/ test (push) Failing after 24s
Recently there was a regression in Pika, and it would generally be nice to use distribution packages for most of our dependencies. Since the image tester is already committing similar crimes I think it's fine for the uploader, too. Right now we only pull in the Google SDK bits from PyPI, as well as the Azure compute module from there since the Azure CLI pins an ancient version. Signed-off-by: Jeremy Cline <jeremycline@microsoft.com> |
||
|---|---|---|
| .. | ||
| fedora_image_uploader | ||
| tests | ||
| LICENSE | ||
| pyproject.toml | ||
| README.md | ||
| tox.ini | ||
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.