zoukankan      html  css  js  c++  java
  • Dockerfile

    Dockerfile

    简述:

    Dockerfile 是一个文本文件,用来定制镜像,其内包含了一条条的指令(Instruction),每一条指令构建一层,因此每一条指令的内容,就是描述该层应当如何构建。
    镜像的定制实际上就是定制每一层所添加的配置、文件。如果我们可以把每一层修改、安装、构建、操作的命令都写入一个脚本,用这个脚本来构建、定制镜像,那么之前提及的无法重复的问题、镜像构建透明性的问题、体积的问题就都会解决。

    dockerfile命令

    FROM

    开头必须以FROM 开始,表示基于什么镜像,直接写镜像名比如:FROM redis
    即表示直接使用官方的redis latest镜像。如果没有实际内容建立一个空白镜像使用 FROM scrath,建立的就是一个虚拟的镜像,实际上它并不存在

    WORKDIR

    定义工作目录,不能使用cd dir的命令格式,应该使用WORKDIR dir
    注意:
    在 Shell 中,连续两行是同一个进程执行环境,因此前一个命令修改的内存状态,会直接影响后一个命令;而在 Dockerfile 中,这两行 RUN 命令的执行环境根本不同,是两个完全不同的容器,每一个 RUN 都是启动一个容器、执行命令、然后提交存储层文件变更。上一层的执行仅仅是当前进程的工作目录变更,一个内存上的变化而已,其结果不会造成任何文件变更。而到第二层的时候,启动的是一个全新的容器,跟第一层的容器更完全没关系,自然不可能继承前一层构建过程中的内存变化。

    RUN

    RUN 指令是用来执行命令行命令的,格式有两种:

    • shell 格式:RUN <命令>,就像直接在命令行中输入的命令一样
      ---eg :RUN echo '<h1>Hello, Docker!</h1>' > /usr/share/nginx/html/index.html
    • exec 格式:RUN ["可执行文件", "参数1", "参数2"],这更像是函数调用中的格式。

    run命令的规范格式

    Dockerfile 中每一个指令都会建立一层,RUN 也不例外。每一个 RUN 的行为,就和刚才我们手工建立镜像的过程一样:新建立一层,在其上执行这些命令,执行结束后,commit 这一层的修改,构成新的镜像。所以应当避免直接像以下格式的run构建命令

    FROM debian:jessie
    
    RUN apt-get update
    RUN apt-get install -y gcc libc6-dev make
    RUN wget -O redis.tar.gz "http://download.redis.io/releases/redis-3.2.5.tar.gz"
    RUN mkdir -p /usr/src/redis
    RUN tar -xzf redis.tar.gz -C /usr/src/redis --strip-components=1
    RUN make -C /usr/src/redis
    RUN make -C /usr/src/redis install
    

    这种写法,创建了 7 层镜像。这是完全没有意义的,而且很多运行时不需要的东西,都被装进了镜像里,比如编译环境、更新的软件包等等。结果就是产生非常臃肿、非常多层的镜像,不仅仅增加了构建部署的时间,也很容易出错。
    Union FS 是有最大层数限制的,比如 AUFS,曾经是最大不得超过 42 层,现在是不得超过 127 层。

    Dockerfile 正确的写法应该是这样:

    FROM debian:jessie
    
    RUN buildDeps='gcc libc6-dev make' 
        && apt-get update 
        && apt-get install -y $buildDeps 
        && wget -O redis.tar.gz "http://download.redis.io/releases/redis-3.2.5.tar.gz" 
        && mkdir -p /usr/src/redis 
        && tar -xzf redis.tar.gz -C /usr/src/redis --strip-components=1 
        && make -C /usr/src/redis 
        && make -C /usr/src/redis install 
        && rm -rf /var/lib/apt/lists/* 
        && rm redis.tar.gz 
        && rm -r /usr/src/redis 
        && apt-get purge -y --auto-remove $buildDeps
    

    首先,之前所有的命令只有一个目的,就是编译、安装 redis 可执行文件。因此没有必要建立很多层,这只是一层的事情。因此,这里没有使用很多个 RUN 对一一对应不同的命令,而是仅仅使用一个 RUN 指令,并使用 && 将各个所需命令串联起来。将之前的 7 层,简化为了 1 层。在撰写 Dockerfile 的时候,要经常提醒自己,这并不是在写 Shell 脚本,而是在定义每一层该如何构建。

    并且,这里为了格式化还进行了换行。Dockerfile 支持 Shell 类的行尾添加 的命令换行方式,以及行首 # 进行注释的格式。良好的格式,比如换行、缩进、注释等,会让维护、排障更为容易,这是一个比较好的习惯。

    此外,还可以看到这一组命令的最后添加了清理工作的命令,删除了为了编译构建所需要的软件,清理了所有下载、展开的文件,并且还清理了 apt 缓存文件。这是很重要的一步,我们之前说过,镜像是多层存储,每一层的东西并不会在下一层被删除,会一直跟随着镜像。因此镜像构建时,一定要确保每一层只添加真正需要添加的东西,任何无关的东西都应该清理掉。

    很多人初学 Docker 制作出了很臃肿的镜像的原因之一,就是忘记了每一层构建的最后一定要清理掉无关文件

    build

    更具dockerfile来构建镜像,即生成自己dockerfile中自定义的镜像

    docker build 的工作原理:

    Docker 在运行时分为 Docker 引擎(也就是服务端守护进程)和客户端工具。Docker 的引擎提供了一组 REST API,被称为 Docker Remote API,而如 docker 命令这样的客户端工具,则是通过这组 API 与 Docker 引擎交互,从而完成各种功能。因此,虽然表面上我们好像是在本机执行各种 docker 功能,但实际上,一切都是使用的远程调用形式在服务端(Docker 引擎)完成。也因为这种 C/S 设计,让我们操作远程服务器的 Docker 引擎变得轻而易举。
    docker的结构如图:docker server daemon

    context

    context即docker build的上下文,docker在buil时会将上下文中所有依赖的文件和包打包发给server(其实docker的server就是一个守护进程即上图中的内核部分),发送过去后的位置即docker的上下文
    一般来说,应该会将 Dockerfile 置于一个空目录下,或者项目根目录下。如果该目录下没有所需文件,那么应该把所需文件复制一份过来。如果目录下有些东西确实不希望构建时传给 Docker 引擎,
    那么可以用 .gitignore 一样的语法写一个 .dockerignore,该文件是用于剔除不需要作为上下文传递给 Docker 引擎的。
    那么为什么会有人误以为 . 是指定 Dockerfile 所在目录呢?这是因为在默认情况下,如果不额外指定 Dockerfile 的话,会将上下文目录下的名为 Dockerfile 的文件作为 Dockerfile。
    这只是默认行为,实际上 Dockerfile 的文件名并不要求必须为 Dockerfile,而且并不要求必须位于上下文目录中,比如可以用 -f ../Dockerfile.php 参数指定某个文件作为 Dockerfile。
    当然,一般大家习惯性的会使用默认的文件名 Dockerfile,以及会将其置于镜像构建上下文目录中。

    命令
    docker build [-optin] <镜像名>
    注意:镜像名都要使用服务端IP:端口/镜像名的格式来命令镜像名
    eg:docker build -t myshop .

    COPY and ADD

    COPY

    格式:

    • 命令行格式:COPY <源路径>... <目标路径>
    • 函数格式:COPY ["<源路径1>",... "<目标路径>"]

    COPY 指令将从构建上下文目录中 <源路径> 的文件/目录复制到新的一层的镜像内的 <目标路径> 位置。<源路径> 可以是多个,甚至可以是通配符,其通配符规则要满足 Go 的 filepath.Match 规则,比如:

    COPY hom* /mydir/
    COPY hom?.txt /mydir/
    

    <目标路径> 可以是容器内的绝对路径,也可以是相对于工作目录的相对路径(工作目录可以用 WORKDIR 指令来指定)。目标路径不需要事先创建,如果目录不存在会在复制文件前先行创建缺失目录。
    此外,还需要注意一点,使用 COPY 指令,源文件的各种元数据都会保留。比如读、写、执行权限、文件变更时间等。这个特性对于镜像定制很有用。特别是构建相关文件都在使用 Git 进行管理的时候。

    ADD

    ADD 指令和 COPY 的格式和性质基本一致。但是在 COPY 基础上增加了一些功能。
    比如 <源路径> 可以是一个 URL,这种情况下,Docker 引擎会试图去下载这个链接的文件放到 <目标路径> 去。如果 <源路径> 为一个 tar 压缩文件的话,压缩格式为 gzip, bzip2 以及 xz 的情况下,ADD 指令将会自动解压缩这个压缩文件到 <目标路径> 去。
    下载后的文件权限自动设置为 600,如果这并不是想要的权限,那么还需要增加额外的一层 RUN 进行权限调整,另外,如果下载的是个压缩包,需要解压缩,也一样还需要额外的一层 RUN 指令进行解压缩。
    所以不如直接使用 RUN 指令,然后使用 wget 或者 curl 工具下载,处理权限、解压缩、然后清理无用文件更合理。因此,这个功能其实并不实用,而且不推荐使用。仅在需要拷贝tar,gzip包并主动解压的情况下使用ADD命令,其他拷贝都使用COPY命令

    EXPOSE

    暴露端口,将容器内的端口暴露出来,当直接使用(docker run -P <镜像名>)-P参数时,随机分配端口时就会将你在dockerfile中expose的端口分配给宿主机随机映射的端口。

    CMD

    shell 格式:CMD <命令>
    exec 格式:CMD ["可执行文件", "参数1", "参数2"...]
    参数列表格式:CMD ["参数1", "参数2"...]。在指定了 ENTRYPOINT 指令后,用 CMD 指定具体的参数。
    之前介绍容器的时候曾经说过,Docker 不是虚拟机,容器就是进程。既然是进程,那么在启动容器的时候,需要指定所运行的程序及参数。CMD 指令就是用于指定默认的容器主进程的启动命令的。

    本博客为Swagger-Ranger的笔记分享,文中源码地址: https://github.com/Swagger-Ranger
    欢迎交流指正,如有侵权请联系作者确认删除: liufei32@outlook.com

  • 相关阅读:
    MCU开发之I2C通信
    hibernate特殊的映射
    Hibernate使用
    css设置让a标签充满整个li
    margin
    border属性
    列表
    链接样式
    相机内参外参
    tmux
  • 原文地址:https://www.cnblogs.com/Swagger-Ranger/p/10670022.html
Copyright © 2011-2022 走看看