commit
590b0bea31
|
@ -32,7 +32,7 @@
|
||||||
* [ONBUILD 为他人作嫁衣裳](image/dockerfile/onbuild.md)
|
* [ONBUILD 为他人作嫁衣裳](image/dockerfile/onbuild.md)
|
||||||
* [参考文档](image/dockerfile/references.md)
|
* [参考文档](image/dockerfile/references.md)
|
||||||
* [其它制作镜像的方式](image/other.md)
|
* [其它制作镜像的方式](image/other.md)
|
||||||
* [移除](image/rmi.md)
|
* [删除本地镜像](image/rmi.md)
|
||||||
* [镜像加速器](image/mirror.md)
|
* [镜像加速器](image/mirror.md)
|
||||||
* [实现原理](image/internal.md)
|
* [实现原理](image/internal.md)
|
||||||
* [容器](container/README.md)
|
* [容器](container/README.md)
|
||||||
|
|
|
@ -17,7 +17,8 @@
|
||||||
"types": [
|
"types": [
|
||||||
"star",
|
"star",
|
||||||
"watch"
|
"watch"
|
||||||
]
|
],
|
||||||
|
"size": "small"
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
|
@ -30,6 +30,6 @@ RUN curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION-linux-
|
||||||
|
|
||||||
在这里先定义了环境变量 `NODE_VERSION`,其后的 `RUN` 这层里,多次使用 `$NODE_VERSION` 来进行操作定制。可以看到,将来升级镜像构建版本的时候,只需要更新 `7.2.0` 即可,`Dockerfile` 构建维护变得更轻松了。
|
在这里先定义了环境变量 `NODE_VERSION`,其后的 `RUN` 这层里,多次使用 `$NODE_VERSION` 来进行操作定制。可以看到,将来升级镜像构建版本的时候,只需要更新 `7.2.0` 即可,`Dockerfile` 构建维护变得更轻松了。
|
||||||
|
|
||||||
下列指令可以支持环境变量展开:`ADD`、`COPY`、`ENV`、`EXPOSE`、`LABEL`、`USER`、`WORKDIR`、`VOLUME`、`STOPSIGNAL`、`ONBUILD`。
|
下列指令可以支持环境变量展开: `ADD`、`COPY`、`ENV`、`EXPOSE`、`LABEL`、`USER`、`WORKDIR`、`VOLUME`、`STOPSIGNAL`、`ONBUILD`。
|
||||||
|
|
||||||
可以从这个指令列表里感觉到,环境变量可以使用的地方很多,很强大。通过环境变量,我们可以让一份 `Dockerfile` 制作更多的镜像,只需使用不同的环境变量即可。
|
可以从这个指令列表里感觉到,环境变量可以使用的地方很多,很强大。通过环境变量,我们可以让一份 `Dockerfile` 制作更多的镜像,只需使用不同的环境变量即可。
|
||||||
|
|
|
@ -29,9 +29,9 @@ Status: Downloaded newer image for ubuntu:14.04
|
||||||
|
|
||||||
上面的命令中没有给出 Docker Registry 地址,因此将会从 Docker Hub 获取镜像。而镜像名称是 `ubuntu:14.04`,因此将会获取官方镜像 `library/ubuntu` 仓库中标签为 `14.04` 的镜像。
|
上面的命令中没有给出 Docker Registry 地址,因此将会从 Docker Hub 获取镜像。而镜像名称是 `ubuntu:14.04`,因此将会获取官方镜像 `library/ubuntu` 仓库中标签为 `14.04` 的镜像。
|
||||||
|
|
||||||
从下载过程中可以看到我们之前提及的分层存储的概念,镜像是由多层存储所构成。下载也是一层层的去下载,并非单一文件。下载过程中给出了每一层的 ID 的前 12 位。并且下载结束后,给出该镜像完整的 `sha256` 的签名,以确保下载一致性。
|
从下载过程中可以看到我们之前提及的分层存储的概念,镜像是由多层存储所构成。下载也是一层层的去下载,并非单一文件。下载过程中给出了每一层的 ID 的前 12 位。并且下载结束后,给出该镜像完整的 `sha256` 的摘要,以确保下载一致性。
|
||||||
|
|
||||||
在实验上面命令的时候,你可能会发现,你所看到的层 ID 以及 `sha256` 的签名和这里的不一样。这是因为官方镜像是一直在维护的,有任何新的 bug,或者版本更新,都会进行修复再以原来的标签发布,这样可以确保任何使用这个标签的用户可以获得更安全、更稳定的镜像。
|
在实验上面命令的时候,你可能会发现,你所看到的层 ID 以及 `sha256` 的摘要和这里的不一样。这是因为官方镜像是一直在维护的,有任何新的 bug,或者版本更新,都会进行修复再以原来的标签发布,这样可以确保任何使用这个标签的用户可以获得更安全、更稳定的镜像。
|
||||||
|
|
||||||
*如果从 Docker Hub 下载镜像非常缓慢,可以参照后面的章节配置加速器。*
|
*如果从 Docker Hub 下载镜像非常缓慢,可以参照后面的章节配置加速器。*
|
||||||
|
|
||||||
|
|
110
image/rmi.md
110
image/rmi.md
|
@ -1,27 +1,105 @@
|
||||||
## 移除本地镜像
|
## 删除本地镜像
|
||||||
如果要移除本地的镜像,可以使用 `docker rmi` 命令。注意 `docker rm` 命令是移除容器。
|
|
||||||
```
|
如果要删除本地的镜像,可以使用 `docker rmi` 命令,其格式为:
|
||||||
$ sudo docker rmi training/sinatra
|
|
||||||
Untagged: training/sinatra:latest
|
```bash
|
||||||
Deleted: 5bc342fa0b91cabf65246837015197eecfa24b2213ed6a51a8974ae250fedd8d
|
docker rmi [选项] <镜像1> [<镜像2> ...]
|
||||||
Deleted: ed0fffdcdae5eb2c3a55549857a8be7fc8bc4241fb19ad714364cbfd7a56b22f
|
|
||||||
Deleted: 5c58979d73ae448df5af1d8142436d81116187a7633082650549c52c3a2418f0
|
|
||||||
```
|
```
|
||||||
|
|
||||||
*注意:在删除镜像之前要先用 `docker rm` 删掉依赖于这个镜像的所有容器。
|
*注意 `docker rm` 命令是删除容器,不要混淆。*
|
||||||
|
|
||||||
##清理所有未打过标签的本地镜像
|
### 用 ID、镜像名、摘要删除镜像
|
||||||
|
|
||||||
`docker images` 可以列出本地所有的镜像,其中很可能会包含有很多中间状态的未打过标签的镜像,大量占据着磁盘空间。
|
其中,`<镜像>` 可以是 `镜像短 ID`、`镜像长 ID`、`镜像名` 或者 `镜像摘要`。
|
||||||
|
|
||||||
使用下面的命令可以清理所有未打过标签的本地镜像
|
比如我们有这么一些镜像:
|
||||||
|
|
||||||
```
|
```bash
|
||||||
$ sudo docker rmi $(docker images -q -f "dangling=true")
|
$ docker images
|
||||||
|
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||||
|
centos latest 0584b3d2cf6d 3 weeks ago 196.5 MB
|
||||||
|
redis alpine 501ad78535f0 3 weeks ago 21.03 MB
|
||||||
|
docker latest cf693ec9b5c7 3 weeks ago 105.1 MB
|
||||||
|
nginx latest e43d811ce2f4 5 weeks ago 181.5 MB
|
||||||
```
|
```
|
||||||
|
|
||||||
其中 `-q` 和 `-f` 是缩写, 完整的命令其实可以写成下面这样,是不是更容易理解一点?
|
我们可以用镜像的完整 ID,也称为 `长 ID`,来删除镜像。使用脚本的时候可能会用长 ID,但是人工输入就太累了,所以更多的时候是用 `短 ID` 来删除镜像。`docker images` 默认列出的就已经是短 ID 了,一般取前3个字符以上,只要足够区分于别的镜像就可以了。
|
||||||
|
|
||||||
|
比如这里,如果我们要删除 `redis:alpine` 镜像,可以执行:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
$ docker rmi 501
|
||||||
|
Untagged: redis:alpine
|
||||||
|
Untagged: redis@sha256:f1ed3708f538b537eb9c2a7dd50dc90a706f7debd7e1196c9264edeea521a86d
|
||||||
|
Deleted: sha256:501ad78535f015d88872e13fa87a828425117e3d28075d0c117932b05bf189b7
|
||||||
|
Deleted: sha256:96167737e29ca8e9d74982ef2a0dda76ed7b430da55e321c071f0dbff8c2899b
|
||||||
|
Deleted: sha256:32770d1dcf835f192cafd6b9263b7b597a1778a403a109e2cc2ee866f74adf23
|
||||||
|
Deleted: sha256:127227698ad74a5846ff5153475e03439d96d4b1c7f2a449c7a826ef74a2d2fa
|
||||||
|
Deleted: sha256:1333ecc582459bac54e1437335c0816bc17634e131ea0cc48daa27d32c75eab3
|
||||||
|
Deleted: sha256:4fc455b921edf9c4aea207c51ab39b10b06540c8b4825ba57b3feed1668fa7c7
|
||||||
```
|
```
|
||||||
$ sudo docker rmi $(docker images --quiet --filter "dangling=true")
|
|
||||||
|
我们也可以用`镜像名`,也就是 `<仓库名>:<标签>`,来删除镜像。
|
||||||
|
|
||||||
|
```bash
|
||||||
|
$ docker rmi centos
|
||||||
|
Untagged: centos:latest
|
||||||
|
Untagged: centos@sha256:b2f9d1c0ff5f87a4743104d099a3d561002ac500db1b9bfa02a783a46e0d366c
|
||||||
|
Deleted: sha256:0584b3d2cf6d235ee310cf14b54667d889887b838d3f3d3033acd70fc3c48b8a
|
||||||
|
Deleted: sha256:97ca462ad9eeae25941546209454496e1d66749d53dfa2ee32bf1faabd239d38
|
||||||
```
|
```
|
||||||
|
|
||||||
|
当然,更精确的是使用 `镜像摘要` 删除镜像。
|
||||||
|
|
||||||
|
```bash
|
||||||
|
$ docker images --digests
|
||||||
|
REPOSITORY TAG DIGEST IMAGE ID CREATED SIZE
|
||||||
|
node slim sha256:b4f0e0bdeb578043c1ea6862f0d40cc4afe32a4a582f3be235a3b164422be228 6e0c4c8e3913 3 weeks ago 214 MB
|
||||||
|
|
||||||
|
$ docker rmi node@sha256:b4f0e0bdeb578043c1ea6862f0d40cc4afe32a4a582f3be235a3b164422be228
|
||||||
|
Untagged: node@sha256:b4f0e0bdeb578043c1ea6862f0d40cc4afe32a4a582f3be235a3b164422be228
|
||||||
|
```
|
||||||
|
|
||||||
|
### Untagged 和 Deleted
|
||||||
|
|
||||||
|
如果观察上面这几个命令的运行输出信息的话,你会注意到删除行为分为两类,一类是 `Untagged`,另一类是 `Deleted`。我们之前介绍过,镜像的唯一标识是其 ID 和摘要,而一个镜像可以有多个标签。
|
||||||
|
|
||||||
|
因此当我们使用上面命令删除镜像的时候,实际上是在要求删除某个标签的镜像。所以首先需要做的是将满足我们要求的所有镜像标签都取消,这就是我们看到的 `Untagged` 的信息。因为一个镜像可以对应多个标签,因此当我们删除了所指定的标签后,可能还有别的标签指向了这个镜像,如果是这种情况,那么 `Delete` 行为就不会发生。所以并非所有的 `docker rmi` 都会产生删除镜像的行为,有可能仅仅是取消了某个标签而已。
|
||||||
|
|
||||||
|
当该镜像所有的标签都被取消了,该镜像很可能会失去了存在的意义,因此会触发删除行为。镜像是多层存储结构,因此在删除的时候也是从上层向基础层方向依次进行判断删除。镜像的多层结构让镜像复用变动非常容易,因此很有可能某个其它镜像正依赖于当前镜像的某一层。这种情况,依旧不会触发删除该层的行为。直到没有任何层依赖当前层时,才会真实的删除当前层。这就是为什么,有时候会奇怪,为什么明明没有别的标签指向这个镜像,但是它还是存在的原因,也是为什么有时候会发现所删除的层数和自己 `docker pull` 看到的层数不一样的源。
|
||||||
|
|
||||||
|
除了镜像依赖意外,还需要注意的是容器对镜像的依赖。如果有用这个镜像启动的容器存在(即使容器没有运行),那么同样不可以删除这个镜像。之前讲过,容器是以镜像为基础,再加一层容器存储层,组成这样的多层存储结构去运行的。因此该镜像如果被这个容器所依赖的,那么删除必然会导致故障。如果这些容器是不需要的,应该先将它们删除,然后再来删除镜像。
|
||||||
|
|
||||||
|
### 用 docker images 命令来配合
|
||||||
|
|
||||||
|
像其它可以承接多个实体的命令一样,可以使用 `docker images -q` 来配合使用 `docker rmi`,这样可以成批的删除希望删除的镜像。比如之前我们介绍过的,删除虚悬镜像的指令是:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
$ docker rmi $(docker images -q -f dangling=true)
|
||||||
|
```
|
||||||
|
|
||||||
|
我们在“镜像列表”章节介绍过很多过滤镜像列表的方式都可以拿过来使用。
|
||||||
|
|
||||||
|
比如,我们需要删除所有仓库名为 `redis` 的镜像:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
$ docker rmi $(docker images -q redis)
|
||||||
|
```
|
||||||
|
|
||||||
|
或者删除所有在 `mongo:3.2` 之前的镜像:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
$ docker rmi $(docker images -q -f before=mongo:3.2)
|
||||||
|
```
|
||||||
|
|
||||||
|
充分利用你的想象力和 Linux 命令行的强大,你可以完成很多非常赞的功能。
|
||||||
|
|
||||||
|
### CentOS/RHEL 的用户需要注意的事项
|
||||||
|
|
||||||
|
在 Ubuntu/Debian 上有 `UnionFS` 可以使用,如 `aufs` 或者 `overlay2`,而 CentOS 和 RHEL 的内核中没有相关驱动。因此对于这类系统,一般使用 `devicemapper` 驱动利用 LVM 的一些机制来模拟分层存储。这样的做法除了性能比较差外,稳定性一般也不好,而且配置相对复杂。Docker 安装在 CentOS/RHEL 上后,会默认选择 `devicemapper`,但是为了简化配置,其 `devicemapper` 是跑在一个稀疏文件模拟的块设备上,也被称为 `loop-lvm`。这样的选择是因为不需要额外配置就可以运行 Docker,这是自动配置唯一能做到的事情。但是 `loop-lvm` 的做法非常不好,其稳定性、性能更差,无论是日志还是 `docker info` 中都会看到警告信息。官方文档有明确的文章讲解了如何配置块设备给 `devicemapper` 驱动做存储层的做法,这类做法也被称为配置 `direct-lvm`。
|
||||||
|
|
||||||
|
除了前面说到的问题外,`devicemapper` + `loop-lvm` 还有一个缺陷,因为它是稀疏文件,所以它会不断增长。用户在使用过程中会注意到 `/var/lib/docker/devicemapper/devicemapper/data` 不断增长,而且无法控制。很多人会希望删除镜像或者可以解决这个问题,结果发现效果并不明显。原因就是这个稀疏文件的空间释放后基本不进行垃圾回收的问题。因此往往会出现即使删除了文件内容,空间却无法回收,随着使用这个稀疏文件一直在不断增长。
|
||||||
|
|
||||||
|
所以对于 CentOS/RHEL 的用户来说,在没有办法使用 `UnionFS` 的情况下,一定要配置 `direct-lvm` 给 `devicemapper`,无论是为了性能、稳定性还是空间利用率。
|
||||||
|
|
||||||
|
*或许有人注意到了 CentOS 7 中存在被 backports 回来的 `overlay` 驱动,不过 CentOS 里的这个驱动达不到生产环境使用的稳定程度,所以不推荐使用。*
|
||||||
|
|
Loading…
Reference in New Issue