Docker-gitlab: What's the difference between this image and the image provided by gitlab?

[persapiens]

I don't know if here is the best place to this question, but I need to know which one is more suitable for production purpose.

[frostieDE]

Basically, the official image is based on the GitLab omnibus package and this image is based on installation from source. But let's take a deeper look:

The official image contains all services in one image (GitLab itself, Postgres, Redis, ...) while this image splits the services into different pieces and uses docker-compose to glue them together. Thus, this image is actually the more Docker-way image (because most services run in seperate containers). As a result, you could actually use multiple redis and/or postgres instances for better scaling.

Futhermore, this image allows you to use either Postgres or MySQL (the official one runs Postgres* only). Also, it allows you to use an external database server (which is actually not the real docker-way, but in some scenarios it might be useful).

Also, the offical image gets updated as soon as a new version of GitLab is released. This image is also updated soon after official releases, but it can take some time (in the past months it took around 1-5 days).

While the official docker image is pretty easy to install and configure, this image might need some time to be configured properly (but the documentation is quite good, so if you have a bit experience in Docker, you should be able to install this image in less than an hour).

In conclusion, I find it hard to say which one is more suitable for production purpose. Generally, I think both images can be used in production environments. I am using this image as it's using Docker the better way. I have been running two instances successfully for more than three months now and I am very satisfied.

I hope it helps :wink:

*) from my past experiences: you get less problems when using Postgres 😉

[persapiens]

Thanks a lot for your detailed answer @frostieDE .

[persapiens]

one more question: Is it required to use host volume with sameersbn image or we could use data volume?

[timfeirg]

this answer should be included in the docs

[ptcuops]

I'm sure this is a common question, so I'll add my two cents.

Pros for this image:

• The documentation is remarkable. It's very rare to see someone make a open source contribution with this level of attention to detail in the documentation. Seriously, it's impressive.
• As someone else mentioned above, this is JUST gitlab; combining the database and other services isn't just "not the docker way", it's actually dangerous, at least as far as the database is concerned. To date, there is still no way to run a true production database using a docker container.

Pros for Official Image

• It's omnibus; that may not seem all that important, but a very large portion of the gitlab community is running the omnibus configuration of gitlab and therefore when you see examples, tutorials, or suggestions, it's almost always referring to the omnibus method which uses a significantly different configuration approach than the "from source" method. For example, configuring the gitlab registry behind a load balancer with SSL handled by the load balancer and gitlab allowing http to pass through is pretty well documented in the community for the omnibus install. After two days doing nothing else, I'm still struggling to figure this out with this image.
• It's the official image. Frankly, as amazing as this image is, the odds are that the official image will be supported for longer

The real killer for the official image is it's monolithic nature. That's a deal breaker. Of course, you can override the connections to the internal services in the official image, but there still there, making for a very fat service.

Ideally, I'd love to see this image's attention to detail and documentation combined with the omnibus installation which would allow, by default, for the modification of every single gitlab setting.

At the moment, I'm still using this image for out gitlab proof of concept, but this HTTPS registry issue might mean we might end up rolling our own based on Omnibus.

[ye]

Great answers @frostieDE and @ptcuops

As much as we like this port of GitLab dockerization, one major concern though I think, is that the new trend of the community is to integrate GitLab with kubernetes ecosystem(helm/charts etc) for container orchestration. And the official GitLab installation guide has acknowledged that, and progress with Cloud Native Images, which will replace its existing recommendation of omnibus GitLab images.

Although Cloud Native Images are still a work in progress, they do intent to address a lot of the issues that mentioned above in existing omnibus images, like breaking down monolithic images into smaller more efficient images, horizontal scaling (with the help of kubernetes), flexible advanced configurations etc.

And most importantly, they are official implementations that's guarantee to be maintained by an commercial organization. With all that, I do feel that many many contributors have poured into huge amount of time and effort into this project, wouldn't it be a better outcome if at last some of these efforts can be back ported into the official cloud native images? In other words, I wonder what's gonna be the ultimate fate of this project?

My team started GitLab installation with this project but looking forward, we are really seeing ourselves better benefiting from utilizing the official cloud native images. Is there a way migration from this project to the official GitLab k8s helm/chart images?

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity for the last 60 days. It will be closed if no further activity occurs during the next 7 days. Thank you for your contributions.