Use 「docker image」 in docker v1.13+

This commit is contained in:
khs1994 2017-10-24 13:06:50 +08:00
parent d8632d8554
commit 23d6736c12
6 changed files with 54 additions and 2 deletions

View File

@ -222,3 +222,11 @@ $ docker build - < context.tar.gz
如果发现标准输入的文件格式是 `gzip`、`bzip2` 以及 `xz` 的话,将会使其为上下文压缩包,直接将其展开,将里面视为上下文,并开始构建。 如果发现标准输入的文件格式是 `gzip`、`bzip2` 以及 `xz` 的话,将会使其为上下文压缩包,直接将其展开,将里面视为上下文,并开始构建。
[^1]: [Docker Store](https://store.docker.com/)是发现公共Docker内容镜像发布和发行软件的新地方 [^1]: [Docker Store](https://store.docker.com/)是发现公共Docker内容镜像发布和发行软件的新地方
# Docker 1.13+
在 Docker 1.13+ 版本中推荐使用 docker image 来管理镜像。
```bash
$ docker image build
```

View File

@ -1,5 +1,7 @@
## 利用 commit 理解镜像构成 ## 利用 commit 理解镜像构成
注意: `docker commit` 命令除了学习之外,还有一些特殊的应用场合,比如被入侵后保存现场等。但是,不要使用 `docker commit` 定制镜像,定制镜像应该使用 `Dockerfile` 来完成。如果你想要定制镜像请查看下一章节。
镜像是容器的基础,每次执行 `docker run` 的时候都会指定哪个镜像作为容器运行的基础。在之前的例子中,我们所使用的都是来自于 Docker Hub 的镜像。直接使用这些镜像是可以满足一定的需求,而当这些镜像无法直接满足需求时,我们就需要定制这些镜像。接下来的几节就将讲解如何定制镜像。 镜像是容器的基础,每次执行 `docker run` 的时候都会指定哪个镜像作为容器运行的基础。在之前的例子中,我们所使用的都是来自于 Docker Hub 的镜像。直接使用这些镜像是可以满足一定的需求,而当这些镜像无法直接满足需求时,我们就需要定制这些镜像。接下来的几节就将讲解如何定制镜像。
回顾一下之前我们学到的知识,镜像是多层存储,每一层是在前一层的基础上进行的修改;而容器同样也是多层存储,是在以镜像为基础层,在其基础上加一层作为容器运行时的存储层。 回顾一下之前我们学到的知识,镜像是多层存储,每一层是在前一层的基础上进行的修改;而容器同样也是多层存储,是在以镜像为基础层,在其基础上加一层作为容器运行时的存储层。
@ -124,5 +126,3 @@ docker run --name web2 -d -p 81:80 nginx:v2
此外,使用 `docker commit` 意味着所有对镜像的操作都是黑箱操作,生成的镜像也被称为**黑箱镜像**,换句话说,就是除了制作镜像的人知道执行过什么命令、怎么生成的镜像,别人根本无从得知。而且,即使是这个制作镜像的人,过一段时间后也无法记清具体在操作的。虽然 `docker diff` 或许可以告诉得到一些线索,但是远远不到可以确保生成一致镜像的地步。这种黑箱镜像的维护工作是非常痛苦的。 此外,使用 `docker commit` 意味着所有对镜像的操作都是黑箱操作,生成的镜像也被称为**黑箱镜像**,换句话说,就是除了制作镜像的人知道执行过什么命令、怎么生成的镜像,别人根本无从得知。而且,即使是这个制作镜像的人,过一段时间后也无法记清具体在操作的。虽然 `docker diff` 或许可以告诉得到一些线索,但是远远不到可以确保生成一致镜像的地步。这种黑箱镜像的维护工作是非常痛苦的。
而且,回顾之前提及的镜像所使用的分层存储的概念,除当前层外,之前的每一层都是不会发生改变的,换句话说,任何修改的结果仅仅是在当前层进行标记、添加、修改,而不会改动上一层。如果使用 `docker commit` 制作镜像,以及后期修改的话,每一次修改都会让镜像更加臃肿一次,所删除的上一层的东西并不会丢失,会一直如影随形的跟着这个镜像,即使根本无法访问到™。这会让镜像更加臃肿。 而且,回顾之前提及的镜像所使用的分层存储的概念,除当前层外,之前的每一层都是不会发生改变的,换句话说,任何修改的结果仅仅是在当前层进行标记、添加、修改,而不会改动上一层。如果使用 `docker commit` 制作镜像,以及后期修改的话,每一次修改都会让镜像更加臃肿一次,所删除的上一层的东西并不会丢失,会一直如影随形的跟着这个镜像,即使根本无法访问到™。这会让镜像更加臃肿。
`docker commit` 命令除了学习之外,还有一些特殊的应用场合,比如被入侵后保存现场等。但是,不要使用 `docker commit` 定制镜像,定制行为应该使用 `Dockerfile` 来完成。下面的章节我们就来讲述一下如何使用 `Dockerfile` 定制镜像。

View File

@ -46,6 +46,12 @@ REPOSITORY TAG IMAGE ID CREATED
$ docker rmi $(docker images -q -f dangling=true) $ docker rmi $(docker images -q -f dangling=true)
``` ```
注意:如果你使用的是 Docker 1.13+ 版本,你可以便捷的使用以下命令来删除虚悬镜像。
```bash
$ docker image prune
```
### 中间层镜像 ### 中间层镜像
为了加速镜像构建、重复利用资源Docker 会利用 **中间层镜像**。所以在使用一段时间后,可能会看到一些依赖的中间层镜像。默认的 `docker images` 列表中只会显示顶层镜像,如果希望显示包括中间层镜像在内的所有镜像的话,需要加 `-a` 参数。 为了加速镜像构建、重复利用资源Docker 会利用 **中间层镜像**。所以在使用一段时间后,可能会看到一些依赖的中间层镜像。默认的 `docker images` 列表中只会显示顶层镜像,如果希望显示包括中间层镜像在内的所有镜像的话,需要加 `-a` 参数。
@ -141,3 +147,11 @@ f753707788c5 ubuntu 16.04
f753707788c5 ubuntu latest f753707788c5 ubuntu latest
1e0c3dd64ccd ubuntu 14.04 1e0c3dd64ccd ubuntu 14.04
``` ```
## Docker 1.13+
在 Docker 1.13+ 版本中推荐使用 docker image 来管理镜像。
```bash
$ docker image ls
```

View File

@ -70,3 +70,13 @@ Loaded image: alpine:latest
```bash ```bash
docker save <镜像名> | bzip2 | pv | ssh <用户名>@<主机名> 'cat | docker load' docker save <镜像名> | bzip2 | pv | ssh <用户名>@<主机名> 'cat | docker load'
``` ```
## Docker 1.13+
在 Docker 1.13+ 版本中推荐使用 docker image 来管理镜像。
```bash
$ docker image import
$ docker image load
$ docker image save
```

View File

@ -69,3 +69,15 @@ $
进入容器后,我们可以在 Shell 下操作,执行任何所需的命令。这里,我们执行了 `cat /etc/os-release`,这是 Linux 常用的查看当前系统版本的命令,从返回的结果可以看到容器内是 `Ubuntu 14.04.5 LTS` 系统。 进入容器后,我们可以在 Shell 下操作,执行任何所需的命令。这里,我们执行了 `cat /etc/os-release`,这是 Linux 常用的查看当前系统版本的命令,从返回的结果可以看到容器内是 `Ubuntu 14.04.5 LTS` 系统。
最后我们通过 `exit` 退出了这个容器。 最后我们通过 `exit` 退出了这个容器。
## Docker 1.13+
在 Docker 1.13+ 版本中推荐使用 docker image 来管理镜像。
```bash
$ docker image pull ubunut:17.10
$ docker container run -it --rm \
ubuntu:17.10 \
bash
```

View File

@ -103,3 +103,11 @@ $ docker rmi $(docker images -q -f before=mongo:3.2)
所以对于 CentOS/RHEL 的用户来说,在没有办法使用 `UnionFS` 的情况下,一定要配置 `direct-lvm``devicemapper`,无论是为了性能、稳定性还是空间利用率。 所以对于 CentOS/RHEL 的用户来说,在没有办法使用 `UnionFS` 的情况下,一定要配置 `direct-lvm``devicemapper`,无论是为了性能、稳定性还是空间利用率。
*或许有人注意到了 CentOS 7 中存在被 backports 回来的 `overlay` 驱动,不过 CentOS 里的这个驱动达不到生产环境使用的稳定程度,所以不推荐使用。* *或许有人注意到了 CentOS 7 中存在被 backports 回来的 `overlay` 驱动,不过 CentOS 里的这个驱动达不到生产环境使用的稳定程度,所以不推荐使用。*
## Docker 1.13+
在 Docker 1.13+ 版本中推荐使用 docker image 来管理镜像。
```bash
$ docker image rm
```