Hacker News Reader

Comment by Snappy | Hacker News Reader

From https://docs.gitlab.com/ee/install/kubernetes/, the best way to run GitLab on Kubernetes today is the gitlab-omnibus chart:

https://docs.gitlab.com/ee/install/kubernetes/gitlab_omnibus...

It's in beta, with some limitations on it's production-worthiness - basically that the Postgres Helm chart that it depends on isn't configured as well as the Postgres built into regular Omnibus.

I know it's confusing that we've got several charts, but we're trying really hard to reduce that down to one as quickly as possible.

View on HN

That’s the one I’m using, but based on today’s release page saying the Helm chart is deprecated and I should use the cloud-native GitLab chart, and based on what your link to the Omnibus chart says:

> This Helm chart is in beta, and will be deprecated by the cloud native GitLab chart.

I interpreted it as this being deprecated.

That said, great work on performance and startup times in the past months, for the first time my 2-user GitLab isn’t maxing a full core and using 6GB RAM anymore, but instead using 60% of a core and 6.3GB RAM, while site load times have gone down significantly, and startup now completes actually within of the first 5 minutes (before, Kubernetes’ readiness checker often killed GitLab before it managed to come up)

Hi Kuschku,

Sorry for the confusion, as noted we are trying to remedy this with a single chart as quickly as possible.

Currently we have two Helm charts that can deploy GitLab, "gitlab" and "gitlab-omnibus".

* The "gitlab" chart deploys only GitLab itself and is not recommended. This is the chart that has been announced as deprecated in the blog post.

* The "gitlab-omnibus" chart is what we recommend users to install today, and deploys everything you need for a working GitLab installation. (Postgres, Redis, an Ingress, etc.)

We still support and maintain the "gitlab-omnibus" chart, but it too will eventually be deprecated as well in favor of the upcoming cloud native charts.

The cloud native charts will have a significant number of advantages, including:

* Separation of components for improved horizontal scaling

* Improved resilience

* Faster startup time (current container runs `gitlab-ctl reconfigure` on every startup)

* No need for root access

Due to the significant architectural changes, migration will be via backup/restore.

> * Faster startup time (current container runs `gitlab-ctl reconfigure` on every startup)

Oh my god, how much I'd love that.

On the topic of cloud native charts, can I use the new cloud native gitlab chart (if I run an external prometheus, postgres and redis already separately) today? And how would I migrate?

And one thing I'd love to see is building docker containers without having to give the runner access to the host's docker. How do other CI solutions do that?

> On the topic of cloud native charts, can I use the new cloud native gitlab chart (if I run an external prometheus, postgres and redis already separately) today? And how would I migrate?

The cloud native chart is still under development and breaking changes will occur, so I would not recommend using it for anything outside of testing. For example our current sprint is focusing on storage persistence.

For migration, you would perform a backup of the current instance and restore the backup onto the new cloud native based deployment.

Reply on news.ycombinator.com