Skip to content

[Proposal] Provide a set of standard templates for running GitLab in OpenShift / Kubernetes separate from one click install

Problem

The current one-click install, and the template syntax that comes with them for OpenShift, are not ideal for a enterprise production install of GitLab

  • Before you do the one-click install, an admin has to provide Persistent Volumes.

  • while the one-click UI provides some configuration options, it does not provide a good way to provide all our configuration options, with no support for anything except text inputs, it does not support making boolean decisions.

    • support for parameters types has been added but not released yet https://github.com/openshift/origin/issues/3946 https://github.com/kubernetes/kubernetes/issues/23896 .

    • the templating does not support flexible choice that impact which kubernetes objects actually get created. It would be difficult to allow a user to decide between running mattermost or not, or running postgres as a single server, or a server-replica setup. Or running redis with sentinel support or not. These decisions impact which objects need to be created, and the templates don't support that.

  • There is no UI for editing template values, or values on specific pods, after it has been created. You are back to editing the deployment configs themselves.

  • OpenShifts router is not made for our type of application

    • templates and pods are only meant to let us define the applications, and some config that was previously handled by ops teams. but not all config. Complete control over service discovery and external routing are not given to us in the templates (nor should they be)

    • The service discovery works well, but the external routing that your ops team sets up for you (or whoever built the all-in-one vm in this case) is setup for deploying developer's webapps, routing on port 80 and 443. GitLab's git over ssh is not supported.

Proposal

Let's additionally tackle the problem using more common seperate Kubernetes/OpenShift objects, which are loaded using the command as oc create etc. Paired with documentation describing how to use different DeploymentConfigs/ReplicationControllers for different desired GitLab topologies.

We can also look at alternate config-and-run solutions like Helm https://github.com/kubernetes/helm to still provide an all-in-one install.

Why

In order to support Production GitLab in OpenShift, an admin is going to have to provision storage, and get down and dirty with changing the config options, and potentially provide the database. OpenShift and Kubernetes are not ready (by themselves) for Highly Available stateful storage, the kind we may need to run a database in production on OpenShift.

Our one-click install will not be enough.