Hacker News Reader

Comment by cygned | Hacker News Reader

Honestly, installing and maintaining GitLab is still not a pleasure. The Omnibus package was too unsafe for us because we wanted greater control about versions and stuff; and the bundled pre-configured applications in it (e.g. nginx) cause a lot of problems with existing installations.

We were basically not able to create a stable deployment on a machine also running other services. But none of use really likes Ruby and rvm, maybe that's also one of the reasons why we struggled.

View on HN

I'd love for you to explain your motives behind not using Omnibus further.

Nowadays we provide images / containers for most major platforms, so there should definitely be a good solution for you there.

That said, we make the Omnibus packages as that's the easiest and best way to maintain GitLab. It takes all the work away from you. The vast majority of our customers use Omnibus, even secure instances with thousands of developers.

Not OP, but I dislike many things about your omnibus packages. I hate packages that install into /opt (thanks for the extra tld). I hate that it's 900+MB of completely redundant junk—nginx? check, postgres, check, and entire ruby? git? curl? All of those are on my system already.

That said, I switched to it after maintaining a hand installed version and I love how I don't have to run rails schema upgrades by hand any more. I used to put off upgrading gitlab for months because it was such a pain and now I don't have to think about it at all. Rails devs could learn a lot from php devs in that regard (upgrading wordpress is absolutely trivial to upgrading gitlab).

So yeah, I love the omnibus package since it means I don't have to think about it any more; I hate the omnibus package because it's a huge redundant monolith and pure crap from the point of view of a Debian package purist.

Debian stretch will have a native GitLab package. https://packages.debian.org/stretch/gitlab

Whether there are enough volunteers to keep it and its dependencies up to date using backports remains to be seen, though.

This is a nuisance for me as a CentOS admin as well. I absolutely dislike software that decides to just plop a big bag of crap in /opt. I don't want something administering it's own PostgreSQL or nginx instance, let those choices and the administration of these services up to system administrators and alternatively provide a quick setup tool for the less inclined.

I work in a mostly .Net shop, but the couple Python+Flask apps I maintain and administer integrate with everything else the way I expect as a sysadmin. As a Linux guy I have scoffed at Windows shops for ages for the sin of "xcopy deploy" but omnibus packages are no better.

quick question - did you consider using jruby ? I see on your docs you mention that you use certain libs with native extensions... but 20 mil should go a long way towards resolving those.

how about building out a single jar based deployment based on jruby ? For example, mingle is built on jruby (ruby on rails) and packaged as a easy to install jar file [1]

[1] https://www.thoughtworks.com/mingle/news/2015/02/18/Forty-Mi...

jruby will be higher performing and will use overall lesser memory in general (yes.. the jvm takes up quite a bit of RAM during startup). Running a jar in production using jetty is a breeze.

Not sure where your problem is. I run gitlab with mattermost and docker registry with my own nginx that also servers a lot of other stuff. You can disable the internal nginx for all application in gitlab.rb and you find the nginx.conf files in the gitlab-omnibus repository. It's not one-click but but it's pretty much more than I have hoped for.

It's also pretty self-contained you don't have to care about ruby and rvm and stuff like that, daemons are supervised with runit. I don't see why you have the need to switch versions on that.

Even if you want to modify it, it's probably easier to maintain a fork of the chef-cookbooks and apply local changes to that.

I'm not saying it couldn't be better but for opensource software it's quite well managed and packaged and documented, at least in my opinion.

> You can disable the internal nginx for all application

Yeah, we have tried that but that didn't work for us. Instead, the internal nginx flooded our hard drive with log files, that was a bit annoying, haha.

Yup, the documentation sufficiently covered our case- we needed the front-end to be Apache httpd for our SSO, and there were steps (and example httpd configs) to substitute it in for the nginx in the omnibus package.

This is also the biggest pain point for me. I had it running on Ubuntu and didn't like the 'we ship nginx' philosophy so tried to install it on arch. After fixing a few obscure problems, I went with GOGS and it installed flawlessly in under five minutes. It's unfortunate because gitlab has a lot to offer.

These days I run all the various different services as different VM's, then have a single reverse proxy that points at the various instances. This way I can make sure that I don't accidentally need a newer version of some library than some other app causing conflicts.

At that point the internal shipped NGINX can be there and be happy without issues.

I think the best practice is isolate the GitLab from others applications in it's own container/VM.

Yeah, that's something we learned from it. At that time, though, we just wanted to replace Redmine and only had a single machine available which was already running a bunch of things.

I've been running the Omnibus for over a year and only ran into an issue with updating a few times and they were typically 500 errors caused by a gitlab bug, and in one case an issue with the database migration needing some tweaks. It's (their omnibus) been far and away one of the most seamless and impressive third-party installation and update systems I've used.

Reply on news.ycombinator.com