這是神馬情況？
我們檢查一下之前啟動方式的”/var/jenkins_home”目錄權限，查看Jenkins容器的當前用戶: 當前用戶是”jenkins”而且”/var/jenkins_home”目錄是屬于jenkins用戶擁有的
docker@default:~$ docker run -ti --rm --entrypoint="/bin/bash" jenkins -c "whoami && id"
jenkins
uid=1000(jenkins) gid=1000(jenkins) groups=1000(jenkins)
docker@default:~$ docker run -ti --rm --entrypoint="/bin/bash" jenkins -c "ls -la /var/jenkins_home"
total 20
drwxr-xr-x 2 jenkins jenkins 4096 Jun 5 08:39 .
drwxr-xr-x 28 root root 4096 May 24 16:43 ..
-rw-r--r-- 1 jenkins jenkins 220 Nov 12 2014 .bash_logout
-rw-r--r-- 1 jenkins jenkins 3515 Nov 12 2014 .bashrc
-rw-r--r-- 1 jenkins jenkins 675 Nov 12 2014 .profile
而當映射本地數據卷時，/var/jenkins_home目錄的擁有者變成了root用戶
docker run -ti --rm -v $(pwd)/data:/var/jenkins_home --entrypoint="/bin/bash" jenkins -c "ls -la /var/jenkins_home" total 4 drwxr-sr-x 2 root staff 40 Jun 5 08:32 . drwxr-xr-x 28 root root 4096 May 24 16:43 ..
這就解釋了為什么當”jenkins”用戶的進程訪問”/var/jenkins_home”目錄時，會出現 Permission denied 的問題
我們再檢查一下宿主機上的數據卷目錄，當前路徑下”data”目錄的擁有者是”root”，這是因為這個目錄是Docker進程缺省創建出來的。
docker@default:~$ ls -la data total 0 drwxr-sr-x 2 root staff 40 Jun 5 08:32 ./ drwxr-sr-x 5 docker staff 160 Jun 5 08:32 ../
發現問題之后，相應的解決方法也很簡單：把當前目錄的擁有者賦值給uid 1000，再啟動”jenkins”容器就一切正常了。
sudo chown -R 1000 data docker start jenkins
這時利用瀏覽器訪問 “http://192.168.99.100:8080/” 就可以看到Jenkins的Web界面了。注：如無法訪問，可能需要通過docker-machine ip命令獲得當前Docker宿主機的IP地址。
當我們再進入容器內部查看”/var/jenkins_home”目錄的權限，其擁有者已經變成 “jenkins”
docker@default:~$ docker exec jenkins ls -la /var/jenkins_home total 24 drwxr-sr-x 11 jenkins staff 340 Jun 5 09:00 . drwxr-xr-x 28 root root 4096 May 24 16:43 .. drwxr-sr-x 3 jenkins staff 60 Jun 5 08:59 .java -rw-r--r-- 1 jenkins staff 289 Jun 5 08:59 copy_reference_file.log ...
而有趣的是在宿主機上我們看到的 “data”目錄的擁有者是”docker”，這是因為”docker”用戶在”boot2docker”宿主機上的uid也是”1000″。
docker@default:~$ ls -la data total 20 drwxr-sr-x 2 docker staff 40 Jun 5 11:55 ./ drwxr-sr-x 6 docker staff 180 Jun 5 11:55 ../ ...
這時我們已經可以知道：容器的本地數據卷中文件/目錄的權限是和宿主機上一致的，只是uid/gid在Docker容器和宿主機中可能映射為不同的用戶/組名稱。
在上文，我們使用了一個常見的技巧，即在宿主機上執行chown命令時采用了uid而不是具體的用戶名，這樣就可以保證設置正確的擁有者。
問題雖然解決了，但思考并沒有結束。因為當使用本地數據卷時，Jenkins容器會依賴宿主機目錄權限的正確性，這會給自動化部署帶來額外的工作。有沒有方法讓Jenkins容器為數據卷自動地設置正確的權限呢？這個問題對很多以non-root方式運行的應用也都有借鑒意義。
為non-root應用正確地掛載本地數據卷
我們可以從萬能的stackoverflow.com找到很多相關的討論，其中一個非常有借鑒意義問答如下
http://stackoverflow.com/questions/23544282/what-is-the-best-way-to-manage-permissions-for-docker-shared-volumes
其中的基本思路有兩個：
一個是利用Data Container的方法在容器間共享數據卷。這樣就規避了解決宿主機上數據卷的權限問題。由于在1.9版本之后，Docker提供了named volume來取代純數據容器，我們還需要真正地解決這個問題。
另外一個思路就是讓容器中以root用戶啟動，在容器啟動腳本中利用”chown”命令來修正數據卷文件權限，之后切換到non-root用戶來執行程序
我們來參照第二個思路來解決這個問題
下面是一個基于Jenkins鏡像的Dockerfile：它會切換到”root”用戶并在鏡像中添加”gosu”命令，和新的入口點”/entrypoint.sh”
FROM jenkins:latest
USER root
RUN GOSU_SHA=5ec5d23079e94aea5f7ed92ee8a1a34bbf64c2d4053dadf383992908a2f9dc8a \
&& curl -sSL -o /usr/local/bin/gosu "https://github.com/tianon/gosu/releases/download/1.9/gosu-$(dpkg --print-architecture)" \
&& chmod +x /usr/local/bin/gosu \
&& echo "$GOSU_SHA /usr/local/bin/gosu" | sha256sum -c -
COPY entrypoint.sh /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
注釋：gosu 是經常出現在官方Docker鏡像中的一個小工具。它是”su”和”sudo”命令的輕量級替代品，并解決了它們在tty和信號傳遞中的一些問題。
新入口點的”entrypoint.sh”的內容如下：它會為”JENKINS_HOME”目錄設置”jenkins”的擁有權限，并且再利用”gosu”命令切換到”jenkins”用戶來執行”jenkins”應用。
#! /bin/bash set -e chown -R 1000 "$JENKINS_HOME" exec gosu jenkins /bin/tini -- /usr/local/bin/jenkins.sh
您可以直接從 https://github.com/denverdino/docker-jenkins 獲得相關代碼，并構建自己的Jenkins鏡像。執行命令如下：
git clone https://github.com/AliyunContainerService/docker-jenkins cd docker-jenkins/jenkins docker build -t denverdino/jenkins .
然后基于新鏡像啟動Jenkins容器
docker rm -f jenkins docker run -d -p 8080:8080 -p 50000:50000 -v $(pwd)/data:/var/jenkins_home --name jenkins denverdino/jenkins
