Чому може користувач Jenkins не мати дозволу на доступ до сокета Docker unix?


9

Я додав 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

Однак під час складання / роботи Дженкінса вона не має дозволу:

# 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 з оболонки як користувач Дженкінса, я бачу, що вона знаходиться в групі докерів, але коли я запускаю id в роботі фрістайлу, вона показує лише користувача Jenkins. Я ще не придумав, як це виправити.
Джозеф Маллой

Спочатку переконайтеся, що у вас є користувач jenkins у групі докерів. Тоді якщо раб, у якого виникли проблеми, підключений до ведучого, відключіть його і знову підключіть його знову. Зробіть це через "керувати дженкінами" / "керувати вузлами".
озброєння

Відповіді:


12

Я думаю, що надання привілеїв групі jenkins до docker unix socket вирішує проблему. Це можна змінити, налаштувавши параметри запуску демона docker у файлі конфігурації, додавши цей рядок

DOCKER_OPTS=' -G jenkins'

У ubuntu /etc/default/docker- файл конфігурації докера.


Це все ще моє рішення про нові встановлення на Ubuntu 16.04
Lead_brogrammer

1

Виконайте groupsкоманду, використовуючи jenkins. Ви бачите dockerгрупу? Якщо ні, спробуйте перезавантажити цього раба Дженкінса. Або просто вбити процес раба Дженкінса.jar: ps aux | grep jenkins


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