| > please, please slow down on chasing new markets + features and just make the stuff you already have work properly I really agree with this. I was working at a company where we were exploring switching from Github enterprise to Gitlab for the K8s integrations, the docker registry, and the CI features. Following the helm chart installation instructions was a nightmare because we were on-prem w/ a custom cluster. There were a lot of assumptions we had to find workarounds for (e.g. we used an f5 integration to manage our ingresses and performed SSL termination elsewhere so the nginx thing was awful). The other terrifying bit was the number of services / pods that got brought up with the installation. If I have to monitor my team's services, I really don't want to monitor the health of: NGINX, Postgres, Redis, Minio, Registry, GitLab/sidekiq, GitLab/gitlab-shell, GitLab/gitaly, GitLab/unicorn, and GitLab/migrations. When it comes to on-prem or self-hosted software I actually prefer running a monolithic application that worst-case I can just bounce or reboot the server. Slow down, simplify things, and improve the user experience. Gitlab already has enough features to be competitive for a while with the Github + marketplace model. |
So why not just skip the helm chart and install the omnibus package on a dedicated server? If you want you can even disable stuff like the omnibus Postgres/Redis/etc and manage those yourself elsewhere.
That's what I do - run the omnibus package sans fancy helm chart - and it works out pretty well. Granted it does require a fair bit of RAM to run smoothly.
> Slow down, simplify things, and improve the user experience. Gitlab already has enough features to be competitive for a while with the Github + marketplace model.
Completely agree with this and what the parent said - I think this is part of why running Gitlab seems to require an ever increasing amount of compute resources :(