linuxea:如何单单修改docker容器的系统时间 一般情况下，我们仅仅需要修改容器的时间与我们宿主机的实际实际一致即可，我们知道，默认情况下docker容器是不允许访问系统时钟，但是有一款开源的软件使这样的需求变成了可能。此lib拦截用于检索当前时间和日期的所有系统调用，完成了容器内时间的修改。阅读此篇文章，你将了解在容器内修改时间的方法。使用以alpine为例，我们进行编译安装，并挑选几个简单的使用方法来进行演示这个时间调整git clone https://github.com/wolfcw/libfaketime.git cd libfaketime/src make install他的使用非常简单，只需要设置环境变量即可，如下bash-4.4$ date Fri Mar 8 15:17:52 CST 2019修改天数bash-4.4$ LD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1 FAKETIME="-2d"bash-4.4$ date Wed Mar 6 15:28:03 CST 2019修改分钟bash-4.4$ LD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1 FAKETIME="-70m"bash-4.4$ date Fri Mar 8 14:18:45 CST 2019虚拟时间的默认规范是缓存的，时间为10秒钟FAKETIME_NO_CACHE =1是禁用缓存，但这可能带来性能影响嵌入docker基础镜像中使用此前的基础镜像。在启动脚本中添加TIME_OFFSET变量，顺便修改启动容器进程的id和用户名#!/bin/bash ######################################################################### # File Name: entrypoint.sh # Author: www.linuxea.com # Created Time: Tue 05 Mar 2019 03:59:05 PM CST ######################################################################### USER_ID=${USER_ID:-1101} USER_NAME=${USER_NAME:-www} TIME_OFFSET=${TIME_OFFSET:-FAKETIME_NO_CACHE=1 FAKETIME=""} echo "Starting with UID : $USER_ID And user $USER_NAME" addgroup --gid $USER_ID $USER_NAME adduser -u $USER_ID -S -H -s /bin/bash -g $USER_NAME -G $USER_NAME $USER_NAME -D # useradd --shell /bin/bash -u $USER_ID -o -c "" -m user export HOME=/home/$USER_NAME export LD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1 $TIME_OFFSET exec /usr/local/bin/gosu $USER_NAME "$@"这样以来，在下次启动的时候，传递环境变量就达到了修改容器时间的办法我将次镜像构建为marksugar/alpine:3.9-time-gosu，你可以下载进行使用[root@linuxea.com /opt/2019/djd/jj]# docker build -t marksugar/alpine:3.9-time-gosu .现在我们进行测试这个时间修改挂载/etc/localtime让容器时间与机器时间一致，而后在进行传递$TIME_OFFSET修改时间的偏移量docker run \ --rm \ -v /etc/localtime:/etc/localtime \ -e TIME_OFFSET=FAKETIME="-10m" \ -e USER_ID=1101 \ -e USER_NAME=linuxea.com \ -it marksugar/alpine:3.9-time-gosu \ date +%F" "%T我们先取出时间[root@linuxea.com ~]# date +%F" "%T 2019-03-08 15:54:11而后修改分钟，减去10分钟，-10m[root@linuxea.com ~]# docker run \ > --rm \ > -v /etc/localtime:/etc/localtime \ > -e TIME_OFFSET=FAKETIME="-10m" \ > -e USER_ID=1101 \ > -e USER_NAME=linuxea.com \ > -it marksugar/alpine:3.9-time-gosu \ > date +%F" "%T Starting with UID : 1101 And user linuxea.com 2019-03-08 15:44:16时间从2019-03-08 15:54:11变成2019-03-08 15:44:16修改天数，减去3天，-3d[root@linuxea.com ~]# docker run \ > --rm \ > -v /etc/localtime:/etc/localtime \ > -e TIME_OFFSET=FAKETIME="-3d" \ > -e USER_ID=1101 \ > -e USER_NAME=linuxea.com \ > -it marksugar/alpine:3.9-time-gosu \ > date +%F" "%T Starting with UID : 1101 And user linuxea.com 2019-03-05 15:57:43或者这样docker run \ --rm \ -v /etc/localtime:/etc/localtime \ -e TIME_OFFSET=FAKETIME="-10m" \ -e USER_ID=1101 \ -e USER_NAME=linuxea.com \ -it marksugar/alpine:3.9-time-gosu \ date +%F" "%TFAKETIME_NO_CACHE=1[root@DT_Node-172_17_0_1 ~]# date +%F" "%T 2019-03-08 16:03:18[root@DT_Node-172_17_0_1 ~]# docker run \ > --rm \ > -v /etc/localtime:/etc/localtime \ > -e TIME_OFFSET="FAKETIME_NO_CACHE=1 FAKETIME="-10m"" \ > -e USER_ID=1101 \ > -e USER_NAME=linuxea.com \ > -it marksugar/alpine:3.9-time-gosu \ > date +%F" "%T Starting with UID : 1101 And user linuxea.com 2019-03-08 15:53:18更多阅读linuxea:docker卷和文件系统权限linuxea:docker容器中程序不应该以root用户身份运行linuxea:变量实值与文件变量替换学习更多学习如何使用Docker CLI命令，Dockerfile命令，使用这些命令可以帮助你更有效地使用Docker应用程序。查看Docker文档和我的其他帖子以了解更多信息。docker目录白话容器docker-compose

linuxea:Docker多阶段构建与- target和--cache-from 在这篇文章中，我描述了在无法提供任何层缓存的无服务器主机上构建时，我如何提高容器的构建性能。我使用多阶段构建和远程存储库缓存的组合来避免重复性工作来提高性能。阅读本篇，你将了解--target的使用和--cache-from的使用，更好理解多阶段构建和缓存的利用。我将会在文章末尾放置多阶段构建使用的本站链接note使用--target来构建多级建立的特定阶段，并推动这些镜像传输到远程存储库。在后续构建中，拉出这些镜像并使用作为构建缓存--cache-from我们先来看，一个普通的构建脚本## 镜像版本号 DOCKER_IMAGE_VERSION=20190305_addpjp ## 构建镜像 docker build \ -t marksugar/test:$DOCKER_IMAGE_VERSION \ -t marksugar/test:latest \ -f "./Dockerfile" \ "." ## 推送到仓库 docker push marksugar/test:$DOCKER_IMAGE_VERSION docker push marksugar/test:latest 此bash脚本基于Dockerfile构建docker镜像，使用特定的版本号$DOCKER_IMAGE_VERSION和latest标记镜像tag，而后推送到仓库中，完成构建过程。事实上我们在实际生产中的构建脚本远比这要复杂的多。为此，学习利用--target和--cache-from能提高时间效益--target创建多阶段构建时候，可以为每个构建阶段提供名称，例如，我此刻命名的createfile和linuxea，分别在(准备阶段createfile和最终阶段linuxea)：FROM marksugar/alpine:3.9-time-gosu as createfile MAINTAINER www.linuxea.com LABEL maintainer="www.linuxea.com" RUN mkdir /data/ && touch /hello.txt WORKDIR /data FROM marksugar/go:alpine-go1.12 as linuxea MAINTAINER www.linuxea.com LABEL maintainer="www.linuxea.com" COPY linuxea.go /data/linuxea.go WORKDIR /data CMD ["go","run","linuxea.go"] COPY --from=createfile /data/ .通过阶段的名称，可以在后续中引用，并且复制到最后的容器中。为了更好的解释这个，我们还是进行一次构建docker build -t test:1 .并运行[root@linuxea.com /opt/2019/djd/go/go2]# docker run -d -p:1818:8080 test:1 01e07ddc26daf94bc57ddc7d61d5cbe0f530c85792e045126dc501e67e047ac8运行正常，可以被访问[root@linuxea.com /opt/2019/djd/go/go2]# curl 127.0.0.1:8080 20190303 欢迎来到 www.linuxea.com但是，这仅仅只是多阶段构建。此刻，我只想构建其中一个阶段，--target就派上用途了。只构建某个阶段，如linuxea或者createfile，并不全部构建只构建linux的阶段[root@linuxea.com /opt/2019/djd/go/go2]# docker build --target linuxea -t test:linuxea -f "$PWD/Dockerfile" "." [root@linuxea.com /opt/2019/djd/go/go2]# docker run --rm -it test:1 bash Starting with UID : 1101 And user www bash-4.4$ ls linuxea.go bash-4.4$ 只构建createfile阶段[root@linuxea.com /opt/2019/djd/go/go2]# docker build --target createfile -t test:2 -f "$PWD/Dockerfile" "." [root@linuxea.com /opt/2019/djd/go/go2]# docker run --rm -it test:2 bash Starting with UID : 1101 And user www bash-4.4$ pwd /data bash-4.4$ ls /hello.txt /hello.txt如上所示中，两个阶段的构建结果仅限于Dockerfile中的多阶段构建的名称下的内容。我们在往下看。--cache-from默认情况下，在构建Docker镜像时，Docker使用它的构建缓存来检查它是否可以跳过Dockerfile中的任何步骤。该--cache-from参数告诉docker，可用缓存的镜像是什么。如果提供的镜像和当前版本具有相同的图层，则可以获得与在同一台计算机上构建镜像时以相同层构建出更快的速度。例如，简单地想象我们没有使用多阶段构建，因此推送到远程存储库的最终镜像包含所有构建层。不使用--cache-from我们的构建脚本总是必须执行Dockerfile中的每个命令，因为构建缓存将为空：docker build -t marksugar/test:01相反，我们可以--cache-from结合使用docker pull，大概如下：docker pull IMAGES1 || true docker build \ --cache-from IMAGES1 \ -t IMAGE2:Version \ -t IMAGE2:latest \ -f "PATH/Dockefile" \ "." docker push IMAGES2:latest docker push IMAGES2:Version为了更好的测试，我们手动进行build两个镜像做一个简单的测试第一个DockerfileFROM marksugar/alpine:3.9-time-gosu as createfile MAINTAINER www.linuxea.com LABEL maintainer="www.linuxea.com" RUN apk add nginx php RUN mkdir -p /data/wwwroot WORKDIR /data/wwwrootdocker build marksugar/test:01第二个Dockerfile在第二个dockerfile中，我们主要看两层，如下：RUN apk add nginx php RUN mkdir -p /data/wwwrootDockerfile。在dockerfile中的这两层与上一个dockerfile的层是相同的FROM marksugar/alpine:3.9-time-gosu MAINTAINER www.linuxea.com LABEL maintainer="www.linuxea.com" RUN apk add nginx php RUN mkdir -p /data/wwwroot RUN echo '\n\ server {\n\ listen 1080;\n \ root /data/wwwroot;\n \ index index.html;\n \ }\n'\ >> /etc/nginx/conf.d/default.conf \ && echo "hello www.linuxea.com" >> /data/wwwroot/index.html WORKDIR /data/wwwroot CMD ["nginx","-g","'daemon off;'"]builddocker build \ --cache-from marksugar/test:01 \ -t marksugar/test:02 \ -f "$PWD/Dockerfile" \ "."如下：[root@linuxea.com /opt/2019/djd/go/go3]# docker build --cache-from marksugar/test:01 -t marksugar/test:02 -f "$PWD/Dockerfile" "." Sending build context to Docker daemon 2.048kB Step 1/8 : FROM marksugar/alpine:3.9-time-gosu ---> 69cd7c6d7a86 Step 2/8 : MAINTAINER www.linuxea.com ---> Using cache ---> 45e40729aaae Step 3/8 : LABEL maintainer="www.linuxea.com" ---> Using cache ---> 5f10b4ec6e3e Step 4/8 : RUN apk add nginx php ---> Using cache ---> 0fd71721e8ff Step 5/8 : RUN mkdir -p /data/wwwroot ---> Using cache ---> 07066ac12068 Step 6/8 : RUN echo '\nserver {\n listen 1080;\n root /data/wwwroot;\n index index.html;\n }\n'>> /etc/nginx/conf.d/default.conf && echo "hello www.linuxea.com" >> /data/wwwroot/index.html ---> Running in 1aaa3449af16 Removing intermediate container 1aaa3449af16 ---> 434c3dee5d37 Step 7/8 : WORKDIR /data/wwwroot ---> Running in 2ed3ce787ab0 Removing intermediate container 2ed3ce787ab0 ---> 078644925acb Step 8/8 : CMD ["nginx","-g","'daemon off;'"] ---> Running in 065aa5b66fe8 Removing intermediate container 065aa5b66fe8 ---> 81adb261a754 Successfully built 81adb261a754 Successfully tagged marksugar/test:02我们在来对比一下层，你会发现这俩个镜像对于上述相同的RUN命令层，公用一个ID，这将减少我们的构建时间如果你的最终构建的镜像包含所有的docker构建层，这个简单的方法很有效。但在多阶段中可能会出现问题，我们可以使用--target和--cache-from一起使用--target And --cache-from倘若此时，在多构建的基础之上，我们需要重新构建准备阶段和最终的运行阶段我们可能使用这种方式，如下：DOCKER_IMAGE_VERSION=VERSION # 拉取最新的镜像 docker pull marksugar/base:1 || true # 使用最新拉取的镜像作为缓存层 docker build \ --target builder \ --cache-from marksugar/base:1 \ -t marksugar/base:1 \ -f "path/Dockerfile" \ "." # 在拉一个最终的镜像 docker pull marksugar/web:latest || true # 不指定target（构建整个Dockerfile） ＃ 使用刚构建的构建器镜像和拉出的运行时候镜像作为缓存 docker build \ --cache-from marksugar/base:1 \ --cache-from marksuagr/Web:latest \ -t marksugar/web:$DOCKER_IMAGE_VERSION \ -t marksugar/Web:latest \ -f "path/Dockerfile" \ "." # 重新推送 docker push marksugar/Web:$DOCKER_IMAGE_VERSION docker push marskugar/Web:latest docker push marksugar/base:1延伸阅读linuxea:Distroless与多阶段构建linuxea:docker多阶段构建Multi-Stage与Builder对比总结学习更多学习如何使用Docker CLI命令，Dockerfile命令，使用这些命令可以帮助你更有效地使用Docker应用程序。查看Docker文档和我的其他帖子以了解更多信息。docker目录白话容器docker-compose

linuxea:缩减docker镜像大小的5个步骤 docker容器的应用程序易于部署管理是基于docker镜像，一个优良的docker镜像是非常有必要的。在多数情况下，我们处于无状态应用的快速部署，这个过程中，且不管你在dockerhub使用还是本地镜像仓库使用，合理的镜像的大小也是有必要的。除此之外，我们应该考虑那些？Docker镜像大小的重要性？网络带宽导致的空闲等待除了镜像大小外，我们还需要考虑更新迭代的问题，更大的基础镜像意味着需要更多的开发时间。这里必然少不了网络带宽的问题，上传下载的等待时间问题。磁盘空间问题当然，镜像大小不单单影响了上传下载操作人员等待的时间。如果你留意过磁盘的使用，你会发现磁盘空间也是一个非常吃紧的事情。安全问题事实上，磁盘并不会耗费太多的金钱。在内网来讲，带宽也不是一个特别大的问题。更多的需要注意的是容器的安全性的问题。太大的镜像往往意味着有更大的攻击面缩减镜像5个步骤在开始之前，我想复述一个重要的问题：你应该妥善考虑将要部署的应用的语言，框架，扩展，工具和第三方包。因为所有安装的内容都会增加镜像大小，docker镜像只需要运行应用所需的环境足以，其他的能少尽量的减少。安装适合的依赖工具包对于从0构建来说，生产的镜像仅仅配置有必要的程序以来包，对于一些不必要的包应该全部删除。如：curl,wget等等。更小的基础镜像假如你要从0开始构建，通常，常见的基础镜像是ubuntu和centos以及debian，除此之外，我们可以考虑使用alpine，alpine的大小仅仅只有5M。使用alpine减小了镜像的大小，但是alpine和centos，debian有一定的差别如果你之是运行一个python程序，或者php程序，你应该考虑使用官方的镜像，比如 : ptyhon:2.7-alpine3.8，这仅仅几十兆。你可以进行自己构建，假如你掌握了这些知识更少的层docker的层也决定了镜像的大小，我们应该尽可能的使用更少的层来构建。更少的层可能意味着更少的dockerfile命令，比如run命令，阅读dockerfile中的RUN指令对镜像大小的影响有助于你深入了解。同时，在很多时候，更少的层解决不了过于繁琐复杂的镜像构建，这时候就需要多阶段构建来解决。使用.dockerignore文件.dockerignore在构建的时候，控制构建的上下文中的内容，对一些内容进行忽略，从而达到想要的预期效果。对于一些特别不需要的文件这特别有用，你可以参考linuxea:docker不能忽视的.dockerignore用法深入了解压缩镜像docker-squash最后一个方式是压缩镜像，docker-squash是一个实用程序，用于将多个层压缩成一个，以便创建具有更少和更小层的镜像。它保留了Dockerfile命令，如PORT，ENV等。这样压扁镜像的工作方式与最初构建时相同。此外，后续图层中删除的文件实际上是在压缩时从镜像中清除的。延伸阅读linuxea:docker不能忽视的.dockerignore用法linuxea:docker多阶段构建Multi-Stage与Builder对比总结docker-squashlinuxea:dockerfile中的RUN指令对镜像大小的影响学习更多学习如何使用Docker CLI命令，Dockerfile命令，使用这些命令可以帮助你更有效地使用Docker应用程序。查看Docker文档和我的其他帖子以了解更多信息。docker目录白话容器docker-compose

linuxea:dockerfile中的RUN指令对镜像大小的影响 我们在github上，或者在一些应用官方提供的docker镜像的Dockerfile中，经常会看到很多难以琢磨的操作，这篇文章主要说明使用Dockerfile的RUN命令为什么要在后面使用&&链接，以及在实际镜像中的影响和区别。阅读本篇文章对Dockerfile的RUN命令和层有更深的认识，同时学会更好的缩减容器的镜像。为了更好的演示RUN命令与层带来的差异，我们分为几个步骤来做！1，测试多条命令的大小与差异2，减少多条命令的大小与差异多条RUN首先，我们进行多条命令RUN命令测试，如下：安装nginx,php,curl三个软件包[root@linuxea.com ~]# cat Dockerfile FROM alpine:3.9 as default MAINTAINER www.linuxea.com LABEL maintainer="www.linuxea.com" RUN apk add nginx RUN apk add php RUN apk add curl在Build的同时，依次进行[root@linuxea.com ~]# docker build -t linuxea:26 . Sending build context to Docker daemon 427kB Step 1/6 : FROM alpine:3.9 as default ---> caf27325b298 Step 2/6 : MAINTAINER www.linuxea.com ---> Using cache ---> 5ee27f5e579a Step 3/6 : LABEL maintainer="www.linuxea.com" ---> Using cache ---> a9b2f826f6c9 Step 4/6 : RUN apk add nginx ---> Running in c2b048d78656 fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/x86_64/APKINDEX.tar.gz fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/community/x86_64/APKINDEX.tar.gz (1/2) Installing pcre (8.42-r1) (2/2) Installing nginx (1.14.2-r0) Executing nginx-1.14.2-r0.pre-install Executing busybox-1.29.3-r10.trigger OK: 7 MiB in 16 packages Removing intermediate container c2b048d78656 ---> 116c307055ed Step 5/6 : RUN apk add php ---> Running in 29c651203043 (1/7) Installing php7-common (7.2.14-r0) (2/7) Installing ncurses-terminfo-base (6.1_p20190105-r0) (3/7) Installing ncurses-terminfo (6.1_p20190105-r0) (4/7) Installing ncurses-libs (6.1_p20190105-r0) (5/7) Installing libedit (20181209.3.1-r0) (6/7) Installing libxml2 (2.9.9-r1) (7/7) Installing php7 (7.2.14-r0) Executing busybox-1.29.3-r10.trigger OK: 21 MiB in 23 packages Removing intermediate container 29c651203043 ---> ec1cbef7f89e Step 6/6 : RUN apk add curl ---> Running in d96aef6e09f8 (1/5) Installing ca-certificates (20190108-r0) (2/5) Installing nghttp2-libs (1.35.1-r0) (3/5) Installing libssh2 (1.8.0-r4) (4/5) Installing libcurl (7.63.0-r0) (5/5) Installing curl (7.63.0-r0) Executing busybox-1.29.3-r10.trigger Executing ca-certificates-20190108-r0.trigger OK: 22 MiB in 28 packages Removing intermediate container d96aef6e09f8 ---> f4000a9883f1 Successfully built f4000a9883f1 Successfully tagged linuxea:26此时构建的镜像大小为18.8M[root@linuxea.com ~]# docker images linuxea:26 REPOSITORY TAG IMAGE ID CREATED SIZE linuxea 26 f4000a9883f1 12 seconds ago 18.8MB分为七层，每一条命令都分为一层，加起来的总大小是18.8M[root@linuxea.com ~]# docker history linuxea:26 IMAGE CREATED CREATED BY SIZE COMMENT f4000a9883f1 18 seconds ago /bin/sh -c apk add curl 1.68MB ec1cbef7f89e 21 seconds ago /bin/sh -c apk add php 8.89MB 116c307055ed 54 seconds ago /bin/sh -c apk add nginx 2.74MB a9b2f826f6c9 9 days ago /bin/sh -c #(nop) LABEL maintainer=www.linu… 0B 5ee27f5e579a 9 days ago /bin/sh -c #(nop) MAINTAINER www.linuxea.com 0B caf27325b298 3 weeks ago /bin/sh -c #(nop) CMD ["/bin/sh"] 0B <missing> 3 weeks ago /bin/sh -c #(nop) ADD file:2a1fc9351afe35698… 5.53MB 单条RUN此刻，我们尝试将安装的nginx,php,curl放在一条RUN，使用&&链接起来执行[root@linuxea.com ~]# cat Dockerfile FROM alpine:3.9 as default MAINTAINER www.linuxea.com LABEL maintainer="www.linuxea.com" RUN apk add nginx \ && apk add php \ && apk add curl [root@linuxea.com ~]# docker build -t linuxea:26-1 . Sending build context to Docker daemon 427kB Step 1/4 : FROM alpine:3.9 as default ---> caf27325b298 Step 2/4 : MAINTAINER www.linuxea.com ---> Using cache ---> 5ee27f5e579a Step 3/4 : LABEL maintainer="www.linuxea.com" ---> Using cache ---> a9b2f826f6c9 Step 4/4 : RUN apk add nginx && apk add php && apk add curl ---> Running in 19fb009c38d1 fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/x86_64/APKINDEX.tar.gz fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/community/x86_64/APKINDEX.tar.gz (1/2) Installing pcre (8.42-r1) (2/2) Installing nginx (1.14.2-r0) Executing nginx-1.14.2-r0.pre-install Executing busybox-1.29.3-r10.trigger OK: 7 MiB in 16 packages (1/7) Installing php7-common (7.2.14-r0) (2/7) Installing ncurses-terminfo-base (6.1_p20190105-r0) (3/7) Installing ncurses-terminfo (6.1_p20190105-r0) (4/7) Installing ncurses-libs (6.1_p20190105-r0) (5/7) Installing libedit (20181209.3.1-r0) (6/7) Installing libxml2 (2.9.9-r1) (7/7) Installing php7 (7.2.14-r0) Executing busybox-1.29.3-r10.trigger OK: 21 MiB in 23 packages (1/5) Installing ca-certificates (20190108-r0) (2/5) Installing nghttp2-libs (1.35.1-r0) (3/5) Installing libssh2 (1.8.0-r4) (4/5) Installing libcurl (7.63.0-r0) (5/5) Installing curl (7.63.0-r0) Executing busybox-1.29.3-r10.trigger Executing ca-certificates-20190108-r0.trigger OK: 22 MiB in 28 packages Removing intermediate container 19fb009c38d1 ---> 6d1be09ddac1 Successfully built 6d1be09ddac1 Successfully tagged linuxea:26-1得到的大小是18.7M[root@linuxea.com ~]# docker images linuxea:26-1 REPOSITORY TAG IMAGE ID CREATED SIZE linuxea 26-1 6d1be09ddac1 9 seconds ago 18.7MB而层也随机变少了，只有5层，18.7M[root@linuxea.com ~]# docker history linuxea:26-1 IMAGE CREATED CREATED BY SIZE COMMENT 6d1be09ddac1 23 seconds ago /bin/sh -c apk add nginx && apk add php &… 13.1MB a9b2f826f6c9 9 days ago /bin/sh -c #(nop) LABEL maintainer=www.linu… 0B 5ee27f5e579a 9 days ago /bin/sh -c #(nop) MAINTAINER www.linuxea.com 0B caf27325b298 3 weeks ago /bin/sh -c #(nop) CMD ["/bin/sh"] 0B <missing> 3 weeks ago /bin/sh -c #(nop) ADD file:2a1fc9351afe35698… 5.53MB 思考？现在我们经过对比，多条RUN似乎会导致多层，并且比一条RUN，也就是同一个层的镜像构建的要小一些。那现在肯定有人会迷惑，这说明了什么？现在，我们不妨在看看，我们换个方式。[root@linuxea.com ~]# cat Dockerfile FROM alpine:3.9 as default MAINTAINER www.linuxea.com LABEL maintainer="www.linuxea.com" RUN apk add nginx RUN apk add php RUN apk add curl RUN apk del nginx php curl如上，假设，我此刻在Dockerfile中已经使用了在这三个软件，在构建的最后步骤，我希望删掉->依赖安装最小化原则。而后我在进行build[root@linuxea.com ~]# docker build -t linuxea:26-2 . Sending build context to Docker daemon 427kB Step 1/7 : FROM alpine:3.9 as default ---> caf27325b298 Step 2/7 : AINTAINER www.linuxea.com ---> Using cache ---> 5ee27f5e579a Step 3/7 : LABEL maintainer="www.linuxea.com" ---> Using cache ---> a9b2f826f6c9 Step 4/7 : RUN apk add nginx ---> Using cache ---> 116c307055ed Step 5/7 : RUN apk add php ---> Using cache ---> ec1cbef7f89e Step 6/7 : RUN apk add curl ---> Using cache ---> f4000a9883f1 Step 7/7 : RUN apk del nginx php curl ---> Running in 124fea0865fb (1/14) Purging nginx (1.14.2-r0) (2/14) Purging php7 (7.2.14-r0) (3/14) Purging php7-common (7.2.14-r0) (4/14) Purging curl (7.63.0-r0) (5/14) Purging pcre (8.42-r1) (6/14) Purging libedit (20181209.3.1-r0) (7/14) Purging ncurses-libs (6.1_p20190105-r0) (8/14) Purging ncurses-terminfo (6.1_p20190105-r0) (9/14) Purging ncurses-terminfo-base (6.1_p20190105-r0) (10/14) Purging libxml2 (2.9.9-r1) (11/14) Purging libcurl (7.63.0-r0) (12/14) Purging ca-certificates (20190108-r0) Executing ca-certificates-20190108-r0.post-deinstall (13/14) Purging nghttp2-libs (1.35.1-r0) (14/14) Purging libssh2 (1.8.0-r4) Executing busybox-1.29.3-r10.trigger OK: 6 MiB in 14 packages Removing intermediate container 124fea0865fb ---> 3a74abf45025 Successfully built 3a74abf45025 Successfully tagged linuxea:26-2构建完成。镜像的大小仍然是18.9M。[root@linuxea.com ~]# docker images linuxea:26-2 REPOSITORY TAG IMAGE ID CREATED SIZE linuxea 26-2 3a74abf45025 16 seconds ago 18.9MB我们使用docker history命令查看镜像，可见我们的确执行了apk del nginx php curl命令[root@linuxea.com ~]# docker history linuxea:26-2 IMAGE CREATED CREATED BY SIZE COMMENT 3a74abf45025 28 seconds ago /bin/sh -c apk del nginx php curl 21.2kB f4000a9883f1 6 minutes ago /bin/sh -c apk add curl 1.68MB ec1cbef7f89e 6 minutes ago /bin/sh -c apk add php 8.89MB 116c307055ed 6 minutes ago /bin/sh -c apk add nginx 2.74MB a9b2f826f6c9 9 days ago /bin/sh -c #(nop) LABEL maintainer=www.linu… 0B 5ee27f5e579a 9 days ago /bin/sh -c #(nop) MAINTAINER www.linuxea.com 0B caf27325b298 3 weeks ago /bin/sh -c #(nop) CMD ["/bin/sh"] 0B <missing> 3 weeks ago /bin/sh -c #(nop) ADD file:2a1fc9351afe35698… 5.53MB 我们进入容器确认是否被卸载[root@linuxea.com ~]# docker run --rm -it linuxea:26-2 sh / # curl sh: curl: not found / # 发生了什么？为什么在Dockerfile删除的软件已经消失，而层的大小并没有因为删除而缩减？要回答这一点，我们要返回上面的docker history linuxea:26-2中查看。我们将SIZE用加法运算，得到的大小与docker image查看的几乎接近，如下[root@linuxea.com ~]# docker history linuxea:26-2|awk '{print $NF}'|grep -v "COMMENT" 21.2kB 1.68MB 8.89MB 2.74MB 0B 0B 0B 5.53MB这说明docker会将所有的层相加。尽管我们在删除了这三个包，但是在上一层中，这三个包仍然是存在的，因为从下到上叠加的层最终构成了镜像。所以，要从层中有效删除，就需要在一个层中有效的组织。这些层是否就没有了作用？当在测试环境中，编写Dockerfile的时候可以使用多层，也就是多条RUN的命令来缓存每一个层做测试或者调试，当相同的指令就会复用缓存中间层。这可以有效的缩减build时间，原因是利用了docker的构建缓存。而构建缓存在CI/CD中是很有用的。RUN正确的使用方式我们应该将命令使用RUN和&&链接起来，这样在中间的层就表现为一个层，这样的情况并不利于调试，如上所述。每次构建都会认为是一条指令，当发生一条命令的变化，就无法使用缓存加速构建。我们重新build，并且删除缓存FROM alpine:3.9 as default MAINTAINER www.linuxea.com LABEL maintainer="www.linuxea.com" RUN apk add nginx \ && apk add php \ && apk add curl \ && apk del nginx php curl \ && rm /var/cache/apk/*重新build后的大小仅为5.56M[root@linuxea.com ~]# docker images linuxea:26-3 REPOSITORY TAG IMAGE ID CREATED SIZE linuxea 26-3 f300b5797d81 33 seconds ago 5.56MB[root@linuxea.com ~]# docker history linuxea:26-3 IMAGE CREATED CREATED BY SIZE COMMENT f300b5797d81 2 seconds ago /bin/sh -c apk add nginx && apk add php &&… 26kB a9b2f826f6c9 10 days ago /bin/sh -c #(nop) LABEL maintainer=www.linu… 0B 5ee27f5e579a 10 days ago /bin/sh -c #(nop) MAINTAINER www.linuxea.com 0B caf27325b298 3 weeks ago /bin/sh -c #(nop) CMD ["/bin/sh"] 0B <missing> 3 weeks ago /bin/sh -c #(nop) ADD file:2a1fc9351afe35698… 5.53MB 其他的办法我们在使用RUN命令的时候，除了尽可能的减少层，我们还可以使用docker多阶段构建Multi-Stage。docker多阶段构建将"上一次的构建用在下一个Dockerfile中"，这很实用FROM golang:1.7.3 as builder WORKDIR /go/src/github.com/alexellis/href-counter/ RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app . FROM alpine:latest WORKDIR /root/ COPY --from=builder /go/src/github.com/alexellis/href-counter/app .延伸阅读linuxea:如何利用docker构建缓存快速迭代？linuxea:docker多阶段构建Multi-Stage与Builder对比总结学习更多学习如何使用Docker CLI命令，Dockerfile命令，使用这些命令可以帮助你更有效地使用Docker应用程序。查看Docker文档和我的其他帖子以了解更多信息。docker目录白话容器docker-compose

linuxea:docker卷和文件系统权限 Docker容器是无状态的（不需要在运行时候做持久化数据）。一般来讲，一些有状态的，存储重要数据的应用需要一些持久存储。卷功能提供了一种支持此要求的方法，但它带有一些关于文件系统权限的问题。在大多数部署的设置中，将使用容器编排机制，并且持久存储由某些公共云产品提供，这些产品可能具有自己的配置权限的方式。但是，在本地开发或产品的早期迭代期间，最简单的方法是将主机目录公开为docker卷。简而言之，这些是将主机目录配置为卷时需要注意的事实：从主机和容器的角度来看，对卷中内容设置的文件权限是相同的。只有UID（用户ID）和GID（组ID）很重要。例如，用户和组的名称和密码不需要匹配，甚至不需要存在于主机和容器中根据自己的配置对在运行的容器，具有所有操作权限，如：强制执行文件权限。例如，如果用户A同时存在于主机和容器中，将用户A添加到主机上的组B，不允许用户A写入容器内的组B所拥有的目录，除非在容器内创建组B并且向其添加用户A.默认情况下，容器的命令以root身份运行（在基于unix的系统上）可以将文件/目录所有权设置为不属于任何实际组的GID如果你掌握上述事实，应该能够配置容器和卷而不会有太多意外事故。如果你不熟悉UNIX文件权限，我可以推荐本站的linuxea基础之权限管理一篇。权限我们可以方便地为本地开发配置内容，示例：将要用作卷的目录的组所有权设置为某些GID（在此示例中为1101）未在主机上的任何实际组上使用[root@linuxea.com ~]# mkdir /root/linuxea.com [root@linuxea.com ~]# chown :1101 /root/linuxea.com更改目录的权限以授予组成员完全访问权限（读取+写入+执行）[root@linuxea.com ~]# chmod 755 /root/linuxea.com确保文件夹中的所有之后内容都将继承组所有权[root@linuxea.com ~]# chmod g+s /root/linuxea.com/在Dockerfile中创建一个用户，该用户是1101组的成员看起来可以是这样FROM alpine:3.9 MAINTAINER www.linuxea.com LABEL maintainer="www.linuxea.com" RUN addgroup --gid 1101 www \ && adduser -u 1101 -S -H -s /bin/bash -g www -G www www -D（可选）将主机用户添加到组中，以便你方便地使用主机中的目录centos:useradd linuxea上面的示例是一个最小化设置，可确保你不以root身份运行容器命令，并且可以使用主机上附加卷的内容，而无需使用主机root用户(你必须确保你使用的非root用户启动容器。该设置在构建时执行硬编码配置，使你无法在运行时调整GID。如果需要，你必须将GID作为环境变量传递，并包含可以使用它的通用脚本。示例如下：entrypoint.sh#!/bin/bash # www.linuxea.com USER_ID=${LOCAL_USER_ID:-1101} USER_NAME=${LOCAL_USER_NAME:-www} echo "Starting with UID : $USER_ID And user $USER_NAME" addgroup --gid $USER_ID $USER_NAME adduser -u $USER_ID -S -H -s /bin/bash -g $USER_NAME -G $USER_NAME $USER_NAME -D # useradd --shell /bin/bash -u $USER_ID -o -c "" -m user export HOME=/home/$USER_NAME exec /usr/local/bin/gosu $USER_NAME "$@"我们在这里做的是从环境变量中获取UID和将要用到的名称，如果它不存在则默认为1101，NAME不存在则www，并且使用adduser/useradd设置UID时实际使用熟悉的命令创建用户“www” 。entrypoint创建最后我们用这个用户gosu来执行我们的流程"$@"。记住来自Dockerfile的CMD或来自docker CLI的命令作为命令行参数传递给entrypoint.sh脚本。我们在看DockerfileFROM alpine:3.9 MAINTAINER www.linuxea.com LABEL maintainer="www.linuxea.com" COPY entrypoint.sh /bin/entrypoint.sh RUN apk update \ && apk add bash \ && wget https://github.com/tianon/gosu/releases/download/1.11/gosu-amd64 -O /usr/local/bin/gosu \ && chmod +x /bin/entrypoint.sh /usr/local/bin/gosu \ && rm /var/cache/apk/* ENTRYPOINT ["entrypoint.sh"] CMD ["sleep","30000"]build[root@linuxea.com ~]# docker build -t marksugar/alpine:3.9 .run可以传递LOCAL_USER_ID和LOCAL_USER_NAME改变脚本参数，从而改变gid和name[root@linuxea.com ~]# docker run -d marksugar/alpine:3.9 00f7afb58a9ee069f1bca6fdd716131e48538bc161911e62bf4249328f98270b[root@linuxea.com ~]# docker exec -it 00f7 ps aux PID USER TIME COMMAND 1 www 0:00 sleep 30000 14 root 0:00 ps aux[root@linuxea.com ~]# ps aux|grep sleep 1101 27414 0.3 0.0 1520 4 ? Ss 21:56 0:00 sleep 30000现在你就可以下载marksugar/alpine:3.9镜像来作为基础镜像了。延伸阅读linuxea:了解uid和gid如何在docker容器中工作linuxea:docker容器中程序不应该以root用户身份运行学习更多学习如何使用Docker CLI命令，Dockerfile命令，使用Bash命令可以帮助你更有效地使用Docker应用程序。查看Docker文档和我的其他帖子以了解更多信息。docker目录白话容器docker-compose

linuxea:docker容器中程序不应该以root用户身份运行 容器中的进程不应以root身份运行，或者假设它们是root用户。正确的方式是使用已知的UID和GID在Dockerfile中创建用户，并以此用户身份运行你的进程。通过限制对资源的访问，遵循此模式的映像更容易安全运行概观精心设计的系统遵循最小特权原则。这简单地说明应用程序应该只能访问它所需的资源以执行其所需的功能。这在设计安全系统时至关重要。无论是恶意还是由于某些错误，进程可能会在运行时产生意外后果。保护自己免受任何意外的最佳方法之一是仅授予进程运行所需的最小权限。大多数容器化进程是应用程序服务，因此不需要root访问权限。虽然Docker需要root运行，但容器本身却不需要。编写良好，安全且可重用的Docker镜像不应该以root身份运行，并且应该提供一种可预测且简单的方法来限制访问。为什么这很重要请记住，在容器中运行的进程与在Linux上运行的其他进程没有什么不同，除了它有一小段元数据声明它在容器中。容器不是信任边界，因此，容器中运行的任何东西都应该与主机本身上运行的任何东西一样对待。就像你不会（或不应该）在服务器上以root身份运行任何东西一样，你不应该在服务器上的容器中以root身份运行任何东西。在别处创建的运行二进制文件需要大量的信任条件，对于容器中的二进制文件也是如此。如果容器内的进程默认以root身份运行，则可以在启动容器时更改uid和gid。作为镜像的作者，你应该默认以不同的用户身份运行，并且更容易限制该用户的访问权限。通过在Dockerfile中创建用户，你不仅可以使其默认安全，而且更容易保持安全。示例将显示以root身份运行容器的风险。让我们在/root目录中创建一个test.file文件，防止root 以外的任何人查看它：[root@linuxea.com ~]# echo "www.linuxea.com" >> ./test.file [root@linuxea.com ~]# chmod 600 test.file [root@linuxea.com ~]# ls -l total 4 -rw------- 1 root root 16 Feb 23 13:24 test.file而后切换到linuxea用户下[root@linuxea.com ~]# su - linuxea Last login: Wed Feb 20 17:44:35 CST 2019 on pts/2[linuxea@linuxea.com ~]$ cat /root/test.file cat: /root/test.file: Permission denied [linuxea@linuxea.com ~]$ ls /root/test.file ls: cannot access /root/test.file: Permission denied [linuxea@linuxea.com ~]$ ls -l /root/test.file ls: cannot access /root/test.file: Permission denied现在我在root家目录创建了一个test.file的文件，并且追加了信息，权限是600，只有root可以看到内容。以普通个用户登陆是没有权限查看的。现在，我创建一个Dockerfile镜像FROM alpine:latest MAINTAINER www.linuxea.com mark ENTRYPOINT ["cat","/opt/test.file"][linuxea@linuxea.com ~]$ docker build -t linuxea:23 . Sending build context to Docker daemon 10.24kB Step 1/3 : FROM alpine:latest ---> caf27325b298 Step 2/3 : MAINTAINER www.linuxea.com mark ---> Using cache ---> c9603327aeb5 Step 3/3 : ENTRYPOINT ["cat","/opt/test.file"] ---> Running in d1d8fd1f5fd6 Removing intermediate container d1d8fd1f5fd6 ---> 1bd2e84b67f9 Successfully built 1bd2e84b67f9 Successfully tagged linuxea:23而后我运行这个镜像，并且将不能查看的文件挂在到容器中并运行[linuxea@linuxea.com ~]$ docker run --rm -v /root/test.file:/opt/test.file linuxea:23 www.linuxea.com即使我是linuxea，容器正在运行root，因此可以访问root此服务器上的所有内容。这不理想; 以这种方式运行容器意味着你从Docker Hub中提取的每个容器都可以完全访问服务器上的所有内容（具体取决于你运行它的方式）。建议这里的建议是创建一个uid Dockerfile中已知的用户，并以该用户身份运行应用程序进程。Dockerfile的开头应遵循以下模式：FROM <centos:-基本镜像> RUN groupadd -g 999 USER && \ useradd -r -u 999 -g USER USER USER USER ... <Dockerfile的其余部分> ...使用此模式，可以在具有所需权限最少的用户/组的上下文中轻松运行容器。例如，我将从上面将它添加到我的Dockerfile并重新运行该示例。我的Dockerfile现在看起来像这样：FROM alpine:latest MAINTAINER www.linuxea.com mark RUN addgroup www && adduser -u 1001 -S -H -s /sbin/nologin -g 'nginx' -G www www USER www ENTRYPOINT ["cat","/opt/test.file"][linuxea@linuxea.com ~]$ docker build -t linuxea:24 . Sending build context to Docker daemon 10.24kB Step 1/5 : FROM alpine:latest ---> caf27325b298 Step 2/5 : MAINTAINER www.linuxea.com mark ---> Using cache ---> c9603327aeb5 Step 3/5 : RUN addgroup www && adduser -u 1001 -S -H -s /sbin/nologin -g 'nginx' -G www www ---> Running in 09d9fc94586a Removing intermediate container 09d9fc94586a ---> 85d82a2b1c7f Step 4/5 : USER www ---> Running in 9dd67807ba0e Removing intermediate container 9dd67807ba0e ---> c56e5dc43a7f Step 5/5 : ENTRYPOINT ["cat","/opt/test.file"] ---> Running in 31007cdf4293 Removing intermediate container 31007cdf4293 ---> e6dfe1c64d2c Successfully built e6dfe1c64d2c Successfully tagged linuxea:24使用与以前相同的命令运行此容器：[linuxea@linuxea.com ~]$ docker run --rm -v /root/test.file:/opt/test.file linuxea:24 cat: can't open '/opt/test.file': Permission denied重复使用其他图像Docker的镜像是很好用的，因为它们是可重用的。但是当FROM的镜像以非root身份运行时，你的容器将继承该非root用户。如果你需要创建自己的或以root身份执行操作，请确保USER root在Dockerfile顶部附近的某处。然后FROM User再次使其可用。FROM alpine:latest MAINTAINER www.linuxea.com mark USER root RUN make install 《root权限需要》 RUN addgroup www && adduser -u 1001 -S -H -s /sbin/nologin -g 'nginx' -G www www USER www ENTRYPOINT ["cat","/opt/test.file"]以非root用户身份运行其他容器Docker镜像设计为可移植的，从Docker Hub中提取其他镜像是正常的。其中一些（官方镜像）将遵循此最佳实践并作为普通用户帐户运行。但许多镜像都没有这样做。许多镜像只是运行root，并由你决定如何安全地运行它们。有几个选项可以让你安全地运行没有创建自己用户的镜像。创建另一个图像首先，一个选项是使用原始镜像作为FROM图层创建另一个镜像。然后，您可以创建用户帐户，并将原始ENTRYPOINT和CMD指令复制到自己的镜像。此结果镜像现在遵循此处概述的最佳实践，并且默认情况下将安全运行。这里的权衡是你需要在更新基本镜像时重建构建镜像。你必须在重建基本镜像时设置重建过程。你可以在原有的镜像之上修改，也可以从docker镜像复现Dockerfile进行重新编写。启动容器时指定uid最后，你可以在主机上创建用户，并uid在启动容器时将其传递给Docker。例如，重新访问原始示例Dockerfile：FROM alpine:latest MAINTAINER www.linuxea.com mark ENTRYPOINT ["cat","/opt/test.file"]我可以使用或不使用用户id参数运行此容器，并查看不同的结果（用户ID 1001是我自己在此服务器上的linuxea帐户）：[linuxea@linuxea.com ~]$ docker run --rm --user=1001 -v /root/test.file:/opt/test.file linuxea:23 cat: can't open '/opt/test.file': Permission denied[linuxea@linuxea.com ~]$ docker run --rm -v /root/test.file:/opt/test.file linuxea:23 www.linuxea.com这与在Dockerfile中创建用户的工作方式相同，但它要求用户可选择安全地运行容器。在Dockerfile中指定非root用户将使容器默认安全运行。进一步了解linuxea:了解uid和gid如何在docker容器中工作linuxea:docker run的十个常用选项linuxea:十个初学Dcoker cli指令学习更多学习如何使用Docker CLI命令，Dockerfile命令，使用这些命令可以帮助你更有效地使用Docker应用程序。查看Docker文档和我的其他帖子以了解更多信息。docker目录白话容器docker-compose

linuxea:docker不能忽视的.dockerignore用法 .dockerignore的文章或许对老司机来说是一个过时的话题，但是我已经写了很多关于dockers使用的文章，并且我在讨论群组里面发现有人对此.dockerignore并不清楚，在这种情况下，我有必要重新复述一次。查看本章节，你将了解.dockerignore的使用和注意事项。祝你愉快Docker镜像可以和普通应用一样运行在云服务上，为什么还要优化它们呢？事实证明使用.dockerignore有很多好处。它可以帮助减少Docker镜像大小，加速docker build并避免意外的秘密曝光（请继续阅读以了解我的意思）。要理解.dockerignore为何如此有效，你必须了解构建上下文。Docker build context该docker build命令用于构建新的Docker镜像。你可以将一个参数传递给build命令构建上下文（build context）。此后的叙述中，都称为“构建上下文”什么是build context？首先，Docker是一个客户端 - 服务器应用程序，它由Docker客户端和Docker服务器（也称为Docker 守护程序）组成。Docker客户端命令行工具与Docker服务器通信并要求它执行操作。其中一个是Docker build：构建一个新的Docker镜像。Docker可以在与客户端，远程计算机或虚拟机上运行，也可以是本地，远程甚至在某些云IaaS上运行。有哪些是重要的？为了创建一个新的Docker镜像，Docker服务器需要访问文件并从中创建Docker镜像。因此，你需要以某种方式将这些文件发送到Docker服务器。这些文件是Docker 构建不可缺少的部分。Docker客户端将所有构建上下文文件打包到tar存档中，并将此存档上传到Docker服务器。默认情况下，客户端将获取当前工作目录中的所有文件（和文件夹），并将它们用作构建上下文。它还可以接受已创建的tar存档或git存储库。在git存储库的情况下 ，客户端将克隆到临时文件夹中，并从中创建构建上下文存档。对Docker构建的影响你看到，运行该docker build命令的第一个输出行是：Sending build context to Docker daemon 4.608kB Step 1/5 : FROM alpine:3.9这应该让事情变得清晰。实际上，每次运行docker build命令时，Docker客户端都会创建一个新的构建上下文存档并将其发送到Docker服务器。因此，总是这样：创建存档，存储和网络流量以及延迟时间所需的时间。提示：如果你在Docker镜像中不需要它们，则不将文件添加到构建上下文中。dockerignore文件该.dockerignore文件是隐藏文件也是一个工具，可以帮助你定义你真正需要的Docker 构建上下文。使用此文件，你可以为这些文件和文件夹规则指定忽略规则和异常，这些规则和异常将不包含在构建上下文中，因此不会打包到存档中并上载到Docker服务器。使用.dockerignore的几个个理由原因＃1：Docker图像大小你的系统由多个组件（或微服务）组成，每个组件都在Linux容器内运行。可能有数十或数百个服务甚至更多服务实例。比如：每个代码提交完成，这些服务实例就可以彼此独立地构建和部署。更重要的是，弹性基础设施意味着可以在系统中添加或删除新的计算节点，并且其微服务可以从一个节点移动到另一个节点，以支持规模或可用性要求。这意味着，你的Docker镜像将经常构建和传输。当你持续交付和微服务架构时，镜像大小和镜像构建时间都很重要。理由＃2：无意识的秘密暴露不控制构建上下文，也可能导致意外暴露你的代码，提交历史记录和密钥（密钥和凭据）。如果你将文件复制到你docker 镜像与ADD .或COPY .命令，可能会无意地包括源文件，整个git历史（一个.git文件夹），机密文件（如.aws，.env，私钥），缓存和其他文件只进不出docker “构建背景”，这些最终也进入最终的Docker镜像。DockerHub上目前有多个Docker镜像，可以显示应用程序源代码，密码，密钥和证书（例如Twitter Vine）。原因＃3：Docker构建 - 缓存失效一种常见的模式是使用如下指令将应用程序的整个代码库注入镜像：COPY . /usr/src/app在这种情况下，我们将整个 构建上下文复制到镜像中。了解每个Dockerfile命令生成一个新层也很重要。因此，如果整个构建上下文中包含的任何文件发生更改，则此更改将使COPY . /opt/myapp图层的构建缓存无效，并且将在下一个构建时生成新的镜像层。如果你的工作目录包含经常更新的文件（日志，测试结果，git历史记录，临时缓存文件等），那么你将为每次docker build运行重新生成此层。dockerignore语法该.dockerignore文件类似于gitignore该git工具使用的文件 。与.gitignore文件类似，它允许你为生成构建上下文时Docker客户端应忽略的文件和文件夹指定模式。虽然.dockerignore用于描述忽略模式的文件语法类似于.gitignore，但它并不相同。该.dockerignore模式匹配的语法是基于filepath.Match()和filepath.clean的功能，包括一些补充。如：Docker还支持一个**匹配任意数量目录（包括零）的特殊通配符字符串。例如，**/*.go将排除.go 在所有目录中找到的以该结尾的所有文件，包括构建上下文的根。以下是完整的语法.dockerignore：pattern: {term} 术语： '*' 匹配任何非分隔符字符序列 '？' 匹配任何单个非分隔符 '['['^'] {character-range}']' 字符类（必须是非空的） c匹配字符c （c！='*'，'？'，'\\'，'['） '\\' c匹配字符c 字符范围： c匹配字符c （c！='\\'，' - '，']'） '\\' c匹配字符c lo' - 'hi匹配字符c for lo＆lt; = c＆lt; = hi 补充： '**' 匹配任意数量的目录（包括零） '！' 行开头！ （感叹号）可用于排除例外情况 以此字符开头的'＃'行将被忽略：将其用于评论!用法可以组合起来用于高级规则示例＃ignore除了README-secret.md以外的所有README*.md和旁边的所有markdown文件（md）格式的都不要 *.MD ！README*.MD README-secret.md＃ignore所有文件夹中的所有*.class文件，包括构建根目录 **/*.class＃ignore .git和.cache文件夹 .git .cache# 排除名称以temp根目录的任何直接子目录开头的文件或者目录，如/somedir/tempfile.txt,目录/somedir/temp/ */temp*# temp从以下两级以下的任何子目录开始排除文件和目录。例如，/somedir/subdir/temporary.txt被排除在外。 */*/temp* # 排除根目录中的文件和目录，其名称是单字符扩展名temp。例如，/tempa与/tempb被排除在外 temp?演示我们先看当前的目录下的文件列表。我将会在其中：排除.git文件或者目录排除*.log文件，或者以*-log-*的文件排除*.tag.gz文件*.war文件，以及jenkins_home下的*.txt文件Dockerfile文件.dockerignore文件，包括所有的*.md文件，但是info.md除外。那么最终就剩下jenkins_home下的mark目录和info.md了。[root@linuxea.com /opt/2019/ignore]# tree -a . . ├── 0.log ├── 1.log ├── 9.log ├── Dockerfile ├── .dockerignore ├── .git ├── info.md ├── jenkins-2.165.tar.gz ├── jenkins_home │   ├── 2019-02-21_10:15:47.txt │   └── mark ├── jenkins.war ├── link.md └── readme.md 2 directories, 12 files.dockerignore文件完成预期[root@linuxea.com /opt/2019/ignore]# cat .dockerignore .git **/*.log **/*-log-* **/*.tar.gz **/*.war jenkins_home/*.txt Dockerfile .dockerignore *.md !info.mdDockerfileFROM alpine:3.9 MAINTAINER www.linuxea.com mark WORKDIR /opt/ COPY . /opt/ CMD ["sleep","1000000"]Build[root@linuxea.com /opt/2019/ignore]# docker build -t ignore . Sending build context to Docker daemon 4.608kB Step 1/5 : FROM alpine:3.9 ---> caf27325b298 Step 2/5 : MAINTAINER www.linuxea.com mark ---> Using cache ---> c9603327aeb5 Step 3/5 : WORKDIR /opt/ ---> Using cache ---> 109238b7358f Step 4/5 : COPY . /opt/ ---> ce0c655d1371 Step 5/5 : CMD ["sleep","1000000"] ---> Running in b1e1bdc833bf Removing intermediate container b1e1bdc833bf ---> 012de3caad48 Successfully built 012de3caad48 Successfully tagged ignore:latest验证[root@linuxea.com /opt/2019/ignore]# docker run --rm -it ignore sh /opt # ls -a . .. info.md jenkins_home /opt # ls -a jenkins_home/ . .. mark /opt # ls -a jenkins_home/mark/ . .. /opt # 学习更多学习如何使用Docker CLI命令，Dockerfile命令，使用这些命令可以帮助你更有效地使用Docker应用程序。查看Docker文档和我的其他帖子以了解更多信息。docker目录白话容器docker-compose

linuxea:docker多阶段构建Multi-Stage与Builder对比总结 此前，在早些时候，我发表过Distroless与多阶段构建，其中介绍了简单的多阶段构建方式。阅读本文，你将跟快的了解多阶段构建带来的便利以及使用方法。本文中主要介绍多阶段构建的方式，这种方式本身就可以节省一部分空间，对于如何缩减镜像大小的几种方式类文章总结将会在此后进行编写发布，那将是后面会发生的事情。我们暂且来看多阶段构建带给我们的便利性为什么镜像会变大？Docker就像一个版本控制系统。每次更改都会创建一个新图层。每次在Docker中运行新命令时，它都会创建一个新层。这就是为什么在Dockerfiles中你会看到链接的多个命令。下面的阶段代表一层：RUN curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py \ && python get-pip.py \ && pip install awscli因此，让我们假设您的容器需要您下载源文件，并构建容器（通常采用静态编译语言）。您必须从容器中删除源文件，否则源将成为镜像的一部分，从而增加了大小。并且，您无法做到，rm -rf $source_files_directory因为它只会创建一个新图层。你怎么解决这个问题？我们将向您展示旧方式和更好的方式。旧的方式：build如果使用最早的叠加累计的方式进行构建，如果是这样，事实上你使用的是两个docker镜像一个镜像来执行构建。一个精简的镜像，用于传送第一个构建的结果，而不会在第一个镜像中产生构建链和工具的损失。您可能已经发现保持图层小的唯一方法是：在进入下一层之前不再需要清理工件。使用shell技巧和其他逻辑来保持层尽可能小，同时确保每个层只有前一层所需的工件。例如，以下是使用构建器模式的常见解决方案，用于调出Tomcat容器并在其上部署应用程序：在甚至于，将常用软件打包在一个镜像中，这些软件包括：git ,jdk,mvn等。这样一来，镜像大小无限扩大，出现问题，排查也不是很方便，如下实例FROM tomcat:9.0.16-jre8 MAINTAINER www.linuxea.com mark WORKDIR /usr/src/project RUN apt-get update \ && apt-get install -y git openjdk-8-jdk \ && git clone http://GITUSER:GITPASS@git.ds.com/mark/java.git \ && wget https://downloads.gradle.org/distributions/gradle-4.8.1-bin.zip \ && unzip gradle-4.8.1-bin.zip \ && PATH=$PATH:$PWD/gradle-4.8.1/bin \ && gradle prod \ && mv /usr/src/project/build/ROOT.war /usr/local/tomcat/webapps/ROOT.war \ && rm -rf /usr/src/project/java COPY entrypoint.sh / COPY tomcat_conf_prod/* /usr/local/tomcat/conf/ RUN chmod +x /entrypoint.sh首先，我们进入/usr/src/project目录(或者COPY指令将我们当前的代码添加到容器中）。然后我们需要安装openjdk和 grande,git克隆代码，编译它并构建ROOT.war。之后，我们将 ROOT.war文件移动到Tomcat目录中，然后我们进行一些最终配置，以使用entrypoint.sh脚本准备和启动容器。但是这样的结果可能并不是我们想要的，容器本身看起来很不错，但是该镜像的大小（934MB）很大，尽管我们做了一些挽救措施，删除克隆的代码，甚至于可以删除git，但是最大的问题是jdk，因为这个镜像本身的大小是464M。那么更好的办法，你可以使用alpine基础镜像包。我们继续往下看。更妥善的方法：Docker Multi-Stage自Docker版本17。05（2017年10月）起可用的Docker Multi-Stage将通过删除不再需要的库，依赖项，包等来减少容器的最终大小。该过程包括：将构建分成不同的阶段，只保留每个阶段的最终结果并将其移动到下一个阶段。在Dockerfile中使用多个FROM语句。每个FROM指令可以使用不同的基础，并且每个指令都开始构建的新阶段。有选择地将工件从一个阶段复制到另一个阶段。我们可以将最后一个Dockerfile片段转换为下一个：我们修改了方式，不在容器中克隆代码，而是复制进容器分段执行FROM openjdk:8 MAINTAINER www.linuxea.com mark COPY . /usr/src/project WORKDIR /usr/src/project RUN wget https://downloads.gradle.org/distributions/gradle-4.8.1-bin.zip \ && unzip gradle-4.8.1-bin.zip \ && PATH=$PATH:$PWD/gradle-4.8.1/bin \ && gradle prod FROM tomcat:9.0.16-jre8 MAINTAINER www.linuxea.com mark COPY --from=0 /usr/src/project/build/ROOT.war /usr/local/tomcat/webapps/ROOT.war COPY entrypoint.sh / COPY tomcat_conf_prod/* /usr/local/tomcat/conf/ RUN chmod +x /entrypoint.sh亦或者这样：FROM maven:3-jdk-11 MAINTAINER www.linuxea.com mark COPY linuxea /linuxea RUN mvn -f /linuxea/pom.xml clean package FROM marksugar/java:jdk1.8.0_131 MAINTAINER www.linuxea.com mark COPY --from=build /linuxea /linuxea EXPOSE 8086 CMD ["/linuxea/target/hello-world-0.0.6.jar"]Docker Multi-Stage与使用Builder模式相比如何？主要区别在于，使用Docker Multi-Stage，我们在同一个Dockerfile中构建了两个不同的镜像。第一个是基于openjdk我们用它来编译我们的代码并生成ROOT.war文件。当我们声明第二个基于Tomcat的镜像时，就会发生改变，我们使用--from=0指令将ROOT.war从第一个镜像复制到第二个镜像。这样做，我们放弃了Gradle（构建工具）用于编译我们的应用程序的所有依赖项，并且只保留最重要的东西，我们的ROOT.war文件。你是否在担心，这个--from=0的问题？事实上这个名称是可以进行命名的 ,如下示例：FROM golang:1.7.3 as builder WORKDIR /go/src/github.com/alexellis/href-counter/ RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app . FROM alpine:latest WORKDIR /root/ COPY --from=builder /go/src/github.com/alexellis/href-counter/app .总结不必局限于第一个镜像的大小，你可以将所有的操作都在里面运行，因为对于第一个镜像来讲，仅做加工，而后将输出输出到第二个镜像，而第二个镜像才是我们将会使用的镜像，而第二个镜像只有存在编译完成的包，仅用来进行run。从安全方面来讲，有一定的意义你也可以在本地编写脚本执行打包，编译，而后在添加到镜像中，某些时候，脚本来完成似乎更加方便，仅对脚本高手来讲（并不建议）。你的镜像也不一定要使用tomcat的官方包，你甚至可以用来修改成自定义的模样，如：alpine，更小的体积，在此之上安装附带一些能够更快，更高效前提下的操作等。并且你不需要拘于某一种形式来做，只需要快捷提供一个小巧的，满足条件的镜像即可。常用于ci/cd构建，在一些环境下，缓存对于构建有加速的作用学习更多学习如何使用Docker CLI命令，Dockerfile命令，使用这些命令可以帮助你更有效地使用Docker应用程序。查看Docker文档和我的其他帖子以了解更多信息。docker目录白话容器

linuxea:如何利用docker构建缓存快速迭代？ 在本文中，你将学习如何使用docker 构建缓存。CachingDocker的优势之一是它提供了缓存，可帮助你更快地迭代镜像构建。构建映像时，Docker会逐步执行Dockerfile中的指令，按顺序执行每个指令。在检查每条指令时，Docker在其缓存中查找现有的中间镜像，它可以重复使用而不是创建新的（重复的）中间镜像。如果缓存无效，则使其无效的指令和所有后续Dockerfile指令都会生成新的中间映像。一旦缓存失效，就可以使用Dockerfile中的其余指令。所以从Dockerfile的顶部开始，如果基本映像已经在缓存中，则重用它。否则，缓存无效。然后将下一条指令与从该基本镜像导出的高速缓存中的所有子镜像进行比较。比较每个缓存的中间镜像以查看指令是否找到缓存命中。如果是高速缓存未命中，则高速缓存无效。重复相同的过程，直到达到Dockerfile的末尾。大多数新指令只是与中间镜像中的指令进行比较。如果匹配，则使用缓存副本。例如，当RUN pip install -r requirements.txt在Dockerfile中找到指令时，Docker会在其本地缓存的中间镜像中搜索相同的指令。旧的和新的requirements.txt文件的内容不进行比较。如果使用新软件包更新requirements.txt文件并使用RUN pip install并希望使用新软件包名称重新运行软件包安装，则此行为可能会出现问题。我马上就会展示一些解决方案。与其他Docker指令不同，ADD和COPY指令确实需要Docker查看文件的内容以确定是否存在缓存命中。将引用文件的校验和与现有中间镜像中的校验和进行比较，在这些校验和中不考虑文件的最后修改时间和最后访问时间。如果文件内容或元数据已更改，则缓存无效。除了ADD和COPY命令之外，缓存检查不会查看容器中的文件来确定缓存匹配。例如，在处理RUN apt-get -y update命令时，不检查容器中更新的文件以确定是否存在缓存命中。在这种情况下，只需使用命令字符串本身来查找匹配项。以下是有效使用缓存的一些提示。缓存可以通过将关闭--no-cache=True与docker build。如果你要对指令进行更改，则后续的每个层都将经常重建。要利用缓存，请将可能更改的指令放在Dockerfile中尽可能低的位置。Chain RUN apt-get update和apt-get install命令，以避免缓存未命中问题。如果你正在使用包装安装程序（如pip和requirements.txt文件），请按照下面的模型进行操作，以确保你没有收到带有requirements.txt中列出的旧包的陈旧中间映像。COPY requirements.txt /tmp/ RUN pip install -r /tmp/requirements.txt COPY . /tmp/一旦高速缓存失效，所有后续Dockerfile命令都会生成新图像，并且不使用高速缓存。如何利用缓存？如何利用缓存来快速的构建？为了演示这一点，我们构建一个镜像，Dockerfile如下：[root@www.linuxea.com /opt/2019/none]# cat Dockerfile FROM alpine:3.9 MAINTAINER www.linuxea.com LABEL maintainer="www.linuxea.com" RUN apk update \ && apk add gcc RUN echo "hello www.linuxea.com see you!" >> /linuxea.txt其中，在update后安装了gcc，并且echo "hello www.linuxea.com see you!" >> /linuxea.txt中，而后开始build[root@www.linuxea.com /opt/2019/none]# docker build -t linuxea.com:t0.1 . Sending build context to Docker daemon 5.12kB Step 1/5 : FROM alpine:3.9 ---> caf27325b298 Step 2/5 : MAINTAINER www.linuxea.com ---> Using cache ---> 5ee27f5e579a Step 3/5 : LABEL maintainer="www.linuxea.com" ---> Using cache ---> a9b2f826f6c9 Step 4/5 : RUN apk update && apk add gcc ---> Running in 79fc02b7c52d fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/x86_64/APKINDEX.tar.gz fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/community/x86_64/APKINDEX.tar.gz v3.9.0-28-g04484bcf48 [http://dl-cdn.alpinelinux.org/alpine/v3.9/main] v3.9.0-27-g022fc53172 [http://dl-cdn.alpinelinux.org/alpine/v3.9/community] OK: 9751 distinct packages available (1/10) Installing binutils (2.31.1-r2) (2/10) Installing gmp (6.1.2-r1) (3/10) Installing isl (0.18-r0) (4/10) Installing libgomp (8.2.0-r2) (5/10) Installing libatomic (8.2.0-r2) (6/10) Installing libgcc (8.2.0-r2) (7/10) Installing mpfr3 (3.1.5-r1) (8/10) Installing mpc1 (1.0.3-r1) (9/10) Installing libstdc++ (8.2.0-r2) (10/10) Installing gcc (8.2.0-r2) Executing busybox-1.29.3-r10.trigger OK: 92 MiB in 24 packages Removing intermediate container 79fc02b7c52d ---> 7a01adbc2a78 Step 5/5 : RUN echo "hello www.linuxea.com see you!" >> /linuxea.txt ---> Running in 52ada0971e54 Removing intermediate container 52ada0971e54 ---> b17ef9b4b4be Successfully built b17ef9b4b4be Successfully tagged linuxea.com:t0.1那么现在就有一个linuxea.com:t0.1的镜像[root@www.linuxea.com /opt/2019/none]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE linuxea.com t0.1 b17ef9b4b4be 2 minutes ago 95.6MB此后，我们在修改了Dockerfile，添加了RUN echo "hello www.linuxea.com see you two!" >> /linuxea.txt[root@www.linuxea.com /opt/2019/none]# cat Dockerfile FROM alpine:3.9 MAINTAINER www.linuxea.com LABEL maintainer="www.linuxea.com" RUN apk update \ && apk add gcc RUN echo "hello www.linuxea.com see you!" >> /linuxea.txt RUN echo "hello www.linuxea.com see you two!" >> /linuxea.txt重新build[root@www.linuxea.com /opt/2019/none]# docker build -t linuxea.com:t0.2 . Sending build context to Docker daemon 5.12kB Step 1/6 : FROM alpine:3.9 ---> caf27325b298 Step 2/6 : MAINTAINER www.linuxea.com ---> Using cache ---> 5ee27f5e579a Step 3/6 : LABEL maintainer="www.linuxea.com" ---> Using cache ---> a9b2f826f6c9 Step 4/6 : RUN apk update && apk add gcc ---> Using cache ---> 7a01adbc2a78 Step 5/6 : RUN echo "hello www.linuxea.com see you!" >> /linuxea.txt ---> Using cache ---> b17ef9b4b4be Step 6/6 : RUN echo "hello www.linuxea.com see you two!" >> /linuxea.txt ---> Running in fe4dc61a4e1b Removing intermediate container fe4dc61a4e1b ---> 4dbddcf438d6 Successfully built 4dbddcf438d6 Successfully tagged linuxea.com:t0.2你看到了什么？在第二次build的时候，并没有看到RUN apk update && apk add gcc的安装过程，而是使用了此前创建的缓存中间层，如下：学习更多学习如何使用Docker CLI命令，Dockerfile命令，使用这些命令可以帮助你更有效地使用Docker应用程序。查看Docker文档和我的其他帖子以了解更多信息。docker目录白话容器docker-compose

linuxea:什么是docker <none><none> image(镜像)? 我们在使用docker build的过程中经常会遇到<none><none>这类的images状态，那么这篇文章主要来简单的解释它是如何产生的，以及它们的影响，我将尝试解释以下几点：1，什么是<none><none>2，为什么会存在<none><none>3，docker images与docker images -a中<none><none>区别以及删除容器出现Error response from daemon: conflict: unable to delete caf27325b298 (cannot be forced) - image has dependent child images是怎么 回事要理解这一点，我们下载一个alpine:3.9的镜像来做示例，重现上述提到的这几种<none>状态。我先尝试解释，docker images -a中的<none><none>docker images -a中的<none><none>编写一个Dockerfile，假设它如下所示：FROM alpine:3.9 MAINTAINER www.linuxea.com LABEL maintainer="www.linuxea.com" RUN echo "hello www.linuxea.com cool!" > /linuxea.txt如上，从Step 1/4到Step 4/4经历了四个阶段，每一个阶段分别有一个标识，分别是：caf27325b298，932697f3313a，21b1f26af8b8，e7367313b8e2如下图：Step 1/4 : FROM alpine:3.9 3.9: Pulling from library/alpine 6c40cc604d8e: Pull complete ---> caf27325b298 Step 2/4 : MAINTAINER www.linuxea.com ---> Running in 0b51600da82c Removing intermediate container 0b51600da82c ---> 932697f3313a Step 3/4 : LABEL maintainer="www.linuxea.com" ---> Running in 6f376b8eeb14 Removing intermediate container 6f376b8eeb14 ---> 21b1f26af8b8 Step 4/4 : RUN echo "hello www.linuxea.com cool!" > /linuxea.txt ---> Running in d5d720c2e07e Removing intermediate container d5d720c2e07e ---> e7367313b8e2这些只读层，从上往下执行，第一个执行完成，执行第二个，一个接一个地运行Dockerfile中的指令，每个层都代表一个Dockerfile指令。这些层是堆叠的，每个层都是前一层变化的增量。在必要时将每条指令的结果提交给新镜像层，最后输出新镜像层的ID。Docker守护程序将自动清理发送的上下文。每条指令创建一个层：FROM alpine:3.9 MAINTAINER www.linuxea.com LABEL maintainer="www.linuxea.com" RUN echo "hello www.linuxea.com cool!" > /linuxea.txtFROM从alpine:3.9Docker镜像创建一个图层。MAINTAINER 添加info信息LABE 添加标签RUN 指定在容器中运行的echo命令。请注意，每条指令都是独立运行的，会导致创建新镜像层 - 因此 echo "hello www.linuxea.com cool!" > /linuxea.txt不会对下一条指令产生任何影响。只要有可能，Docker将重新使用中间图像（缓存），以docker build显着加速该过程。这由Using cache控制台输出中的消息指示。（有关详细信息，请参阅构建高速缓存段的 Dockerfile最佳实践指南）这其中最有意思的还是--cache-from，缓存重用但我们了解上述的表达后，我们使用docker history在看镜像的中间层[root@linuxea.com /opt/2019/none]# docker history linuxea.com:v0.1 IMAGE CREATED CREATED BY SIZE COMMENT e7367313b8e2 2 hours ago /bin/sh -c echo "hello www.linuxea.com cool!… 28B 21b1f26af8b8 2 hours ago /bin/sh -c #(nop) LABEL maintainer=www.linu… 0B 932697f3313a 2 hours ago /bin/sh -c #(nop) MAINTAINER www.linuxea.com 0B caf27325b298 2 weeks ago /bin/sh -c #(nop) CMD ["/bin/sh"] 0B <missing> 2 weeks ago /bin/sh -c #(nop) ADD file:2a1fc9351afe35698… 5.53MB 而这些中间层在构建之后会存放在这里，供给给最上面的读写层。此时，如果使用docker images -a你会看到<none><none> ，这些<none><none>是镜像的中间层，只会在Build的时候产生在本地，并且不能被删除。如果此时，根据IMAGE ID来删除基础镜像便会提示Error response from daemon: conflict: unable to delete caf27325b298 (cannot be forced) - image has dependent child images正确的删除方式是通过镜像REPOSITORY:TAG进行删除依赖的镜像[root@linuxea.com /opt/2019/none]# docker rmi -f alpine:3.9 Untagged: alpine:3.9 Untagged: alpine@sha256:b3dbf31b77fd99d9c08f780ce6f5282aba076d70a513a8be859d8d3a4d0c92b8docker images <none><none>我们在来看第二种场景，docker images中的none我们准备三个Dockerfile，如下FROM alpine:3.9 MAINTAINER www.linuxea.com LABEL maintainer="www.linuxea.com" RUN echo "hello www.linuxea.com cool!" > /linuxea.txtFROM alpine:3.9 MAINTAINER www.linuxea.com LABEL maintainer="www.linuxea.com" RUN echo "hello www.linuxea.com cool!" > /linuxea.txt RUN echo "hello www.linuxea.com good!" >> /linuxea.txtFROM alpine:3.9 MAINTAINER www.linuxea.com RUN echo "hello www.linuxea.com see you!" >> /linuxea.txt LABEL maintainer="www.linuxea.com" RUN echo "hello www.linuxea.com cool!" >> /linuxea.txt RUN echo "hello www.linuxea.com good!" >> /linuxea.txt第一个build命名linuxea.com:v0.1，第二个命名linuxea.com:v0.2，第三个build命名到linuxea.com:v0.3我们会得到三个镜像[root@DT_Node-172_25_50_250 /opt/2019/none]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE linuxea.com v0.3 9ba68f247813 5 seconds ago 5.53MB linuxea.com v0.2 f14e080bbad1 35 seconds ago 5.53MB linuxea.com v0.1 00a0fad355c1 53 seconds ago 5.53MB alpine 3.9 caf27325b298 2 weeks ago 5.53MB而后在将第三个Dockerfile build成linuxea.com:v0.2[root@linuxea.com /opt/2019/none]# docker build -t linuxea.com:v0.2 .此时就出现了一个<none> <none> ，并且iD是之前的f14e080bbad1，也就是之前的linuxea.com:v0.2[root@linuxea.com /opt/2019/none]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE linuxea.com v0.2 9ba68f247813 About a minute ago 5.53MB linuxea.com v0.3 9ba68f247813 About a minute ago 5.53MB <none> <none> f14e080bbad1 About a minute ago 5.53MB linuxea.com v0.1 00a0fad355c1 2 minutes ago 5.53MB alpine 3.9 caf27325b298 2 weeks ago 5.53MB这又是为什么？我们来大胆的想象一下，如下图：上图中标识每次构建都基于上次构建的层之上进行，如果相同就复用。在最后我们使用docker build -t linuxea.com:v0.2 .事实上是将原本的linuxea.com:v0.2标记到linuxea.com:v0.3的IMAGE ID，而原本的linuxea.com:v0.2就变成了<none><none>，这也就解释了<none><none>的IMAGE ID是f14e080bbad1，和之前的linuxea.com:v0.2一样。而<none><none>这样的镜像是可以通过REPOSITORY:TAG删除的。我想我已经解释明白了开头的三点<none><none>。学习更多学习如何使用Docker CLI命令，Dockerfile命令，使用这些命令可以帮助你更有效地使用Docker应用程序。查看Docker文档和我的其他帖子以了解更多信息。docker目录白话容器docker-compose