Pourquoi l'utilisateur Jenkins pourrait-il ne pas être autorisé à accéder au socket Docker Unix?

J'ai ajouté l' jenkinsutilisateur au dockergroupe en pensant qu'il permettrait aux travaux Jenkins d'exécuter les commandes Docker. Si je passe à l' jenkinsutilisateur, je peux vérifier que cela fonctionne (manuellement):

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

Cependant, lors d'une build / job Jenkins, il n'a pas l'autorisation:

# 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

C'est avec Docker 1.3.0 et Ubuntu 14.04.1. Des indices?

— Matt W
source

Semble lié à ce problème . Le redémarrage a résolu cela pour moi.

— smilly92

Le redémarrage n'a pas résolu ce problème pour moi.

— Matt W

Il semblerait que Jenkins supprime des groupes autres que le groupe principal de l'utilisateur Jenkins. Lorsque j'exécute la commande id à partir d'un shell en tant qu'utilisateur Jenkins, je vois qu'elle se trouve dans le groupe docker, mais lorsque j'exécute id dans un travail de style libre, elle ne montre que l'utilisateur Jenkins. Je n'ai pas encore trouvé de solution.

— Joseph Mulloy

Assurez-vous d'abord d'avoir l'utilisateur jenkins dans le groupe docker. Ensuite, si l'esclave avec lequel vous rencontrez des problèmes est connecté au maître, déconnectez-le puis reconnectez-le à nouveau. Pour ce faire, utilisez «gérer jenkins» / «gérer les nœuds».

— arminmor

Je pense que donner des privilèges de groupe jenkins au socket docker unix résout le problème. Cela peut être modifié avec la configuration des options de démarrage du démon docker dans le fichier de configuration en ajoutant cette ligne

DOCKER_OPTS=' -G jenkins'

Dans ubuntu se /etc/default/dockertrouve le fichier de configuration du docker.

— eldos
source

C'est toujours ma solution

— préférée

Exécutez la groupscommande à l'aide de jenkins. Voyez-vous un dockergroupe? Sinon, essayez de redémarrer cet esclave Jenkins. Ou tout simplement tuer le processus Jenkins slave.jar: ps aux | grep jenkins

— Vanuan
source

Après avoir fait quelques-unes des étapes ci-dessus, la dernière pièce pour le faire fonctionner était de reconnecter l'esclave Jenkins. Merci pour le conseil.

— Dean Poulin