Docker相关知识点(五) [DockerFile]

• 当我们前面学习Docker的时候,我们每一次完善的容器需求,都需要很多行Docker命令才能完成
• 而DockerFile是用来构建Docker镜像的文本文件,是由一条条构建镜像所需的指令和参数构成的自动化脚本,我们可以通过DockerFile基于基础镜像,充实基础镜像,将该镜像打造成我们所需要的镜像,供我们后续的使用.
  
  官网介绍: Docker官方文档

• 编写DockerFile文件
• docker build命令构建镜像
• docker run 依赖镜像运行容器实例

• FROM`：基础镜像，当前新镜像是基于哪个镜像的，指定一个已经存在的镜像作为模板，第一条必须是from

• MAINTAINER：镜像维护者的姓名和邮箱地址

• RUN：容器构建时需要运行的命令，有以下两种格式

  • shell格式

    RUN <命令行命令》
    # <命令行命令> 等同于，在终端操作的shell命令
    

  • exec格式

    RUN ["可执行文件","参数","参数2"]
    # 例如：
    # RUN ["./test.php","dev","offline"]等价于 RUN ./test.php dev offline
    

  • RUN是在docker build时运行的

• EXPOST：当前容器对外暴露的端口

• WORDDIR：指定在创建容器后，终端默认登录进来的工作目录，一个落脚点

• USER：指定该镜像以什么样的用户取执行，如果都不执行，默认为root

• ENV：用来在构建过程中指定环境变量

• ADD：将宿主机目录下的文件拷贝进镜像且会自动处理URL和解压tar压缩包

• COPY：类似ADD，拷贝文件和目录到镜像中，将从构建上下文目录中的<源路径>的文件/目录复制到新的一层的镜像内的<目标目录>位置

  • COPY src dest
  • COPY[“src”,"dest]
  • ：容器内的指定路径，该路径不用实现建好。路径不存在的话，会自动创建。

• VOLUME：容器数据卷，用于数据保存和持久化工作

• CMD：指定容器启动后的要干的事

  • 一个DockerFile中会有很多个CMD命令，但是只有最后一个CMD命令将会生效，CMD会被docker run 之后携带的参数替换掉

• ENTRYPOINT：指定容器启动后要干的事

  • 和CMD的区别在于：ENTRYPOINT不会被docker run 命令后携带的参数替换，而且这些命令行参数会被当作参数送给ENTRYPOINT指令指定的程序
    

• docker build命令会从一个DockerFile文件和context来构建镜像.构建的上下文是指定位置的文件集PATH或URL.这个PATH是本地文件系统上的目录,URL是一个Git存储库位置.
• 构建上下文是递归处理的,因此,PATH包括任何子目录,并且URL包括存储库以及子模块.

  docker build .
  

  • 上述示例显示了一个使用当前目录(.)作为构建上下文的构建命令.
  • 构建由Docker守护程序来运行,而不是由CLI运行.构建过程所做的第一件事就是将整个上下文文档(递归)发送给守护进程,最好从一个空目录作为上下文执行,并将DockerFIle保存在该目录中.仅添加构建DockerFile所需的文件.
  • 不要将根目录“/”用作PATH构建上下文,因为这会导致构建过程会将整个硬盘驱动器的全部内容传输给Docker守护线程
  • 要在构建上下文中使用文件,DockerFile指的是在指令中指定的文件,例如COPY指令.若要提高构建的性能,可以通过将.dockerignore文件添加到上下文目录中来排除文件和目录.dockerignore具体使用请参照官网教程: dockerignore help Doc
  • 当Dockerfile被调用时Dockerfile位于上下文的根中.我们可以使用-f 标志 docker build 命令来指向文件系统中任何位置的Dockerfile.

  docker build -f /path/to/a/Dockerfile
  

  • 如果构建成功,我们可以指定保存的新镜像的存储库和标记(Tag)

  docker build -t shykes/myapp
  

  • 倘若我们要在构建后将镜像标记到多个存储库中,我们也可以在运行命令-t后添加多个存储库和标记
  • 在Docker 守护进程执行 运行Dockerfile指令之前.它会对Dockerfile进行一次初步的验证,如果Dockerfile语法不正确,则会返回错误信息
  • Docker的守护进程会一条一条的执行Dockerfile中的指令,必要时,会将Dockerfile文件中的每一条指令的执行结果commit成一个新的镜像.最终返回一个新镜像的ID,Docker守护进程会自动清理我们发送的context上下文.
  • 每条指令都是独立运行的，并会创建一个新图像 - 因此RUN cd /tmp不会对下一条指令产生任何影响。
  • 只要有可能，Docker 就会使用构建缓存来docker build 显着加速该过程。这由CACHED控制台输出中的消息指示。

• DockerFile内容基础知识
  • 每条保留字指令都必须为大写字母,并且后面要跟随至少一个参数
  • 指令按照从上到下,顺序执行
  • #: 井号表示注释
  • 每条指令都会创建一个新的镜像并对镜像进行提交
• DockerFile执行流程大致如下:
  • Docker会从基础镜像中实例化一个容器,后续操作基于该容器进行操作的
  • 会逐条执行DockerFile中的命令,充实基础镜像相关功能
  • 然后执行Commit命令,提交成一个新的镜像
  • 然后,DockerFile会重新将这个新的镜像实例化成一个新的容器,后续操作基于该容器进行操作
  • 最后,执行DockerFile中的下一条指令,直到所有的指令都执行完成

虚悬镜像(dangling images)

• 什么是虚悬镜像
  • 仓库名、标记(TAG)都为的镜像,俗称虚悬镜像(dangling images)
• 虚悬镜像是怎么出现的呢?
  • 场景：当我们从Docker远程仓库中pull下来一个镜像（例如 jdk1.8），这时，该镜像作者又重新发布了一个新的jdk1.8镜像，该镜像中修复了一些BUG，这时，我们需要重新pull下来该镜像，旧的jdk1.8镜像名会被新的镜像名所取代，旧的镜像名和TAG标签都为，我们就称该旧镜像为虚悬镜像
• 如果出现虚悬镜像,我们应该怎么做呢?
• 虚悬镜像已经失去了使用的价值,我们需要对虚悬镜像进行删除操作
  • 可以使用docker image prune命令查看本地images中是否含有虚悬镜像，使用docker rmi 镜像ID来删除虚悬镜像
    
    我的docker中没有虚悬镜像,所以,删除的大小为0B