目录
一 pull拉取
docker pull [选项] [Docker Registry 地址[:端口号]/]仓库名[:标签]
- Docker 镜像仓库地址:地址的格式一般是 <域名/IP>[:端口号]。默认地址是 Docker Hub。
- 仓库名:如之前所说,这里的仓库名是两段式名称,即 <用户名>/<软件名>。对于 Docker Hub,如果不给出用户名,则默认为 library,也就是官方镜像。
[root@zhuyc ~]# docker pull ubuntu:16.04
16.04: Pulling from library/ubuntu
e80174c8b43b: Pull complete
d1072db285cc: Pull complete
858453671e67: Pull complete
3d07b1124f98: Pull complete
Digest: sha256:bb5b48c7750a6a8775c74bcb601f7e5399135d0a06de004d000e05fd25c1a71c
Status: Downloaded newer image for ubuntu:16.04
从下载过程中可以看到我们之前提及的分层存储
的概念,镜像是由多层存储所构成。下载也是一层层的去下载
,并非单一文件。下载过程中给出了每一层的 ID 的前 12 位。并且下载结束后,给出该镜像完整的 sha256 的摘要,以确保下载一致性
二 运行
有了镜像,我们可以运行
docker run 就是运行容器的命令,我们这里简要的说明一下上面用到的参数。
[root@zhuyc ~]# docker run -it --rm \
> ubuntu:16.04 \
> bash
-it
:这是两个参数,一个是 -i:交互式操作,一个是 -t 终端。我们这里打算进入 bash 执行一些命令并查看返回结果,因此我们需要交互式终端。--rm
:这个参数是说容器退出后随之将其删除。默认情况下,为了排障需求,退出的容器并不会立即删除,除非手动 docker rm。我们这里只是随便执行个命令,看看结果,不需要排障和保留结果,因此使用 --rm 可以避免浪费空间。- ubuntu:16.04:这是指用 ubuntu:16.04 镜像为基础来启动容器。
bash
:放在镜像名后的是命令
,这里我们希望有个交互式 Shell
,因此用的是 bash。
补充
沙盒机制
容器和容器是隔离的
三 列出镜像
docker image ls
或
docker images
镜像 ID 则是镜像的唯一标识,一个镜像可以对应多个标签
3.1 镜像体积
一般 Docker Hub中的大小比我们用docker images
看到的小。那是因为Docker Hub中展示的是压缩后的文件大小。二我们本地展示的是:解压后,各层
总共本地磁盘空间占用的大小。
docker image ls 列表中的镜像体积总和并非
是所有镜像实际硬盘消耗。由于 Docker 镜像是多层存储结构,并且可以继承、复用
,因此不同镜像可能会因为使用相同的基础镜像,从而拥有共同的层。由于 Docker 使用 Union FS,相同的层只需要保存一份即可,因此实际镜像硬盘占用空间很可能要比这个列表镜像大小的总和要小的多
。
你可以通过以下命令来便捷的查看镜像、容器、数据卷所占用的空间。
[root@zhuyc ~]# docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 1 0 122.6MB 122.6MB (100%)
Containers 0 0 0B 0B
Local Volumes 0 0 0B 0B
Build Cache 0B 0B
[root@zhuyc ~]#
3.2 虚悬镜像
一个特殊的镜像,这个镜像既没有仓库名,也没有标签,均为none
,如:
原因
这个镜像原本是有镜像名和标签的,原来为 mongo:3.2
,随着官方镜像维护,发布了新版本
后,重新 docker pull mongo:3.2
时,mongo:3.2 这个镜像名被转移到了新下载的镜像身上,而旧的镜像上的这个名称则被取消
,从而成为了 <none
>。除了 docker pull 可能导致这种情况,docker build 也同样
可以导致这种现象。由于新旧镜像同名,旧镜像名称被取消,从而出现仓库名、标签均为 <none>
的镜像。这类无标签镜像也被称为 虚悬镜像(dangling image) ,可以用下面的命令专门显示这类镜像:
$ docker image ls -f dangling=true
REPOSITORY TAG IMAGE ID CREATED SIZE
<none> <none> 00285df0df87 5 days ago 342 MB
一般来说,虚悬镜像已经失去了存在的价值,是可以随意删除的,可以用下面的命令删除。
$ docker image prune
3.3 中间层镜像
为了加速镜像构建、重复利用资源,Docker 会利用 中间层镜像。所以在使用一段时间后,可能会看到一些依赖的中间层镜像。默认的 docker image ls 列表中只会显示顶层镜像,如果希望显示包括中间层镜像在内的所有镜像的话,需要加 -a 参数。
$ docker image ls -a
这样会看到很多无标签的镜像,与之前的虚悬镜像不同,这些无标签的镜像很多都是中间层镜像,是其它镜像所依赖的镜像。这些无标签镜像不应该删除,否则会导致上层镜像因为依赖丢失而出错
。实际上,这些镜像也没必要删除,因为之前说过,相同的层只会存一遍
,而这些镜像是别的镜像的依赖,因此并不会因为它们被列出来而多存了一份,无论如何你也会需要它们。只要删除那些依赖它们的镜像后,这些依赖的中间层镜像也会被连带删除
。
四 删除镜像
$ docker image rm [选项] <镜像1> [<镜像2> ...]
或
docker rmi [选项] <镜像1> [<镜像2> ...]
其中,<镜像> 可以是 镜像短 ID、镜像长 ID、镜像名 或者 镜像摘要。
[root@zhuyc ~]# docker rmi 5f2
Untagged: ubuntu:16.04
Untagged: ubuntu@sha256:bb5b48c7750a6a8775c74bcb601f7e5399135d0a06de004d000e05fd25c1a71c
Deleted: sha256:5f2bf26e35249d8b47f002045c57b2ea9d8ba68704f45f3c209182a7a2a9ece5
Deleted: sha256:0ede31ddf30de46bceba5710ea3003a7c422fc518aa7e2fbdfda212b68a7e028
Deleted: sha256:1d7d6a85a6e52d5c6970517e1dbb83bf5cd40fa20fff510586110ace29de4de8
Deleted: sha256:c4ab874de3a30c67f9c36b38e78f2a990ec151deb2d2a888700fc13704d1fd9c
Deleted: sha256:788b17b748c23d38ec62e913e87b084b7e3efda49843b3c0809b1857559b553e
[root@zhuyc ~]#
4.1 Untagged 和 Deleted
如果观察上面这几个命令的运行输出信息的话,你会注意到删除行为分为两类
,一类是 Untagged
,另一类是 Deleted。我们之前介绍过,镜像的唯一标识是其 ID 和摘要,而一个镜像可以有多个标签。
因此当我们使用上面命令删除镜像的时候,实际上是在要求删除某个标签的镜像
。所以首先需要做的是将满足我们要求的所有镜像标签都取消,这就是我们看到的 Untagged 的信息。因为一个镜像可以对应多个标签,因此当我们删除了所指定的标签后,可能还有别的标签指向了这个镜像
,如果是这种情况,那么 Delete 行为就不会发生
。所以并非所有的 docker image rm 都会产生删除镜像的行为,有可能仅仅是取消了某个标签而已。
当该镜像所有的标签都被取消了,该镜像很可能会失去了存在的意义
,因此会触发删除
行为。镜像是多层存储结构,因此在删除的时候也是从上层向基础层方向依次进行判断删
除。镜像的多层结构让镜像复用变动非常容易,因此很有可能某个其它镜像正依赖于当前镜像的某一层。这种情况,依旧不会触发删除该层的行为。直到没有任何层依赖当前层时,才会真实的删除当前层。这就是为什么,有时候会奇怪,为什么明明没有别的标签指向这个镜像,但是它还是存在的原因,也是为什么有时候会发现所删除的层数和自己 docker pull 看到的层数不一样的源。
除了镜像依赖以外,还需要注意的是容器对镜像的依赖。如果有用这个镜像启动的容器存在(即使容器没有运行
),那么同样不可以删除这个镜像。之前讲过,容器是以镜像为基础,再加一层容器存储层,组成这样的多层存储结构去运行的。因此该镜像如果被这个容器所依赖的,那么删除必然会导致故障。如果这些容器是不需要的,应该先将它们删除,然后再来删除镜像
4.2 配合docker image ls
像其它可以承接多个实体的命令一样,可以使用docker image ls -q
来配合使用 docker image rm,这样可以成批的删除
希望删除的镜像。我们在“镜像列表”章节介绍过很多过滤镜像列表的方式都可以拿过来使用。
比如,我们需要删除所有仓库名为 redis 的镜像:
$ docker image rm $(docker image ls -q redis)
或者删除所有在 mongo:3.2 之前的镜像:
$ docker image rm $(docker image ls -q -f before=mongo:3.2)
充分利用你的想象力和 Linux 命令行的强大,你可以完成很多非常赞的功能。
4.3 CentOS/RHEL使用docker注意
所以对于CentOS/RHEL
的用户来说,在没有办法使用 UnionFS 的情况下,一定要配置 direct-lvm
给 devicemapper,无论是为了性能、稳定性还是空间利用率。
或许有人注意到了CentOS 7 中存在被 backports 回来的 overlay
驱动,不过 CentOS 里的这个驱动达不到生产环境使用的稳定程度,所以不推荐使用。
五 简单使用Dockerfile 定制镜像
5.1 commit指令
我们运行的容器可能在镜像的基础上做了一些修改,有时候我们希望保存起来,封装成一个更新的镜像。
docker commit 容器id 新的镜像名称
5.2 编写Dockerfile
- 创建一个Dockerfile的文件(不是在容器里面)
- 编写文件,如:
FROM nginx
RUN echo '<h1>Hello, Docker!</h1>' > /usr/share/nginx/html/index.html
FROM 指定基础镜像
所谓定制镜像,那一定是以一个镜像为基础,在其上进行定制。有且只有一个
RUN 执行命令
RUN 指令是用来执行命令行命令的。由于命令行的强大能力,RUN 指令在定制镜像时是最常用的指令之一。其格式有两种:
- shell 格式:
RUN <命令>
,就像直接在命令行中输入的命令一样。刚才写的 Dockerfile 中的 RUN 指令就是这种格式。
RUN echo '<h1>Hello, Docker!</h1>' > /usr/share/nginx/html/index.html
- exec 格式:
RUN ["可执行文件", "参数1", "参数2"]
,这更像是函数调用中的格式。
构建镜像
在 Dockerfile 文件所在目录
执行:
$ docker build -t nginx:v3 .
镜像构建上下文(Context)
如果注意,会看到 docker build 命令最后有一个.
。. 表示当前目录,而 Dockerfile 就在当前目录,因此不少初学者以为这个路径是在指定 Dockerfile 所在路径,这么理解其实是不准确的
。如果对应上面的命令格式,你可能会发现,这是在指定上下文路径。那么什么是上下文呢?
关键:docker是一个cs架构的软件
内容较多且关键,就不总结了。建议看原文。
需要记住:docker是一个容器
,本质是一个进程,不是一个虚拟机