GitLab运行器无法通过http克隆存储库 [英] GitLab runner unable to clone repository via http

查看:2332
本文介绍了GitLab运行器无法通过http克隆存储库的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个在测试环境中运行的GitLab的最新Docker镜像,我遇到了GitLab亚军的问题。它无法通过HTTP链接克隆,产生以下消息:

 在runner -bd27e50b-project-1-concurrent- 0通过机器... 
克隆存储库...
克隆到'/ builds / my / awesome-project'...
致命:无法访问'http:// gitlab- ci-token:xxxxxx@127.0.0.1/my/awesome-project.git/':
无法连接到127.0.0.1端口80:连接被拒绝

错误:生成失败:退出代码1

我使用运行gitlab-runner - debug 标志并使用它正在尝试的确切地址(使用令牌),并且我可以很好地克隆存储库。我不知道为什么服务无法克隆存储库。跑步执行者也被配置为'码头'。也许有一些端口映射问题进入该容器?

解决方案

我假设这个问题可能与注册跑步者有关一个码头容器导致localhost地址不能解析到正确的机器(我开始跑步的地方);在这种情况下,它可能会解析为容器。



























$ b <编辑:这是一个更详细的问题,因为我的理解和解决方案。装载的docker实例就像一个(非常)轻量级的虚拟机。 Docker配置一个虚拟网络接口,如果您从主机运行ifconfig,您将看到:

  user @ pc:〜> ; ifconfig 
docker0 Link encap:Ethernet HWaddr XXXX
inet addr:172.17.0.1 Bcast:0.0.0.0 Mask:255.255.0.0
...

这是该接口上主机的IP地址。因此,如果您希望运行器能够连接到该主机上运行的服务,则不能将其指向localhost / 127.0.0.1,因为它来自运行器的实例,它将路由到运行器的 VM,但是GitLab没有运行在运行者VM内部,它在主机上,所以运行者无法与GitLab进行通信。



解决方案是注册运行者指向docker界面上的主机虚拟地址(),或者使用主机的公共IP或域名(如果有),并且可以公开访问。只是不要将它发送到localhost或127.0.0.1,因为对运行者来说,它指向它的虚拟机,而不是你的GitLab实例。


I have the latest docker image of GitLab running in a test environment and I'm running into an issue with the GitLab runner. It's unable to clone via the HTTP link, yielding the following message:

Running on runner-bd27e50b-project-1-concurrent-0 via machine...
Cloning repository...
Cloning into '/builds/my/awesome-project'...
fatal: unable to access 'http://gitlab-ci-token:xxxxxx@127.0.0.1/my/awesome-project.git/': 
    Failed to connect to 127.0.0.1 port 80: Connection refused

ERROR: Build failed with: exit code 1

I ran gitlab-runner with the --debug flag and used the exact address it was trying (with the token in-tact) and I could clone the repository just fine. I'm at a loss as to why the service is unable to clone the repository. The runner executor is configured as 'docker' as well. Maybe there is some port mapping issue into that container?

解决方案

I hypothesized the issue might have something to do with registering the runner as a docker container causing the localhost address not to resolve to the right machine (where I'm starting the runner); in this case it probably resolves to the container instead. Using the host's IP on the docker proxy interface (172.17.0.1 for me) or using the host's real address instead of "localhost" when registering the runner fixes the problem.

Edit: Here is a bit more detail on the problem as I understand it and a solution. The docker instance that's loaded up is like a (very) lightweight virtual machine. Docker configures a virtual network interface which you'll see if you run ifconfig from your host machine:

user@pc:~> ifconfig
docker0   Link encap:Ethernet  HWaddr XXXX
          inet addr:172.17.0.1  Bcast:0.0.0.0  Mask:255.255.0.0
          ...

This is the IP address of the host machine on that interface. So, if you want the runner to be able to connect to the service that's running on that host machine, you can't point it to localhost/127.0.0.1 because, coming from inside the runner's instance, that will route to the runner's "VM", but GitLab is not running inside that runner "VM", it's on the host, so the runner is unable to communicate with GitLab.

The solution is to register the runner to point to the host's virtual address on the docker interface (http://172.17.0.1/ci for me), or to use the host's public IP or a domain name if you have one and it's accessible publicly. Just don't send it to localhost or 127.0.0.1 because, to the runner, that points to its "VM", not your GitLab instance.

这篇关于GitLab运行器无法通过http克隆存储库的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆