Почему пользователь Jenkins не может получить доступ к Unix-сокету Docker?


9

Я добавил jenkinsпользователя в dockerгруппу, полагая, что это позволит заданиям Jenkins запускать команды Docker. Если я переключаюсь на jenkinsпользователя, я могу убедиться, что он работает (вручную):

ubuntu@hostname:~$ ps aux | grep java
jenkins   2210  9.5  7.5 1950316 292896 ?      Sl   00:01   1:00 /usr/bin/java -jar /data/jenkins/jenkins-1.586.war --httpPort=8080 -Xloggc:/var/log/jenkins/gc.log
ubuntu@hostname:~$ getent group docker
docker:x:999:jenkins
ubuntu@hostname:~$ ls -la /var/run/docker.*
-rw-r--r-- 1 root root   4 Oct 23 18:32 /var/run/docker.pid
srw-rw---- 1 root docker 0 Oct 23 18:32 /var/run/docker.sock
ubuntu@hostname:~$ sudo su -s /bin/bash jenkins
jenkins@hostname:/home/ubuntu$ docker ps
CONTAINER ID        IMAGE                      COMMAND                CREATED             STATUS              PORTS                     NAMES

Однако во время сборки / задания Jenkins у него нет разрешения:

# Job log
Started by user Matt Wright
Building on master in workspace /data/jenkins/jobs/docker-base-images-build/workspace
[ssh-agent] Using credentials CI-jenkins
[ssh-agent] Looking for ssh-agent implementation...
[ssh-agent]   Java/JNR ssh-agent
[ssh-agent] Started.
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git@github.com:<redacted>/docker-base-images.git # timeout=10
Fetching upstream changes from git@github.com:<redacted>/docker-base-images.git
 > git --version # timeout=10
using GIT_SSH to set credentials 
 > git fetch --tags --progress git@github.com:<redacted>/docker-base-images.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 83c4463e7195b412a3a803dd7338210c1a772f55 (refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 83c4463e7195b412a3a803dd7338210c1a772f55
 > git rev-list 83c4463e7195b412a3a803dd7338210c1a772f55 # timeout=10
[workspace] $ /bin/sh -xe /tmp/hudson5606381166745886966.sh
+ ./build.sh
Sending build context to Docker daemon 
2014/10/24 16:14:18 Post http:///var/run/docker.sock/v1.15/build?rm=1&t=<redacted>%2Fpython%3A3.4: dial unix /var/run/docker.sock: permission denied
Build step 'Execute shell' marked build as failure
[ssh-agent] Stopped.
Notifying upstream projects of job completion
Finished: FAILURE

Это с Docker 1.3.0 и Ubuntu 14.04.1. Есть какие-нибудь подсказки?


Кажется, связано с этой проблемой . Перезагрузка решила это для меня.
smilly92

Перезагрузка не помогла мне.
Мэтт W

1
Казалось бы, Дженкинс отбрасывает группы, отличные от основной группы пользователя Дженкинса. Когда я запускаю команду id из оболочки как пользователь Jenkins, я вижу, что она входит в группу docker, но когда я запускаю id в вольном задании, он показывает только пользователя Jenkins. Я еще не понял, как это исправить.
Джозеф Маллой

Сначала убедитесь, что у вас есть пользователь jenkins в группе Docker. Затем, если ведомый, с которым у вас возникли проблемы, подключен к главному устройству, отключите его, а затем снова подключите. Сделайте это через «Управление Дженкинсом» / «Управление узлами».
arminmor

Ответы:


12

Я думаю, что решение проблемы с предоставлением групповых привилегий jenkins для сокетов Docker Unix. Это можно изменить, настроив параметры запуска демона docker в файле конфигурации, добавив эту строку

DOCKER_OPTS=' -G jenkins'

В Ubuntu /etc/default/dockerесть файл конфигурации докера.


Это все еще мое решение для новых установок в Ubuntu 16.04
lead_brogrammer

1

Запустите groupsкоманду, используя Дженкинс. Вы видите dockerгруппу? Если нет, попробуйте перезагрузить этого раба Дженкинса. Или просто убейте процесс Jenkin slave.jar: ps aux | grep jenkins


Выполнив несколько шагов, описанных выше, последняя часть, которая заработала, состояла в том, чтобы восстановить соединение раба Дженкинса. Спасибо за совет.
Дин Пулин
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.