5 ms·

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

by cygned 10y ago

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.

meirelles 10y ago
I think the best practice is isolate the GitLab from others applications in it's own container/VM.
- cygned 10y ago
  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.
nisa 10y ago
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.
- cygned 10y ago
  > 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.
- brainfire 10y ago
  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.
green7ea 10y ago
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.
jobvandervoort 10y ago
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.
- zebra9978 10y ago
  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-Min-Build.html 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.
- __david__ 10y ago
  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.
  - Rondom 10y ago
    Debian stretch will have a native GitLab package. https://packages.debian.org/stretch/gitlab 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.
SysArchitect 10y ago
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.
swozey 10y ago
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.

by cygned 10y ago

meirelles 10y ago

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

cygned 10y ago
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.

nisa 10y ago

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.

cygned 10y ago
> 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.
brainfire 10y ago
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.

green7ea 10y ago

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.

jobvandervoort 10y ago

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.

zebra9978 10y ago
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-Min-Build.html 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.
__david__ 10y ago
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.
- Rondom 10y ago
  Debian stretch will have a native GitLab package. https://packages.debian.org/stretch/gitlab 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.

SysArchitect 10y ago

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.

swozey 10y ago

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.