Announcing: Fedora Docker Layered Image Build Service is GO!

It is with great pleasure that the Fedora Project Announces the availability of the Fedora Docker Layered Image Build Service to the Fedora Contributor Community!

With this announcement we open the availability of the Docker Layered Image Build Service for the Docker Layered Images. The Fedora Cloud WG has been the primary maintainers of this project on GitHub. But now the service is available in dist-git as official components of Fedora. From there we will extend an invitation to all Fedora Contributors to maintain Docker Layered Image Containers for official release by the Fedora Project. Currently this effort is to enable the Fedora Cloud/Atomic Working Group goals of targeting Fedora Atomic Host as a primary deliverable to power the future of Cloud. This is also to enable the Fedora Modularity work be delivered as Containers in the future as Fedora becomes fundamentally more modular in nature.

How do I get started?

Contributors will go through a similar process to RPM review requests. There will be container reviews as well as container guidelines.

At this time the Cloud/Atomic WG will maintain the Guidelines and the Review Process, along with input from all Fedora contributors. This may change later with the formation of a Fedora Container Committee (similar to the Fedora Packaging Committee).

Please note that both the guidelines and the review process are likely to evolve along with the Container technologies. So we encourage community members to check the documentation for updates.

How does it all work?

Those who want to get into the weeds are welcome to check out the Fedora Release Engineering architecture document, but here is a brief overview. The Fedora Layered Image Build System is built using a combination of open source projects. The main elements are: Docker, Koji, OpenShift Origin, Atomic Reactor, and OSBS Client.

First up, what is a container?

Well, containers are what we in the greater Linux community like to call Operating-System-Level Virtualization, which has been around for some time. This concept allows us to run multi-tenant user space instances within a different context than that of the host Operating System. What effectively happens here is that we are able to create “images” of an application runtime and then run one or many “instances” of that image on our systems even if the Host does not have the required software installed to actually run the application inside the image as the requirements are shipped along with the Image.

This can get interesting by mixing and matching Fedora release runtimes with different Fedora host releases, effectively decoupling the user space from the operating system. Functionality such as this can be leveraged by the Fedora Modularity effort as a distribution mechanism. An example is in the diagram below where we take an application and it’s required libraries and put them into an image that can then be run on a newer (or older) version of Fedora thanks to containers. One thing to note here is that the Application in question here is put into a Layered Image and the Base Image is something that is released as a component from the Fedora Release Engineering team. Fedora contributors will submit Layered Image builds to the new system in order to provide these “container-ized applications” as Layered Images. (Hence the Build System’s name.)

Now that we have the basic understanding of how containers work, let’s move onto the actual build system and how these things are used inside the build system. We’ll start with the main building block of the entire system, OpenShift Origin.

What is OpenShift?

OpenShift (or OpenShift Container Platform) is an open source container orchestration platform by Red Hat built on top of Kubernetes (also known as a Kubernetes distribution), which is optimized for continuous application development and multi-tenant deployment. Origin is OpenShift’s upstream community project where development and collaboration takes place.

In the green colored section above we can see “BUILD AUTOMATION” which is the component of OpenShift we are most interested in for our use case. What’s even more interesting is that OpenShift has a Build API Endpoint that defines an OpenShift primitive type “build.” Of the Build Strategies (what OpenShift calls different methods by which builds are performed) available, the one we are utilizing is “custom” which gives us maximum control and flexibility our of our Builds. This allows us to define the base container to be used as well as everything about how it is run, executed, and various parameters about it.

This leads us to OSBS Client.

OSBS Client defines an OpenShift Custom Build Strategy, a python API, and a command line tool that can be used in concert to perform builds using OpenShift and atomic-reactor (more on atomic-reactor later) as the backend. We then create a “buildroot” container image much like what is used for RPM builds. These buildroots are isolated from the rest of the world and can only access resources and inputs that the Fedora Project has authorized. This buildroot is used along with an OpenShift Custom Build Strategy as provided by the OSBS Client to then farm out builds across the OpenShift cluster, which then imports the resulting image and its metadata to Fedora’s Koji Instance (more on that later).

What goes into a buildroot? Enter Atomic Reactor.

Atomic Reactor is, in short, a Python library with a command line interface used to build docker images. It has many useful features such as the ability to push an image to a registry upon build completion, build a docker image inside a docker container (nested docker), use remote git repositories as the source of Dockerfile directories, collect build logs, integrate with various systems (including koji and fedpkg), provide several execution modes, and a large library of plugins for a customized build approach and much more. The buildroot used within Fedora’s Docker Layered Image Build System uses atomic-reactor as the primary driver behind the actual container build execution along with many plugins that provide the various integration points into Fedora’s systems, such as Koji.

Koji: The canonical source of truth.

As Fedora Packagers well know, Koji is the central point of everything (RPM packages, cloud images, install media, etc) built and shipped officially by Fedora. The Docker Layered Image Build Service is no different, except only slightly as it technically performs it’s build outside of Koji in OpenShift and instead uses Koji Content Generator Metadata Import to bring all the build data back into the Koji database for safe keeping as the canonical source of truth about build artifacts. With this information we can re-create built images and can provide an audit trail proving that they contain the exact same contents (RPM package manifest, source files from exact git commit id in the pkgdb/DistGit docker namespace, etc). This maintains the Fedora release engineering philosophy, which was a fundamental goal of the project.

And that’s it! Now go out and container-ize some stuff!