CNG: Distinguish between Asset and Runtime images
Definition
A Runtime image is an image that is directly used in Kubernetes workload. It has an entrypoint and accepts commands to run.
An Asset image strictly contains assets, either executable or non-executable. They can be based on scratch
and are used by runtime image layers to COPY
required assets from.
The key benefit of this model is that we are flattening the image hierarchy and as a result shortening the pipeline.
Classification
Many of the images can be classified as asset-only images. For example ruby
can be categorized as an asset image which is injected into the gitlab-rails
image (currently it is used as a base image).
We can use a different naming convention to explicitly distinguish between the two. For asset images we use the name of the asset, without gitlab
prefix, unless it is part of the asset name itself (for example gitlab-logger
) and for runtime images we use the gitlab
prefix unless the name is already GitLab specific (for example gitaly
).
Asset images:
certificates
cfssl
exiftool
gitlab-elasticsearch-indexer
gitlab-logger
gitlab-metrics-exporter
gomplate
graphicsmagick
kubectl
postgresql
python
ruby
Runtime images:
gitaly
gitlab-container-registry
gitlab-exporter
gitlab-geologcursor
gitlab-kas
gitlab-mailroom
gitlab-pages
gitlab-shell
gitlab-sidekiq
gitlab-toolbox
gitlab-webservice
gitlab-workhorse
There are some case corner cases for this separation:
-
gitlab-base
andgitlab-rails
are intermediate images that are used as the base image for final images. -
kubectl
is both an asset image and a runtime image. The part that it is being built can be separated into an asset image and the part that it is shipped can be moved to another runtime image, for examplegitlab-kubectl
.
Revisiting the build process
Let’s assume that we have pulled out the builder images and they have their own lifecycle. Then the core of the CNG pipeline, where the images are built, can be broken down into three steps:
- Build asset images
- Build intermediate base images
- Build final images
We use a Version Manifest, which itself is version controlled in the CNG repository, to specify the version of assets that we are using and we use the same version to tag the latest stable version of these assets.
NOTE: We already have a partial version manifest in ci_files/variables.yaml
. It is probably a good idea to explicitly separate this manifest.
Considerations
- We need to take additional steps for air-gap build, for example for DSOP. The asset-only images must be exported to tar files, distributed in the offline build bundle, and imported again on air-gapped build environments. This will require changes to offline build scripts. This can be an opportunity to use OCI layout to distribute air-gap build artifacts.