Docker-Context

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

    表面在本机执行docker build,但是其实是有一个docker daemon在运行的,所以你所执行的命令与产生的结果都是与docker服务交互后的结果,这是一种C/S架构的东西,所以构建其实并非是在本地执行,而是在服务端完成的

  3. 所以我们指定了.这个上下文路径后,docker会根据这个上下文路径来去构建镜像,我们来测试一下
  4. 首先最简单的构建操作如下

    [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的默认文件名而已
  5. 刚才为docker指定了上下文,为.,这时候docker知道这个路径后, docker会将这个目录下的所有东西打包上传到服务端,然后进行解析构建
  6. 现在我们全部用错误的构建来说明docker的context路径问题,
  7. 先说一下 -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的检查
  8. 然后我们在说一下后面的.的问题

    • 构建如下

      [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
  9. 知道了路径问题后,我们再来看一下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目录下(COPYADD 命令不能拷贝上下文之外的本地文件)
  10. 下面是我自己画的一张图,更直观的展示了Docker命令和目录路径之间的关联,如果有异议请评论指出,谢谢

markdown_img_paste_20190315141029959

目录
相关文章
|
网络协议
用 ipv6 和端口号发起 http 请求
用 ipv6 和端口号发起 http 请求
|
网络协议 网络架构
内网IP 外网IP 网卡 路由器通信过程(全)
       这几天上了计算机网络的课,对于老师讲的内容也是懵懵懂懂,一个慌神就没跟上,啥ip 啥NAT一脸蒙蔽。课后oogle补了点东西算是大致有了点了解,不过网上的总结都是零零散散而且点到即止。
5371 0
|
开发工具 git Windows
经验:停止 cherry-pick,请开始 merge!
cherry-pick 是一个比较常用的 git 操作,可以将一个分支上的 commit “精选”到另一个分支上。然而在最近的开发过程中,却时不时的遇到 merge 冲突。在下文中,我将会详细的分析 cherry-pick 造成冲突的原因,以及 cherry-pick 可能造成的其他更严重问题。
8022 0
经验:停止 cherry-pick,请开始 merge!
|
8月前
|
人工智能 API 开发工具
GitHub官方开源MCP服务!GitHub MCP Server:无缝集成GitHub API,实现Git流程完全自动化
GitHub MCP Server是基于Model Context Protocol的服务器工具,提供与GitHub API的无缝集成,支持自动化处理问题、Pull Request和仓库管理等功能。
1659 2
GitHub官方开源MCP服务!GitHub MCP Server:无缝集成GitHub API,实现Git流程完全自动化
|
8月前
|
传感器 人工智能 边缘计算
AI赋能油田巡检——无人机视频监控系统的技术解析
无人机油田巡检系统融合无人机硬件与AI视频监控技术,实现全域覆盖、智能分析和高效管理。通过多旋翼/固定翼无人机搭载高分辨率摄像头及传感器,采集多维数据;结合YOLOv9等算法进行异常检测,准确率高达98%。系统支持5G实时传输、边缘计算及集中化管理平台,提供可视化监控与预测性维护。基于开源框架设计,灵活扩展且成本低,大幅提升油田巡检效率与安全性。
855 0
|
Web App开发
如何设置谷歌浏览器在新窗口中打开链接?如何设置谷歌浏览器在新标签页中打开链接?
一、快捷键方式:  1、左键单击 ==》 在当前窗口中打开目标网页。  2、Shift + 左键单击 ==》 在新窗口中打开目标网页。  3、Ctrl + 左键单击 ==》 在新标签页中打开目标网页。  4、鼠标中键点击书签即打开新的标签页,在新的标签页中显示指定的网页。
59758 0
|
消息中间件 负载均衡 Kafka
Kafka分区分配策略大揭秘:RoundRobin、Range、Sticky,你真的了解它们吗?
【8月更文挑战第24天】Kafka是一款突出高吞吐量、可扩展性和数据持久性的分布式流处理平台。其核心特性之一是分区分配策略,对于实现系统的负载均衡和高可用性至关重要。Kafka支持三种主要的分区分配策略:RoundRobin(轮询)、Range(范围)和Sticky(粘性)。RoundRobin策略通过轮询方式均衡分配分区;Range策略根据主题分区数和消费者数量分配;而Sticky策略则在保持原有分配的基础上动态调整,以确保各消费者负载均衡。理解这些策略有助于优化Kafka性能并满足不同业务场景需求。
1190 59
|
Java
@Max和@Min注解失效
Springboot 2.3及以上版本不再内置hibernate-validator 6.0.13.Final添加上述依赖可解决。
447 3
|
安全 网络架构
|
域名解析 搜索推荐 Apache
服务器301重定向详细教程
301重定向是一种HTTP状态码,用于指示网页已永久移至新位置,对SEO和用户体验至关重要。本文详解了301重定向的作用,包括提升搜索引擎排名和自动引导用户访问新URL。同时介绍了多种设置方法,如通过网站控制面板、Apache的mod_rewrite模块、IIS的URL重写模块等,并提醒注意新URL的准备、链接更新及流量监控。合理设置301重定向有助于网站平稳过渡和长期发展。
1828 7