Gitlab docker not working if external_url is set

Hello community,
I’ve been struggling for a while with a problem that I’m still unable to solve. Help would be much appreciated!
What I did:

  1. Install Gitlab-CE using the docker image (8.9.6-ce.0) on an Ubuntu 16.04.1 LTS virtual machine in my server following http://docs.gitlab.com/omnibus/docker/README.html
  2. Setup a user locally and push some projects for a machine in the same LAN >> all working ok
  3. Add a new mapping to my firewall to map gitlab-machine-ip:80 > mydomain.org:8138 so that I can access gitlab with http

I’m now able to access the web interface at http://mydomain.org:8138 and use it
NOW THE PROBLEM: the URLs for cloning projects show up incorrectly since they miss the :8138 port (they get the mydomain.org part from the --host setting passed to the docker container).
Cloning works ok if I manually add my custom ports to the URLs

I wanted to solve this so gave a try to the external_url setting in gitlab.rb setting it to:
external_url 'http://mydomain.org:8138
and restarted (also tried calling gitlab-ctl configure manually)

STATUS IS THAT I CANNOT ACCESS THE WEB INTERFACE ANYMORE AT http://mydomain.org:8138 getting a ERR_CONNECTION_REFUSED in my browser
If I just comment out the external_url setting everything is back working (apart from the missing port in URLs obviously)

I’ve read a bunch of issues report but none of them helped in solving the issue:
https://gitlab.com/gitlab-org/omnibus-gitlab/issues/244 >> (I’m NOT using an external NGINX)
also tried updating to 8.11 after I read about this: https://gitlab.com/gitlab-org/gitlab-ce/issues/20131 but it did not help

Don’t really know what’s going on here.
Output of gitlab-rake gitlab:env:info and gitlab-rake gitlab:check follows

System information
System:
Current User: git
Using RVM: no
Ruby Version: 2.3.1p112
Gem Version: 2.6.6
Bundler Version:2.3.0
Rake Version: 10.5.0
Sidekiq Version:4.1.4

GitLab information
Version: 8.11.3
Revision: 6cd4edb
Directory: /opt/gitlab/embedded/service/gitlab-rails
DB Adapter: postgresql
URL: http://labmedinfo.org:8138
HTTP Clone URL: http://labmedinfo.org:8138/some-group/some-project.git
SSH Clone URL: git@labmedinfo.org:some-group/some-project.git
Using LDAP: no
Using Omniauth: no

GitLab Shell
Version: 3.4.0
Repository storage paths:

  • default: /var/opt/gitlab/git-data/repositories
    Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks/
    Git: /opt/gitlab/embedded/bin/git

Checking GitLab Shell …

GitLab Shell version >= 3.4.0 ? … OK (3.4.0)
Repo base directory exists?
default… yes
Repo storage directories are symlinks?
default… no
Repo paths owned by git:git?
default… yes
Repo paths access is drwxrws—?
default… yes
hooks directories in repos are links: …
telemed / banca … ok
telemed / calcolatrice … ok
telemed / chat … ok
telemed / collections … ok
telemed / interfacce … ok
telemed / partite … ok
telemed / polimorfismo … ok
telemed / ristoranti … ok
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Access to /var/opt/gitlab/.ssh/authorized_keys: OK
Send ping to redis server: OK
gitlab-shell self-check successful

Checking GitLab Shell … Finished

Checking Sidekiq …

Running? … yes
Number of Sidekiq processes … 1

Checking Sidekiq … Finished

Checking Reply by email …

Reply by email is disabled in config/gitlab.yml

Checking Reply by email … Finished

Checking LDAP …

LDAP is disabled in config/gitlab.yml

Checking LDAP … Finished

Checking GitLab …

Git configured with autocrlf=input? … yes
Database config exists? … yes
All migrations up? … yes
Database contains orphaned GroupMembers? … no
GitLab config exists? … yes
GitLab config outdated? … no
Log directory writable? … yes
Tmp directory writable? … yes
Uploads directory setup correctly? … yes
Init script exists? … skipped (omnibus-gitlab has no init script)
Init script up-to-date? … skipped (omnibus-gitlab has no init script)
projects have namespace: …
telemed / banca … yes
telemed / calcolatrice … yes
telemed / chat … yes
telemed / collections … yes
telemed / interfacce … yes
telemed / partite … yes
telemed / polimorfismo … yes
telemed / ristoranti … yes
Redis version >= 2.8.0? … yes
Ruby version >= 2.1.0 ? … yes (2.3.1)
Your git bin path is "/opt/gitlab/embedded/bin/git"
Git version >= 2.7.3 ? … yes (2.7.4)
Active users: 4

Checking GitLab … Finished

UP
if anyone able to help needs further info I’ll be glad to provide it

Ok was able to figure out the problem on my own.
Apparetly when you change the external_url parameter in gitlab.rb there’s the side effect (not very clearly explained in the documentation if you ask me!) that nginx will now run on the port you put in the http://mydomain.org:8138

Since I instead mapped port 80 on my external URL through my firewall then the gitlab website was not reachable anymore. I would suggest to clearly state in the documentation that changing external_url (if a port number is included) would cause nginx and the website to run http on a different port than the standard 80!!!

Hope this helps some other people having a problem similar to mine :slight_smile:

9 Likes

Thanks alot for reporting the fix, I never suspected its cause to be hidden so out of sight. I wasted quite a lot of time on this problem before stumbling across your thread.

1 Like

Thanks Enea! I’ve been trying for way to long and only after I was able to pinpoint it to external_url I found this thread. It’s unfortunate that the documentation has an incorrect example at this moment.


On a second note: in an attempt to fix the documentation I found out that this merge request (which has been open for 7 months) made a correction to the README which would’ve made the example work.

1 Like

Actually, it is very surprising behaviour!

This way, after change external_url setting, I should also change not only external port mapping side in docker command, but also the internal side. So, 6080:80 become 6080:6080 if I set external_url 'http://192.168.1.1:6080'.

It is very surprising and unexpected behavior. Inside docker container nginx should not change it’s listen port at all. Thank you @eparimbelli for the hint!

2 Likes

I was confused by this as well for quite a while. Looks like there is an open issue which you can +1 if you want:

I totally agree with you. They should definitely clearly stated this in the documentation.

I was also caught out by this. It seems like a bug, honestly, external_url should mean just that - taking just the ‘port’ component of that URL and applying it to internal configuration is plain wrong & misleading.

this addressed my problem, thank you!