Skip to content

CNG: Create gitlab-base image, providing stable basis for all others

Summary

Currently, much of the CNG is based around gitlab-ruby in some form or another. This is far from required, and removing this is a large part of technical debt to reduce the image sizes.

We should implement gitlab-base, and have any/all other containers base off of this. From there, we can rework the inheritance of the various down-stream images that include Ruby, Go, et al.

Details

In attempting to work through parts of #2697 (closed), it was reminded (via 🤦) that every running application container from the CNG actually builds from gitlab-ruby, and removing that also "breaks" behavior because of the missing chain of entrypoint.sh, set-config, exec-env. We must break the reliance on the gitlab-ruby container, but preserve the operational behaviors.

We should create a base image that all application component containers inherit from, which provide all of the necessary expectations of our start up patterns. This image should replace gitlab-ruby for all images not using Ruby (See #2697 (closed)), and provide a reasonable base function with the minimal requirements only.

To perform this work, we need to do the following:

  • Map image inheritance, confirming that the documentation matches (docs/build.md)
  • Re-evaluate the truly needed inheritance path
    • Revisit / re-evaluate container versioning patterns (#2825 (moved)) with any insights
  • Change the FROM lines for images as appropriate
    • Application component containers should inherit without modifying ENTRYPOINT

Current behavior

Most GitLab component application containers have Ruby, because they are in some way derived from gitlab-ruby.

Expected behavior

Images container are capable of having only the runtime components they need to operate, which means not deriving from gitlab-ruby

Actionable

Build a gitlab-base container which all images inherit from. This is done to provide a consistent base, and a common immutable ancestor for all images. This design provides run-time optimization for deployment as it is a shared layer consumed by all, reducing pull times and overall network transit costs.

Acceptance

  • Update dependency documentation, after mapping inheritance (gitlab-org/build/CNG!814 (merged))
  • Update dependency documentation, after changes to inheritance
  • gitlab-base image exist, in phase-zero
    • For Debian: FROM debian:bullseye-slim
    • For UBI8: FROM registry.access.redhat.com/ubi8/ubi:8.5 (suggest using variables)
  • gitlab-ruby builds on top of gitlab-base

Future

  • ❓ gitlab-go builds on top of gitlab-base (currently gitlab-ruby)
    • Does it need to? Or should the end containers simply build on top of gitlab-base + gomplate?
    • gitlab-workhorse/Dockerfile has FROM ../gitlab-go .. as builder, similar to gitaly
  • ❓ gitlab-python builds on top of gitlab-base (currently debian)
    • gitlab-python seems to only be used as a component image, not a base image. (FROM ... as python ; COPY --from=python ...)
  • ... xzy build on top of gitlab-* as appropriate (from investigation)
Edited by Jason Plum