Dial unix /var/run/docker.sock: connect: no such file or directory" context canceled

I’m trying to run gitlab-runner on my linux(not server):

sudo docker run -d --name gitlab-runner --restart always -v /srv/gitlab-runner/config:/etc/gitlab-runner -v /var/run/docker.sock:/var/run/do
cker.sock gitlab/gitlab-runner:latest

and register gitlab-runner successfully

Here is the repo and job: http://git.chenli.space/chenli/linux-kernel/-/jobs/42

When .gitlab-ci.yml run sudo docker build -t docker-build-debian-kernel-package:10:

`$ sudo docker build -t docker-build-debian-kernel-package:10 .
time="2019-08-07T02:07:15Z" level=error msg="failed to dial gRPC: cannot connect to the Docker daemon. Is 'docker daemon' running on this host?: dial unix /var/run/docker.sock: connect: no such file or directory"
context canceled

I have many ways from google, e.g., change DOCKER_HOST in .gitlab-ci.yml. But all of them don’t work

When I try to edit docker.sock(it exists already) in gitlab-runner docker:

root@129329a2e62f:/# vim /var/run/docker.sock  

vim tells me permission denied.

I should use shell as executor, because I run docker build/run manually in .gitlab-ci.yml

You can use the shell executor to execute Docker commands of course, but the problem is that your CI job won’t be starting from a clean environment (i.e., the shell commands run at host level, where “host” refers to the environment where the GitLab runner is executing). This can make the job unstable.

It’s better to use the GitLab runner’s Docker executor, so that your job starts inside a cleanly provisioned Docker container.

Now, if your job will communicate with Docker (e.g., issue docker ... commands), then the job needs access to a Docker CLI and a Docker daemon.

This means the job must run inside a container that has the Docker CLI in it (e.g., image: docker:19.03.12) and that this container must be connected to a Docker daemon.

There are a couple of ways: connect to the host’s Docker daemon (via a bind-mount of /var/run/docker.sock into the job container) or connect to a dedicated Docker daemon running inside a “service” container (the “Docker-in-Docker” approach).

Both of these work and have different pros/cons (I personally like the DinD approach better because you get a dedicated Docker daemon for the job).

I wrote a blog explaining all of this, and describing how these setups work but are not secure (i.e., the job can easily gain control of the GitLab runner’s host machine). The blog also describes a solution to secure them.

Hope that helps!