AuFS

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 众所周知，Docker 始于2013年的 dotCloud，迄今刚刚七年，如果你刚好在圈中经历了2013-2015年这段早期岁月的话，自然应该知道，最初的 Docker = LXC + aufs，前者就是所谓的 Linux 容器了，而后者则是我今天要聊的镜像。 千禧年：惊艳的 Live CD 说到 Linux distro，除了做差异化的界面主题之外，核心差异一般都在于： 如何更方便地安装； 如何更方便地升级； 而在 distro 界却有一股清流，超脱于这两件事情之外，它们就是 Live CD，它们装在一张光盘里，或者是一个 U盘上，不需要安装、也不会改变。之前创业的时候，我司的运维大佬——彤哥曾经说过： 第一次见到 liveCD 时我内心是震惊的。。 这我当然是赞同的，那时我也是震惊的同学之一，要知道 Knoppix 在 2000 千禧年就来到了世界，而它所基于的著名的 Debian，直到2005年6月，Sarge (3.1) 发布的时候才正式在 stable release 里带上了图形界面的安装程序 debian-installer （简称 d-i），此前版本的安装还在用文本菜单。就在这个年代，这样一个开光盘即用、启动起来就是图形界面的系统，给我们这些玩家带来的震撼

一、Docker概述 LXC所实现的隔离性主要是来自kernel的namespace, 其中pid, net, ipc, mnt, uts 等namespace将container的进程, 网络, 消息, 文件系统和hostname 隔离开。 cgroups 实现了对资源的配额和度量。 cgroups 的使用非常简单，提供类似文件的接口，在 /cgroup目录下新建一个文件夹即可新建一个group，在此文件夹中新建task文件，并将pid写入该文件，即可实现对该进程的资源控制。 二、网络 （1）网络模型 bridge：网桥网络 当Docker进程启动时，会在主机上创建一个名为docker0的虚拟网桥，此主机上启动的Docker容器会连接到这个虚拟网桥上。虚拟网桥的工作方式和物理交换机类似，这样主机上的所有容器就通过交换机连在了一个二层网络中。 host：主机网络 如果启动容器的时候使用host模式，那么这个容器将不会获得一个独立的Network Namespace，而是和宿主机共用一个Network Namespace。容器将不会虚拟出自己的网卡，配置自己的IP等，而是使用宿主机的IP和端口。但是，容器的其他方面，如文件系统、进程列表等还是和宿主机隔离的。 none：禁用容器网络 container：容器网络 这个模式指定新创建的容器和已经存在的一个容器共享一个 Network

虚拟化： varmvare,virtualbox docker:container技术(以内核为支撑进行虚拟机)。不用安装操作系统直接通过宿主机的os虚拟化出应用 Docker 是一个 开源 的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现 虚拟化 。容器是完全使用 沙箱 机制，相互之间不会有任何接口； 一个完整的Docker有以下几个部分组成： dockerClient客户端 Docker Daemon守护进程 Docker Image镜像 DockerContainer容器 起源 Docker 是 PaaS 提供商 dotCloud 开源的一个基于 LXC 的高级容器引擎，源代码托管在 Github 上, 基于 go语言 并遵从Apache2.0协议开源。 Docker自2013年以来非常火热，无论是从 github 上的代码活跃度，还是 Redhat 在RHEL6.5中集成对Docker的支持, 就连 Google 的 Compute Engine 也支持 docker 在其之上运行。 一款开源软件能否在商业上成功，很大程度上依赖三件事 - 成功的 user case(用例), 活跃的社区和一个好故事。 dotCloud 自家的 PaaS 产品建立在 docker 之上，长期维护且有大量的用户

Docker 一.底层技术支持cgroups/LXC/AUFS 1.cgroups cgroups 进程分组化管理，Linux内核提供原生支持。通过分组实现对系统资源的限制与分配。 cgroups中的重要概念是“子系统”，也就是资源控制器，每种子系统就是一个资源的分配器.比如cpu子系统是控制cpu时间分配的。首先挂载子系统，然后才有control group的。比如先挂载memory子系统，然后在memory子系统中创建一个cgroup节点，在这个节点中，将需要控制的进程id写入，并且将控制的属性写入，这就完成了内存的资源限制。 2.LXC LXC是Linux containers的简称，是一种基于容器的操作系统层级的虚拟化技术。 借助于namespace的隔离机制和cgroup限额功能，LXC提供了一套统一的API和工具来建立和管理container。 LXC旨在提供一个共享kernel的OS级虚拟化方法，在执行时不用重复加载Kernel,且container的kernel与host共享. 3.联合文件系统（UnionFS） 联合文件系统（UnionFS）是一种分层、轻量级并且高性能的文件系统。 联合文件系统是 Docker 镜像的基础。镜像可以通过分层来进行继承，基于基础镜像可以制作各种具体的应用镜像。 AuFS是ubantu上最常用的联合文件系统。

AUFS 的英文全称为 Advanced Mult-Layered Unification Filesystem，曾经是 Another Mult-Layered Unification Filesystem，显然，现在的内涵规格更高些。说明：本文的演示环境为 ubuntu 16.04。 Union File System Union File System，简称 UnionFS，是一种为 Linux、FreeBSD 和 NetBSD 操作系统设计的，把其它文件系统联合到一个联合挂载点的文件系统服务。它使用 branch 把不同文件系统的文件和目录"透明地"覆盖，形成一个单一一致的文件系统。这些 branch 或者是 read-only 的，或者是 read-write 的，所以当对这个虚拟后的联合文件系统进行写操作的时候，系统是真正写到了一个新的文件中。看起来这个虚拟后的联合文件系统是可以对任何文件进行操作的，但是其实它并没有改变原来的文件。这是因为 Union File System 用到了一个重要的资源管理技术：写时复制。 写时复制(copy-on-write，常被简写为 CoW)，也叫隐式共享，是一种提高资源使用效率的资源管理技术。它的思想是：如果一个资源是重复的，在没有对资源做出修改前，并不需要立即复制出一个新的资源实例，这个资源被不同的所有者共享使用

简介 　　AUFS曾是Docker默认的首选存储驱动。它非常稳定、有很多真实场景的部署、很强的社区支持。它有以下主要优点： 　　极短的容器启动时间。 　　有效的存储利用率。 　　有效的内存利用率。 　　虽然如此，但由于它没有包含在Linux内核主线中，所有很多Linux发行版并不支持AUFS。 　　以下章节介绍AUFS的特性，并且它们如何作用于Docker。 特性 镜像分层和部署 　　AUFS是一种联合文件系统。它使用同一个Linux host上的多个目录，逐个堆叠起来，对外呈现出一个统一的文件系统。AUFS使用该特性，实现了Docker镜像的分层。下图展示出ubuntu:latest的镜像的分层。 　　 　　 注意 ：在Docker1.10之前，layer的ID对应着其在/var/lib/docker下的目录名称，但在Docker1.10之后，不再有这种直接的对应关系。 　　对于一个容器来说， 只有顶层的容器layer是可读写的，而下面的layer都是只读 的。 读写文件 　　Docker使用AUFS的CoW（Copy-on-Write）技术来实现镜像共享和最小化磁盘空间的使用。AUFS作用于文件层，也就是说AUFS CoW拷贝整个文件——即使文件只修改了一点点的内容。所以，它对容器的性能影响很明显，尤其拷贝多层镜像下的大文件，或者是在一个深层次的目录树中进行搜索。 　　不过

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 【推荐】2020年最新Java电子书集合.pdf(吐血整理) >>> 到虚拟化技术，我们首先想到的一定是 Docker，经过四年的快速发展 Docker 已经成为了很多公司的标配，也不再是一个只能在开发阶段使用的玩具了。作为在生产环境中广泛应用的产品，Docker 有着非常成熟的社区以及大量的使用者，代码库中的内容也变得非常庞大。 同样，由于项目的发展、功能的拆分以及各种奇怪的改名 PR ，让我们再次理解 Docker 的的整体架构变得更加困难。 虽然 Docker 目前的组件较多，并且实现也非常复杂，但是本文不想过多的介绍 Docker 具体的实现细节，我们更想谈一谈 Docker 这种虚拟化技术的出现有哪些核心技术的支撑。 首先，Docker 的出现一定是因为目前的后端在开发和运维阶段确实需要一种虚拟化技术解决开发环境和生产环境环境一致的问题，通过 Docker 我们可以将程序运行的环境也纳入到版本控制中，排除因为环境造成不同运行结果的可能。但是上述需求虽然推动了虚拟化技术的产生，但是如果没有合适的底层技术支撑，那么我们仍然得不到一个完美的产品。本文剩下的内容会介绍几种 Docker 使用的核心技术，如果我们了解它们的使用方法和原理，就能清楚 Docker 的实现原理。 Namespaces 命名空间

现在是数据的时代，数据的重要性不言而喻，因此在使用docker的过程中，如何存储其产生的数据就是docker的重中之中，现在我们就一起来看看docker是怎么存储数据的。 数据卷及挂载 volume（数据卷）： 其由docker自身创建与管理，用于docker数据的持久化与容器间数据共享。 Bind mounts（挂载）： 使用-v或–mount进行引用宿主机上已经存在的目录或文件，用于docker数据的持久化与容器间数据共享。 tmpfs mounts（tmpfs挂载）： 用于存储程序运行中产生的临时数据，数据保存在主机内存中。 Linux系统下专用 优缺点 volume 1、管理更方便，可以使用docker的CLI与API进行管理 2、不需要docker主机必须具有给定的目录或文件结构 3、迁移更加方便 3、数据卷可以存储在远程主机或云上 4、swarm下共享数据更加方便 bind mounts 1、只需要挂载文件时，更加方便 2、当确保Docker主机的文件或目录结构与容器所需的绑定挂载一致时。 tmpfs mounts 1、存储敏感临时数据 2、容器停止，tmpfs挂载被删除 存储驱动 容器和镜像 介绍驱动之前，我们先介绍以下docker的容器与镜像。 镜像： 由一层层的只读的文件系统（镜像）组成，在Dockerfile中，每一个RUN命令都会创建一层镜像

一 镜像的分层特性 在说docker的文件系统之前，我们需要先想清楚一个问题。我们知道docker的启动是依赖于image，docker在启动之前，需要先拉取image，然后启动。多个容器可以使用同一个image启动。那么问题来了：这些个容器是共用一个image，还是各自将这个image复制了一份， 然后各自独立运行呢？ 我们假设每个容器都复制了一份这个image，然后各自独立运行，那么就意味着，启动多少个容器，就需要复制多少个image，毫无疑问这是对空间的一种巨大浪费。事实上，在容器的设计当中，通过同一个Image启动的容器，全部都共享这个image，而并不复制。那么问 题又随之而来：既然所有的容器都共用这一个image，那么岂不是我在任意一个容器中所做的修改，在其他容器中都可见？如果我一个容器要将一个配置文件修改成A，而另一个容器同样要将这个文件修改成B，两个容器岂不是会产生冲突？ 我们把上面的问题放一放，先来看下面一个拉取镜像的示例： [root@docker-server1 ~]# docker pull ubuntu:16.04 Unable to find image 'ubuntu:16.04' locally 16.04: Pulling from library/ubuntu e80174c8b43b: Pull complete d1072db285cc:

Ŀ¼ Union File System AUFS Docker是如何使用AUFS的 image layer 和 AUFS (docker版本不同可能会有区别，我的是在/var/lib/docker下的其他文件夹中) container layer 和AUFS(docker版本不同可能会有区别，我的是在/var/lib/docker下的其他文件夹中) 写一个AUFS Union File System Union File System, 简称UnionFS，是一种为Linux，FreeBSD，和NetBSD操作系统设计的把其他文件系统联合挂载到一个挂载点的文件系统服务。 它通过使用branch把不同文件系统的文件和目录覆盖，形成一个一致的文件系统。这些branch是只读或者只写的。当对文件进行写操作时候，才会真正的复制 文件进行写操作。实际上本身没有对原来的文件进行修改，可以看做是共享了原来的文件。在写的时候进行修改用到了一种资源管理技术成为写时复制。 写时复制(copy-on write,CoW),也叫作隐式共享，如果一个资源是重复的，那我们没有必要去在拷贝一份。只需要将唯一的一份共享给不同的对象。当某一个对象 需要去修改这个资源时，再去重新复制一份对新复制的进行修改。通过资源共享，可以减少未修改资源复制带来的消耗。在mapbit的垃圾回收算法中也会用到。 AUFS AUFS