• 镜像的概念
• docker镜像层
• docker存储驱动AUFSOverlayFSDeviceMapper
• docker registry
• docker镜像的制作Docker Hubdocker镜像的获取镜像的生成基于容器制作镜像
• 镜像的导入与导出

镜像的概念

镜像可以理解为应用程序的集装箱，而docker用来装卸集装箱。

docker镜像含有启动容器所需要的文件系统及其内容，因此，其用于创建并启动容器。

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

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

注意：当删除容器时，这个容器自有的“可写”层会一起被删除

docker镜像层

位于下层的镜像称为父镜像（parrent image），最底层的称为基础镜像（base image）；最上层为“可读写”层，其下的均为“只读”层。

docker存储驱动

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

• AUFS
• OverlayFS
• Devicemapper
• Btrfs
• VFS

AUFS

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

AUFS文件系统据说有3W行代码，而ext4文件系统却只有4000-5000行左右代码，这些代码是要被整合进内核的，后来AUFS申请要被合并进内核代码的时候，linuz觉得它这代码太过臃肿，于是拒绝了。因此AUFS这个文件系统一直以来就不是linux内核中自有的文件系统，想用AUFS这个文件系统的话，必须自己向内核打补丁并去编译使用它，但redhat系列的操作系统一向以稳定著称，不会干这种出格的事，所以在redhat系列操作系统中使用AUFS并无可能。而ubuntu上的docker默认使用的就是AUFS。

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的性能相对要强一些。

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中可以存在多个RepositoryRepository可分为“顶层仓库”和“用户仓库”用户仓库名称格式为“用户名/仓库名”每个仓库可包含多个Tag(标签)，每个标签对应一个镜像
• Index维护用户帐户、镜像的检验以及公共命名空间的信息相当于为Registry提供了一个完成用户认证等功能的检索接口

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

docker镜像的制作

多数情况下，我们做镜像是基于别人已存在的某个基础镜像来实现的，我们把它称为base image。比如一个纯净版的最小化的centos、ubuntu或debian。

那么这个最小化的centos镜像从何而来呢？其实这个基础镜像一般是由Docker Hub的相关维护人员，也就是Docker官方手动制作的。这个基础镜像的制作对于Docker官方的专业人员来说是非常容易的，但对于终端用户来说就不是那么容易制作的了。

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.

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

Docker Hub provides the following major features:

• Image RepositoriesFind and pull images from community and official libraries, and manage, push to, and pull from private images libraries to which you have access.
• Automated BuildsAutomatically create new images when you make changes to a source code repository.
• WebhooksA feature of Automated Builds, Webhooks let you trigger actions after a successful push to a repository.
• OrganizationsCreate work groups to manage access to image repositories.
• GitHub and Bitbucket IntegrationAdd the Hub and your Docker Images to your current workflows.

docker镜像的获取

To get Docker images from a remote registry（such as your own Docker registry）and add them to your local system, use the docker pull command：

# docker pull <registry>[:<port>]/[<namespace>/]<name>:<tag>

The is a host that provides the docker-distribution service on TCP （default：5000）

Together, and identify a particular image controlled by at the registry

• Some registries also support raw ;for those, is optional
• When it is included, however, the additional level of hierarchy that provides is usefull to distinguish between images with the same

The additional level of hierarchy of

Namespace	Examples(<namespace>/<name>)
organization	redhat/kubernetes, google/kubernetes
login(username)	Alice/application, bob/application
role	devel/database, test/database, prod/database

镜像的生成

镜像的生成途径：

• Dockerfile
• 基于容器制作
• Docker Hub automated builds

基于容器制作镜像

Create a new image from container's changes

Usage：

docker commit [OPTIONS] CONTAINER [REPOSITORY[:TAG]]

Options	Default	Description
—author, -a		Author (e.g., "John Hannibal Smith hannibal@a-team.com")
-c, –change list		Apply Dockerfile instruction to the created image
-m, –message string		Commit message
-p, –pause	true	Pause container during commit

[root@localhost ~]# docker pull busybox

Using default tag: latestlatest: Pulling from library/busyboxbdbbaa22dec6: Pull complete Digest: sha256:6915be4043561d64e0ab0f8f098dc2ac48e077fe23f488ac24b665166898115aStatus: Downloaded newer image for busybox:latest

docker.io/library/busybox:latest

[root@localhost ~]# docker run –name b1 -it busybox

/ # ls

bin dev etc home proc root sys tmp usr var

/ # mkdir data

/ # echo 'Busybox page test.' > data/index.html

/ # cat data/index.html

Busybox page test.

在创建镜像时，我们不能关闭容器，必须使其处于运行状态，所以我们必须要另起一个终端，然后执行

[root@localhost ~]# docker commit -p b1sha256:b84e7e2972700a24f675182818666bf22c6c0cd95bf30643513020d4d9f3920d

[root@localhost ~]# docker images

REPOSITORY TAG IMAGE ID CREATED SIZE

<none> <none> b84e7e297270 3 seconds ago 1.22MB

busybox latest 6d5fcfe5ff17 6 weeks ago 1.22MB

[root@localhost ~]# docker tag b84e7e297270 seancheng1002/b1:v0.1

[root@localhost ~]# docker images

REPOSITORY TAG IMAGE ID CREATED SIZE

seancheng1002/b1 v0.1 b84e7e297270 58 seconds ago 1.22MB

busybox latest 6d5fcfe5ff17 6 weeks ago 1.22MB

此时要注意的是，我们的仓库名叫b1，所以我们要在Docker Hub上创建一个名为b1的仓库，然后再将我们做好的镜像push上去

[root@localhost ~]# docker login

Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.

Username: seancheng1002

Password:

WARNING! Your password will be stored unencrypted in /root/.docker/config.json.

Configure a credential helper to remove this warning. See

https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded

[root@localhost ~]# docker push seancheng1002/b1:v0.1

The push refers to repository [docker.io/seancheng1002/b1]

b91c804c38c2: Pushed 195be5f8be1d: Mounted from library/busybox

v0.1: digest: sha256:67be9d39f8a31405078567f51a447fe60b52f398bc6c0e9f351c083e5e512e2d size: 734

使用新生成的镜像创建容器

[root@localhost ~]# docker run –name t1 -it seancheng1002/b1:v0.1WARNING: IPv4 forwarding is disabled. Networking will not work.

/ # ls

bin data dev etc home proc root sys tmp usr var

/ # ls data/

index.html

/ # cat data/index.html

Busybox page test.

由此可见，新生成的镜像中是包含了新增的内容的，但是此时有一个问题，那就是容器默认要启动的进程是什么？在这里，默认情况下是启动的sh进程，但我们是要启动一个http站点，所以我们要在创建镜像时将容器默认启动的进程设为httpd，这样一来我们就可以通过新生成的镜像来快速构建一个简单的http站点了。

使用docker inspect命令查看b1容器启动的默认进程是什么

[root@localhost ~]# docker inspect b1

[

…此处省略N行

"Cmd": [

"sh"

],

…此处省略N行

"Gateway": "172.17.0.1",

"IPAddress": "172.17.0.2",

…此处省略N行

]

重新生成镜像并上传

[root@localhost ~]# docker commit -a 'sean <sean1002@126.com>' -c 'CMD ["/bin/httpd","-f","-h","/data"]' -p b1 seancheng1002/b1:v0.2

[root@localhost ~]# docker push seancheng1002/b1

使用新生成的镜像创建容器

[root@localhost ~]# docker run –name t2 -d seancheng1002/b1:v0.298708886e332243bb64dac32f7e5210c8219e30495150c8fde4938d5d748ada7

[root@localhost ~]# docker container ls

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES98708886e332 seancheng1002/b1:v0.2 "/bin/httpd -f -h /d…" 7 seconds ago Up 5 seconds t2

a2e954da2011 busybox "sh" About an hour ago Up About a minute b1

使用docker inspect命令查看t2容器启动的默认进程是什么，以及其IP地址，然后用curl命令访问该IP，看是否能访问到网页

[root@localhost ~]# curl 172.17.0.3

Busybox page test.

镜像的导入与导出

假如有2台主机，我们在主机1上做了一个镜像，主机2想用这个镜像怎么办呢？

我们可以在主机1上push镜像到镜像仓库中，然后在主机2上pull把镜像拉下来使用，这种方式就显得比较麻烦，假如我只是测试用的，在一台主机上做好镜像后在另一台主机上跑一下就行了，没必要推到仓库上然后又把它拉到本地来。

此时我们可以在已有镜像的基础上把镜像打包成一个压缩文件，然后拷贝到另一台主机上将其导入，这就是镜像的导入和导出功能。

docker中我们使用docker save进行导出，使用docker load进行导入。

在已生成镜像的主机上执行docker save导出镜像

docker save -o myimages.gz seancheng1002/b1

在另一台没有镜像的主机上执行docker load导入镜像

docker load -i myimages.g

【PConline 资讯】手机系统一般都会有漏洞，只是时间发现早晚的问题，随着时间推移厂商会相继推出修复补丁，据外媒报道，谷歌近日发布3月份Android安全公告，并面向支持的Nexus和Pixel系列设备发布了全新的工厂和OTA镜像更新。

据谷歌介绍称，今年3月的安全公告中，所披露的所有漏洞都是合作商在2017年2月6日及更早时候发现的，公告中写道：“2017年3月5日或之后发布的安全补丁级别都已经解决了该日期之前的所有报告漏洞。”

据悉，OTA更新已经于今天开始面向Google设备开始推送；用户可通过Google的网站为支持的Nexus和Pixel设备找寻最新的OTA镜像文件，而且最新工厂镜像也上线。尽管最新补丁已经在AOSP库上线，但其他OEM厂商为旗下设备更新这些安全补丁依然需要做进一步的审查和测试，尤其是运营商版本，因此还需要等待一段时间。（OTA地址）（工厂镜像）

谷歌发布Nexus9安卓5.0出厂镜像

出处：IT之家 原创（蓝莲）

2014-11-5 13:48:35 评论

谷歌今天发布了Nexus9安卓5.0的出厂镜像，并推出了Nexus Player；Nexus9和Nexus Player是目前唯一两款已向用户推出的运行Android 5.0的设备。

对于Android玩家来说这几乎是必需品，因为出厂镜像是恢复原厂设置的基本配备。当用户不断刷机时，需要出厂文件来以防万一，要是出错或设备不能重启只能使用出厂镜像解决。

该出厂镜像的型号与这两款设备中的安卓5.0型号一致：LRX21L。

由于LTE版Nexus9尚未开卖，因此谷歌还没有提供这个型号的出厂镜像下载。（via：androidbeat）

背景

随着容器技术的普及，越来越多的应用被容器化。人们使用容器的频率越来越高，但常常忽略一个基本但又非常重要的问题 – 容器镜像的体积。本文将介绍精简容器镜像的必要性并以基于 spring boot 的 Java 应用为例描述最小化容器镜像的常用技巧。

精简容器镜像的必要性

精简容器镜像是非常必要的，下面分别从安全性和敏捷性两个角度进行阐释。

安全性

基于安全方面的考虑，将不必要的组件从镜像中移除可以减少攻击面、降低安全风险。虽然 docker 支持用户通过 Seccomp 限制容器内可以执行操作或者使用 AppArmor 为容器配置安全策略，但它们的使用门槛较高，要求用户具备安全领域的专业素养。

敏捷性

精简的容器镜像能提高容器的部署速度。假设某一时刻访问流量激增，您需要通过增加容器副本数以应对突发压力。如果某些宿主机不包含目标镜像，需要先拉取镜像，然后启动容器，这时使用体积较小的镜像能加速这一过程、缩短扩容时间。另外，镜像体积越小，其构建速度也越快，同时还能减少存储和传输的成本。

常用技巧

将一个 java 应用容器化所需的步骤可归纳如下：

1. 编译 java 源码并生成 jar 包。
2. 将应用 jar 包和依赖的第三方 jar 包移动到合适的位置。

本章所用的样例是一个基于 spring boot 的 java 应用 spring-boot-docker，所用的未经优化的 dockerfile 如下：

FROM maven:3.5-jdk-8
COPY src /usr/src/app/src
COPY pom.xml /usr/src/app
RUN mvn -f /usr/src/app/pom.xml clean package
ENTRYPOINT [“java”,”-jar”,”/usr/src/app/target/spring-boot-docker-1.0.0.jar”]

由于应用使用 maven 构建，dockerfile 中指定maven:3.5-jdk-8作为基础镜像，该镜像的大小为 635MB。通过这种方式最终构建出的镜像非常大，达到了 719MB，这是因为一方面基础镜像本身就很大，另一方面 maven 在构建过程中会下载许多用于执行构建任务的 jar 包。

多阶段构建

Java 程序的运行只依赖 JRE，并不需要 maven 或者 JDK 中众多用于编译、调试、运行的工具，因此一个明显的优化方法是将用于编译构建 java 源码的镜像和用于运行 java 应用的镜像分开。为了达到这一目的，在 docker 17.05 版本之前需要用户维护 2 个 dockerfile 文件，这无疑增加了构建的复杂性。好在自 17.05 开始，docker 引入了多阶段构建的概念，它允许用户在一个 dockerfile 中使用多个 From 语句。每个 From 语句可以指定不同的基础镜像并将开启一个全新的构建流程。您可以选择性地将前一阶段的构建产物复制到另一个阶段，从而只将必要的内容保留在最终的镜像里。优化后的 dockerfile 如下：

FROM maven:3.5-jdk-8 AS build
COPY src /usr/src/app/src
COPY pom.xml /usr/src/app
RUN mvn -f /usr/src/app/pom.xml clean package
FROM openjdk:8-jre
ARG DEPENDENCY=/usr/src/app/target/dependency
COPY –from=build ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY –from=build ${DEPENDENCY}/META-INF /app/META-INF
COPY –from=build ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT [“java”,”-cp”,”app:app/lib/*”,”hello.Application”]

该 dockerfile 选用maven:3.5-jdk-8作为第一阶段的构建镜像，选用openjdk:8-jre作为运行 java 应用的基础镜像并且只拷贝了第一阶段编译好的.claass文件和依赖的第三方 jar 包到最终的镜像里。通过这种方式优化后的镜像大小为 459MB。

使用 distroless 作为基础镜像

虽然通过多阶段构建能减小最终生成的镜像的大小，但 459MB 的体积仍相对过大。经调查发现，这是因为使用的基础镜像openjdk:8-jre体积过大，到达了 443MB，因此下一步的优化方向是减小基础镜像的体积。

Google 开源的项目 distroless 正是为了解决基础镜像体积过大这一问题。Distroless 镜像只包含应用程序及其运行时依赖项，不包含包管理器、shell 以及在标准 Linux 发行版中可以找到的任何其他程序。目前，distroless 为依赖 java、python、nodejs、dotnet 等环境的应用提供了基础镜像。

使用 distroless 的 dockerfile 如下：

FROM maven:3.5-jdk-8 AS build
COPY src /usr/src/app/src
COPY pom.xml /usr/src/app
RUN mvn -f /usr/src/app/pom.xml clean package
FROM gcr.io/distroless/java
ARG DEPENDENCY=/usr/src/app/target/dependency
COPY –from=build ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY –from=build ${DEPENDENCY}/META-INF /app/META-INF
COPY –from=build ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT [“java”,”-cp”,”app:app/lib/*”,”hello.Application”]

该 dockerfile 和上一版的唯一区别在于将运行阶段依赖的基础镜像由openjdk:8-jre（443 MB）替换成了gcr.io/distroless/java（119 MB）。经过这一优化，最终镜像的大小为 135MB。

使用 distroless 的唯一不便是您无法 attach 到一个正在运行的容器上排查问题，因为镜像中不包含 shell。虽然 distroless 的 debug 镜像提供 busybox shell，但需要用户重新打包镜像、部署容器，对于那些已经基于非 debug 镜像部署的容器无济于事。 但从安全角度来看，无法 attach 容器并不完全是坏事，因为攻击者无法通过 shell 进行攻击。

使用 alpine 作为基础镜像

如果您确实有 attach 容器的需求，又希望最小化镜像的大小，可以选用 alpine 作为基础镜像。Alpine 镜像的特点是体积非常下，基础款镜像的体积仅 4 MB 左右。

使用 alpine 后的 dockerfile 如下：

FROM maven:3.5-jdk-8 AS build
COPY src /usr/src/app/src
COPY pom.xml /usr/src/app
RUN mvn -f /usr/src/app/pom.xml clean package
FROM openjdk:8-jre-alpine
ARG DEPENDENCY=/usr/src/app/target/dependency
COPY –from=build ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY –from=build ${DEPENDENCY}/META-INF /app/META-INF
COPY –from=build ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT [“java”,”-cp”,”app:app/lib/*”,”hello.Application”]

这里并未直接继承基础款 alpine，而是选用从 alpine 构建出的包含 java 运行时的openjdk:8-jre-alpine（83MB）作为基础镜像。使用该 dockerfile 构建出的镜像体积为 99.2MB，比基于 distroless 的还要小。

执行命令docker exec -ti <container_id> sh可以成功 attach 到运行的容器中。

distroless vs alpine

既然 distroless 和 alpine 都能提供非常小的基础镜像，那么在生产环境中到底应该选择哪一种呢？如果安全性是您的首要考虑因素，建议选用 distroless，因为它唯一可运行的二进制文件就是您打包的应用；如果您更关注镜像的体积，可以选用 alpine。

其他技巧

除了可以通过上述技巧精简镜像外，还有以下方式：

1. 将 dockerfile 中的多条指令合并成一条，通过减少镜像层数的方式达到精简镜像体积的目的。
2. 将稳定且体积较大的内容置于镜像下层，将变动频繁且体积较小的内容置于镜像上层。虽然该方式无法直接精简镜像体积，但充分利用了镜像的缓存机制，同样可以达到加快镜像构建和容器部署的目的。

想了解更多优化 dockerfile 的小窍门可参考教程 Best practices for writing Dockerfiles。

总结

1. 本文通过一系列的优化，将 java 应用的镜像体积由最初的 719MB 缩小到 100MB 左右。如果您的应用依赖其他环境，也可以用类似的原则进行优化。
2. 针对 java 镜像，google 提供的另一款工具 jib 能为您屏蔽镜像构建过程中的复杂细节，自动构建出精简的 java 镜像。使用它您无须编写 dockerfile，甚至不需要安装 docker。
3. 对于类似 distroless 这样无法 attach 或者不方便 attach 的容器，建议您将它们的日志中心化存储，以便问题的追踪和排查。具体方法可参考文章面向容器日志的技术实践。

作者：吴波bruce_wu