《基于Kubernetes的容器云平台实战》——1.3　Docker基本概念

1.3　Docker基本概念

用户使用Docker的一般场景如下：用户在某镜像基础上，在本地生成并标识新镜像；也可根据镜像标识从镜像仓库下载镜像到本地；Docker引擎利用本地镜像创建出多个相互隔离运行的容器；或者先自动下载，然后创建出容器。这里涉及三个基本概念，即镜像、容器和镜像仓库（如图1-2所示）。为了能够很好地理解和运用Docker，有必要先对一些基本概念进行整理和说明。

图1-2　Docker容器示意图

1.3.1　镜像

尽管镜像的创建是Docker引擎的重要功能，但对此话题的介绍可以参考“镜像管理”一章的内容，这里不再赘述。这里首先介绍的是镜像的标识、存储和传输这几方面的内容。

镜像的标识

在Docker中，镜像以及与镜像相关的层、配置都是用十六进制字符串表示的摘要来唯一标识的，这种摘要一般称为ID。但是这种ID形式不利于记忆，因此对于镜像来说，人们更喜欢使用另一种标识形式：example.com:5000/org/app:v1.0.0，被称为镜像的名称或者引用。

这种镜像名称中可以带有镜像仓库的主机名和端口号，下载镜像时，Docker就是根据它们（可以是IP地址加端口号）来访问镜像仓库的。如果镜像名称中没有仓库的主机名和端口号，那么默认仓库域名指向registry-1.docker.io，而端口号为80。Docker访问镜像仓库时一般使用HTTPS，只有对运行在本机上的仓库服务才默认使用HTTP传输。

镜像名称中的路径部分相当于命名空间，并且镜像名后可带有标签（tag）和镜像摘要（digest）部分。标签的前缀为“:”，如果镜像名称中不带有标签的话，Docker会自动为它加上“latest”；而镜像摘要部分的前缀为“@”；这两者最好不要组合使用。

镜像摘要是在镜像仓库创建镜像的时候生成的，也是一个十六进制串（带有表示产生镜像摘要的算法前缀，比如“sha256:”）。Docker引擎可从镜像仓库返回的消息头中得到镜像摘要，并记录在镜像的描述信息中。镜像仓库可以根据镜像名称中的镜像摘要直接准确地索引到镜像的描述文件。

当使用docker images列出本地仓库中的镜像时，可以看到如下输出：

REPOSITORY                TAG    IMAGE ID      CREATED       SIZE

127.0.0.1:5000/alpine-32  3.6.2  c0f08c91ed89  4 months ago  3.92MB

那么，这个镜像的标识为127.0.0.1:5000/alpine-32:3.6.2，其内部镜像ID的缩写，也就是完整摘要串的前缀为c0f08c91ed89。

镜像的存储

Docker引擎将本地镜像默认存储在/var/lib/docker目录下，其中，image目录中包含镜像的元数据以及各个层的链接关系，而实际的镜像层通过AUFS、Btrfs、ZFS、OverlayFS和Device Mapper等支持COW技术的文件系统来构建，并通过内容可寻址的ID，由元数据将它们关联起来。使用了内容可寻址的ID后，就可以在镜像的存储和传输过程中实现镜像层的共享和缓存。

由于历史原因，Docker原生的镜像配置文件中不仅包含镜像层的相互关系，还包含此镜像用于何种平台环境、何种OS、创建时间、默认启动运行命令等很多元数据。而经过标准化的manifest文件只包含各个层的描述符，以及这个原生配置文件对应的描述符。这两种描述文件都是json格式的。

两种描述文件中都有各个层的摘要信息的汇聚，并且这些层是有严格的前后顺序的。Docker原生镜像配置文件中各个层的本地标识与标准化的manifest中各个层的摘要不一样，原因在于manifest中各个层的摘要是直接根据各个层的tar格式归档文件来计算的，而原生镜像配置文件中的各个层的摘要是先对各个层中包含的每一个文件计算其摘要，再与目录信息组成一个列表，将这个列表用tar格式归档文件保存起来，并计算其摘要作为各个层的标识。在镜像仓库中，除了保存各个层的tar文件之外，还需要保存镜像对应的Docker原生镜像配置文件，此配置文件也有自己的摘要，也会在manifest文件中有对应描述。但是在Docker引擎中并不保存manifest文件，而只保存各个层的摘要和本地标识之间的对应

关系。

这里只给出一个manifest json串的例子，原因在于镜像传输过程中，它是与镜像仓库之间交互的基础：

{

    "schemaVersion": 2,

    "mediaType": "application/vnd.docker.distribution.manifest.v2+json",

    "config": {

        "mediaType": "application/vnd.docker.container.image.v1+json",

        "size": 1702,

        "digest": "sha256:c0f08c91..."

    },

    "layers": [

        {

            "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",

            "size": 2045593,

            "digest": "sha256:c493eb32..."

        },

        {

            "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",

            "size": 8259,

            "digest": "sha256:eb43f181..."

        }

    ]

}

镜像的传输

客户端在上传和下载镜像时，首先请求和发送manifest文件，然后是配置文件和各个层的归档压缩文件。由于每个元素都对应着唯一摘要，只要请求中带上它，不管是镜像仓库还是Docker引擎，都可以据此判断出镜像或者某个层是否已经存储在本地了。只有镜像仓库或者本地没有的镜像/镜像层，才需要上传和下载。

在传输的每一个步骤中都使用media-type以说明请求和载荷的内容。比如：application/vnd.docker.distribution.manifest.v2+json，对应着manifest文件。这些media-type已经被标准化，并且整个传输过程也被标准化了。