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?
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.
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.
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.
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.