Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Docker GitLab (github.com/sameersbn)
50 points by snake_case on April 25, 2015 | hide | past | favorite | 24 comments


This image is very good but we recommend the one based on the Omnibus Packages https://gitlab.com/gitlab-org/gitlab-ce/tree/master/docker

I plan to make these official on Dockerhub over the weekend. But if there are vulunteers that want to keep them up to date that would be perfect.


Out of curiosity, why do you recommend running an Omnibus container instead of separate containers for Gitlab, Postgres and Redis?

It seems like it only gains a tiny bit of convenience (one "docker run" command instead of three), and you lose a lot of flexibility to move things around and reconfigure later on. What if I want to run multiple frontend instances, or keep a warm standby database replica?


The main reason is that the Omnibus package setup has additional logic to respawn workers that are using too much memory. I also like that it uses a separate data container to store everything.


In the https://github.com/sameersbn/docker-gitlab container, you can mount volumes from the Docker host to store data as well, and it also uses linked containers for Redis and Postgres.

The respawn workers logic does seem important though. Does the manual gitlab install also handle situation?


No, the manual install doesn't handle that. It requires Runit if I remember correctly.


Send me an email - nick@docker.com - I'll make sure you get connected to the right team.


Thanks! Just send you an email.


The official omnibus packages do work very nicely - I can't say I've had any problem with them since they came out!


Good to hear that!


I like http://gogs.io/ better. Trivial to install and works great.


As do I, Gogs was amazing at my previous place of employment; I migrated our team from BitBucket over to it, self-hosted on AWS. The nicest part of it was that its deployment is so simple, and it's architecture and file structure easy to understand that setting up a backup and restore workflow in case something happened to the instance was one of the easiest things I've done in that sort of domain. Dump the database, send the files and dump to S3, also download it to a local server not on AWS just in case and have a small bash script to restore everything if it goes pear shaped. Testing the backup restore showed that 99% of the time taken was waiting on the new instance to start-up, which if we wanted higher uptime could be simply solved using horizontal scaling across AZs or data centres. The entire process almost made me want to become a sysadmin... Almost!


I understand you also prefer Gogs to GitLab, mainly because of the easy of performing backups. Have you run into problems with GitLab backups? Did you use our raketask that supports backups to s3? http://doc.gitlab.com/ce/raketasks/backup_restore.html


Back when I used GitLab (version 3), a lot of the nice things you have now didn't really exist then. The biggest argument for Gogs instead of GitLab is that despite it lacking features compared to GitLab, the much smaller amount of moving parts make it simpler to deal with. That said, GitLab is an excellent product, Gogs is just simpler in a lot of ways, which when you're dealing with a team of 10 instead of 100 and I'm the person looking after it (and thus writing the documentation for how to manage it) makes it a better choice for that use-case :)


Thanks Josh, that makes sense. I'm sure that if you install and use GitLab now it will be a completely different experience, GitLab 3 was 1 year old, GitLab 7.10 is 3.5 years old. It should be much easier to deal with now.


Have you tried the Omnibus packages for GitLab by any chance? We launched a package server for them two days ago: https://about.gitlab.com/2015/04/22/gitlab-7-10-released/ Installation should take only two commands and two minutes.


I love how much longer the documentation is than the actual file. That said, I'm also somewhat wary of using forked pgsql and ubuntu images.


A big issue with these docker images is that nobody can vouch for their quality.


GitLab CEO here, the quality of this image is very high, we listed it on https://about.gitlab.com/installation/

Still we recommend people use an Omnibus based image, see https://gitlab.com/gitlab-org/gitlab-ce/tree/master/docker

I agree it is hard to know what image is good, I'm working on an official docker image (with 'gitlab' as a group on Docker Hub) to remedy that.


Got to say, I love that you're active on HN as CEO.

Part of the reason I use and love gitlab is the developer focused nature of your product, glad to see that it extends to the management as well!


Thanks mijoharas, glad to hear that, I'll try to keep it up!


This is one of the best configured and thought-out Docker containers I've ever used. Running this for our project's git repository for several months now, over several upgrades. Really well done.


And you decided to host this on GitHub?


This isn't official, not made by the people at GitLab.


Exactly! And we're pretty pragmatic about it. The canonical place of GitLab is at GitLab.com but we also have a GitHub mirror. Bringing back the D in DVCS.




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

Search: