Dlaczego użytkownik Jenkins może nie mieć uprawnień dostępu do gniazda unix Docker?


9

Dodałem jenkinsużytkownika do dockergrupy, myśląc, że pozwoli to zadaniom Jenkins na uruchamianie poleceń Dockera. Jeśli przejdę do jenkinsużytkownika, mogę sprawdzić, czy działa (ręcznie):

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

Jednak podczas kompilacji / zadania Jenkins nie ma pozwolenia:

# 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

Dotyczy to Docker 1.3.0 i Ubuntu 14.04.1. Jakieś wskazówki?


Wydaje się, że jest związany z tym problemem . Ponowne uruchomienie rozwiązało to dla mnie.
smilly92

Ponowne uruchomienie nie rozwiązało tego dla mnie.
Matt W

1
Wydaje się, że Jenkins opuszcza grupy inne niż główna grupa użytkownika Jenkins. Kiedy uruchamiam polecenie id z powłoki jako użytkownik Jenkins, widzę, że jest on w grupie dokerów, ale kiedy uruchamiam id w zadaniu freestyle, pokazuje tylko użytkownika Jenkins. Jeszcze nie wymyśliłem, jak to naprawić.
Joseph Mulloy

Najpierw upewnij się, że masz użytkownika Jenkins w grupie dokerów. Następnie jeśli slave, z którym masz problem, jest podłączony do mastera, odłącz go, a następnie podłącz ponownie. Zrób to za pomocą „manage jenkins” / „manage nodes”.
arminmor

Odpowiedzi:


12

Wydaje mi się, że przyznanie uprawnień grupy Jenkins gniazdu dokera unix rozwiązuje ten problem. Można to zmodyfikować, konfigurując opcje uruchamiania demona dokera w pliku konfiguracyjnym, dodając ten wiersz

DOCKER_OPTS=' -G jenkins'

W Ubuntu /etc/default/dockerjest plik konfiguracyjny dokera.


To wciąż moje rozwiązanie dla nowych instalacji na Ubuntu 16.04
lead_brogrammer

1

Uruchom groupspolecenie za pomocą Jenkins. Czy widzisz dockergrupę? Jeśli nie, spróbuj ponownie uruchomić niewolnika Jenkinsa. Lub po prostu zabij proces Jenkins slave.jar: ps aux | grep jenkins


Po wykonaniu kilku powyższych kroków ostatnim krokiem, aby go uruchomić, było ponowne podłączenie niewolnika Jenkinsa. Dzięki za wskazówkę.
Dean Poulin
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.