Docker之构建上下文详解
昨天写了使用 Dockerfile 定制镜像。其中构建上下文这一块没有写,今天把这一块单独拿出来写一下。
Docker镜像构建
简单说下构建镜像步骤:
cd Dockerfile 所在目录;
执行 docker build 构建命令:
docker build -t imageName:imageTag .
通过上面的工作流,很容易形成这样的理解误区:
- docker build 后面的 . 为 Dockerfile 所在的目录;
- Dockerfile 文件名 必须为 Dockerfile;
其实上面这种理解是错误的,要想准确理解其含义,首先我们需要先了解下 Docker 的架构和 docker build 的工作原理。
Docker架构
Docker 使用C/S (客户端/服务器)体系的架构,Docker 客户端与 Docker 守护进程通信,Docker 守护进程负责构建,运行和分发 Docker 容器。Docker 客户端和守护进程可以在同一个系统上运行,也可以将 Docker 客户端连接到远程 Docker 守护进程。Docker 客户端和守护进程使用 REST API 通过UNIX套接字或网络接口进行通信。
docker build 的工作原理
- Client端执行 docker build . 命令 ;
- Docker 客户端会将构建命令后面指定的路径(.)下的所有文件打包发送给 Docker 服务端;
- 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
可以看出:
- 镜像构建上下文路径并不是 Dockerfile文件所在的路径;
- 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之构建上下文详解的更多相关文章
- 最佳实战Docker持续集成图文详解
最佳实战Docker持续集成图文详解 这是一种真正的容器级的实现,这个带来的好处,不仅仅是效率的提升,更是一种变革:开发人员第一次真正为自己的代码负责——终于可以跳过运维和测试部门,自主维护运行环境( ...
- Docker Swarm 负载均衡详解 or 模式选择
Docker Swarm 负载均衡详解 Swarm模式内置DNS组件,可以自动为集群中的每个服务分配DNS记录. Swarm manager使用内部负载均衡,根据服务的DNS名称在集群内的服务之间分发 ...
- Docker Swarm 高可用详解
Docker Swarm 高可用详解 Manager管理节点宕机后其他管理节点仍然可以使用管理 intermal distributed state store:内部分布式状态存储同步共享到每个节点. ...
- jekins构建触发器详解
jenkins版本:2.89.2 1.触发远程构建 (例如,使用脚本):通过一个网址的访问来触发构建,这样就不需要登录jenkins系统也能触发构建了. 示例地址: http://localhost: ...
- docker entrypoint入口文件详解
docker entrypoint入口文件详解 pasting Dockerfile创建自定义Docker镜像以及CMD与ENTRYPOINT指令的比较 [k8s]args指令案例-彻底理解docke ...
- Docker:网络模式详解
Docker作为目前最火的轻量级容器技术,牛逼的功能,如Docker的镜像管理,不足的地方网络方面. Docker自身的4种网络工作方式,和一些自定义网络模式 安装Docker时,它会自动创建三个网络 ...
- Docker基础 :网络配置详解
本篇文章将讲述 Docker 的网络功能,包括使用端口映射机制来将容器内应用服务提供给外部网络,以及通过容器互联系统让多个容器之间进行快捷的网络通信,有兴趣的可以了解下. 大量的互联网应用服务包含多个 ...
- [P4基础]p4app的Docker镜像仓使用详解
How to use the p4lang/p4app Docker image 本文参考 孙勇峰博客 和 p4app README 以及 p4app Dockerfile 结合自己的理解做一些记录, ...
- Docker Daemon 连接方式详解
前言 在 Docker 常用详解指令 一文中粗粗提了一下, Docker 是分为客户端和服务端两部分的, 本文将介绍客户端是如何连接服务端的. 连接方式 1. UNIX域套接字 默认就是这种方式, 会 ...
随机推荐
- Java诊断利器Arthas
1 简介 Arthas 是Alibaba开源的Java诊断工具,深受开发者喜爱 当你遇到以下类似问题而束手无策时,Arthas可以帮助你解决: 这个类从哪个 jar 包加载的?为什么会报各种类相关的 ...
- [Python] Python 学习记录(1)
1.概论 弱类型 一个变量能被赋值时能与原类型不同 x = 1 x = "1" #不加分号,给x赋值为int后再次赋值为string是可行的 与或非 and or not / ...
- SpringBoot系列:Spring Boot使用模板引擎Thymeleaf
一.Java模板引擎 模板引擎(这里特指用于Web开发的模板引擎)是为了使用户界面与业务数据(内容)分离而产生的,它可以生成特定格式的文档,用于网站的模板引擎就会生成一个标准的HTML文档. 在jav ...
- ASRWGAN: Wasserstein Generative Adversarial Network for Audio Super Resolution
ASEGAN:WGAN音频超分辨率 这篇文章并不具有权威性,因为没有发表,说不定是外国的某个大学的毕业设计,或者课程结束后的作业.或者实验报告. CS230: Deep Learning, Sprin ...
- js通过方法返回对象的注意点
问题:js通过方法返回一个字面量对象和返回一个提前已经定义好的字面量对象有区别吗? 答案:有 我们先来看看第一种情况,fun1方法返回一个提前没定义的字面量对象,然后通过调用方法返回三个对象,分别是o ...
- 移动端网页常用meta
今天在对前公司的某直播室前端进行改版时,整理了一下平时移动端页面开发时,最常用的meta.如下: <!--定义页面制作者,可以留姓名,也可以留联系方式--> <meta name=& ...
- 基于 Web 端 3D 地铁站可视化系统
前言 工业互联网,物联网,可视化等名词在我们现在信息化的大背景下已经是耳熟能详,日常生活的交通,出行,吃穿等可能都可以用信息化的方式来为我们表达,在传统的可视化监控领域,一般都是基于 Web SCAD ...
- [NOIp2011] luogu P1314 聪明的质监员
题目描述 点进去看吧,说的不能再清楚了. Solution 看到数据规模不难想到二分 WWW,然后用个前缀和优化一下即可.注意上下界. #include<cstdio> #include& ...
- [JZOJ5185] 【NOIP2017提高组模拟6.30】tty's sequence
Description
- 【Spring Cloud】服务容错保护:Hystrix(四)
一.雪崩效应 在微服务架构中,由于服务和服务之间可以互相调用,一项工作的完成可能会依赖调用多个微服务模块,但由于网络原因或者自身的原因,服务并不能保证100%可用,如果单个服务出现问题,调用这个服务就 ...