GitLab Pipeline连接本地SonarQube报Connection refused错误

你的GitLab Runner使用docker作为执行器，Pipeline所有脚本都运行在独立的Docker容器内部，此时脚本中配置的127.0.0.1、localhost指向的是当前运行作业的容器自身回环地址，而非部署SonarQube的宿主机地址，自然无法连接到宿主机9000端口上的SonarQube服务。本地终端执行命令能正常连通，是因为终端环境直接运行在宿主机上，localhost指向的就是宿主机自身。

• 替换SonarQube服务地址
  把Pipeline里SonarQube的服务地址从http://127.0.0.1:9000改成宿主机的实际物理IP，也就是你Runner配置里clone_url字段填的机器IP，最终地址格式为http://<宿主机实际IP>:9000。
  注意：如果SonarQube服务默认绑定的是127.0.0.1地址，需要先修改SonarQube的监听配置，把绑定地址改成0.0.0.0，否则通过宿主机IP访问会被拒绝。
• 放通网络访问权限
  检查宿主机的防火墙规则，放通9000端口的入站访问，确保Docker容器网段可以正常访问宿主机9000端口。
• 修正CI配置的语法错误
  原配置存在两处会直接导致执行失败的语法问题：
  1. 删掉SONAR_USER_HOME变量配置下方多余的task cache无效行，否则CI配置解析会直接报错
  2. 修正sonarscanner begin命令里的引号转义问题，原命令中/k:"trukkerfinops"段的引号没有正确转义，会导致参数解析失败
     修正后的可参考配置如下：

stages:
  - sonar

sonarqube-check:
  stage: sonar
  image: mcr.microsoft.com/dotnet/sdk:6.0
  variables:
    SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"
    GIT_DEPTH: "0"
  cache:
    key: "${CI_JOB_NAME}"
    paths:
      - .sonar/cache
  script: 
      - "apt-get update"
      - "apt-get install --yes openjdk-11-jre"
      - "dotnet tool install --global dotnet-sonarscanner"
      - "export PATH=\"$PATH:$HOME/.dotnet/tools\""
      - "dotnet sonarscanner begin /k:\"trukkerfinops\" /d:sonar.login=username /d:sonar.password=password /d:sonar.host.url=http://<替换为宿主机实际IP>:9000"
      - "dotnet build"
      - "dotnet sonarscanner end /d:sonar.login=\"$SONAR_TOKEN\""
  allow_failure: true
  only:
    - main

• 可选：无需写死宿主机IP的配置方案
  如果不想在配置里硬编码宿主机IP，可以修改GitLab Runner的config.toml配置文件，在[runners.docker]段落下添加extra_hosts参数，把固定域名映射到宿主机网关：

extra_hosts = ["host.docker.internal:host-gateway"]

修改完成后重启gitlab-runner服务，之后Pipeline里的SonarQube地址可以直接写成http://host.docker.internal:9000，不需要固定写死宿主机IP。

修改完成后重新触发Pipeline，作业执行到sonarscanner begin步骤时，会正常拉取SonarQube服务端版本信息，不会再抛出连接拒绝、无法分配地址的错误。

内容的提问来源于stack exchange，提问作者Deepak Sharma