[WIP] Build a web-based Admin portal for GitLab

We support a large number of settings for configuring GitLab, and many of them interact with each other. This is a significant amount of complexity, and typically requires consulting the documentation to use. For new users, this can be intimidating. We should consider instead a more user-friendly solution, especially for beginners and less technical users. Everyone should be able to contribute!

By offering a configuration interface we could improve some of the currently challenging areas of setting up GitLab:

  • We could provide validation as changes are made, and if errors occur we can provide intelligent and user friendly feedback. (Flagging the fields with issue, inline help text, etc.) Right now you have to edit a text file, save, exit, and and then run reconfigure. Only then do you get feedback on whether your config worked or was even valid.
  • A number of settings are co-dependant. If you enable SSL, a number of other settings become relevant or need to be adjusted. If you enable HA or Geo, another set of options need to be set. This is all very confusing to admins, and could be significantly streamlined with a UI.
    • For example these options could be hidden unless you enable the feature, and when you do you are then presented with the new settings that you have to set (or even better are set automatically for you).
  • Presently warnings and other feedback are printed within a wall of text, making it extremely difficult to grok. We are improving this with a feedback step at the end, but managing this in text is not the most user friendly way.
  • Since new settings are generally easy to add to GitLab, and existing settings hard to remove, we tend to have configuration bloat. Requiring specific UI to be added will increase the bar, and it should help us be more considerate about how we handle these.
  • Editing gitlab.rb and running reconfigure typically require root access. This means that the user who wants to make config changes also owns full admin rights of the machine. Often this is not the case, an application team owns the application and infrastructure retains admin rights over the box.

One method we could consider is a separate management app for GitLab. This would have a few benefits:

  • This could be a small container/package download which starts up and begins the installation experience. Reducing the time to start working with GitLab (currently Omnibus is ~300mb).
  • It could ask you how you wanted to install, what options you wanted (Geo/HA, etc), and then grab the right components. This would reduce the total download size, as most users won't use all features, as well as present a guided experience for certain options.
    • For example if you don't want Mattermost, it won't be downloaded and present on disk.
    • It may also help you install and connect shared Runners.
    • While these options would require installation of the "admin" package for raw VM's, it may not for an installation on a cloud provider like AWS or Kubernetes. Instead this app could have access rights to the management API.
  • It would have its own simplified configuration, just enough to get it running. Could even be just HTTP. It could also use a webserver/proxy with advanced built-in Let's Encrypt, like Caddy.
  • Importantly, it would also have reduced attack surface since the tool would need root privileges. This would avoid too much interaction with the larger GitLab app, preventing privilege escalation in that larger code base.

Configuration could then be further optimized as well, storing it in Consul. This would provide a number of benefits:

  • The web admin portal would write the settings into a consolidated and centralized store.
  • Each node would then connect, and could pick up the relevant configuration changes. If config changed, they could detect it and automatically apply (or restart, as needed).
  • Status could also be relayed that the latest configuration changes were applied, and the node health.
  • This would reduce a lot of the manual configuration work which is required with HA and Geo, across multiple machines.
  • For other deployment types, like our cloud native chart on Kubernetes, this ability to manage configuration outside of Helm could also be quite helpful. In particular, this would reduce the need for manually editing the raw gitlab.rb settings within the Helm chart.

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Edited by 🤖 GitLab Bot 🤖