Docker gitlab/gitlab-ee:latest -- where is the actual gitlab.rb?

I have Gitlab installed per GitLab Docker images | GitLab

My gitlab.rb is:

      external_url ''
      nginx['redirect_http_to_https'] = true
      nginx['redirect_http_to_https_port'] = 80
      letsencrypt['enable'] = false
#      letsencrypt['contact_emails'] = ['']

I’m having trouble with LetsEncrypt: it always tries to renew my certificate (it is < 30 days from expiry), whether or not I have letsencrypt['enable'] = false; and it always fails with “Connection refused”

The “Connection refused” is entirely understandable, if I run curl localhost from inside the container, I’ll get the same response! But this suggests that both the redirect_http_to_https and letsencrypt['enable'] settings are being ignored.

So, I try to look at /etc/gitlab/gitlab.rb and every line is commented. How can I see what settings are actually in use?

Where is your gitlab.rb if not at /etc/gitlab/gitlab.rb?

/etc/gitlab/ should be a host mounted volume (see here). So the config file should actually reside somewhere on the host, not within the container, though it will appear to be at /etc/gitlab/ from within the container.

Also did you run gitlab-ctl reconfigure (or restart the container) after making your configuration changes?

1 Like

As I said, installed per the instructions at GitLab Docker images | GitLab.


  - $GITLAB_HOME/data:/var/opt/gitlab
  - $GITLAB_HOME/logs:/var/log/gitlab
  - $GITLAB_HOME/config:/etc/gitlab
  GITLAB_OMNIBUS_CONFIG: "from_file('/omnibus_config.rb')"
  - source: gitlab
    target: /omnibus_config.rb


    file: ./gitlab.rb

So, my gitlab.rb is in the directory from which I run docker swarm deploy. Inside the container it should be, and is, found in /omnibus_config.rb. But it does not appear to be the file that is actually being used, which is why I want to find where the actual running config really should be.

And, no, I haven’t run gitlab-ctl reconfigure. This is a Docker deployment, there is no “configuration change”, this is the initial configuration (and just to be sure, I’ve been deploying it with an initially empty directory at $GITLAB_HOME/config:/etc/gitlab$GITLAB_HOME/config:/etc/gitlab always gets recreated and is always only comments ).

Wait… Is that a bug in the Docker directions? Surely

  - source: gitlab
    target: /omnibus_config.rb

either source should not be preceded by a dash or target should! But, it does get copied to target, so that can’t be it.

Sorry, for some reason I didn’t receive a notification of your response.

I didn’t want to assume that you’re using Docker Swarm based on the link you posted, and I’m only running GitLab as a container for dev purposes using Docker Engine. So in your context my knowledge is limited, however I did a bit more reading…

One interesting thing I found is here: " The settings contained in GITLAB_OMNIBUS_CONFIG aren’t written to the gitlab.rb configuration file, and are evaluated on load." I think this explains why you’re not seeing anything in /etc/gitlab/gitlab.rb.

Perhaps you can find some innocuous setting to test whether any of your settings are actually being applied? For example disabling a certain feature that’s visible in the UI, or something along those lines.

Otherwise you might be able to use the rails console to check the state/value of particular settings, but that’s just an idea and not something I’ve tried myself.

By the way, I think the Docker directions are fine as source and target are relevant to one particular config, so one dash makes sense here.

That’s helpful. Somehow I’d always missed that line about not being written to the gitlab.rb file, but that’s good, because it means I shouldn’t be seeing anything in the one in my mounted directory.

Which takes me to the second part of the question. “How can I see what settings are actually in use?” I’m sure it should be possible in the rails console, but I can’t find instructions for that, and know nothing about Ruby to be able to deduce it. I know some settings are in effect, because my gitlab.rb contains LDAP configuration which works fine.