Gitlab EE runs in docker - subgit on host

SubGit
#1

We are runnig the latest docker image from gitlab/gitlab-ee:latest on CentOs8 Host. On this Host we have installed subgit 3.3.11.

I haven’t found any direction how to configure subgit to work with Gitlab in the docker container.
Is this a valid scenario, or do I have to install subgit inside the container?

#2

Hi Josef,

SubGit is supposed to run on the same machine with GitLab – in the same container in case if GitLab is installed in a container, I’m afraid this is the only way to configure SubGit to work with GitLab directly.

#3

Hi Ildar,
Thanx for ur reply. In the meantime we use the docker image from GitHub - cmarquardt/docker-gitlab-ee-subgit: A GitLab container (Enterprise Edition) with SubGit included
This works fine so far. We are just wondering why it uses gitlab 3.3.6 instead of 3.3.11. Are there known Problems using subgit later den 3.3.6 within a docker image?

#4

Hi Josef,

no, there are no known issues using SubGit in a docker container; and there are no issues using SubGit with GitLab as long as SubGit is in the same container as GitLab.

#5

Sorry to hijack this conversation. We have similar kind of scenario but we manually installed Subgit on GitLab EE docker container. In case, if we want to upgrade the GitLab image, and if we want to install same version of Subgit on the newly upgraded GitLab docker container, can we use the same enterprise license which we used on the old container? or we have to request for a new one for free?

#6

Hi Vijay,

a license is valid for a “server” which means an environment where SubGit tracks all the mirrored repositories and counts all the committers across all those repositories. For a containerised environment that would be a single container, so if the intent is to have another running GitLab container with SubGit installed, then it would require a separate license. If, however, the intent is to replace an old container with a new one, then it’s OK to use the same license.
From the technical point, I’d like to note that the last case of replacing the container would require persisting SubGit’s metadata – repository-specific metadata is being stored inside the repository which, I believe, essentially persistent, but SubGit also stores some common metadata in /etc/subgit that is also better to keep.