How can I get gitlab-runner to use a port other than 80 when cloning a repository over HTTP?

How can I get gitlab-runner to use a port other than 80 when cloning a repository over HTTP?

I want to run gitlab-ce in one docker container, and gitlab-runner in another docker container, and use yet another docker container to do the actual CI build. The configs etc. are below, but basically the gitlab-runner fails trying to clone the repository because the ports don’t match. The gitlab-ce is configured to listen for HTTP on port 7080 but the runner seems to always assume port 80.

Running with gitlab-runner 13.0.1 (21cb397c)
  on docker-runner XXXXX
Preparing the "docker" executor
  Using Docker executor with image cicd-sandbox-ci ...
  Using locally found image version due to if-not-present pull policy
  Using docker image sha256:ec98f57e6adb23af0c106bae1579af72ad441b849b5e25a1339ac4e6306feb4e for cicd-sandbox-ci ...
Preparing environment
  Running on runner-xxxxxxx-project-2-concurrent-0 via 9b32f419a8b5...
Getting source from Git repository
  Fetching changes with git depth set to 50...
  Reinitialized existing Git repository in /builds/dev/cicd-sandbox/.git/
  fatal: unable to access 'http://192.168.1.150/dev/cicd-sandbox.git/': Failed to connect to 192.168.1.150 port 80: Connection refused
Uploading artifacts for failed job
  ERROR: Job failed: exit code 1

I’m running gitlab-ce version 12.9.3 and gitlab-runner version 13.0.1 as separate docker containers. I’m not using docker compose (but that will be my next big adventure). I’m on macOS Catalina, using Docker Desktop 2.3.0.3.

The gitlab-ce container was started with the following. Note that the port 80 is mapped to 7080. (I’m not using HTTPS for this experiment and I don’t think it matters for this question.)

sudo docker run --detach \
    --hostname localhost \
    --publish 7443:443 --publish 7080:80 --publish 7022:22 \
    --name gitlab \
    --restart always \
    --volume $GITLAB_HOME/gitlab/config:/etc/gitlab \
    --volume $GITLAB_HOME/gitlab/logs:/var/log/gitlab \
    --volume $GITLAB_HOME/gitlab/data:/var/opt/gitlab \
    gitlab/gitlab-ce:latest

The gitlab.rb is sets external URL to the host IP address…

external_url 'http://192.168.1.150'

The gitlab-runner container was started with the following.

docker run -d --name gitlab-runner --restart always \
    -v /Users/Shared/gitlab-runner/config:/etc/gitlab-runner \
    -v /var/run/docker.sock:/var/run/docker.sock \
    gitlab/gitlab-runner:latest

The gitlab-runner config.toml is as follows. I use the IP address 192.168.1.150 is the host IP which gitlab listens on. The image cicd-sandbox-ci is the image I want to use for the CI.

concurrent = 1
check_interval = 0

[session_server]
  session_timeout = 1800

[[runners]]
  name = "docker-runner"
  url = "http://192.168.1.150:7080"
  token = "XXXXXXX"
  executor = "docker"
  [runners.custom_build_dir]
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]
  [runners.docker]
    tls_verify = false
    image = "cicd-sandbox-ci"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0
    pull_policy = "if-not-present"

The CI/CD works if I set up all this to use port 80. … Just tested it to be sure it wasn’t something other than the port. But I’m still asking the question :slight_smile: How can I do this with a different port?

I don’t understand why have you set

external_url 'http://192.168.1.150'

rather than

external_url 'http://192.168.1.150:7080'

Is GitLab web IF nevertheless working?

I can’t browse to gitlab when the port is appended to external_url.
¯\(ツ)

Also can’t git push if external_url has the port.
¯\(ツ)/¯ ¯\(ツ)

Looking at the gitlab-runner logs, though, it seems it is using the port from the config.toml…

WARNING: Checking for jobs... failed runner=XXXXX status=couldn't execute POST against 
http://192.168.1.150:7080/api/v4/jobs/request: Post
http://192.168.1.150:7080/api/v4/jobs/request: EOF

So maybe the problem isn’t in the runner.

I have also a Docker installation and have the following setting in my gitlab.rb:

external_url 'http://my_ubuntu_server.westeurope.cloudapp.azure.com:21009'
nginx['listen_port'] = 80

and there are no problems neither with accessing web IF nor with the runner

Looking at the gitlab-runner logs, though, it seems it is using the port from the config.toml…

Correct, the URL that GitLab Runner uses to connect to your GitLab instance will be defined in /etc/gitlab-runner/config.toml.

url = "https://gitlab.example.com/"

The URL the runner uses is set at the time you register the runner, and it uses external_url set in gitlab.rb.

What URL do you see if you go to <external_url>/admin/runners in the “Set up a shared Runner manually” section? Does it match the URL in config.toml?

If you set GitLab to use a non-default port for nginx over HTTP after registering your runner, you’ll most likely need to re-register the runner for the change to take effect.

I seem to have the same or a related problem.
Gitlab and the runner both run in docker.
Gitlab configured first on port 8080.
Then the runner. The runner config.toml has the correct url and port.
I can start a CI job, the runner picks it up.

But… From the runner logfile I can see that the job that is sent to the runner is missing the port number in the parameter repo_url=…

Does this info help a bit?

So…

I found this: https://docs.gitlab.com/runner/configuration/advanced-configuration.html

Parameter “clone_url” => Overwrite the URL for the GitLab instance. Used if the Runner can’t connect to GitLab on the URL GitLab exposes itself.

That resolves my problem, although this doesn’t feel like a good solution, because the repo_url that was sent is still incorrect.

Thinking some more about this, it feels like what’s going on inside the gitlab container isn’t fully aware that port 80 is mapped to port 8080. Gut feeling says running the gitlab container with -p 8080:80 isn’t the way to go, and gitlab should be installed on port 8080 too and then -p 8080:8080. I haven’t tried this out yet though…