ERROR: Preparation failed: Error response from daemon: The requested URL /v1.25/info was not found on this server

Still bad.
This time, the whole stuff is very short :
I put “No Proxy” in the docker Gui Settings

Create the gitlab container :

docker volume create gitlab-logs
docker volume create gitlab-data
docker volume create gitlab-conf

docker run --detach --name gitlab --hostname gitlab.mod --publish 4443:443 --publish 4480:80 --publish 8222:22 --volume gitlab-conf:/etc/gitlab --volume gitlab-logs:/var/log/gitlab --volume gitlab-data:/var/opt/gitlab gitlab/gitlab-ee

Create the runner

docker volume create gitlab-runner-conf 
docker run -d --name gitlab-runner -v gitlab-runner-conf:/etc/gitlab-runner gitlab/gitlab-runner:latest

Declare my ssh key in gitlab
Register the runner

docker run --rm -t -i -v gitlab-runner-conf:/etc/gitlab-runner gitlab/gitlab-runner register --url "http://155.180.54.59:4480/" --registration-token "AzJWN68isYy6pcyMaz1v" --description "Runner des tests unitaires" --executor "docker" --docker-host "tcp://10.0.75.1" --docker-image alpine:latest --docker-services postgres:latest --non-interactive

(I tried --url=“http://localhost:4480” to be completely disconnected but it didn’t work)

Then I created a new project where I add a .gitlab-ci.yml file with

variables:
    HELLO: World
    DOCKER_HOST: tcp://10.0.75.1

test:
    script:
        - docker version

add ., commit, push

and Still the /v1.25/info url error

My docker info is (no http proxy setting) :

>docker info
Containers: 6
 Running: 2
 Paused: 0
 Stopped: 4
Images: 133
Server Version: 18.09.2
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 9754871865f7fe2f4e74d43e2fc7ccd237edcbce
runc version: 09c8266bf2fcf9519a651b04ae54c967b9ab86ec
init version: fec3683
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.125-linuxkit
Operating System: Docker for Windows
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.934GiB
Name: linuxkit-00155ddad103
ID: YFXJ:3SUV:IYYE:NXN7:PIPX:THUR:ZTTH:QIOG:KAXK:Z55P:VAFX:AZPF
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 34
 Goroutines: 56
 System Time: 2020-01-20T14:29:45.1856985Z
 EventsListeners: 1
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine

My docker version :

Client: Docker Engine - Community
 Version:           18.09.2
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        6247962
 Built:             Sun Feb 10 04:12:31 2019
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.2
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.6
  Git commit:       6247962
  Built:            Sun Feb 10 04:13:06 2019
  OS/Arch:          linux/amd64
  Experimental:     false

gitlab and gitlab-runner are in 12.6 version

Hm. With all these containers, this is getting weird. Let’s summarize this a bit more.

• Host system is Windows 10
• GitLab server runs in a Docker container with ports mapped 4443, 4480, 8222 on the host system
• GitLab runner runs in another Docker container, no shared ports or networks
• GitLab runner is registered via http/mapped 4480

In order to access a service from within the Docker container, you need to use a special DNS name.
https://docs.docker.com/docker-for-windows/networking/#use-cases-and-workarounds Either host.docker.internal or gateway.docker.internal.

The GitLab Runner Docker image uses the Docker executor on its own to connect to the host’s Docker daemon.

The docs provide some limitations on that, e.g. with the host system being Server 2016 or 2019 only.
https://docs.gitlab.com/runner/executors/docker.html#using-windows-containers

That may be the culprit.

Before you dig deeper into the problem, your production server is running Linux, right? Does GitLab run inside a Docker image over there, or is it installed via Omnibus packages? If so, try a different way and start VirtualBox on Windows, setup the same Linux distribution, install GitLab, Docker and the runner and investigate on there.

Cheers,
Michael

Thank you. You summarized summarize is what i tried to do.
I saw what may be the reason of the problem in the first link you provided :

Note: GitLab Runner uses Docker Engine API v1.25 to talk to the Docker Engine. This means means the minimum supported version of Docker is 1.13.0 

I also saw another

To force the Docker CLI or the Docker Engine SDKs to use an old version version of the API than the version reported by docker version, set the environment variable DOCKER_API_VERSION to the correct version. This works on Linux, Windows, or macOS clients.

DOCKER_API_VERSION='1.27'

This seems to be an explanation.
I’ll try to test all this but i have already spent much too much time on this…

Still not working.
I have set DOCKER_API_VERSION to 1.25 in windows and in the two containers, restarted everything.
The CLI API version changed

>docker version
Client: Docker Engine - Community
 Version:           18.09.2
 API version:       1.25
 Go version:        go1.10.8
 Git commit:        6247962
 Built:             Sun Feb 10 04:12:31 2019
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.2
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.6
  Git commit:       6247962
  Built:            Sun Feb 10 04:13:06 2019
  OS/Arch:          linux/amd64
  Experimental:     false

But i still have the error. However this should be very near the answer as this gives an explanation to the v1.25 url.
I think i’ll leave this for a while because i can’t spend hours more on this. Too bad.

It is not really clear what the problem is here, is the runner not working or a push with your git client to the dockerized GitLab server?

Runner

• In the GitLab administration/runners section your runner is visible and it has a contact within the last minutes after the registration?
• I’m never used a container on Windows but I guess the commands are the same…
  docker logs -f gitlab-runner-container-name should show you messages that the runner is asking GitLab for new jobs.
• I guess there is a debug switch for the registration, enable this.
• In the CI file: what is this line for DOCKER_HOST: tcp://10.0.75.1?

Git push, whatever

• In one of the post you added this: Declare my ssh key in gitlab - are you using ssh or http(s)
• for http you must include your exposed port 4480 in the URL, for https the port 4443
• when ssh is used you have to add an entry for the server in the ssh config with the port 8222

BTW: When you want an isolated environment use a virtualisation like VirtualBox with a Linux installed. GitLab containers are relying on Ubuntu; may be the same OS as host is better that any MS “OS” whatever.

It’s not clear for me either :-). When I register the runner, everithing is OK. I can see the runner appear in the gitlab runners settings page. For me, the runner is up and runing. I can “exec -it /bin/bash” and navigate in the container.
The error occurs when I push my code.

Previously, i had another different error

Thanks. It gives much info

WARNING: Failed to process runner                   builds=0 error=Error response from daemon: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /v1.25/info was not found on this server.</p>
</body></html> (executor_docker.go:982:0s) executor=docker runner=DCfv4xWy
Configuration loaded                                builds=0
Runtime platform                                    arch=amd64 os=linux pid=6 revision=ac8e767a version=12.6.0
Starting multi-runner from/etc/gitlab-runner/config.toml...  builds=0
Running in system-mode.

Configuration loaded                                builds=0
listen_address not defined, metrics & debug endpoints disabled  builds=0
[session_server].listen_address not defined, session endpoints disabled  builds=0
WARNING: Checking for jobs... failed                runner=DCfv4xWy status=couldn't execute POST against http://11.22.33.44:4480/api/v4/jobs/request: Post http://11.22.33.44:4480/api/v4/jobs/request: EOF
WARNING: Checking for jobs... failed                runner=DCfv4xWy status=couldn't execute POST against http://11.22.33.44:4480/api/v4/jobs/request: Post http://11.22.33.44:4480/api/v4/jobs/request: EOF
WARNING: Checking for jobs... failed                runner=DCfv4xWy status=couldn't execute POST against http://11.22.33.44:4480/api/v4/jobs/request: Post http://11.22.33.44:4480/api/v4/jobs/request: EOF
WARNING: Checking for jobs... failed                runner=DCfv4xWy status=couldn't execute POST against http://11.22.33.44:4480/api/v4/jobs/request: Post http://11.22.33.44:4480/api/v4/jobs/request: EOF
WARNING: Checking for jobs... failed                runner=DCfv4xWy status=502 Bad Gateway
WARNING: Checking for jobs... failed                runner=DCfv4xWy status=502 Bad Gateway
WARNING: Checking for jobs... failed                runner=DCfv4xWy status=502 Bad Gateway

It’s a scar from previous errors and search… It’s the docker host ip used to communicate with containers. Is is useful in the gitlab-runner config.toml file. Not sure it is used in the CI File. But with or without, the error is the same.

The error may be here. I think i use ssh but i’m not sure to see where is the 8222 port to be configures (gitlab server, host, runner ?). I’m not familiar with ssh : i use it but not configuring it.

Oh yes. And the best would be that my working machine’s os is linux. But i’m not very easy with all of this and if i put containers in VMs… I think i will face many problems (ports not matching, proxies, hosts). As far as i can see, the problem is more a fail in config than a windows host one. Maybe i’m wrong…

Chiming back in here, since I had suggested this before. Wouldn’t it make more sense to spin up a Linux VM with the same OS as your production server? If you could tell which distribution and version, we could point you there e.g. with Vagrant making this more easy. I don’t think that you will need Docker at all, except for the runner executor itself. Imho this topic has eaten too much time already, we should focus on on solving the real issue - create a staging env for production, where you can test things.

Cheers,
Michael

In fact you’re right, it would certainly make sense. And maybe will i do it when i’ll have time (as you say, too much time has been spent on this) but between security policy (this VM won’t have the security environnement needed for many operations), the port mappings, the proxies and other network config, it will certainly not be an easy thing (at least for me), so i’m a little afraid I would go once more in an endless installation.
This last sentence (mine) was written because I’ve had an opportunity to do this (not with gitlab but with some couchbase servers (to test again)) on my personal linux machine and everything worked nearly on the first try.

I’m not sure if I can follow. You’re running Docker containers on a Windows desktop, which uses their hypervisor actually in a small VM itself. The VirtualBox VM would be a problem then? I would just try it, either manually install Ubuntu LTS in there, or use Vagrant for it.

vagrant init bento/ubuntu-18.04
vagrant up
vagrant ssh

Yeah this world is not perfect… without a minimum of knowledge nothing will be good at all?

Are you interested in a usable Docker deployment? If yes I can try to create some step by step instruction.

When people think a container is deployed quite fast without configuration effort this may be true until everything is running inside one container. When more containers are required which all communicating to each other this is not true.

Just by the way: I’m operating Docker based GitLab deployments in my company incl. runners and everything work well. I never would replace this by a “native” installation just because an upgrade for each instance is finished after 20 minutes, depending on the DB size.

Maybe it’s me that can’t follow
If i use VM, i’ll have to install Virtual Box (and/or Vagrant, which i don’t know at all), install Docker in the virtual box VM, create containers in the VM (at least one for the runner… and make all this communicate with the host (where my sources are) and internet via my compagny proxies…

As all this is not something i’m very used to (i’m learning through this experiment), i’m afraid that this additional step will add some additional pain (in my experience, nothing works perfectly the first time).

Anyway, my feeling is that all this mess comes from a misunderstanding in local machine "network conf". Everything is going well till the registeration (included), I now understand where the v1.25/info url comes from, both containers run and i can exec -it /bin/bash on both.

Just to review the context : this is an experiment i do to have a gitlab-CI stack up and running. As dsnmichi suggest, there is certainly other ways that can be used to reach this goal but i very much appreciated my firsts steps with docker (another experiment on a linux machine) and i like the flexibility of containers (and i fear to start a new long and hard experiment). So, i’d prefer to make this stack work this way.
If this don’t work, there is no serious result : i won’t be able to use the CI part of gitlab before our admins decide to make it run in some months (or more ?). I am just curious and i don’t like this kind of situation

So, i am interested in nightman68 suggestion of a step by step instruction but, as this is more for personal purpose than vital professionnal one, feel free to do what you want.

On the first and the 21 posts, i put all the steps i did. I don’t think i forgot anything (no ssh conf for exemple as i thought expose it in the run gitlab command would do the trick) so maybe you could see there what misses…

Thanks anyway, both of you, but especially dnsmichi, for the time spent. Even if it doesn’t work, i greatly raised my understanding of gitlab-CI and docker through these exchanges.