问题目标
- 自动化实现jenkins container的初始化。包含初始化jenkins job、plugins、slave node 等等
问题描述
- 我们采用官网推荐的方式，将job的config.xml、jenkins所需要的插件（由于AWS下载插件速度过慢）、以及node 的config.xml均使用docker cp的方式从容器外部copy到容器内
/var/jenkins_home下的对应文件 - 当使用docker cp将插件和job都放在容器中的正确位置之后，打开jenkins GUI发现没有一个job被load。
思路
- Q1:为什么明明在容器中的
~/jobs/下面存放了一个test job，却在GUI上看不到这个job？ - A1:表象是GUI上看不见这个test job，真实的是这个job没有被创建，既然创建失败，必然会有log信息。因此
docker logs jenkins -f发现果然报错,报出错误java.io.IOException: Failed to create a temporary file in /var/jenkins_home/jobs/test/builds Caused by: java.io.IOException: Permission denied错误信息很明显说是没有办法在/var/jenkins_home/jobs/test下创建builds文件
- Q2:为什么没有办法在
/var/jenkins_home/jobs/test下创建builds文件？ - A2:看到permission denied可以反应过来，肯定是test文件夹下不能创建文件。那么我们进入容器查看test文件夹的权限，发现权限很奇怪
drwxr-xr-x 3 501 dialout 4096 Aug 17 10:11 test,那么说明我现在需要一个写权限，通过使用whoami发现当前用户是jenkins，发现文件夹确实没有给jenkins写权限，那么不如直接chmod修改权限,但是jenkins用户没有chmod的权限。只好重新cp 一份权限是775 的test文件夹。发现依旧不能创建文件。
- Q3:为什么权限改成755这时候我已经给jenkins用户分配了写的权限为什么还是不能创建文件呢？
- A3:因为好奇去查看的Linux文件权限，才发现自己对文件权限的理解一直是错的。我一直以为
drwxr-xr-x 3 501 dialout 4096 Aug 17 10:11 test第一组rwx是分给root用户的，第二组是给jenkins的，第三组是给其他人的，所以理解完全错误。用一张图给出正解：
image.png
因此说明此时jenkins并不是501用户，他只有最后一组权限。所以我尝试重新再次修改权限为757docker cp。此是GUI可以看到这个job了，但是不能构建，构建就会立刻报错
No such file: /var/jenkins_home/jobs/test/builds/2/log进入容器发现builds文件夹存在但是没有2文件夹
- Q4:既然没有/builds/2/log文件能说明builds文件夹jenkins也没有创建文件的权限对吗？这样改下去什么真的很痛苦，有没有别的办法？
- A4:查看build之后发现确实没有权限创建文件。想起胡老师说尽量不要改权限，可以采用让当前用户cp一份这个文件，那么jenkins用户就拥有了对文件的所有权限了。这时候，在容器中使用jenkins用户在jobs 下cp test test1 。restart之后发现可以test1 job并且可以构建。
- Q5:问题解决，突然想起来看到的test文件的owner竟然是501，是什么鬼？为什么使用docker cp进来的文件权限如此奇怪？
- A5:经过查阅Linux知识发现：每个用户其实有对应的UID number（比如root UIDnumber是0），而UID是501的用户是admin。并且查阅官网后发现使用docker cp将文件从容器外cpoy到容器内文件owner会变成root--->files copied to a container are created with UID:GID of the root user.
反思
- Linux基础知识实在太差。
action
- 以后每天至少总结一条Linux基础知识，不可以间断
