Changes/Layered Docker Image Build Service

Layered Docker Image Build Service

Summary

Fedora currently ships a Docker base image, but Docker supports a layering concept. There are some applications like Cockpit which we would like to ship as layered applications.

This change will deploy the build service to support building and delivering a set of layered Docker images, and will enable Fedora contributors to create and maintain Dockerfiles from which those images will be generated.

Owners

• Name: Colin Walters
• Name: Adam Miller
• Name: Tomas Tomecek
• Name: Tim Waugh

• Release notes owner:

Current status

• Targeted release: Fedora 23
• Last updated: 2015-07-02
• Tracker bug:

Detailed Description

This change opens up an new type of official binary artifact produced by Fedora. Currently, we produce two main types of artifacts: RPMs, and images. The RPMs are created in Koji from specfiles in dist-git. The images come in different formats, but have in common creation in Koji from kickstart files — this includes the official Fedora Docker Base Image. This change introduces a new type of image, a Docker Layered Image, which is created from a Dockerfile and builds on top of that base image.

The system has five major parts:

• A command-line client — already integrated into rpkg; needs only minor work to enable in fedpkg
• dist-git for Dockerfiles
• A koji plugin, containerbuild
• An OpenShift 3 backend
• A distribution mechanism; initially, this will be

1. ftp/http mirror (either alt or main mirrors), and
2. pushed to upstream Docker hub (running our own registry is currently out of scope; see below)

For more information, see this presentation for the high level overview of the whole system.

Benefit to Fedora

What is the benefit to the platform?

Docker is a very popular way to deliver container images. This will help deliver Fedora-based containers inside the Docker ecosystem, and other applications that are part of the Fedora package collection as containers.

Fedora Server is planning to deliver Server Roles as containers; this will facilitate that. And vital parts of Fedora Atomic are now designed to be delivered in containers, but we currently have no mechanism to do that within Fedora itself.

Scope

Proposal owners

Proposal owners shall have to

• • Deploy OSBS
    • Deploy OpenShift v3
    • Deploy container build koji plugin (optional)
  • create dist-git for Dockerfiles

Task matrix

See Layered Docker Image Build Service RACI Matrix for an individual breakdown of tasks and responsibilities. This also includes a basic, task-level accounting of status, which we will keep updated.

Other developers

• Possible integration with Bodhi for releasing updated images

Release engineering

• Deploy OSBS

Policies and guidelines

• • Need to determine who can submit/build images
  • Determine who is responsible for building/testing images as RPMs change
  • Determine policy for non-RPM content. (Initial policy will be that all content must be existing RPMs in the official released or updates repositories.)
  • "Packaging guidelines" for Dockerfiles; suggest starting lightweight and building as needed. Project Atomic documentation can be a starting point.

Out of Scope

Registry

This Change does not include running a Fedora container registry. Although we might want to do so in the future, this should not be a blocker. Container images will be a) delivered to the upstream Docker Hub and b) put on the Fedora FTP/HTTP mirror network.

Other Integrations

In the future, images could be integrated into Bodhi, just like RPMs.

It would also be nice to have a pkgdb interface, but that shouldn't be a blocker.

CentOS has offered to let Fedora test images in their continuous integration infrastructure, and we need to figure out how we can hook that in — perhaps through bodhi.

Content Tracking, Automatic Rebuilds

It would be nice for images to automatically rebuilt and pushed to testing when any of their contents change, or at least when any of their content changes due to a security update. But we don't want to block having the basic build service in place on that; initially, updates will need to be initiated by the container packager.

Upgrade/compatibility impact

Since the world of containers is changing rapidly, it is possible that the system might need to be upgraded in future to latest stable version.

How To Test

Ideally, we have a Fedora registry. If so, then adding it and doing:

atomic run registry.fedoraproject.org/cockpit

Before we have a registry, images can be tested by...

1. ??? 2. ??? 3. ???

User Experience

There's many potential roles interacting here - the container owner, the container user, release engineering.

Container Packager

From a container packager point of view, the overall experience should be very similar to that of an RPM packager. Instead of a spec file, a Dockerfile will be created, but then that will be built using fedpkg through koji. This maintains both a comfortable workflow that will be easy for contributors to adapt to, and the release engineering benefits of koji.

Workflow analogy with RPM

RPM	Layered Image
dist-git repo per RPM	dist-git repo per image
Specfile in dist-git	Dockerfile in dist-git
Source code and patches	No source code — refers to existing RPMs
fedpkg build	fedpkg container-build
created in koji (koji build task)	created in koji (through containerbuild plugin)
pushed to mirrors	pushed to mirrors
available via yum/dnf	repo creation currently out of scope

Container User

Without a registry — a next step currently out of scope — the user experience is not quite ideal. The images will need to be downloaded manually from the mirrors and imported. For use cases like Fedora Server's, this will be scripted. Alternately, users can pull from the upstream project's Docker Hub.

Release Engineering

tbd

Dependencies

• N/A

Contingency Plan

People continue to upload to the Docker Hub in an ad-hoc fashion with no integration with Fedora.

Documentation

Needs filling in.