Comment by contingencies | Hacker News Reader

Comment by contingencies | Hacker News Reader

@Gitlab: The features are great but the interface setup is shocking. That whole video assumes you have a K-cluster going already, and is a maze of this-thing, that-thing, auth-thing, copy-thing, etc. Have you guys ever tried interviewing users who are new or maintaining a Gitlab instance over major version upgrades? It's painful.

The 'quick fix' for setup these days is supposed to be to use a docker image... but the docker image most people use is unofficial, the maintainer is swamped and has a policy of ignoring problems, and although it runs it doesn't work well with real IPs/DNS/SSL/etc. for common cases (eg. email setup silently fails for many and has for ages - see https://github.com/sameersbn/docker-gitlab/issues/596 and https://github.com/sameersbn/docker-gitlab/issues/1005 which I recently opened) and adds the docker-is-a-moving-target complexity issue to the potential user's stack.

Normally I am based in China. Given that Github access is not super fast or stable there, you guys have a great opportunity to take that market. I'd personally love to use Gitlab both for my own business and those I consult for, but I can't get past go with mail on real infrastructure, and experiences with upgrades to date have been terrible.

Just offering my own recent experiences as a point of reference.

Pardon me here, but I don't understand what you mean by "the docker image most people use is unofficial."

I was under the impression that everyone used the fully featured official docker image (https://hub.docker.com/r/gitlab/gitlab-ee/). We've been using this for over a year without issues now. Is there a reason you need the unofficial version? Does it do something different?

IIRC because last time I checked it had no comments/community around it and was until recently out of date.

The image Cidan referred to was last pushed 5 hours ago when we released 8.15 and should always be up to date. For more information about our official docker images see https://docs.gitlab.com/omnibus/docker/README.html

I've added a section to say that these images are officially supported with https://gitlab.com/gitlab-org/omnibus-gitlab/commit/26501d91...

If you experience problems with them please feel free to file an issue under https://gitlab.com/gitlab-org/omnibus-gitlab/issues (more than 1500 have been closed there already).

I suspect that many of the upgrade problems you experienced can be solved by using an official image.

I agree that the demo video we show is limited to a specific Kubernetes installation (OpenShift self hosted). In 2017 we plan to make sure everyone can use it, for details see https://gitlab.com/gitlab-org/gitlab-ce/issues/25986

should always be up to date

OK. I definitely remember running in to something that looked official but wasn't up to date (remotely) a few weeks ago. Perhaps it was this image, perhaps not. IIRC at the time I was judging only from the 'updated [time periods] ago' data in the docker hub webpages.

Mmm, I remember mishaps with updating but those were quite some time ago.

Anyway, if there is an urgent problem with those consider tweeting to @gitlabstatus to get our attention. I think it won't be needed since many people use them so we should be on top of them. The only package that is sometimes late is the non-docker package for the Raspberry Pi since it takes hours to build.

If someone gave me a bug report along the lines of "the image didn't work, but I don't remember which image it was", it would be ... bad.

Thanks for the honest feedback, it's genuinely useful for improving the product.

Out of curiosity, why use the Docker image over our Omnibus package? Omnibus is generally what we recommend, but if that's not good enough we'd love to know how it can be improved.

Even if I trusted it not to munge other things (doubtful), IIRC omnibus does not support my distro (Gentoo), and setting up another distro I have to (remember to) maintain just to support one application does not appeal medium term versus using a popular docker image which has done that for me already in a pre-tested fashion and should handle maintenance smoother.

Basically I'm at this point: 'what's the easiest self-contained box to run and maintain', with conditions 'I have an IP but it's not dedicated (ports 22/80/443 unavailable)' and 'there may not be existing DNS/SSL for this server but I can set it up' and 'SMTP from this IP is not desired/desirable, but I have an existing offsite ISP allowing relay with credentials'. This doesn't strike me as particularly weird, except that in the latter case Google is not an option (GFW'd from China).

I don't think your concerns are founded, I just deployed GitLab for personal use on a virtual machine with the omnibus image (gitlab-ce:latest) and it worked flawlessly. And since they released an update today, to upgrade all I had to do was:

    docker pull gitlab/gitlab-ce:latest
    docker stop gitlab
    docker rename gitlab gitlab-old
    docker run --detach --publish 60100:80 --publish 58432:22 --name gitlab --restart always \
         --volume /var/volumes/gitlab/config:/etc/gitlab \
         --volume /var/volumes/gitlab/logs:/var/log/gitlab \
         --volume /var/volumes/gitlab/data:/var/opt/gitlab \
         gitlab/gitlab-ce:latest
    
    # after verifying the new image works, docker rm docker-old; docker rmi [old image].

It took less than an hour to configure it for external SMTP relay, external auth with two factor authentication, etc.

I did just get started with it, but I have to say the omnibus install was fairly easy.

Great, I'm glad it worked for you. It didn't work for me and other people, as per the issues linked. When it doesn't work, there's no clearly defined debug path, and very little response.

Respectfully, it seems like you are using the wrong Docker image, and that's the source of your troubles. Others have commented similarly, and I think that you are too easily dismissing them.

I think you're right Aaron.

The Sameer docker image used to be the only way to run GitLab with Docker but we don't recommend it and it is no longer listed on our installation page https://about.gitlab.com/installation/ to prevent confusion.

Also see my answer in https://news.ycombinator.com/item?id=13243443

I tried the docker image for gitlab-ce just 2 days ago and had to exec bash into it and chmod a workhorse socket file to get it working. Glad they fixed it.

Is there a Omnibus package for Kubernetes (perhaps a Helm package?) I'd be very interested in that.

FWIW: I ran GitLab at my previous company (2yrs agoish) because GitHub was a non-starter for political reasons. We loved it! Keep rocking.

There is indeed a helm package, gitlab-ce.

Aha! I was looking for this recently. Doesn't appear to be on https://about.gitlab.com/installation/, which is where I stopped my search for it.

It's very new and still maturing. Pull requests and improvements welcome!

Thanks for making it Greg. I added it to the community installation methods section of https://about.gitlab.com/installation/ with https://gitlab.com/gitlab-com/www-gitlab-com/commit/c4ea6aa9...

I haven't tried omnibus but I'd vote for docker too after being spoilt by setting up and maintaining a Discourse instance. They've done an absolutely fantastic job in making installation and updates painless.

Omnibus makes a ton of assumptions about how many things you want bundled, as well as the monolithic configuration is daunting. I'd suggest breaking up into smaller containers for each service. No matter what container medium you choose, the philosophy of omnibus isn't something you want to 'containerize' as it is.

We run gitlab and the full config is 57 lines. A little more than half of those are comments or blank lines. This includes email and oauth. I would suggest not unbundling.

They could do both? Offer the separate parts in an easy-to-use way, and have the bundle re-use those parts.

Unless you're just super pressed for resources I'm not sure why you wouldn't just install the omnibus then disable the services you don't want.

We recently revamped our in-house deployment process of GitLab, and while we are certainly addicted to Docker Kool-Aid, the Docker image for GitLab just didn't do it for us. This is a few months ago, so my specifics would be a little rusty, but I remember it simply not working, spam-logging errors that didn't help me, and personally I find Docker images that try to run many-multiple applications inside a non-preferred design anyway. Contrasting that, the Omnibus installation worked absolutely without a glitch, so we went with that. Loving GitLab, though!

We have been using the official Docker image without any problems so far.

To be honest, the APT package is easy to configure, runs flawlessly and updates seamlessly.

I thought the same thing :) How did things get so complex :)

Reply on news.ycombinator.com