From Fedora Project Wiki
No edit summary |
No edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 10: | Line 10: | ||
* the high level "application glue code" that combines dependencies into a coherent application typically isn't designed for reuse | * the high level "application glue code" that combines dependencies into a coherent application typically isn't designed for reuse | ||
* packaging things as RPMs is very helpful for building Fedora itself, but markedly less so when building things to run *on* Fedora | * packaging things as RPMs is very helpful for building Fedora itself, but markedly less so when building things to run *on* Fedora | ||
* consuming RPMs directly can become a complex "DIY" adventure as different component versions are mixed and matched on the same system | |||
Accordingly, these recommendations cover the approaches offered by Fedora to assemble individual components produced by the Software Component Pipeline into larger binary images for easier consumption. | |||
= Base Container Images = | = Base Container Images = | ||
Inputs: RPMs built in Koji | * Inputs: RPMs built in Koji | ||
Outputs: Docker container images | * Outputs: Docker container images | ||
Build system: Koji | * Build system: Koji | ||
= Layered Container Images = | = Layered Container Images = | ||
Inputs: Source-to-image git repos, RPMs built in Koji (official images), RPMs built in COPR (unofficial images) | * Inputs: Source-to-image git repos, upstream source packages (built on demand), RPMs built in Koji (official images), RPMs built in COPR (unofficial images), other container images | ||
Outputs: Docker container images | * Outputs: Docker container images | ||
Build system: Koji (official images), DOPR (unofficial images) | * Build system: Koji (official images), DOPR (unofficial images) | ||
Layered images are notable as they're the recommended means of combining official content from Koji (RPMs, container images) with unofficial content from COPR (RPMs), DOPR (container images), upstream distribution systems (source packages), and version control systems (source-to-image repos). | |||
As the Fedora.next modularisation discussion evolve, there may eventually be official source-to-image repos, allowing some Fedora components to be made available *solely* in container form. | |||
= OSTree Images = | = OSTree Images = | ||
Inputs: RPMs built in Koji | * Inputs: RPMs built in Koji | ||
Outputs: rpm-ostree trees | * Outputs: rpm-ostree trees | ||
Build system: Koji | * Build system: Koji | ||
= Machine Images = | = Machine Images = | ||
Inputs: RPMs built in Koji, container images built in Koji | * Inputs: RPMs built in Koji, container images built in Koji | ||
Outputs: machine images (AMI, qcow2, etc) | * Outputs: machine images (AMI, qcow2, etc) | ||
Build system: Koji | * Build system: Koji | ||
= Live ISOs = | = Live ISOs = | ||
Inputs: RPMs built in Koji, container images built in Koji | * Inputs: RPMs built in Koji, container images built in Koji | ||
Outputs: Live CD/DVD/USB images | * Outputs: Live CD/DVD/USB images | ||
Build system: Koji | * Build system: Koji | ||
= Installer ISOs = | = Installer ISOs = | ||
Inputs: RPMs built in Koji, container images built in Koji | * Inputs: RPMs built in Koji, container images built in Koji | ||
Outputs: Installer CD/DVD/USB images | * Outputs: Installer CD/DVD/USB images | ||
Build system: Koji | * Build system: Koji | ||
Latest revision as of 13:03, 24 September 2015
This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.
It is still under construction and content may change. Do not rely on the information on this page.
Image Assembly Overview
The Env_and_Stacks/Projects/SoftwareComponentPipeline is designed to make it straightforward to automatically produce updated RPMs and RPM repositories from upstream components releases.
However:
- not all upstream applications (especially web applications) are amenable to being disassembled into component RPMs
- the high level "application glue code" that combines dependencies into a coherent application typically isn't designed for reuse
- packaging things as RPMs is very helpful for building Fedora itself, but markedly less so when building things to run *on* Fedora
- consuming RPMs directly can become a complex "DIY" adventure as different component versions are mixed and matched on the same system
Accordingly, these recommendations cover the approaches offered by Fedora to assemble individual components produced by the Software Component Pipeline into larger binary images for easier consumption.
Base Container Images
- Inputs: RPMs built in Koji
- Outputs: Docker container images
- Build system: Koji
Layered Container Images
- Inputs: Source-to-image git repos, upstream source packages (built on demand), RPMs built in Koji (official images), RPMs built in COPR (unofficial images), other container images
- Outputs: Docker container images
- Build system: Koji (official images), DOPR (unofficial images)
Layered images are notable as they're the recommended means of combining official content from Koji (RPMs, container images) with unofficial content from COPR (RPMs), DOPR (container images), upstream distribution systems (source packages), and version control systems (source-to-image repos).
As the Fedora.next modularisation discussion evolve, there may eventually be official source-to-image repos, allowing some Fedora components to be made available *solely* in container form.
OSTree Images
- Inputs: RPMs built in Koji
- Outputs: rpm-ostree trees
- Build system: Koji
Machine Images
- Inputs: RPMs built in Koji, container images built in Koji
- Outputs: machine images (AMI, qcow2, etc)
- Build system: Koji
Live ISOs
- Inputs: RPMs built in Koji, container images built in Koji
- Outputs: Live CD/DVD/USB images
- Build system: Koji
Installer ISOs
- Inputs: RPMs built in Koji, container images built in Koji
- Outputs: Installer CD/DVD/USB images
- Build system: Koji