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:了解uid和gid如何在docker容器中工作 了解用户名，组名，用户ID（uid）和组ID（gid）如何在容器内运行的进程与主机系统之间进行映射对于构建安全系统非常重要。如果没有提供任何其他选项，容器中的进程将以root身份执行（除非在Dockerfile中提供了不同的uid）。本文将解释这是如何工作的，如何正确授予权限并显示示例来说明。逐步分析uid/gid安全性首先，让我们回顾一下如何实现uid和gid。linux内核负责管理uid和gid空间，它的内核级系统调用用于确定是否应该授予所请求的权限。例如，当进程尝试写入文件时，内核会检查创建该进程的uid和gid，以确定它是否具有足够的权限来修改该文件。这里不使用用户名，使用uid。在服务器上运行Docker容器时，仍然只有一个内核。容器化带来的巨大价值在于所有这些独立的进程可以继续共享单个内核。这意味着即使在运行Docker容器的服务器上，整个uids和gids也由单个内核控制。所以你不能让不同的用户在不同的容器中使用相同的uid。这是因为在常见的linux工具中显示的用户名（和组名）不是内核的一部分，而是由外部工具（/etc/passwd，LDAP，Kerberos等）管理。因此，你可能会看到不同的用户名，但即使在不同的容器内，你也无法为同一个uid/gid拥有不同的权限。这一开始看起来很混乱，所以让我们用几个例子说明一下：简单的Docker运行我将首先以docker组中的普通用户（linuxea）身份登录服务器。这允许我在不使用sudo命令的情况下启动docker容器。然后，从容器外部，让我们看看这个过程是如何出现的。[root@www-linuxea-com ~]# useradd linuxea -G docker [linuxea@www-linuxea-com ~]# su - linuxea[linuxea@www-linuxea-com ~]$ docker run -d alpine:3.9 sleep 10000 e18b6e93b21a30f095ca0c6cbfbd0762dcbc220b3c057a7233c5371fe4f40c47[linuxea@www-linuxea-com ~]$ ps aux|grep sleep root 7145 0.5 0.0 1520 4 ? Ss 15:57 0:00 sleep 10000 linuxea 7203 0.0 0.1 112716 2192 pts/0 S+ 15:58 0:00 grep --color=auto sleep这很有趣。即使我从未输入sudo并且我不是root用户，我执行的sleep命令也以root用户身份启动并具有root权限。我怎么知道它有root权限？容器内的root = =容器外的root吗？是的，因为，正如我所提到的，有一个内核和一个共享的uids和gids池。因为用户名在容器外部显示为“root”，所以我可以肯定地知道容器内的进程是由具有uid = 0的用户启动的。定义用户的Dockerfile当我在Dockerfile中创建不同的用户并以该用户身份启动命令时会发生什么？为了简化这个例子，我没有在这里指定一个gid，但同样的概念适用于组ID。首先，我将这些命令作为用户“linuxea”运行，其uid为1001。[linuxea@www-linuxea-com ~]$ echo $UID 1001Dockerfile[linuxea@www-linuxea-com ~]$ cat 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 ["sleep","30000"]让我们构建并运行它：[linuxea@www-linuxea-com ~]$ docker build -t test . Sending build context to Docker daemon 6.656kB Step 1/5 : FROM alpine:latest ---> caf27325b298 Step 2/5 : MAINTAINER www.linuxea.com mark ---> Using cache ---> 97c60ecc6438 Step 3/5 : RUN addgroup www && adduser -u 1001 -S -H -s /sbin/nologin -g 'nginx' -G www www ---> Running in dd3eaaa2d820 Removing intermediate container dd3eaaa2d820 ---> 1a81d642cab6 Step 4/5 : USER www ---> Running in fedfcda0d798 Removing intermediate container fedfcda0d798 ---> fc564057218b Step 5/5 : ENTRYPOINT ["sleep","30000"] ---> Running in a87dfbe5edd8 Removing intermediate container a87dfbe5edd8 ---> 0b28fd7c7ad1 Successfully built 0b28fd7c7ad1 Successfully tagged test:latest[linuxea@www-linuxea-com ~]$ docker run -d test 06494798ce210032582e21a2b3f990fcdfe3e9623402c41bd78f4c22fa5ce518[linuxea@www-linuxea-com ~]$ ps aux|grep sleep linuxea 10652 0.1 0.0 1520 4 ? Ss 16:42 0:00 sleep 30000 linuxea 10716 0.0 0.1 112716 2144 pts/0 S+ 16:42 0:00 grep --color=auto sleep[linuxea@www-linuxea-com ~]$ docker exec -i 0649 ps aux|grep sleep 1 www 0:00 sleep 30000?到底发生了什么，这表明了什么？我构建了一个Docker镜像，其用户名为“www”，该用户的定义uid为1001.在我的测试服务器上，我正在使用的帐户名为“linuxea”，它的uid为1001。我启动容器，sleep命令作为www执行，因为Dockerfile包含“ADDUSER www”行。但这实际上并没有使它作为www运行，它使它作为用户的uid运行，Docker镜像是已知www用户是自己的用户的。当我检查在容器外部运行的进程时，我看到它被映射到用户“linuxea”，但是在容器内部它被映射到用户“www”。这两个用户名只显示其执行上下文已知的用户名映射到1001。这不是非常重要的。但重要的是要知道在容器内部，用户“www”从容器外获取用户“linuxea”的权限和特权。在linux主机上向用户linuxea或uid 1001授予权限也将授予容器内www的这些权限。如何控制容器的访问权限另一种选择是运行docker容器并指定用户名或uid，以及运行时的组名或gid。再次使用上面的初始示例。[linuxea@www-linuxea-com ~]$ docker run -d --user 1001 alpine:3.9 sleep 30001 b197a816bdc0a71060331e2b5a6701432cce786161e2d9939dd3a50eabf0fa9b[linuxea@www-linuxea-com ~]$ ps aux|grep sleep linuxea 12071 0.7 0.0 1520 4 ? Ss 17:01 0:00 sleep 30001 linuxea 12131 0.0 0.1 112716 2216 pts/0 S+ 17:01 0:00 grep --color=auto sleep我在这做什么?我创建了容器以作为1001用户启动。因此，当我执行诸如ps或top（或大多数监视工具）之类的命令时，该过程将映射到“linuxea”用户。有趣的是，当我执行到该容器时，你可以看到1001用户在/etc/passwd文件中没有条目，并在容器的bash提示符中显示为“I have no name！”。现在我使用ubuntu[linuxea@www-linuxea-com ~]$ docker run -d --user 1001 ubuntu:19.04 sleep 30001 a658a0a5b49db14831d83b792413dc0cc08112877c64ffb2006c4c0e716a83f4[linuxea@www-linuxea-com ~]$ docker exec -it a65 bash I have no name!@a658a0a5b49d:/$ 需要注意的是，在创建容器时指定用户标志也会覆盖Dockerfile中的该值。还记得第二个例子，我使用的Dockerfile有一个映射到本地主机上不同用户名的uid吗？当我们在命令行上使用用户标志运行它以启动执行“sleep 30000”过程的容器时会发生什么？[linuxea@www-linuxea-com ~]$ docker run -d test 25a0cdc509b2d56185fd42046249d2b53c3a84e393f76c1ca304e552b5ab1058 [linuxea@www-linuxea-com ~]$ ps aux|grep sleep linuxea 14157 0.6 0.0 1520 4 ? Ss 17:18 0:00 sleep 30000 linuxea 14215 0.0 0.1 112716 2144 pts/1 S+ 17:18 0:00 grep --color=auto sleep[linuxea@www-linuxea-com ~]$ docker run -d --user 0 test 5dc20cacd8d8c075c3e0ba910a72b36c16b851ef9a7ef56a4d90a2c97d148dc6 [linuxea@www-linuxea-com ~]$ ps aux|grep sleep linuxea 14157 0.1 0.0 1520 4 ? Ss 17:18 0:00 sleep 30000 root 14275 3.0 0.0 1520 4 ? Ss 17:18 0:00 sleep 30000 linuxea 14330 0.0 0.1 112716 2216 pts/1 S+ 17:18 0:00 grep --color=auto sleep在上面的最后一个例子中，你可以看到我最终有2个容器运行睡眠过程，一个用作“linuxea”，另一个用作“root”。这是因为第二个命令通过--user在命令行上传递标志来更改uid 。权限测试为了更好的验证这些，我们来测试一下。众所周知，普通用户是无法删除root用户创建的文件的[linuxea@www-linuxea-com /opt]$ \rm -rf 2 rm: cannot remove ‘2’: Permission denied如果此时，我们将这些文件挂载到容器内，请注意，我通过不同的用户ID挂载后，进行删除user=0[linuxea@www-linuxea-com ~]$ docker run -d --user=0 -v /opt:/opt test[linuxea@www-linuxea-com ~]$ docker exec -it modest_newton sh / # cd /opt/ /opt # ls 1 2 2019 /opt # \rm -rf 1 /opt # ls 2 2019 /opt # 使用--user=0后进行挂载，可以顺利删除root创建的目录user=1001[linuxea@www-linuxea-com /opt]$ docker run -d --user=1001 -v /opt:/opt test a4663d98c6e89f5c4af0f34516f0c4efe48a6fa881af881da5d8fd4029d9ccf8[linuxea@www-linuxea-com /opt]$ docker exec -it a46 sh / $ cd /opt/ /opt $ ls 2 2019 /opt $ ls -l total 4 -rw-r--r-- 1 root root 3784 Feb 15 06:44 2 drwxr-xr-x 4 root root 174 Feb 19 02:35 2019 /opt $ \rm -rf 2 rm: can't remove '2': Permission denied显而易见，单单从上述来看，普通用户似乎更为安全为了改善这一点，我们可以使用券权限来解决，仍然使用--user=0，挂在的/opt权限是ro，这样就不能被删除了。如下：[linuxea@www-linuxea-com ~]$ docker run -d --user=0 -v /opt:/opt:ro test ac8cc54d81dec6b528519c85f845c15c6b8515ab2777dff6d0a51cae59350ad2 [linuxea@www-linuxea-com ~]$ docker exec -it ac8 sh / # cd /opt/ /opt # ls 2 2019 /opt # \rm -rf 2 rm: can't remove '2': Read-only file system /opt # ls -ll total 4 -rw-r--r-- 1 www root 3784 Feb 15 06:44 2 drwxr-xr-x 4 root root 174 Feb 19 02:35 2019 /opt # \rm -rf 2019 rm: can't remove '2019/1.sh': Read-only file system rm: can't remove '2019/go1.11.4.linux-amd64.tar.gz': Read-only file system rm: can't remove '2019/pipe.go': Read-only file system rm: can't remove '2019/telnet.go': Read-only file system rm: can't remove '2019/telnet.sh': Read-only file system但是普通用户1001赋予rw，仍然无法删除[linuxea@www-linuxea-com /opt]$ docker run -d --user=1001 -v /opt:/opt:rw test a7cc54fd596df7b9f226d2633cd5fdffa5b6784469a2f6b37e944cdac0633db5 [linuxea@www-linuxea-com /opt]$ docker exec -it a7cc sh / $ cd /opt /opt $ ls 2 2019 /opt $ ls -ll total 4 -rw-r--r-- 1 www root 3784 Feb 15 06:44 2 drwxr-xr-x 4 root root 174 Feb 19 02:35 2019 /opt $ \rm -rf 2 rm: can't remove '2': Permission denied /opt $ \rm -rf 2019 rm: can't remove '2019/1.sh': Permission denied rm: can't remove '2019/go1.11.4.linux-amd64.tar.gz': Permission denied rm: can't remove '2019/pipe.go': Permission denied rm: can't remove '2019/telnet.go': Permission denied另外，我们还需要知道一点，尽管是root用户user=0，但是与宿主机的root用户权限还是有与别的，突破这一点，我们需要使用特权模式--privileged/opt # ls -ll /dev total 0 lrwxrwxrwx 1 root root 11 Feb 20 10:01 core -> /proc/kcore lrwxrwxrwx 1 root root 13 Feb 20 10:01 fd -> /proc/self/fd crw-rw-rw- 1 root root 1, 7 Feb 20 10:01 full drwxrwxrwt 2 root root 40 Feb 20 10:01 mqueue crw-rw-rw- 1 root root 1, 3 Feb 20 10:01 null lrwxrwxrwx 1 root root 8 Feb 20 10:01 ptmx -> pts/ptmx drwxr-xr-x 2 root root 0 Feb 20 10:01 pts crw-rw-rw- 1 root root 1, 8 Feb 20 10:01 random drwxrwxrwt 2 root root 40 Feb 20 10:01 shm lrwxrwxrwx 1 root root 15 Feb 20 10:01 stderr -> /proc/self/fd/2 lrwxrwxrwx 1 root root 15 Feb 20 10:01 stdin -> /proc/self/fd/0 lrwxrwxrwx 1 root root 15 Feb 20 10:01 stdout -> /proc/self/fd/1 crw-rw-rw- 1 root root 5, 0 Feb 20 10:01 tty crw-rw-rw- 1 root root 1, 9 Feb 20 10:01 urandom crw-rw-rw- 1 root root 1, 5 Feb 20 10:01 zero而宿主机[linuxea@www-linuxea-com /opt]$ ls /dev autofs cuse fuse lightnvm network_latency raw tty tty16 tty24 tty32 tty40 tty49 tty57 tty8 block disk hidraw0 log network_throughput rtc tty0 tty17 tty25 tty33 tty41 tty5 tty58 tty9 btrfs-control dm-0 hpet loop-control null rtc0 tty1 tty18 tty26 tty34 tty42 tty50 tty59 ttyS0 bus dm-1 hugepages mapper nvram shm tty10 tty19 tty27 tty35 tty43 tty51 tty6 ttyS1 char dm-2 hwrng mcelog port snapshot tty11 tty2 tty28 tty36 tty44 tty52 tty60 ttyS2 console dri initctl mem ppp snd tty12 tty20 tty29 tty37 tty45 tty53 tty61 ttyS3 core fb0 input memory_bandwidth ptmx stderr tty13 tty21 tty3 tty38 tty46 tty54 tty62 uhid cpu fd kmsg mqueue pts stdin tty14 tty22 tty30 tty39 tty47 tty55 tty63 uinput cpu_dma_latency full LBVG net random stdout tty15 tty23 tty31 tty4 tty48 tty56 tty7 urando这意味着什么现在我们已经探讨了这一点，有意义的是，运行具有有限权限的容器的方法都利用来自主机的用户系统：如果有一个已知的uid，即容器内的进程正在执行的用户，它可能就像限制对主机系统的访问一样简单，以便容器中的uid具有有限的访问权限。更好的解决方案是使用已知的uid启动容器--user（你也可以使用用户名，但请记住，它只是从主机的用户名系统提供uid的更友好的方式），然后限制对主机上的uid的访问你决定容器将运行为。因为uid和用户名（以及gid和组名称）从容器映射到主机，指定一个容器进程运行的用户可以使进程看起来由容器内部和外部的不同用户拥有。注意这些测试我在Centos7服务器上运行这些测试。涉及的镜像有Ubuntu 19.04和alpine:3.9 。虽然可以在Docker for OSX上执行相同的命令和测试，但你会看到不同的结果，因为Docker for OSX实际上是在基于Alpine Linux的虚拟机上执行docker-engine，并且你执行的命令是在OSX上执行。学习更多学习如何使用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特权模式与--cap-add和--cap-drop 你可能希望在容器中执行的一些高级操作（例如Docker-in-Docker（DinD），NTP，安装环回设备等），默认情况下将需要比给予容器的root用户更高的权限。因此，需要允许其他特权才能使容器无问题地运行，因此对于该用例，Docker具有非常简单但非常宽泛的特权模式，可将完整主机的功能添加到容器中。要使用此模式，只是追加--privileged到docker run命令：Docker-in-Docker（通常称为DinD）是一种容器的特殊配置，允许你在已经在Docker引擎上运行但不共享Docker套接字的容器内运行Docker引擎，这允许（如果预防措施是在你的基础架构中构建已经容器化的容器的更安全和强大的方法。此配置的流行程度有点罕见，但在用作持续集成（CI）和持续交付（CD）设置的一部分时非常强大。没有额外特权的NTP守护进程，看看会发生什么[root@www.linuxea.com ~]# run -it \ --rm \ cguenther/ntpd ntpd: can't set priority: Permission denied reset adjtime failed: Operation not permitted creating new /var/db/ntpd.drift adjtimex failed: Operation not permitted adjtimex adjusted frequency by 0.000000ppm ntp engine ready reply from 139.99.97.88: offset -0.010032 delay 0.040738, next query 5s settimeofday: Operation not permitted reply from 210.23.25.77: offset -0.003515 delay 0.043521, next query 9s reply from 139.99.41.7: offset -0.017110 delay 0.044403, next query 9s reply from 139.99.97.88: offset -0.012315 delay 0.045440, next query 6s reply from 210.23.25.77: offset -0.008560 delay 0.053329, next query 6s reply from 139.99.97.88: offset -0.007878 delay 0.036450, next query 8s那现在我使用特权模式[root@www.linuxea.com ~]# docker run -it --rm --privileged cguenther/ntpd creating new /var/db/ntpd.drift adjtimex adjusted frequency by 0.000000ppm ntp engine ready reply from 128.199.87.57: offset -0.007699 delay 0.036460, next query 9s set local clock to Mon Feb 18 08:10:32 UTC 2019 (offset -0.007699s) reply from 210.23.25.77: offset 0.005943 delay 0.029169, next query 8s reply from 183.177.72.201: offset 0.018927 delay 0.052242, next query 7s reply from 183.177.72.201: offset 0.020719 delay 0.066146, next query 8s reply from 210.23.25.77: offset 0.000334 delay 0.056709, next query 9s如你所见，添加此标志会从输出中删除所有错误，因为我们现在可以更改系统时间。通过解释此模式的功能，我们现在可以讨论为什么理想情况下，如果可能，你永远不应该使用特权模式。默认情况下，特权模式允许几乎完全访问大多数主机系统，并且在大多数情况下都不够精确，因此在你发现容器需要其他权限后，你应该选择性地添加它们--cap-add。这些标志是标准的Linux功能标识符，你可以在http://man7.org/linux/man-pages/man7/capabilities.7.html等位置找到它们，并允许微调到你想要的访问级别。如果我们现在将我们之前的NTP守护程序示例转换为这种新样式，它应该看起来更像这样：[root@www.linuxea.com ~]# docker run -it --rm cguenther/ntpd ntpd: can't set priority: Permission denied reset adjtime failed: Operation not permitted creating new /var/db/ntpd.drift adjtimex failed: Operation not permitted adjtimex adjusted frequency by 0.000000ppm ntp engine ready现在增加了SYS_TIME功能[root@www.linuxea.com ~]# docker run -it --rm --cap-add SYS_TIME cguenther/ntpd ntpd: can't set priority: Permission denied creating new /var/db/ntpd.drift adjtimex adjusted frequency by 0.000000ppm ntp engine ready reply from 209.58.172.140: offset 0.028803 delay 0.044228, next query 5s set local clock to Mon Feb 18 08:29:25 UTC 2019 (offset 0.028803s) reply from 202.73.57.107: offset -0.027237 delay 0.113698, next query 7s reply from 103.114.160.109: offset 0.000547 delay 0.210185, next query 8s如果你注意到，由于另一个缺少功能，我们仍然可以看到错误，但settimeofday 错误 消失了，这是我们需要修复此容器运行的最重要问题。有趣的是，--cap-drop如果我们想要提高安全性，我们也可以从我们的容器中删除未使用的功能。对于此标志，还有一个特殊关键字，ALL可用于删除所有可用权限。如果我们使用它来完全锁定我们的NTP容器，但一切正常，让我们看看它会是什么样子：[root@www.linuxea.com ~]# docker run -it \ > --rm \ > --cap-drop ALL \ > --cap-add SYS_TIME \ > --cap-add SYS_CHROOT \ > --cap-add SETUID \ > --cap-add SETGID \ > --cap-add SYS_NICE \ > cguenther/ntpd creating new /var/db/ntpd.drift adjtimex adjusted frequency by 0.000000ppm ntp engine ready reply from 139.162.12.72: offset -0.013927 delay 0.036491, next query 7s set local clock to Mon Feb 18 08:33:24 UTC 2019 (offset -0.013927s) reply from 209.58.172.140: offset 0.021554 delay 0.030414, next query 5s reply from 183.177.72.202: offset 0.006347 delay 0.043784, next query 7s reply from 209.58.172.140: offset 0.029093 delay 0.043691, next query 8s reply from 139.162.12.72: offset 0.000467 delay 0.037517, next query 9s reply from 183.177.72.202: offset 0.013560 delay 0.059300, next query 5s reply from 183.177.72.202: offset 0.014058 delay 0.057387, next query 5s reply from 209.58.172.140: offset 0.028728 delay 0.045038, next query 5s reply from 139.162.12.72: offset 0.000349 delay 0.038627, next query 5s peer 183.177.72.202 now valid reply from 183.177.72.202: offset 0.011139 delay 0.063721, next query 5s peer 209.58.172.140 now valid reply from 209.58.172.140: offset 0.029599 delay 0.043637, next query 9s在这里，我们首先删除了所有功能，然后添加了运行容器所需的几个功能，正如你所看到的，情况正常。在你自己的部署中，我强烈建议如果你有备用开发容量或面向安全性，请花一些时间以这种方式锁定正在运行的容器，因为它们会更加安全，你将更加确信容器以最小特权原则运行。在最小权限原则是在计算机安全，你只允许运行到用户或服务组件所需的最低权限的概念。这个原则是高安全性实现的主要原因，但由于管理访问的假设开销，往往在其他地方找不到，即使它是提高系统安全性和稳定性的好方法。如果你想了解有关此概念的更多信息，请查看最小特权原则。参考： https://docs.docker.com/engine/reference/run/学习更多学习如何使用Docker CLI命令，Dockerfile命令，使用这些命令可以帮助你更有效地使用Docker应用程序。查看Docker文档和我的其他帖子以了解更多信息。docker目录白话容器docker-compose

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

linuxea:如何从docker镜像恢复Dockerfile 有这么两个场景：1，当我丢失了原本的Dockfile，我希望找回Dockerfile，但是我只有镜像2，我希望知道一个镜像中的Dockfile详情鉴于此，我找到了几种解决方案，大致可以复现出Dockfile的很大一部分的内容，如下：我们有必要了解docker history ,但是仅仅使用docker history --no-trunc是无法提取完整docker环境[root@linuxea.com ~]# docker version Client: Version: 18.06.1-ce API version: 1.38 Go version: go1.10.3 Git commit: e68fc7a Built: Tue Aug 21 17:23:03 2018 OS/Arch: linux/amd64 Experimental: false Server: Engine: Version: 18.06.1-ce API version: 1.38 (minimum version 1.12) Go version: go1.10.3 Git commit: e68fc7a Built: Tue Aug 21 17:25:29 2018 OS/Arch: linux/amd64 Experimental: falseDiveDive用于发现docker镜像，镜像层内容以及发现缩小Docker镜像大小的方法的工具。要分析Docker镜像，只需使用图像标记/ id / digest运行潜水：dive <your-image-tag>或者如果你想建立新的，那么直接跳到分析它：dive build -t <some-tag> .建立在Macbook上docker run --rm -it \ -v /usr/local/bin/docker:/bin/docker \ -v /var/run/docker.sock:/var/run/docker.sock \ -v "$(pwd)":"$(pwd)" \ -w "$(pwd)" \ -v "$HOME/.dive.yaml":"$HOME/.dive.yaml" \ wagoodman/dive:latest build -t <some-tag> .rpm安装curl -OL https://github.com/wagoodman/dive/releases/download/v0.6.0/dive_0.6.0_linux_amd64.rpm rpm -i dive_0.6.0_linux_amd64.rpmDive查看Dockerfile使用dive marksugar/redis:5.0.0 即可查看，如下图中。相信你也看到了，这里的内容不止于此Dive CI此外，您可以在CI管道中运行此命令，以确保将浪费的空间保持在最低限度（这会跳过UI）：CI=true dive <your-image>ok，我们本来是看Dockfile的，但是也不妨测试一下镜像的质量使用CI=true dive marksugar/redis:5.0.0bash解决方案我们看一下效果脚本如下：#!/bin/bash ######################################################################### # File Name: dockerfile.sh # Author: www.linuxea.com # Version: 1 # Created Time: Thu 14 Feb 2019 10:52:01 AM CST ######################################################################### case "$OSTYPE" in linux*) docker history --no-trunc --format "{{.CreatedBy}}" $1 | # extract information from layers tac | # reverse the file sed 's,^\(|3.*\)\?/bin/\(ba\)\?sh -c,RUN,' | # change /bin/(ba)?sh calls to RUN sed 's,^RUN #(nop) *,,' | # remove RUN #(nop) calls for ENV,LABEL... sed 's, *&& *, \\\n \&\& ,g' # pretty print multi command lines following Docker best practices ;; darwin*) docker history --no-trunc --format "{{.CreatedBy}}" $1 | # extract information from layers tail -r | # reverse the file sed -E 's,^(\|3.*)?/bin/(ba)?sh -c,RUN,' | # change /bin/(ba)?sh calls to RUN sed 's,^RUN #(nop) *,,' | # remove RUN #(nop) calls for ENV,LABEL... sed $'s, *&& *, \\\ \\\n \&\& ,g' # pretty print multi command lines following Docker best practices ;; *) echo "unknown OSTYPE: $OSTYPE" ;; esac分步说明：docker history --no-trunc --format "{{.CreatedBy}}" $1 从镜像层中提取信息tac 反转文件sed 's,^\(|3.*\)\?/bin/\(ba\)\?sh -c,RUN,' 修改shell调用run的操作sed 's,^RUN #(nop) *,,' '删除/bin/sh调用ENV，LABEL等sed 's, *&& *, \\\n \&\& ,g 以更易读的方式打印此运行 bash dockerfile2.sh CONTAINER_NAME即可，如：[root@linuxea.com ~]# bash dockerfile2.sh marksugar/redis:5.0.0学习更多学习如何使用Docker CLI命令，Dockerfile命令，使用这些命令可以帮助你更有效地使用Docker应用程序。查看Docker文档和我的其他帖子以了解更多信息。docker目录白话容器docker-compose