PaaS:平台即服务。
DevOps（英文Development和Operations的组合）
Docker 容器引擎 基于 LXC 基于go语言 遵从Apache2.0协议开源。托管在 Github 上
Docker 使用客户端-服务器 (C/S) 架构模式，使用远程API来管理,通过镜像来创建Docker容器。
应用以及依赖包=>容器(沙箱)
作为sandbox大概是container的最基本想法了: 轻量级的隔离机制, 快速重建和销毁, 占用资源少。
用docker在开发者的单机环境下模拟分布式软件部署和调试，可谓又快又好。
同时docker提供的版本控制和image机制以及远程image管理，可以构建类似git的分布式开发环境。
Docker已经不仅仅是DevOps人员手中的神器了，每一个开发者都应该学会如何使用Docker。[14]
交付运行环境..海运,OS..货轮,软件..集装箱,
交付一个软件，就是一系列标准化组件的集合的交付，如同乐高积木
Docker daemon 作为服务端接受来自客户的请求，并处理这些请求（创建、运行、分发容器）。一般在宿主主机后台运行，等待接收来自客户端的消息。
docker能够只加载每个container变化的部分，这样资源占用小，能够在单机环境下与KVM之类的虚拟化方案相比能够更加快速和占用更少资源
** LXC是基于cgroup等linux kernel功能的，因此container的guest系统只能是linux base的
*** LXC 是一个操作系统级虚拟化方法
*** 用户的进程是lxc-start进程的子进程, 只是在Kernel的namespace中隔离的,
***** 隔离性 - 每个用户实例之间相互隔离, 互不影响。 硬件虚拟化方法给出的方法是VM, LXC给出的方法是container，更细一点是kernel namespace
***** 可配额/可度量 - 每个用户实例可以按需提供其计算资源，所使用的资源可以被计量。硬件虚拟化方法因为虚拟了CPU, memory可以方便实现, LXC则主要是利用cgroups来控制资源
移动性 - 用户的实例可以很方便地复制、移动和重建。硬件虚拟化方法提供snapshot和image来实现，docker(主要)利用AUFS实现
Control Groups cgroups 实现了对资源的配额和度量。 cgroups 的使用非常简单，提供类似文件的接口，
在 /cgroup目录下新建一个文件夹即可新建一个group，在此文件夹中新建task文件，并将pid写入该文件，即可实现对该进程的资源控制。
具体的资源配置选项可以在该文件夹中新建子 subsystem ，{子系统前缀}.{资源项} 是典型的配置方法，
如memory.usage_in_bytes 就定义了该group 在subsystem memory中的一个内存限制选项。
另外，cgroups中的 subsystem可以随意组合，一个subsystem可以在不同的group中，也可以一个group包含多个subsystem - 也就是说一个 subsystem。
我们主要关心cgroups可以限制哪些资源，即有哪些subsystem是我们关心。
cpu : 在cgroup中，并不能像硬件虚拟化方案一样能够定义CPU能力，但是能够定义CPU轮转的优先级，因此具有较高CPU优先级的进程会更可能得到CPU运算。
通过将参数写入cpu.shares,即可定义改cgroup的CPU优先级 - 这里是一个相对权重，而非绝对值。当然在cpu这个subsystem中还有其他可配置项，手册中有详细说明。
cpusets : cpusets 定义了有几个CPU可以被这个group使用，或者哪几个CPU可以供这个group使用。在某些场景下，单CPU绑定可以防止多核间缓存切换，从而提高效率
memory : 内存相关的限制
blkio : block IO相关的统计和限制，byte/operation统计和限制(IOPS等)，读写速度限制等，但是这里主要统计的都是同步IO
net_cls， cpuacct , devices , freezer 等其他可管理项。
LXC的虚拟化方法的IO和CPU性能几乎接近 baremetal 的性能
典型的Linux启动到运行需要两个FS - bootfs + rootfs (从功能角度而非文件系统角度)（图1）
bootfs (boot file system) 主要包含 bootloader 和 kernel, bootloader主要是引导加载kernel, 当boot成功后 kernel 被加载到内存中后 bootfs就被umount了.
rootfs (root file system) 包含的就是典型 Linux 系统中的 /dev, /proc, /bin, /etc 等标准目录和文件。
由此可见对于不同的linux发行版, bootfs基本是一致的, rootfs会有差别, 因此不同的发行版可以公用bootfs 如下（图2）：
典型的Linux在启动后，首先将 rootfs 置为 readonly, 进行一系列检查, 然后将其切换为 “readwrite” 供用户使用。
在docker中，起初也是将 rootfs 以readonly方式加载并检查，然而接下来利用 union mount 的将一个 readwrite 文件系统挂载在 readonly 的rootfs之上，
并且允许再次将下层的 file system设定为readonly 并且向上叠加, 这样一组readonly和一个writeable的结构构成一个container的运行目录, 每一个被称作一个Layer。如下（图3）：
得益于AUFS的特性, 每一个对readonly层文件/目录的修改都只会存在于上层的writeable层中。这样由于不存在竞争, 多个container可以共享readonly的layer。
所以docker将readonly的层称作 “image” - 对于container而言整个rootfs都是read-write的，但事实上所有的修改都写入最上层的writeable层中,
image不保存用户状态，可以用于模板、重建和复制。
步骤1：
分解。一般来说，应用程序都是复杂的，它们都有很多的组件。例如，大多数应用程序都需要数据库或中间件服务的支持以实现对数据的存储、检索和集成。
所以，需要通过设计和部署把这些服务拆分成为它们自己的容器。如果一个应用程序能够被拆分成为越多的分布式组件，那么应用程序扩展的选择则越多。
但是，"分布式组件"越多也意味着管理的复杂性越高。
步骤2：
选择基础映像。当执行应用程序迁移时，应尽量避免推倒重来的做法。搜索Docker注册库找到一个基本的Docker映像并将其作为应用程序的基础来使用。
随着时间的推移，企业将会发现这些Docker注册库中基本映像的价值所在。请记住，Docker支持着一个Docker开发人员社区，所以项目的成功与否很大程度上取决于用户对于映像管理和改良的参与度。
步骤3：
基于容器的应用程序是分布式应用程序。
为每一个应用程序组件和数据提供一个唯一的标识符
企业用户还应当增加一个日志记录的方法。
步骤4：
增加代码。为了创建镜像，企业用户需要使用一个Dockerfile来定义映像开发的必要步骤。一旦创建了映像，企业用户就应将其添加至Docker Hub。
步骤5：
配置测试部署。应对在容器中运行的应用程序进行配置，以便于让应用程序知道可以在哪里连接外部资源或者应用程序集群中的其他容器。
企业用户可以把这些配置部署在容器中或使用环境变量。
*** 对基于容器的应用程序进行测试类似于对其他分布式应用程序的测试。
企业可以对每个容器进行组件测试，并将容器集群作为一个整体进行测试。
确定应用程序应如何能够在负载增加的情况下进行扩展。如果用户正在使用一个集群管理器（例如Swarm），则可测试其性能。
最后，把容器部署到实际生产环境中。为了积极主动地关注基于容器的应用程序的运行状况，可考虑实施必要的监控和管理机制 。确保打开日志记录功能。
很多应用程序迁移至云计算都是采用容器技术的。虽然迁移有一点复杂，但是容器可以保护应用程序投资并赋予了它一个更长的使用寿命。
1.Docker镜像
CPU使用率：
docker run -it --rm --cpuset=0,1 -c 2 ...
内存使用：
docker run -it --rm -m 128m ...
存储使用：
docker -d --storage-opt dm.basesize=5G
2.用户命名空间
Docker不支持用户的命名空间，但是目前的一个开发[13]功能。
**** 该功能将允许Docker程序像一个没有特权的用户在主机上运行，但显示出来的是和在容器中运行的一样。
