Docker-Context-低调大师

Docker-Context

2019-03-14 632

在 Docker-Dockerfile入门 - 1 中我们提到了build中.的作用，当时说的是代表当前目录其实说的并不准确具体，我们今天来说一下这个问题，如果理解不对请指正
之前提到了Docker context ，那么这到底是个什么东西，有什么作用，在 <>中大致意思是这样解释的：

表面在本机执行docker build，但是其实是有一个docker daemon在运行的，所以你所执行的命令与产生的结果都是与docker服务交互后的结果，这是一种C/S架构的东西，所以构建其实并非是在本地执行，而是在服务端完成的
所以我们指定了.这个上下文路径后，docker会根据这个上下文路径来去构建镜像，我们来测试一下

首先最简单的构建操作如下

[qidai@qidai-pc cc]$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
nginx               latest              881bd08c0b08        9 days ago          109MB
ubuntu              latest              47b19964fb50        5 weeks ago         88.1MB
centos              latest              1e1148e4cc2c        3 months ago        202MB
[qidai@qidai-pc cc]$ tree .
.
└── file
0 directories, 1 file
[qidai@qidai-pc cc]$ docker build -t x:x -f file .
Sending build context to Docker daemon  2.048kB
Step 1/2 : FROM nginx
 ---> 881bd08c0b08
Step 2/2 : RUN touch succ /
 ---> Running in a57757a928f2
Removing intermediate container a57757a928f2
 ---> 8ce68f7c4572
Successfully built 8ce68f7c4572
Successfully tagged x:x

tree：linux命令，列出当前目录结构
同时我们也知道了用来构建的文件不一定是叫Dockerfile，Dockerfile只是docker的默认文件名而已

刚才为docker指定了上下文，为.，这时候docker知道这个路径后， docker会将这个目录下的所有东西打包上传到服务端，然后进行解析构建
现在我们全部用错误的构建来说明docker的context路径问题，

先说一下 -f 参数的问题

构建如下

[qidai@qidai-pc cc]$ cd ..
[qidai@qidai-pc test]$ tree .
.
└── cc
    └── file
1 directory, 1 file
[qidai@qidai-pc test]$ docker build -t s:s -f cc/file .
Sending build context to Docker daemon   2.56kB
Step 1/2 : FROM nginx
 ---> 881bd08c0b08
Step 2/2 : RUN touch succ /
 ---> Running in ef1fa8e3bb07
Removing intermediate container ef1fa8e3bb07
 ---> 416623a1c3f7
Successfully built 416623a1c3f7
Successfully tagged s:s

更改构建路径

[qidai@qidai-pc test]$ docker build -f s:s -f cc/nofile .
unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /run/media/qidai/_yingpan/test/cc/nofile: no such file or directory
[qidai@qidai-pc test]$ docker build -t s:s -f cc .
Sending build context to Docker daemon   2.56kB
Error response from daemon: unexpected error reading Dockerfile: read /var/lib/docker/tmp/docker-builder684771877/cc: is a directory

如上我们就很清楚了，首先-f参数指定的Dockerfile的具体路径在本地是必须存在的，这个无可质疑，如果本地都不存在那么本地的机器就会跟你爆出不存在的错误，其次那就是本地存在，而且本地不报错了，这就通过过了第一步的本地审查，所以就打包上传到docker服务器，在服务器中解析，发现cc并不是具体的构建文件的路径，所以会给你再次报错，我们从两次的报错中的路径也可以看出来，/run/media是本地检查，而/var/lib/tmp/...是docker的检查

然后我们在说一下后面的.的问题

构建如下

[qidai@qidai-pc cc]$ cd ..
[qidai@qidai-pc test]$ tree .
.
└── cc
    └── file
1 directory, 1 file
[qidai@qidai-pc test]$ docker build -t s:s -f cc/file .
Sending build context to Docker daemon   2.56kB
Step 1/2 : FROM nginx
 ---> 881bd08c0b08
Step 2/2 : RUN touch succ /
 ---> Running in ef1fa8e3bb07
Removing intermediate container ef1fa8e3bb07
 ---> 416623a1c3f7
Successfully built 416623a1c3f7
Successfully tagged s:s

更改构建路径

[qidai@qidai-pc test]$ docker build -t s:s -f cc/file cc
Sending build context to Docker daemon  2.048kB
Step 1/2 : FROM nginx
 ---> 881bd08c0b08
Step 2/2 : RUN touch succ /
 ---> Using cache
 ---> 416623a1c3f7
Successfully built 416623a1c3f7
Successfully tagged s:s
[qidai@qidai-pc test]$ docker build -t s:s -f cc/  cc
Sending build context to Docker daemon  2.048kB
Error response from daemon: unexpected error reading Dockerfile: read /var/lib/docker/tmp/docker-builder657763113: is a directory

如上，我们给出的context路径其实是上传后的服务器的相对路径，当给出的context为cc的时候，那么docker就会在context_path/cc/ 下去找构建文件，这时候会根据-f参数去找构建文件，然后开始构建，而上面第二次构建就不行了，依旧传入的context为cc，然后根据-f找构建文件，但是-f并没有具体指定文件，所以构建失败

当然也可以指定本机的绝对路径为docker的context路径，如下

[qidai@qidai-pc test]$ docker build -t s:s -f cc/file .
Sending build context to Docker daemon   2.56kB
Step 1/1 : FROM nginx
 ---> 881bd08c0b08
Successfully built 881bd08c0b08
Successfully tagged s:s
[qidai@qidai-pc test]$ pwd
/run/media/qidai/_yingpan/test
[qidai@qidai-pc test]$ docker build -t s:s -f cc/file /run/media/qidai/_yingpan/test
Sending build context to Docker daemon   2.56kB
Step 1/1 : FROM nginx
 ---> 881bd08c0b08
Successfully built 881bd08c0b08
Successfully tagged s:s

知道了路径问题后，我们再来看一下Dockerfile中的文件问题，拿COPY指令来说

构建文件内容如下
```
FROM nginx
COPY cc/file /file.bak
```

构建过程

[qidai@qidai-pc test]$ tree .
.
└── cc
    └── file
1 directory, 1 file
[qidai@qidai-pc test]$ docker build -t a:a -f cc/file .
Sending build context to Docker daemon   2.56kB
Step 1/2 : FROM nginx
 ---> 881bd08c0b08
Step 2/2 : COPY cc/file /file.bak
 ---> 9b5b8bcc0246
Successfully built 9b5b8bcc0246
Successfully tagged a:a

如果我们将COPY的源目的地址改一下呢？，如下

[qidai@qidai-pc test]$ touch /home/qidai/tempFile   #本机新建一个文件
[qidai@qidai-pc test]$ cat cc/file
FROM nginx
COPY /home/qidai/tempFile /file.bak  #想法是将本机内的指定文件复制到容器
[qidai@qidai-pc test]$ docker build -t s:s -f cc/file .
Sending build context to Docker daemon   2.56kB
Step 1/2 : FROM nginx
 ---> 881bd08c0b08
Step 2/2 : COPY /home/qidai/tempFile /file.bak
COPY failed: stat /var/lib/docker/tmp/docker-builder527470065/home/qidai/tempFile: no such file or directory

如上我们就可以看到了，构建文件中也是应用的是context的相对路径，所以想将我们的文件复制到容器内只能是将文件放入我们指定的context目录下（COPY 和 ADD 命令不能拷贝上下文之外的本地文件）

下面是我自己画的一张图，更直观的展示了Docker命令和目录路径之间的关联，如果有异议请评论指出，谢谢

微信关注我们

原文链接：https://yq.aliyun.com/articles/693777

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

不要自建Kubernetes

这是“如何高效使用云服务”系列文章的首篇分享。可能有朋友好奇为什么不是从云计算最基础的服务--计算资源ECS/EC2讲起呢？在Cloud Native已经被越来越接受的今天，基于Kubernetes部署、编排应用的方式已经是业界的事实标准。无论是互联网巨头，传统500强企业，还是创业团队都在使用或规划使用Kubernetes作为应用程序的自动化部署、可扩展管理平台。在云计算平台，虚拟机越来越不需要单独的管理，在绝大多数的业务场景下，它们只是作为容器集群所管理的计算资源。甚至虚拟机的创建到销毁整个生命周期管理都可以由Kubernetes根据集群的负载来自动完成。所有主流的云计算厂商都在解决方案中力推托管的Kubernetes，AWS的EKS，Azure上的AKS，当然少不了Google家GCP上的Kubernetes Engine。国内阿里云，腾讯云等每一个公有云玩家也都基于开源Kubernetes推出了托管服务。如果一家云计算厂商在提供托管Kubernetes这一服务上没跟上业界的步伐，将来极大可能被淘汰出这个市场。托管的Kubernetes类型以国内的阿里云为例，目前提供了两大...

2019-03-15

712

一、需求分析当前kubernetes集群中的worker节点可以支持添加多可用区中的ECS，这种部署方式的目的是可以让一个应用的多个pod（至少两个）能够分布在不同的可用区，起码不能分布在同一个可用区，已达到高可用或者同城灾备的部署。二、效果图三、实现原理为了实现上述的效果，kubernetes提供了pod的亲和性和反亲和性来保证pod在节点级别，可用区级别的高可用部署；具体的值为topologyKey：failure-domain.beta.kubernetes.io/zone。四、实现步骤在ACK上创建完集群后，不论从哪个可用区添加节点，都会对该节点打上对应的可用区标签，比如，一个节点是属于北京可用区a的，那么在加入到kubernetes集群后，该节点上会有一个这样的标签：

2019-03-15

673

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

Docker-Context

不要自建Kubernetes

Pod在多可用区worker节点上的高可用部署

相关文章

发表评论

资源下载

Mario

腾讯云软件源

Nacos

Sublime Text

欢迎您来访！