Container Images Build Process

Owned by Adolfo Perez-Duran
Last updated: Dec 18, 2018 by Frank Sandoval
2 min read

This page assumes some familiarity with docker registries and client engines, images and layers. 

The diagram below illustrates the high-level process resulting in ONAP multi-arch (aka platform-agnostic) images





The desired result is a set of so-called multi-arch images in the ONAP registry that may be run on at least Intel and Arm platforms.

Background

A multi-arch image is referenced like any other image, yet only the image layers that are appropriate for the target platform are fetched. For example, when the multi-arch image myRegistry/myRepo:myImage is instantiated as a container, only the layers built for the platform running the container engine are downloaded, e.g. > docker run myRegistry/myRepo:myImage on an Arm machine will pull only the Arm layers. 

Multi-arch images may take one of two forms; manifest-list or manifest.

manifest-list (aka fat manifest) is an image content type that lists images that are specific to a platform. In other words, one may use a single Dockerfile to build images on each of Intel and Arm platforms, and create a manifest-list that references each sub-image. When a container is pulled or executed, the correct platform-specific layers are dispatched to the client depending on the platform on which its running. 

A simple image manifest may be multi-arch as it may contain layers for multiple platforms. In this scenario, a separate manifest-list is not created, but the results of image builds on each target platform are pushed to an identical label in a given registry. For example, one may build a Dockerfile on Intel and push to myRegistry/myRepo:myImage, then build the same Dockerfile on an Arm machine and push to the same label. 

Build Process

Each ONAP project is responsible for building and publishing images, and projects have taken differing approaches. For example, some project use build scripts to configure environment variables and build arguments for Dockerfiles, some use a maven docker plug-in.

Images are built and tested in the CIST environment via Jenkins jobs. The set of jobs has been extended to build images on both Intel and Arm machines (CIMAN-217: Add new projects for docker image builds on arm64 In Progress) .

  • an Arm machine has been configured and made available to the CIST platform https://gerrit.onap.org/r/#/c/71742/

  • Jenkins jobs have been added for each project to build images on Arm and test 

  • the ci-management project has been patched to include references to new Arm-centric Jenkins jobs

Build issues have not been fully addressed (as of 12/18/2018).

Ideally, any changes to Dockerfiles or build scripts can be validated locally before being introduced as patches to a project's repo. Such changes include migration to normative base images that are multi-arch, or base images that are minimal footprint, e.g. alpine images. Since images are built in Jenkins, it doesn't appear to always be simple to recreate a build environment locally.