昨天写了使用 Dockerfile 定制镜像。其中构建上下文这一块没有写,今天把这一块单独拿出来写一下。

Docker镜像构建

简单说下构建镜像步骤:

  1. cd Dockerfile 所在目录;

  2. 执行 docker build 构建命令:

    docker build -t imageName:imageTag .

通过上面的工作流,很容易形成这样的理解误区:

  1. docker build 后面的 . 为 Dockerfile 所在的目录;
  2. Dockerfile 文件名 必须为 Dockerfile;

其实上面这种理解是错误的,要想准确理解其含义,首先我们需要先了解下 Docker 的架构和 docker build 的工作原理。

Docker架构

Docker 使用C/S (客户端/服务器)体系的架构,Docker 客户端与 Docker 守护进程通信,Docker 守护进程负责构建,运行和分发 Docker 容器。Docker 客户端和守护进程可以在同一个系统上运行,也可以将 Docker 客户端连接到远程 Docker 守护进程。Docker 客户端和守护进程使用 REST API 通过UNIX套接字或网络接口进行通信。

docker build 的工作原理

  1. Client端执行 docker build . 命令 ;
  2. Docker 客户端会将构建命令后面指定的路径(.)下的所有文件打包发送给 Docker 服务端;
  3. Docker 服务端收到客户端发送的包,然后解压,根据 Dockerfile 里面的指令进行镜像的分层构建;

镜像构建上下文(Context)

当我们进行镜像构建的时候,并非所有定制都会通过 RUN 指令完成,经常会需要将一些本地文件复制进镜像,比如通过 COPY 指令、ADD 指令等。而 docker build 命令构建镜像,其实并非在本地构建,而是在服务端,也就是 Docker 引擎中构建的。那么在这种客户端/服务端的架构中,如何才能让服务端获得本地文件呢?

这就引入了上下文的概念。当构建的时候,用户会指定构建镜像上下文的路径,docker build 命令得知这个路径后,会将路径下的所有内容打包,然后上传给 Docker 引擎。这样 Docker 引擎收到这个上下文包后,展开就会获得构建镜像所需的一切文件。如果在 Dockerfile 中这么写:

COPY ./package.json /app/

这并不是要复制执行 docker build 命令所在的目录下的 package.json,也不是复制 Dockerfile 所在目录下的 package.json,而是复制 上下文(context) 目录下的 package.json。

因此,COPY这类指令中的源文件的路径都是相对路径。这也是初学者经常会问的为什么 COPY ../package.json /app 或者 COPY /opt/xxxx /app 无法工作的原因,因为这些路径已经超出了上下文的范围,Docker 引擎无法获得这些位置的文件。如果真的需要那些文件,应该将它们复制到上下文目录中去。

示例1 :

[root@192 test]# ls
Dockerfile
[root@192 test]# cat Dockerfile
FROM alpine:latest
ADD /root/mydocker/apache-tomcat-9.0.27.tar.gz /data/soft
[root@192 test]# ls /root/mydocker/apache-tomcat-9.0.27.tar.gz
/root/mydocker/apache-tomcat-9.0.27.tar.gz
[root@192 test]# docker build .
Sending build context to Docker daemon 3.072kB
Step 1/2 : FROM alpine:latest
---> 965ea09ff2eb
Step 2/2 : ADD /root/mydocker/apache-tomcat-9.0.27.tar.gz /data/soft
ADD failed: stat /var/lib/docker/tmp/docker-builder904012777/root/mydocker/apache-tomcat-9.0.27.tar.gz: no such file or directory

可以看出:

  1. 镜像构建上下文路径并不是 Dockerfile文件所在的路径;
  2. Dockerfile 中指令的工作目录是服务端解压客户端传输包的路径,因为 ADD 指令失败了,意味着当前目录并没有 apache-tomcat 文件;

理解构建上下文对于镜像构建是很重要的,可以避免犯一些不应该的错误。比如有些初学者在发现 COPY /opt/xxxx /app 不工作后,于是干脆将 Dockerfile 放到了硬盘根目录去构建,结果发现 docker build 执行后,在发送一个几十 GB 的东西,极为缓慢而且很容易构建失败。那是因为这种做法是在让 docker build 打包整个硬盘,这显然是使用错误。

一般来说,应该会将 Dockerfile 置于一个空目录下,或者项目根目录下。如果该目录下没有所需文件,那么应该把所需文件复制一份过来。如果目录下有些东西确实不希望构建时传给 Docker 引擎,那么可以用 .gitignore 一样的语法写一个.dockerignore,该文件是用于剔除不需要作为上下文传递给 Docker 引擎的。

那么为什么会有人误以为 . 是指定 Dockerfile 所在目录呢?这是因为在默认情况下,如果不额外指定 Dockerfile 的话,会将上下文目录下的名为 Dockerfile 的文件作为 Dockerfile。

这只是默认行为,实际上 Dockerfile 的文件名并不要求必须为 Dockerfile,而且并不要求必须位于上下文目录中,比如可以用-f ../Dockerfile.php参数指定某个文件作为 Dockerfile。

当然,一般大家习惯性的会使用默认的文件名 Dockerfile,以及会将其置于镜像构建上下文目录中。

示例2

[root@192 test]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
tomcat jdk8-adoptopenjdk-hotspot 1a2bfb3e6eee 15 hours ago 318MB
openjdk 8-jre-slim d0cfe439ce3d 13 days ago 184MB
btnguyen2k/oraclejdk8_jre-alpine latest fab475620d00 4 years ago 208MB
[root@192 test]# cat ../mynginx/test
FROM alpine:latest
[root@192 test]# ls
apache-tomcat-9.0.27.tar.gz
[root@192 test]# docker build -f ../mynginx/test -t test:v1 .
Sending build context to Docker daemon 10.99MB
Step 1/1 : FROM alpine:latest
latest: Pulling from library/alpine
89d9c30c1d48: Already exists
Digest: sha256:c19173c5ada610a5989151111163d28a67368362762534d8a8121ce95cf2bd5a
Status: Downloaded newer image for alpine:latest
---> 965ea09ff2eb
Successfully built 965ea09ff2eb
Successfully tagged test:v1
[root@192 test]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
tomcat jdk8-adoptopenjdk-hotspot 1a2bfb3e6eee 15 hours ago 318MB
alpine latest 965ea09ff2eb 11 days ago 5.55MB
test v1 965ea09ff2eb 11 days ago 5.55MB
openjdk 8-jre-slim d0cfe439ce3d 13 days ago 184MB
btnguyen2k/oraclejdk8_jre-alpine latest fab475620d00 4 years ago 208MB

可以看出:

Dockerfile 的文件名并不要求必须为 Dockerfile,而且并不要求必须位于上下文目录中,比如可以用-f ../mynginx/test参数指定某个文件作为 Dockerfile。

Docker之构建上下文详解的更多相关文章

  1. 最佳实战Docker持续集成图文详解

    最佳实战Docker持续集成图文详解 这是一种真正的容器级的实现,这个带来的好处,不仅仅是效率的提升,更是一种变革:开发人员第一次真正为自己的代码负责——终于可以跳过运维和测试部门,自主维护运行环境( ...

  2. Docker Swarm 负载均衡详解 or 模式选择

    Docker Swarm 负载均衡详解 Swarm模式内置DNS组件,可以自动为集群中的每个服务分配DNS记录. Swarm manager使用内部负载均衡,根据服务的DNS名称在集群内的服务之间分发 ...

  3. Docker Swarm 高可用详解

    Docker Swarm 高可用详解 Manager管理节点宕机后其他管理节点仍然可以使用管理 intermal distributed state store:内部分布式状态存储同步共享到每个节点. ...

  4. jekins构建触发器详解

    jenkins版本:2.89.2 1.触发远程构建 (例如,使用脚本):通过一个网址的访问来触发构建,这样就不需要登录jenkins系统也能触发构建了. 示例地址: http://localhost: ...

  5. docker entrypoint入口文件详解

    docker entrypoint入口文件详解 pasting Dockerfile创建自定义Docker镜像以及CMD与ENTRYPOINT指令的比较 [k8s]args指令案例-彻底理解docke ...

  6. Docker:网络模式详解

    Docker作为目前最火的轻量级容器技术,牛逼的功能,如Docker的镜像管理,不足的地方网络方面. Docker自身的4种网络工作方式,和一些自定义网络模式 安装Docker时,它会自动创建三个网络 ...

  7. Docker基础 :网络配置详解

    本篇文章将讲述 Docker 的网络功能,包括使用端口映射机制来将容器内应用服务提供给外部网络,以及通过容器互联系统让多个容器之间进行快捷的网络通信,有兴趣的可以了解下. 大量的互联网应用服务包含多个 ...

  8. [P4基础]p4app的Docker镜像仓使用详解

    How to use the p4lang/p4app Docker image 本文参考 孙勇峰博客 和 p4app README 以及 p4app Dockerfile 结合自己的理解做一些记录, ...

  9. Docker Daemon 连接方式详解

    前言 在 Docker 常用详解指令 一文中粗粗提了一下, Docker 是分为客户端和服务端两部分的, 本文将介绍客户端是如何连接服务端的. 连接方式 1. UNIX域套接字 默认就是这种方式, 会 ...

随机推荐

  1. java架构之路-(SpringMVC篇)SpringMVC主要流程源码解析(上)源码执行流程

    做过web项目的小伙伴,对于SpringMVC,Struts2都是在熟悉不过了,再就是我们比较古老的servlet,我们先来复习一下我们的servlet生命周期. servlet生命周期 1)初始化阶 ...

  2. web前端之浏览器: 知识汇总

    一.URL到页面 准备阶段: 输入URL,Enter进入查找 浏览器在本地查找host文件,匹配对应的IP: 找到返回浏览器并缓存 没有,则进入路由查找: 找到返回浏览器并缓存 再没有,再进入公网DN ...

  3. 通俗易懂spring之singleton和prototype

    关于spring bean作用域,基于不同的容器,会有所不同,如BeanFactory和ApplicationContext容器就有所不同,在本篇文章,主要讲解基于ApplicationContext ...

  4. 写了那么多年 Java 代码,终于 debug 到 JVM 了

    继上篇文章 原创 | 全网最新最简单的 openjdk13 代码编译 之后,我们有了自己编译后的 jdk 和 hotspot,如下图所示.接下来就来干一番事情. 搭建调试环境 1.下载 CLion 软 ...

  5. TouchListener PK OnTouchEvent + 多点触碰

    1.基于监听的TouchListener 代码示例: 实现效果图: 实现代码: main.xml <RelativeLayout xmlns:android="http://schem ...

  6. WebGL简易教程(十一):纹理

    目录 1. 概述 2. 实例 2.1. 准备纹理 2.2. 配置纹理 2.3. 使用纹理 3. 结果 4. 参考 1. 概述 在之前的之前的教程<WebGL简易教程(九):综合实例:地形的绘制& ...

  7. Java8 Period.between方法坑及注意事项

    在使用Java8 新特性中关于Period.between的方法时需注意该方法获取日期的区间问题. @Test public void test1(){ LocalDate from = LocalD ...

  8. MySQL基础(四)常用函数

    转载自 http://blog.csdn.net/evankaka MySQL数据库中提供了很丰富的函数.MySQL函数包括数学函数.字符串函数.日期和时间函数.条件判断函数.系统信息函数.加密函数. ...

  9. 6个Linux运维典型问题,看大牛的分析解决思路

    问题1:文件系统破坏导致系统无法启动 Checking root filesystem /dev/sda6 contains a file system with errors, check forc ...

  10. 浑身尖刺的服务可用性守护者——hystrix熔断器实践记录

    netflix公司的产品hystrix(长满刺的豪猪),在高可用目标下具有一定熔断.限流.降级的作用.这里主要写一些自己在使用时的问题解决思路,原理请自行理解,包括线程池与信号量模式等. 注意三个参数 ...