Concepts of dockerfiles - accetto/ubuntu-vnc-xfce-g3 GitHub Wiki

Concepts of Dockerfiles

Version: G3v1, G3v2

Updated: 2022-11-04


Introduction

This page describes the concepts that should help by understanding the specifics of the used Dockerfiles.

The page does not describe the common and well-known concepts of Dockerfiles, e.g. build arguments or multi-stage builds.

The concepts described here are specific to this project and they should help by achieving the project goals.

The page should also help to understand how the actual implementation works.

Concept of features

One of the consequences of having fewer Dockerfiles and fewer dependencies between them is the increased complexity of the Dockerfiles. On the other hand, more complex Dockerfiles can also be more flexible.

The features are any properties of a Docker image, that have some significance for the developer or the user of the image. For example, slim build or novnc included could be features.

The features are expressed as variables in the source code.

The feature variables could be translated to build arguments.

The feature variables set in Dockerfiles are persisted in the images as environment variables.

Concept of version stickers

The version sticker is a description of the feature set of a particular image build. It is somehow looser concept as the usual version used in programming. However, it is tight enough to be conceptually used a fingerprint of a particular image.

There are two forms of the version stickers.

  • The verbose version sticker is essentially a list of the feature variables and the versions of the essential software contained in the image. What is essential can be freely decided by the developer of the image.

    The intended usage of the verbose version stickers is to compare image builds. If the verbose version stickers match, then the images are considered to be the same in the meaning, that no re-build is required.

  • The short version sticker is a compact string describing the versions of important software included in the image. What is important can be freely decided by the developer of the image.

    The intended usage of the short verbose sticker is for the image metadata (labels) and for the badges, that are usually included in the readme files.

Concept of building graph

This concept has not been invented in this project, but it is utilized by it.

The BuildKit follows this well-known concept and it analyses the Dockerfile before building the image. It finds out, which stages in the Dockefile are actually required for the current build.

In other words, not all Dockerfile stages must be necessarily used during the building. This allows to have several possible building graphs in one Dockerfile. The path, which the BuildKit will actually take, is configurable by using variables in the FROM statements.

In reality the limits of practicability are reached pretty soon, but some flexibility can still be achieved.