GitLab CI runner nie może połączyć się z unixem: ///var/run/docker.sock w kubernetes

Question

GitLab działa w klastrze kubernetes. Runner nie może zbudować obrazu dokowanego z artefaktami kompilacji. Próbowałem już rozwiązać kilka podejść, ale bez powodzenia. Oto kilka fragmentów configs:

.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 

Pakiet dziennika etap:

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 

Co robię źle?

Answer 1

nie trzeba korzystać z tego:

DOCKER_DRIVER: overlay 

przyczyną wydaje się, że nakładki nie jest obsługiwany, tak SVC-0 pojemnik jest w stanie rozpocząć z nim:

$ 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." 

również dodać export DOCKER_HOST="tcp://localhost:2375" do 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

Podczas korzystania z Kubernetes, musisz dostosować swój obraz Build, aby połączyć się z silnikiem Docker.

Dodaj do budowania obrazu:

DOCKER_HOST=tcp://localhost:2375 

cytat z docs:

Uruchamianie docker: dind znany również jako obraz doker-in-dokowanym jest również możliwe, ale niestety potrzebuje kontenery uruchamiane w trybie uprzywilejowanym. Jeśli chcesz podjąć to ryzyko, pojawią się inne problemy, które mogą na pierwszy rzut oka wydawać się proste. Ponieważ demon dokowania jest uruchamiany jako usługa zwykle w .gitlab-ci.yaml, będzie on uruchamiany jako oddzielny kontener w twoim bloku. Zasadniczo pojemniki w strąkach dzielą się tylko woluminami przypisanymi im do adresów IP i ich adresem IP, dzięki czemu mogą się nawzajem kontaktować za pomocą hosta lokalnego. /var/run/docker.sock nie jest udostępniany przez docker: kontener dind i docker plik binarny próbuje go używać domyślnie. Aby zastąpić to i sprawić, aby klient używał tcp do kontaktowania się z demonem dockera w drugim kontenerze, należy koniecznie uwzględnić DOCKER_HOST = tcp: // localhost: 2375 w zmiennych środowiskowych kontenera budowania.

Gitlab-CI on Kubernetes