Fedora Container Build System
In order to get a better understanding of the big picture of how all this works, Container Maintainers might find the Layered Image Build Service Architecture Document interesting. However, extensive coverage of the Build System is out of the scope of this Guidelines document.
The Fedora Base Image provides information that can be used by the Layered Images via inherited Environment Variables:
$DISTTAGis defined just as it is for RPMs, but since Containerfiles (or Dockerfiles) lack a mechanism similar to RPM Macros this is being stored in the base image such that it can be inherited by layered images.
In Fedora there are two Registries: candidate and stable.
All Layered Image Builds end up in the candidate registry as soon as they are successful in the Fedora Layered Image Build System. These images can immediately be pulled. For example:
# With podman
podman pull candidate-registry.fedoraproject.org/$FGC/$NAME:latest`
# With Docker
docker pull candidate-registry.fedoraproject.org/$FGC/$NAME:latest`
Gated releases will happen on a Two Week Cadence, alternating with the Fedora Two Week Atomic Host.
Fedora Base Images will be available at the "root" namespace of the registry, an example is below:
Fedora Layered Images will be available in their respective
$FGC namespace which correlates to their DistGit branch and Koji tag. An example is as follows for the
f25 Fedora Generational Core and the cockpit container image.
There are multiple tags applied to each image:
:latesttag can be omitted when issuing a
The latter two tags are updated in-place and a new execution of
podman pull or
docker pull will get the latest image.
Want to help? Learn how to contribute to Fedora Docs ›