Dokcerfile中的USER root无法处理COPY进来的文件

昨天的问题没有解决也没有思路所以就停下了。今天继续来解决，目标稍作修改，仍然是修改COPY文件的owner为jenkins以便jenkins对其操作。

问题描述

• Dockerfile中执行COPY
• 然后使用USER装换用户为root
• 此时删除copy进来的文件
• 发现无论如何都无法删除
• 然而root身份进入容器就可随意删除

解决思路

• Q1:是否是因为USER指令出现问题，下面RUN的运行者并不是root？

• A1:我去官网查询了USER这个指令的使用方式,以下对USER功能补充

  USER 可以设置UID和GID，并且可以保证USER之后的CMD以及RUN、ENTRYPOINT这些指令都是USER设置的用户在执行。

  这样看来不是USER的问题，为了验证，我在RUN中添加了whoami指令Dockerfile如下：

  RUN whoami && rm -rf /var/jenkins_home/jobs/test
  
  

  但是whoami的执行结果确实是root。

---

• Q2:既然我们确定删除操作确实是root执行的，光从容器中还能看到这个文件，就能证明rm操作没有执行？到打容器阶段，我们已经经历了镜像的创建和运行，这其中难道没有问题？
• A2:我尝试在RUN中继续添加指令RUN whoami && rm -rf jobs/test && ls jobs以证实是否rm操作曾经成功过。发现结果跟我想的一样，ls log后发现目录下面确实没有test了，RUN的时候确实已经成功删除了。

---

• Q3:那么为什么RUN之后的镜像和我们容器的运行的镜像会不同呢？
• A3:重新打开Dockerfile之后

  FROM jenkins:2.60.2
  WORKDIR /var/jenkins_home
  COPY ./jenkinsConfig/jobs jobs
  USER root
  RUN  whoami && rm -rf jobs/test 
  USER jenkins
  

  发现最后有一个转回jenkins用户的操作。我去了最后一句，发现容器中仍然还有jobs/test。就算RUN是最后一条指令，但是容器和Dockerfile的镜像仍然不一样。之前知道有layer这个概念。现在怀疑最后创建的镜像其实是RUN之前的镜像。这里补充些知识：

  镜像层，Dockerfile中的每一条指令，我们都可以创建一个镜像层，并且将这个镜像层docker commit而最终我们运行的容器就是最后一层镜像层

---

Q4:是否可以说明最后我们使用的是USER root commit的镜像层？
A4:现在只能说明最后RUN产生的镜像层没有作为最后的运行镜像层，但是为什么这样，我查了很多资料，真的解释不了了。。已经咨询了老师，现在只能问问有经验的人了~

反思

• 把这个问题挖到现在这个深度，才发现我竟然从来都没有了解过这个镜像层的概念。说明自己在潜意识里更注重的是如何使用，好像只要能用就行但是都没想过去了解他的内容基础概念，还是学东西太急于求成，目标性太强。一旦当我涉及的深度到某种程度，就会有太多我想不通也解决不了的问题。还是what没有做好。

action

• 为了建立系统性的学习。我决定通过看书的方式。每天给自己至少两个小时的时间看书，并且固定读书时间，到时间立刻放下手里的事情看书。提高阅读速度。争取做到一个月一本书。