GitLab CI Runner kann keine Verbindung zu Unix herstellen: ///var/run/docker.sock in kubernetes

Question

GitLab läuft im kubernetes Cluster. Runner kann kein Docker-Image mit Buildartefakten erstellen. Ich habe bereits verschiedene Ansätze ausprobiert, um dieses Problem zu beheben, aber kein Glück. Hier sind einige configs Schnipsel:

.gitlab-ci.yml

image: docker:latest 
services: 
    - docker:dind 

variables: 
    DOCKER_DRIVER: overlay 

stages: 
    - build 
    - package 
    - deploy 

maven-build: 
    image: maven:3-jdk-8 
    stage: build 
    script: "mvn package -B --settings settings.xml" 
    artifacts: 
    paths: 
     - target/*.jar 

docker-build: 
    stage: package 
    script: 
    - docker build -t gitlab.my.com/group/app . 
    - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN gitlab.my.com/group/app 
    - docker push gitlab.my.com/group/app 

config.toml

concurrent = 1 
check_interval = 0 

[[runners]] 
    name = "app" 
    url = "https://gitlab.my.com/ci" 
    token = "xxxxxxxx" 
    executor = "kubernetes" 
    [runners.kubernetes] 
    privileged = true 
    disable_cache = true 

Paket Stufe log:

running with gitlab-ci-multi-runner 1.11.1 (a67a225) 
    on app runner (6265c5) 
Using Kubernetes namespace: default 
Using Kubernetes executor with image docker:latest ... 
Waiting for pod default/runner-6265c5-project-4-concurrent-0h9lg9 to be running, status is Pending 
Waiting for pod default/runner-6265c5-project-4-concurrent-0h9lg9 to be running, status is Pending 
Running on runner-6265c5-project-4-concurrent-0h9lg9 via gitlab-runner-3748496643-k31tf... 
Cloning repository... 
Cloning into '/group/app'... 
Checking out 10d5a680 as master... 
Skipping Git submodules setup 
Downloading artifacts for maven-build (61)... 
Downloading artifacts from coordinator... ok  id=61 responseStatus=200 OK token=ciihgfd3W 
$ docker build -t gitlab.my.com/group/app . 
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? 
ERROR: Job failed: error executing remote command: command terminated with non-zero exit code: Error executing in Docker Container: 1 

Was mache ich falsch?

Answer 1

Sie brauchen nicht diese zu verwenden:

DOCKER_DRIVER: overlay 

Ursache scheint es, wie OVERLAY nicht unterstützt wird, so SVC-0 Behälter nicht in der Lage ist, mit ihm zu beginnen:

$ kubectl logs -f `kubectl get pod |awk '/^runner/{print $1}'` -c svc-0 
time="2017-03-20T11:19:01.954769661Z" level=warning msg="[!] DON'T BIND ON ANY IP ADDRESS WITHOUT setting -tlsverify IF YOU DON'T KNOW WHAT YOU'RE DOING [!]" 
time="2017-03-20T11:19:01.955720778Z" level=info msg="libcontainerd: new containerd process, pid: 20" 
time="2017-03-20T11:19:02.958659668Z" level=error msg="'overlay' not found as a supported filesystem on this host. Please ensure kernel is new enough and has overlay support loaded." 

fügen Sie außerdem export DOCKER_HOST="tcp://localhost:2375" zum docker-build:

docker-build: 
    stage: package 
    script: 
    - export DOCKER_HOST="tcp://localhost:2375" 
    - docker build -t gitlab.my.com/group/app . 
    - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN gitlab.my.com/group/app 
    - docker push gitlab.my.com/group/app 

Answer 2

Wenn Sie Kubernetes verwenden, müssen Sie Ihr Build-Image anpassen, um eine Verbindung mit der Docker-Engine herzustellen.

In dem Build Bild:

DOCKER_HOST=tcp://localhost:2375 

Zitat aus der Dokumentation:

die Docker Lauf: Dind auch als Docker-in-Docker Bild bekannt ist auch möglich, aber leider Bedürfnisse die Container, die im privilegierten Modus ausgeführt werden sollen. Wenn Sie bereit sind, dieses Risiko einzugehen, werden andere Probleme auftreten, die nicht auf den ersten Blick so einfach erscheinen. Da der Andock-Dämon als Dienst normalerweise in Ihrem .gitlab-ci.yaml gestartet wird, wird er als separater Container in Ihrem Pod ausgeführt. Grundsätzlich teilen Container in Pods nur die ihnen zugewiesenen Volumes und eine IP-Adresse, über die sie sich mit localhost erreichen können. /var/run/docker.sock wird vom Andockfenster nicht gemeinsam genutzt: dind container und das Andockfenster versucht es standardmäßig zu verwenden. Um dies zu überschreiben und den Client dazu zu veranlassen, tcp zu kontaktieren, um den Andock-Daemon in dem anderen Container zu kontaktieren, müssen Sie DOCKER_HOST = tcp: // localhost: 2375 in Ihren Umgebungsvariablen des Build-Containers einschließen.

Gitlab-CI on Kubernetes