Best practice guide for OpenStack image build process
The build processes for Yaook OpenStack images are very diverse.
For example:
- Different base images are used (centos:7, centos:8, ubuntu:18.04, python:3.6, ...)
- @jssfr once told me on IRC that it should either be centos or ubuntu
- Some images specify a run user for the service (
USER
statement in the Dockerfile)- Probably there should no user be specified but instead let K8s/Yaook decide which user runs the service
- Some images try to reduce the layer count by using less
RUN
statements but instead chain up the single commands- As a consequence one can do cleanup work and thus not only reduce the number of layers but also the size of the resulting image (see here for example)
- Sometimes the OS service is installed within a python virtual environment (see here for example) but mostly not
- That allows the usage of
COPY --from=0
and thus allows to just throw away the first image with all artifacts required for installation but not for running the service -> Fewer layers and smaller image
- That allows the usage of
A) Furthermore all image build processes have in common that they install the actual OS service from a cloned git repository whereas the dependencies are installed from PIP source. Why not installing the actual OS service from PIP source as well? Most OS services which are installed from cloned git repository are installed as version 0.0.0 which leads to version conflicts which requires workarounds (see here for example).
B) How to deal with different OS releases? If the Dockerfile does not differ from release to release just the branch
variable in the Dockerfile is overridden (docker build . -t "$BRANCH_IMAGE_TAG" --build-arg branch="stable/$OPENSTACK_VERSION"
in .gitlab-ci.yml
). If the Dockerfile differs more different Dockerfiles are used for each release (e.g. Dockerfile-queens
, Dockerfile-rocks
, Dockerfile-stein
). I think as the number of supported OS releases increase (think of the transition from Python 2 to 3) we cannot avoid having different Dockerfiles for each release. So shall we consider having different Dockerfiles for each release a good practice?
I propose to write down a good practice guide for OS image build processes and file merge requests to fit the existing image build processes to that guide.
Resolution from Fortnightly 2022-01-13
- All new images SHOULD, use
debian:11
as base image, updating it as Debian releases new stable versions - Existing images which do not use
centos
,almalinux
,rhel
, orrocky
as base image MUST be migrated to usedebian:11
ordebian:10
(if and only if Python 2.x is required). - For nova-compute images we require an ubuntu image to support vgpus. In this case we use a noral ubuntu image.
- The
python
base images MUST NOT be used for new images, because they contain a lot of unrelated stuff.