Hacker News new | past | comments | ask | show | jobs | submit login

> gitlab is also so large it requires its own chef deployment to competently install it from omnibus, and has no HA roadmap in sight unless you want to break apart its rube-goldberg structure and attempt to HA the individual components of it.

Use the gitlab-ce docker container and save yourself the hassle. Literally takes less than 10min to set up and a version upgrade is nothing more than docker stop, docker rm, docker run <new version> away.

Only thing I haven't solved with this is HA but you can use a central NFS mountpoint with an HA'd setup there, and simply start a new container on another machine with the NFS mount... will require manual intervention, yes, but it's more efficient than trying to break up the dozens of moving parts.




Thanks for posting. HA is a paid feature of GitLab and will likely stay a paid feature.

We're working hard on a cloud native alternative to the docker container that works well on Kubernetes. There is more information on https://gitlab.com/charts/gitlab/ and you can see the activity on https://gitlab.com/charts/gitlab/commits/master Since it is cloud native I assume it will allow autoscaling and it neatly orders every component in its own container.

Today GitLab is using a lot of RAM and the best way to reduce that is to make the application server multithreaded https://gitlab.com/gitlab-org/gitlab-ce/issues/3592 The first priority is to add rubocop rules for https://github.com/covermymeds/rubocop-thread_safety There is a WIP merge request in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/1899 Any help is appreciated.


> Today GitLab is using a lot of RAM and the best way to reduce that is to make the application server multithreaded https://gitlab.com/gitlab-org/gitlab-ce/issues/3592

how is multi-threading helping with memory consumption?


Because the Rails application server is currently single threaded it forks multiple processes that each take up about half a gigabyte of RAM. Running fewer processes would cause increased latency for users.


In a multi-threaded program, the threads share memory. Currently the application server is running in multiple processes, each of which contains a full copy of the core application.


NFS will give you redundancy but not high availability. In fact it will probably lower your availability the first time NFS gets hung.

But if manual intervention works for your setup, then you probably don’t really need HA anyway, just redundancy.


We're working towards Gitaly 1.0 that would allow you to run GitLab without NFS. This isn't HA but it would prevent one NFS server from taking down the whole cluster.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: