Provide fully integrated container based GitLab dev environment
Problem
GitLab is considered a monolithic application, but that is only partially true. The GitLab Rails app in this repository does not operate in a vacuum but works in tandem with multiple satellite systems:
- Workhorse (Go reverse proxy)
- CustomersDot (customer portal)
- Gitaly (git RPC service)
- Prometheus exporter servers
- Elastic search (FTS engine)
- AI gateway (AI model access)
Developers typically only operate a subset on these on their systems, based on their immediate stage group responsibilities (someone not on the search team will most likely not run ES locally). As we expand the number of systems gitlab-rails needs to integrate with, it becomes increasingly cumbersome to manage them. This is particularly true for GDK, which does not provide a container based developer experience, which leads to poor resource isolation (e.g. one Redis instance shared between completely unrelated systems) or micro-management of such connected resources (run n
redises each connecting through different UNIX sockets or ports).
The GCK provides containers for some of these, but not all; some systems like the AI gateway and CustomersDot provide their own dev container setup based on Docker Compose, which means that developers have to wire them up with GCK manually.
This makes a poor ground for productive development when features are concerned that cross several system boundaries. A recent example was a three-fold integration with gitlab-rails/CDot/AI-gateway to develop and test code suggestions for self-managed users.
Proposal
Remove setup and integration burden by providing a fully integrated, container based environment that developers and CI runner can stand-up to test changes across multiple systems. Some desired properties:
- Immutable: changes are impermanent, outside of writes to connected volumes such as databases
- Picks up changes to source code: If I make a change to one of these systems, it should be easy and fast for the env to pick this up
- Universal: should work on a developer laptop and in CI, so that we can use it both for development and manual testing as well as automated end-to-end tests in CI
Potential solutions
- KinD or minikube based setup, deployed via Helm charts
- ...