docker镜像

docker镜像

1.镜像的概念

Docker镜像类似于虚拟机中的镜像，是一个只读的模板，也是一个独立的文件系统，包括运行容器所需的数据。

Docker镜像:是Docker容器的静态表示，包括Docker容器所要运行的应用代码及运行时的配置。Docker镜像采用分层的方式构建，每个镜像均由一系列的"镜像层”组成。镜像一旦被创建就无法被修改。

docker镜像采用分层构建机制，最底层为bootfs，其上为rootfs

• bootfs：用于系统引导的文件系统，包括bootloader和kernel，容器启动完成后会被卸载以节约内存资源
• rootfs：位于bootfs之上，表现为docker容器的根文件系统
  • 传统模式中，系统启动之时，内核挂载rootfs会首先将其挂载为“只读”模式，完整性自检完成后将其重新挂载为读写模式
  • docker中，rootfs由内核挂载为“只读”模式，而后通过“联合挂载”技术额外挂载一个“可写”层

2.docker镜像层

1.（内核层）：由AUFS，LXC，Bootfs（boot file system）组成为上层的镜像提供kernel内核支持

AUFS是一个联合文件系统，它使用同一个Linux host上的多个目录，逐个堆叠起来，对外呈现出一个统一的文件系统。AUFS使用该特性，实现了Docker镜像的分层 分层的思想
bootfs：负责与内核交互 主要是引导加载kernel，linux刚启动时会加载bootfs文件系统，在Docker镜像的最底层时bootfs，这一层与经典的Linux/Unix系统是一样的，包含boot加载器和内核。当boot加载完成之后整个内核就都在内存中了，此时内存的使用权已由bootfs转交给内核，此时系统就会卸载bootfs
rootfs（root file system）属于base images 在bootfs之上（base images）比如在linux系统中包含/dev，/proc，/bin，/etc等标准目录和文件，包含创建、启动操作系统的一些必要的组件，rootfs就是各个不同的操作系统的发行版本，比如Ubuntu，CentOS等等
lxc早期的内核引擎与docker引擎对接交互，docker提供一些库文件和引导文件。现在docker自身内置了所需要的lib库
2.base image（基础/系统镜像层）：构建镜像运行的操作系统环境

3.add image（run指令运行的镜像层）：比如nginx镜像的yum安装模块，或者nginx编译安装的指令，使用镜像封装每一个run执行命令

4.Container（可读写执行层）：将下面的镜像组合运行提供给docker client使用

3.docker存储驱动

docker提供了多种存储驱动来实现不同的方式存储镜像，下面是常用的几种存储驱动：

• AUFS：文件级的存储驱动
• OverlayFS：一种Union FS
• Devicemapper：映射框架机构
• Btrfs：文件级存储驱动
• VFS：接口的“原生”的实现，完全没有使用 ‘’联合文件系统或者写时复制技术‘’

AUFS：（AnotherUnionFS）是一种Union FS，是文件级的存储驱动。AUFS是一个能透明覆盖一个或多个现有文件系统的层状文件系统，把多层合并成文件系统的单层表示。简单来说就是支持将不同目录挂载到同一个虚拟文件系统下的文件系统。这种文件系统可以一层一层地叠加修改文件。无论底下有多少层都是只读的，只有最上层的文件系统是可写的。当需要修改一个文件时，AUFS创建该文件的一个副本，使用CoW将文件从只读层复制到可写层进行修改，结果也保存在可写层。在Docker中，底下的只读层就是image，可写层就是Container。

OverlayFS：Overlay是Linux内核3.18后支持的，也是一种Union FS，和AUFS的多层不同的是Overlay只有两层：一个upper文件系统和一个lower文件系统，分别代表Docker的镜像层和容器层。当需要修改一个文件时，使用CoW将文件从只读的lower复制到可写的upper进行修改，结果也保存在upper层。在Docker中，底下的只读层就是image，可写层就是Container。目前最新的OverlayFS为Overlay2。

AUFS和Overlay都是联合文件系统，但AUFS有多层，而Overlay只有两层，所以在做写时复制操作时，如果文件比较大且存在比较低的层，则AUSF会慢一些。而且Overlay并入了linux kernel mainline，AUFS没有。目前AUFS已基本被淘汰。

Devicemapper：Device mapper是Linux内核2.6.9后支持的，提供的一种从逻辑设备到物理设备的映射框架机制，在该机制下，用户可以很方便的根据自己的需要制定实现存储资源的管理策略。AUFS和OverlayFS都是文件级存储，而Device mapper是块级存储，所有的操作都是直接对块进行操作，而不是文件。Device mapper驱动会先在块设备上创建一个资源池，然后在资源池上创建一个带有文件系统的基本设备，所有镜像都是这个基本设备的快照，而容器则是镜像的快照。所以在容器里看到文件系统是资源池上基本设备的文件系统的快照，并没有为容器分配空间。当要写入一个新文件时，在容器的镜像内为其分配新的块并写入数据，这个叫用时分配。当要修改已有文件时，再使用CoW为容器快照分配块空间，将要修改的数据复制到在容器快照中新的块里再进行修改。

OverlayFS是文件级存储，Device mapper是块级存储，当文件特别大而修改的内容很小，Overlay不管修改的内容大小都会复制整个文件，对大文件进行修改显然要比小文件要消耗更多的时间，而块级无论是大文件还是小文件都只复制需要修改的块，并不是整个文件，在这种场景下，显然device mapper要快一些。因为块级的是直接访问逻辑盘，适合IO密集的场景。而对于程序内部复杂，大并发但少IO的场景，Overlay的性能相对要强一些。

Btrfs：Btrfs被称为下一代写时复制文件系统，并入Linux内核，也是文件级存储驱动，但可以像Device mapper一直接操作底层设备。Btrfs把文件系统的一部分配置为一个完整的子文件系统，称之为subvolume 。采用 subvolume，一个大的文件系统可以被划分为多个子文件系统，这些子文件系统共享底层的设备空间，在需要磁盘空间时便从底层设备中分配，类似应用程序调用 malloc()分配内存一样。为了灵活利用设备空间，Btrfs 将磁盘空间划分为多个chunk 。每个chunk可以使用不同的磁盘空间分配策略。比如某些chunk只存放metadata，某些chunk只存放数据。这种模型有很多优点，比如Btrfs支持动态添加设备。用户在系统中增加新的磁盘之后，可以使用Btrfs的命令将该设备添加到文件系统中。Btrfs把一个大的文件系统当成一个资源池，配置成多个完整的子文件系统，还可以往资源池里加新的子文件系统，而基础镜像则是子文件系统的快照，每个子镜像和容器都有自己的快照，这些快照则都是subvolume的快照。

vfs：对于vfs要创建新层，需要对上一层进行“深度复制”。与其他存储驱动程序相比，这会导致性能降低和磁盘上更多的空间使用。但是，它是健壮，稳定的，并且可以在每种环境中使用

3.docker registry

启动容器时，docker daemon会试图从本地获取相关的镜像，本地镜像不存在时，其将从Registry中下载该镜像并保存到本地。

Registry用于保存docker镜像，包括镜像的层次结构和元数据。用户可以自建Registry，亦可使用官方的Docker Hub。

docker registry的分类：

• Sponsor Registry：第三方的Registry，供客户和Docker社区使用
• Mirror Registry：第三方的Registry，只让客户使用
• Vendor Registry：由发布docker镜像的供应商提供的registry
• Private Registry：通过设有防火墙和额外的安全层的私有实体提供的registry

docker registry的组成：

• Repository
  • 由某特定的docker镜像的所有迭代版本组成的镜像仓库
  • 一个Registry中可以存在多个Repository
    • Repository可分为“顶层仓库”和“用户仓库”
    • 用户仓库名称格式为“用户名/仓库名”
  • 每个仓库可包含多个Tag(标签)，每个标签对应一个镜像
• Index
  • 维护用户帐户、镜像的检验以及公共命名空间的信息
  • 相当于为Registry提供了一个完成用户认证等功能的检索接口

Docker Registry中的镜像通常由开发人员制作，而后推送至“公共”或“私有”Registry上保存，供其他人员使用，例如“部署”到生产环境。

4.Docker Hub

Docker Hub is a cloud-based registry service which allows you to link to code repositories, build your images and test them, stores manually pushed images, and links to Docker Cloud so you can deploy images to your hosts.

（Docker Hub是一个基于云的注册服务，它允许你链接到代码库，构建你的镜像并测试它们，存储手动推送的镜像，并链接到Docker Cloud，这样你就可以将镜像部署到你的主机上。）

It provides a centralized resource for container image discovery, distribution and change management, user and team collaboration, and workflow automation throughout the development pipeline.

（它为容器映像发现、分布和变更管理、用户和团队协作以及整个开发管道中的工作流自动化提供了一个集中的资源。）

• Image Repositories (镜像存储库)

  • Find and pull images from community and official libraries, and manage, push to, and pull from private images libraries to which you have access.

    （从社区和官方库中查找和提取镜像，管理、推送和提取您可以访问的私有镜像库。）

• Automated Builds（自动构建）

  • Automatically create new images when you make changes to a source code repository.

    （在更改源代码存储库时自动创建新镜像）

• Webhooks

  • A feature of Automated Builds, Webhooks let you trigger actions after a successful push to a repository.

    （自动构建的一个特性，Webhooks可以让你在成功推送到存储库后触发操作。）

• Organizations（组织）

  • Create work groups to manage access to image repositories.

• GitHub and Bitbucket Integration （GitHub和Bitbucket集成）

  • Add the Hub and your Docker Images to your current workflows.

    （添加枢纽和您的Docker图像到您的当前工作流程。）