Failed pull image from mrc.microsoft.com on self hosted gitlab

How to Use GitLab Self-managed
,
1

hi; i can pull any image from mcr.microsoft.com on my server. gitlab installed on same server(docker) but when is using in giltab ci/cd i get “net/http: TLS handshake timeout”.

my .gitlab-ci.yml on self hosted gitlab

publish:
  image: docker:20.10.16
  services:
  - docker:20.10.16-dind
  only:
    - myapp.domain.com
  tags:
    - myapp.domain.com.tag
  stage: publish
  script:
    - cat /etc/resolv.conf
    - ping -c 2 mcr.microsoft.com
    - docker pull hello-world
    - docker pull mcr.microsoft.com/dotnet/sdk:5.0

error:

01
01923×517 56.8 KB

2

I’ve copied your configuration into a test project on GitLab.com SaaS, and it worked publish (#2574281949) · Jobs · Michael Friedrich / ci-cd-playground · GitLab

I would investigate on your self-hosted runner which is executing the job, if there is anything intercepting or blocking network traffic to the container registry. ping sends ICMP packets, which is using a different protocol to docker pull which communicates over http/TLS.

Maybe the internet connection is too slow, and the TLS handshake fails, linux networking - Docker pull: TLS handshake timeout - Server Fault has some more insights. Or you’ll need to configure an outgoing HTTP proxy in your company environment to being able to transfer HTTP traffic.

3

thank dnsmichi,
I have no problem to pull any image from https://mcr.microsoft.com in same server gitlab-runner installed. firewall is off.

02
021296×348 14.5 KB

i also accessto https://mcr.microsoft.com inside gitlab-runner container:

03
031315×183 9.46 KB

but pull from .gitlab-ci-.yml is too long. is any setting to increase network performance?

4

Hm, tricky. I do believe that this is a Docker problem, where the runner itself spawns a container (Docker in Docker) and then somewhat network inception problems may occur.

Is there a possibility to install gitlab-runner directly on the machine (not in Docker) and compare if the behaviour continues? This would help to rule out a DinD problem.

Another idea would be to use the Dependency Proxy in GitLab and cache Docker images, moving them more local to GitLab and avoid the pull timeouts. Dependency Proxy | GitLab Still, this won’t solve the first pull timing out.