docker概述

虚拟化：

varmvare,virtualbox

docker:container技术(之内核为支撑进行虚拟机)。不用安装操做系统直接经过宿主机的os虚拟化出应用

 

Docker 是一个开源的应用容器引擎，让开发者能够打包他们的应用以及依赖包到一个可移植的容器中，而后发布到任何流行的 Linux 机器上，也能够实现虚拟化。容器是彻底使用沙箱机制，相互之间不会有任何接口；

一个完整的Docker有如下几个部分组成：

1. dockerClient客户端
2. Docker Daemon守护进程
3. Docker Image镜像
4. 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的故事。

• 环境管理复杂 - 从各类OS到各类中间件到各类app, 一款产品可以成功做为开发者须要关心的东西太多，且难于管理，这个问题几乎在全部现代IT相关行业都须要面对。
• 云计算时代的到来 - AWS的成功, 引导开发者将应用转移到 cloud 上, 解决了硬件管理的问题，然而中间件相关的问题依然存在 (因此openstack HEAT和 AWS cloudformation 都着力解决这个问题)。开发者思路变化提供了可能性。
• 虚拟化手段的变化 - cloud 时代采用标配硬件来下降成本，采用虚拟化手段来知足用户按需使用的需求以及保证可用性和隔离性。然而不管是KVM仍是Xen在 docker 看来,都在浪费资源，由于用户须要的是高效运行环境而非OS, GuestOS既浪费资源又难于管理, 更加轻量级的LXC更加灵活和快速
• LXC的移动性 - LXC在 linux 2.6 的 kernel 里就已经存在了，可是其设计之初并不是为云计算考虑的，缺乏标准化的描述手段和容器的可迁移性，决定其构建出的环境难于迁移和标准化管理(相对于KVM之类image和snapshot的概念)。docker 就在这个问题上作出实质性的革新。这是docker最独特的地方。

VM技术和容器技术对比

 

面对上述几个问题，docker设想是交付运行环境如同海运，OS如同一个货轮，每个在OS基础上的软件都如同一个集装箱，用户能够经过标准化手段自由组装运行环境，同时集装箱的内容能够由用户自定义，也能够由专业人员制造。这样，交付一个软件，就是一系列标准化组件的集合的交付，如同乐高积木，用户只须要选择合适的积木组合，而且在最顶端署上本身的名字(最后个标准化组件是用户的app)。这也就是基于docker的PaaS产品的原型。

 

Docker 架构

Docker 使用客户端-服务器 (C/S) 架构模式，使用远程API来管理和建立Docker容器。Docker 容器经过 Docker 镜像来建立。 容器与镜像的关系相似于面向对象编程中的对象与类。

 

 

 

Docker采用 C/S架构 Docker daemon 做为服务端接受来自客户的请求，并处理这些请求（建立、运行、分发容器）。 客户端和服务端既能够运行在一个机器上，也可经过 socket 或者RESTful API 来进行通讯。

Docker daemon 通常在宿主主机后台运行，等待接收来自客户端的消息。 Docker 客户端则为用户提供一系列可执行命令，用户用这些命令实现跟 Docker daemon 交互。  

 

特性

在docker的网站上提到了docker的典型场景：

• Automating the packaging and deployment of applications（使应用的 打包与部署自动化）
• Creation of lightweight, private PAAS environments（建立 轻量、私密的PAAS环境）
• Automated testing and continuous integration/deployment（实现 自动化测试和持续的集成/部署）
• Deploying and scaling web apps, databases and backend services（ 部署与扩展webapp、数据库和后台服务）

因为其基于LXC的轻量级虚拟化的特色，docker相比KVM之类最明显的特色就是 启动快，资源占用小。所以对于构建隔离的标准化的运行环境，轻量级的PaaS(如dokku), 构建自动化测试和持续集成环境，以及一切能够横向扩展的应用(尤为是须要快速启停来应对峰谷的web应用)。

1. 构建标准化的运行环境，现有的方案大可能是在一个baseOS上运行一套puppet/chef，或者一个image文件，其缺点是前者须要base OS许多前提条件，后者几乎不能够修改(由于copy on write 的文件格式在运行时rootfs是read only的)。而且后者文件体积大，环境管理和版本控制自己也是一个问题。
2. PaaS环境是不言而喻的，其设计之初和dotcloud的案例都是将其做为PaaS产品的环境基础
3. 由于其标准化构建方法(buildfile)和良好的REST API，自动化测试和持续集成/部署可以很好的集成进来
4. 由于LXC 轻量级的特色，其启动快，并且 docker可以只加载每一个container变化的部分，这样资源占用小，可以在单机环境下与KVM之类的虚拟化方案相比可以更加快速和占用更少资源

 

局限

Docker并非全能的，设计之初也不是KVM之类虚拟化手段的替代品，简单总结几点：

1. Docker是基于Linux 64bit的，没法在32bit的linux/Windows/unix环境下使用
2. LXC是基于cgroup等linux kernel功能的，所以container的guest系统只能是linux base的
3. 隔离性相比KVM之类的虚拟化方案仍是有些欠缺，全部container公用一部分的运行库
4. 网络管理相对简单，主要是基于namespace隔离
5. cgroup的cpu和cpuset提供的cpu功能相比KVM的等虚拟化方案相比难以度量(因此dotcloud主要是按内存收费)
6. Docker对disk的管理比较有限
7. container随着用户进程的中止而销毁，container中的log等用户数据不便收集

针对1-2，有windows base应用的需求的基本能够pass了; 3-5主要是看用户的需求，究竟是须要一个container仍是一个VM, 同时也决定了docker做为 IaaS 不太可行。

针对6,7虽然是docker自己不支持的功能，可是能够经过其余手段解决(disk quota, mount --bind)。总之，选用container仍是vm, 就是在隔离性和资源复用性上作权衡。

另外即使docker 0.7可以支持非AUFS的文件系统，可是因为其功能还不稳定，商业应用或许会存在问题，而AUFS的稳定版须要kernel 3.8, 因此若是想复制dotcloud的成功案例，可能须要考虑升级kernel或者换用ubuntu的server版本(后者提供deb更新)。这也是为何开源界更倾向于支持ubuntu的缘由(kernel版本)

Docker并不是适合全部应用场景，Docker只能虚拟基于Linux的服务。Windows Azure 服务可以运行Docker实例，但到目前为止Windows服务还不能被虚拟化。

可能最大的障碍在于管理实例之间的交互。因为全部应用组件被拆分到不一样的容器中，全部的服务器须要以一致的方式彼此通讯。这意味着任何人若是选择复杂的基础设施，那么必须掌握应用编程接口管理以及集群工具，好比Swarm、Mesos或者Kubernets以确保机器按照预期运转并支持故障切换。

Docker在本质上是一个附加系统。使用文件系统的不一样层构建一个应用是有可能的。每一个组件被添加到以前已经建立的组件之上，能够比做为一个文件系统更明智。分层架构带来另外一方面的效率提高，当你重建存在变化的Docker镜像时，不须要重建整个Docker镜像，只须要重建变化的部分。

可能更为重要的是，Docker旨在用于弹性计算。每一个Docker实例的运营生命周期有限，实例数量根据需求增减。在一个管理适度的系统中，这些实例生而平等，再也不须要时便各自消亡了。

针对Docker环境存在的不足，意味着在开始部署Docker前须要考虑以下几个问题。首先，Docker实例是无状态的。这意味着它们不该该承载任何交易数据，全部数据应该保存在数据库服务器中。

其次，开发Docker实例并不像建立一台虚拟机、添加应用而后克隆那样简单。为成功建立并使用Docker基础设施，管理员须要对系统管理的各个方面有一个全面的理解，包括Linux管理、编排及配置工具好比Puppet、Chef以及Salt。这些工具生来就基于命令行以及脚本。

 

原理

Docker核心解决的问题是利用LXC来实现相似VM的功能，从而利用更加节省的硬件资源提供给用户更多的计算资源。同VM的方式不一样,  LXC 其并非一套硬件虚拟化方法 - 没法归属到全虚拟化、部分虚拟化和半虚拟化中的任意一个，而是一个操做系统级虚拟化方法, 理解起来可能并不像VM那样直观。因此咱们从虚拟化到docker要解决的问题出发，看看他是怎么知足用户虚拟化需求的。

用户须要考虑虚拟化方法，尤为是硬件虚拟化方法，须要借助其解决的主要是如下4个问题:

• 隔离性 - 每一个用户实例之间相互隔离, 互不影响。 硬件虚拟化方法给出的方法是VM, LXC给出的方法是container，更细一点是kernel namespace
• 可配额/可度量 - 每一个用户实例能够按需提供其计算资源，所使用的资源能够被计量。硬件虚拟化方法由于虚拟了CPU, memory能够方便实现, LXC则主要是利用cgroups来控制资源
• 移动性 - 用户的实例能够很方便地复制、移动和重建。硬件虚拟化方法提供snapshot和image来实现，docker(主要)利用AUFS实现
• 安全性 - 这个话题比较大，这里强调是host主机的角度尽可能保护container。硬件虚拟化的方法由于虚拟化的水平比较高，用户进程都是在KVM等虚拟机容器中翻译运行的, 然而对于LXC, 用户的进程是lxc-start进程的子进程, 只是在Kernel的namespace中隔离的, 所以须要一些kernel的patch来保证用户的运行环境不会受到来自host主机的恶意入侵, dotcloud(主要是)利用kernel grsec patch解决的.

 

Linux Namespace

LXC所实现的隔离性主要是来自kernel的namespace, 其中pid, net, ipc, mnt, uts 等namespace将container的进程, 网络, 消息, 文件系统和hostname 隔离开。

pid namespace

以前提到用户的进程是lxc-start进程的子进程, 不一样用户的进程就是经过pidnamespace隔离开的，且不一样 namespace 中能够有相同PID。具备如下特征:

1. 每一个namespace中的pid是有本身的pid=1的进程(相似/sbin/init进程)
2. 每一个namespace中的进程只能影响本身的同一个namespace或子namespace中的进程
3. 由于/proc包含正在运行的进程，所以在container中的pseudo-filesystem的/proc目录只能看到本身namespace中的进程
4. 由于namespace容许嵌套，父namespace能够影响子namespace的进程，因此子namespace的进程能够在父namespace中看到，可是具备不一样的pid

正是由于以上的特征，全部的LXC进程在docker中的父进程为docker进程，每一个lxc进程具备不一样的namespace。同时因为容许嵌套，所以能够很方便的实现 LXC in LXC

net namespace

有了 pid namespace, 每一个namespace中的pid可以相互隔离，可是网络端口仍是共享host的端口。网络隔离是经过netnamespace实现的，

每一个net namespace有独立的 network devices, IP addresses, IP routing tables, /proc/net 目录。这样每一个container的网络就能隔离开来。

LXC在此基础上有5种网络类型，docker默认采用veth的方式将container中的虚拟网卡同host上的一个docker bridge链接在一块儿。

ipc namespace

container中进程交互仍是采用linux常见的进程间交互方法(interprocess communication - IPC), 包括常见的信号量、消息队列和共享内存。然而同VM不一样，container 的进程间交互实际上仍是host上具备相同pid namespace中的进程间交互，所以须要在IPC资源申请时加入namespace信息 - 每一个IPC资源有一个惟一的 32bit ID。

mnt namespace

相似chroot，将一个进程放到一个特定的目录执行。mnt namespace容许不一样namespace的进程看到的文件结构不一样，这样每一个 namespace 中的进程所看到的文件目录就被隔离开了。同chroot不一样，每一个namespace中的container在/proc/mounts的信息只包含所在namespace的mount point。

uts namespace

UTS(“UNIX Time-sharing System”) namespace容许每一个container拥有独立的hostname和domain name,  
　　使其在网络上能够被视做一个独立的节点而非Host上的一个进程。

user  namespace

每一个container能够有不一样的 user 和 group id, 也就是说能够以container内部的用户在container内部执行程序而非Host上的用户。

有了以上6种namespace从进程、网络、IPC、文件系统、UTS和用户角度的隔离，一个container就能够对外展示出一个独立计算机的能力，而且不一样container从OS层面实现了隔离。  
　　然而不一样namespace之间资源仍是相互竞争的，仍然须要相似ulimit来管理每一个container所能使用的资源 - LXC 采用的是cgroup。 

 

Control Groups

cgroups 实现了对资源的配额和度量。 cgroups 的使用很是简单，提供相似文件的接口，在 /cgroup目录下新建一个文件夹便可新建一个group，在此文件夹中新建task文件，并将pid写入该文件，便可实现对该进程的资源控制。具体的资源配置选项能够在该文件夹中新建子 subsystem ，{子系统前缀}.{资源项} 是典型的配置方法，

如memory.usage_in_bytes 就定义了该group 在subsystem memory中的一个内存限制选项。

另外，cgroups中的 subsystem能够随意组合，一个subsystem能够在不一样的group中，也能够一个group包含多个subsystem - 也就是说一个 subsystem。

关于术语定义

A *cgroup* associates a set of tasks with a set of parameters for one  
　　or more subsystems. 
　　A *subsystem* is a module that makes use of the task grouping 
　　facilities provided by cgroups to treat groups of tasks in 
　　particular ways. A subsystem is typically a "resource controller" that 
　　schedules a resource or applies per-cgroup limits, but it may be 
　　anything that wants to act on a group of processes, e.g. a 
　　virtualization 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 等其余可管理项。

 

Linux 容器

借助于namespace的隔离机制和cgroup限额功能， LXC提供了一套统一的API和工具来创建和管理container, LXC利用了以下 kernel 的features:  ^[8]  

• Kernel namespaces (ipc, uts, mount, pid, network and user)
• Apparmor and SELinux profiles
• Seccomp policies
• Chroots (using pivot_root)
• Kernel capabilities
• Control groups (cgroups)

LXC 向用户屏蔽了以上 kernel 接口的细节, 提供了以下的组件大大简化了用户的开发和使用工做:

• The liblxc library
• Several language bindings (python3, lua and Go)
• A set of standard tools to control the containers
• Container templates

LXC 旨在提供一个共享kernel的 OS 级虚拟化方法，在执行时不用重复加载Kernel, 且container的kernel与host共享，所以能够大大加快container的 启动过程，并显著减小内存消耗。在实际测试中，基于LXC的虚拟化方法的IO和CPU性能几乎接近 baremetal 的性能  ^[9]    , 大多数数据有相比 Xen具备优点。固然对于KVM这种也是经过Kernel进行隔离的方式, 性能优点或许不是那么明显, 主要仍是内存消耗和启动时间上的差别。在参考文献 ^[10]  中提到了利用iozone进行 Disk IO吞吐量测试KVM反而比LXC要快，并且笔者在device mapping driver下重现一样case的实验中也确实能获得如此结论。参考文献从网络虚拟化中虚拟路由的场景(网络IO和CPU角度)比较了KVM和LXC, 获得结论是KVM在性能和隔离性的平衡上比LXC更优秀 - KVM在吞吐量上略差于LXC, 但CPU的隔离可管理项比LXC更明确。

关于CPU, DiskIO, network IO 和 memory 在KVM和LXC中的比较仍是须要更多的实验才能得出可信服的结论。

AUFS

Docker对container的使用基本是创建在LXC基础之上的，然而LXC存在的问题是难以移动 - 难以经过标准化的模板制做、重建、复制和移动 container。

在以VM为基础的虚拟化手段中，有image和snapshot能够用于VM的复制、重建以及移动的功能。想要经过container来实现快速的大规模部署和更新, 这些功能不可或缺。

Docker 正是利用AUFS来实现对container的快速更新 - 在docker0.7中引入了storage driver, 支持AUFS, VFS, device mapper, 也为 BTRFS以及ZFS引入提供了可能。 但除了AUFS都未通过dotcloud的线上使用，所以咱们仍是从AUFS的角度介绍。

AUFS (AnotherUnionFS) 是一种 Union FS, 简单来讲就是支持将不一样目录挂载到同一个虚拟文件系统下(unite several directories into a single virtual filesystem)的文件系统, 更进一步地, AUFS支持为每个成员目录(AKA branch)设定'readonly', 'readwrite' 和 'whiteout-able' 权限, 同时AUFS里有一个相似

分层的概念, 对 readonly 权限的branch能够逻辑上进行修改(增量地, 不影响readonly部分的)。一般 Union FS有两个用途, 一方面能够实现不借助 LVM， RAID 将多个disk和挂在到一个目录下, 另外一个更经常使用的就是将一个readonly的branch和一个writeable的branch联合在一块儿，Live CD正是基于此能够容许在 OS image 不变的基础上容许用户在其上进行一些写操做。Docker在AUFS上构建的container image也正是如此，接下来咱们从启动container中的linux为例介绍docker在AUFS特性的运用。

图1

典型的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）：

图2

典型的Linux在启动后，首先将 rootfs 置为 readonly, 进行一系列检查, 而后将其切换为 “readwrite” 供用户使用。在docker中，起初也是将 rootfs 以readonly方式加载并检查，然而接下来利用 union mount 的将一个 readwrite 文件系统挂载在 readonly 的rootfs之上，而且容许再次将下层的 file system设定为readonly 而且向上叠加, 这样一组readonly和一个writeable的结构构成一个container的运行目录, 每个被称做一个Layer。以下（图3）：

得益于AUFS的特性, 每个对readonly层文件/目录的修改都

图3

只会存在于上层的writeable层中。这样因为不存在竞争, 多个container能够共享readonly的layer。

因此docker将readonly的层称做 “image” - 对于container而言整个rootfs都是read-write的，但事实上全部的修改都写入最上层的writeable层中,

image不保存用户状态，能够用于模板、重建和复制。

（图四、5）

图4

图5

上层的image依赖下层的image，所以docker中把下层的image称做父image，没有父image的image称做base image （图6）

图6

所以想要从一个image启动一个container，docker会先加载其父image直到base image，用户的进程运行在writeable的layer中。全部parent image中的数据信息以及  

图7

　　ID、网络和lxc管理的资源限制等具体container的配置，构成一个docker概念上的container。以下（图7）:

因而可知，采用AUFS做为docker的container的文件系统，可以提供以下好处：

1. 节省存储空间 - 多个container能够共享base image存储
2. 快速部署 - 若是要部署多个container，base image能够避免屡次拷贝
3. 内存更省 - 由于多个container共享base image, 以及OS的disk缓存机制，多个container中的进程命中缓存内容的概率大大增长
4. 升级更方便 - 相比于 copy-on-write 类型的FS，base-image也是能够挂载为可writeable的，能够经过更新base image而一次性更新其之上的container
5. 容许在不更改base-image的同时修改其目录中的文件 - 全部写操做都发生在最上层的writeable层中，这样能够大大增长base image能共享的文件内容。

以上5条 1-3 条能够经过 copy-on-write 的FS实现, 4能够利用其余的union mount方式实现, 5只有AUFS实现的很好。这也是为何Docker一开始就创建在AUFS之上。

因为AUFS并不会进入linux主干 (According to Christoph Hellwig, linux rejects all union-type filesystems but UnionMount.),  
　　同时要求kernel版本3.0以上(docker推荐3.8及以上)，所以在RedHat工程师的帮助下在docker0.7版本中实现了driver机制, AUFS只是其中的一个driver, 在RHEL中采用的则是Device Mapper的方式实现的container文件系统。

GRSEC

grsec是linux kernel安全相关的patch, 用于保护host防止非法入侵。因为其并非docker的一部分，咱们只进行简单的介绍。

grsec能够主要从4个方面保护进程不被非法入侵:

• 随机地址空间 - 进程的堆区地址是随机的
• 用只读的memory management unit来管理进程流程, 堆区和栈区内存只包含数据结构/函数/返回地址和数据, 是non-executeable
• 审计和Log可疑活动
• 编译期的防御

安全永远是相对的，这些方法只是告诉咱们能够从这些角度考虑container类型的安全问题能够关注的方面。

 

方法

随着Docker在云计算市场中领先地位的日益稳固，容器技术也成为了一种主流技术。为了对用户的应用程序使用容器技术，可遵循如下五个步骤。

Docker容器技术已在云计算市场中风靡一时了，而众多主流供应商则面临着技术落后的窘境。那么，是什么让Docker容器技术变得如此受欢迎呢？对于刚入门的新手来讲，容器技术可实现不一样云计算之间应用程序的可移植性，以及提供了一个把应用程序拆分为分布式组件的方法。此外，用户还能够管理和扩展这些容器成为集群。

在企业用户准备把应用程序迁往容器以前，理解应用程序的迁移过程是很是重要的。这里将介绍把用户应用程序迁往Docker容器的五个基本步骤。

 

步骤1：

分解。通常来讲，应用程序都是复杂的，它们都有不少的组件。例如，大多数应用程序都须要数据库或中间件服务的支持以实现对数据的存储、检索和集成。因此，须要经过设计和部署把这些服务拆分红为它们本身的容器。若是一个应用程序可以被拆分红为越多的分布式组件，那么应用程序扩展的选择则越多。可是，分布式组件越多也意味着管理的复杂性越高。

 

步骤2：

选择基础映像。当执行应用程序迁移时，应尽可能避免推倒重来的作法。搜索Docker注册库找到一个基本的Docker映像并将其做为应用程序的基础来使用。

随着时间的推移，企业将会发现这些Docker注册库中基本映像的价值所在。请记住，Docker支持着一个Docker开发人员社区，因此项目的成功与否很大程度上取决于用户对于映像管理和改良的参与度。

 

步骤3：

安全管理问题。安全性和管理应当是一个高优先级的考虑因素；企业用户不该再把它们看成应用程序迁移至容器的最后一步。反之，企业必须从一开始就作好安全性和管理的规划，把它们的功能归入应用程序的开发过程当中，并在应用程序运行过程当中积极主动地关注这些方面。这就是企业应当花大功夫的地方。

基于容器的应用程序是分布式应用程序。企业应当更新较老的应用程序以支持联合身份管理方法，这将很是有利于确保分布式应用程序的安全性。为了作到这一点，应为每个应用程序组件和数据提供一个惟一的标识符，这个标识符可容许企业在一个细粒度的级别上进行安全性管理。企业用户还应当增长一个日志记录的方法。

 

步骤4：

增长代码。为了建立镜像，企业用户须要使用一个Dockerfile来定义映像开发的必要步骤。一旦建立了映像，企业用户就应将其添加至Docker Hub。

 

步骤5：

配置测试部署。应对在容器中运行的应用程序进行配置，以便于让应用程序知道能够在哪里链接外部资源或者应用程序集群中的其余容器。企业用户能够把这些配置部署在容器中或使用环境变量。

对基于容器的应用程序进行测试相似于对其余分布式应用程序的测试。企业能够对每一个容器进行组件测试，并将容器集群做为一个总体进行测试。 肯定应用程序应如何可以在负载增长的状况下进行扩展。若是用户正在使用一个集群管理器（例如Swarm），则可测试其性能。

最后，把容器部署到实际生产环境中。为了积极主动地关注基于容器的应用程序的运行情况，可考虑实施必要的监控和管理机制 。确保打开日志记录功能。

不少应用程序迁移至云计算都是采用容器技术的。虽然迁移有一点复杂，可是容器能够保护应用程序投资并赋予了它一个更长的使用寿命。

 

安全

 

确保环境安全

　　Docker十分火热，不少人表示不多见如此可以吸引行业兴趣的新兴技术。然而，当兴奋转化为实际部署时，企业须要注意Docker的安全性。
　　了解Docker的人都知道，Docker利用容器将资源进行有效隔离。所以容器至关于与Linux OS和hypervisor有着几乎相同的安全运行管理和配置管理级别。但当涉及到安全运营与管理，以及具备保密性、完整性和可用性的通用控件的支持时，Docker可能会让你失望。
　　当容器运行在本地系统上时，企业能够经过其安全规则确保安全性。但一旦容器运行在云端，事实就不会如此简单了。
　　当Docker运行在云提供商平台上时，安全性变得更加复杂。你须要知道云提供商正在作什么，或许你正在与别人共享一台机器。
　　虽然容器没有内置的安全因素，并且像Docker这样的新兴技术很难有比较全面的安全措施，但这并不意味着之后也不会出现。

 

部署安全性

　　也有专家将Docker安全问题的实质定位于配置安全，认为Docker目前的问题是很难配置一个安全的容器。虽然如今Docker的开发人员经过建立很是小的容器来下降攻击面，但问题在于大型企业内部在生产环境中运行Docker容器的员工须要有更多的可见性和可控性。
　　专家认为，大约90%的外部网络攻击并非超级复杂的，攻击者可能是利用了管理员的行为漏洞，好比配置错误或者未及时安装补丁。
　　所以，企业在部署数千或数万台容器时，可以确保这些容器都遵照企业安全策略进行配置是相当重要的事情。
　　为解决这个问题，就须要增长Docker容器部署的实时可见性，同时实施企业制定的安全策略。  

 

Docker安全中心

在新的功能中有硬件的部分，能够 跨任何基础架构，容许开发和随后的升级中的数字编码签名。构建在Docker Trust框架之上用来进行镜像发布者认证，同时进行新的镜像扫描和官方漏洞检测，以便可以更好地理解容器内部是什么。

命名空间是本周发布的另一个Docker安全升级。容许IT运用来为基于用户群组的容器指派受权，约束了主机的访问根源，并指定了系统管理员，限制了群组对于指定服务的访问。

镜像扫描对于Docker Hub上的全部官方版本均可用，同时命名空间和硬件签名则在Docker的实验渠道提供。

安全问题仍旧是容器采纳要解决的最大问题，尤为是若是大量容器是便携的，IDC研究经理Larry Carvalho说道。经过硬件解决这个问题很明智，由于这样更难以介入，而且提供了将来可能被使用的大量容器的效率。

Carvhalho说：“他们还应该解决的一个问题是容量，你没有办法在软件层面作大量的安全，由于要有不少开支。”  

对比 LXC

看似docker主要的OS级虚拟化操做是借助LXC, AUFS只是锦上添花。那么确定会有人好奇docker到底比LXC多了些什么。无心中发现 stackoverflow 上正好有人问这个问题，

回答者是Dotcloud的创始人，出于备忘目的原文摘录以下  ^[13]    。

On top of this low-level foundation of kernel features, Docker offers a high-level tool with several powerful functionalities:

• Portable deployment across machines. Docker defines a format for bundling an application and all its dependencies into a single object which can be transferred to any docker-enabled machine, and executed there with the guarantee that the execution environment exposed to the application will be the same. Lxc implements process sandboxing, which is an important pre-requisite for portable deployment, but that alone is not enough for portable deployment. If you sent me a copy of your application installed in a custom lxc configuration, it would almost certainly not run on my machine the way it does on yours, because it is tied to your machine's specific configuration: networking, storage, logging, distro, etc. Docker defines an abstraction for these machine-specific settings, so that the exact same docker container can run - unchanged - on many different machines, with many different configurations.
• Application-centric. Docker is optimized for the deployment of applications, as opposed to machines. This is reflected in its API, user interface, design philosophy and documentation. By contrast, the lxc helper scripts focus on containers as lightweight machines - basically servers that boot faster and need less ram. We think there's more to containers than just that.
• Automatic build. Docker includes a tool for developers to automatically assemble a container from their source code, with full control over application dependencies, build tools, packaging etc. They are free to use make, maven, chef, puppet, salt, debian packages, rpms, source tarballs, or any combination of the above, regardless of the configuration of the machines.
• Versioning. Docker includes git-like capabilities for tracking successive versions of a container, inspecting the diff between versions, committing new versions, rolling back etc. The history also includes how a container was assembled and by whom, so you get full traceability from the production server all the way back to the upstream developer. Docker also implements incremental uploads and downloads, similar to “git pull”, so new versions of a container can be transferred by only sending diffs.
• Component re-use. Any container can be used as an “base image” to create more specialized components. This can be done manually or as part of an automated build. For example you can prepare the ideal python environment, and use it as a base for 10 different applications. Your ideal postgresql setup can be re-used for all your future projects. And so on.
• Sharing. Docker has access to a public registry (http://index.docker.io) where thousands of people have uploaded useful containers: anything from redis, couchdb, postgres to irc bouncers to rails app servers to hadoop to base images for various distros. The registry also includes an official “standard library” of useful containers maintained by the docker team. The registry itself is open-source, so anyone can deploy their own registry to store and transfer private containers, for internal server deployments for example.
• Tool ecosystem. Docker defines an API for automating and customizing the creation and deployment of containers. There are a huge number of tools integrating with docker to extend its capabilities. PaaS-like deployment (Dokku, Deis, Flynn), multi-node orchestration (maestro, salt, mesos, openstack nova), management dashboards (docker-ui, openstack horizon, shipyard), configuration management (chef, puppet), continuous integration (jenkins, strider, travis), etc. Docker is rapidly establishing itself as the standard for container-based tooling.

 

应用

有了docker这么个强有力的工具，更多的玩家但愿了解围绕docker能作什么

 

Sandbox

做为sandbox大概是container的最基本想法了 - 轻量级的隔离机制, 快速重建和销毁, 占用资源少。用docker在开发者的单机环境下模拟分布式软件部署和调试，可谓又快又好。

同时docker提供的版本控制和image机制以及远程image管理，能够构建相似git的分布式开发环境。能够看到用于构建多平台image的packer以及同一做者的vagrant已经在这方面有所尝试了，笔者会后续的blog中介绍这两款来自同一geek的精致小巧的工具。

Docker已经不只仅是DevOps人员手中的神器了，每个开发者都应该学会如何使用Docker。

 

PaaS

dotcloud、heroku以及cloudfoundry都试图经过container来隔离提供给用户的runtime和service，只不过dotcloud采用docker，heroku采用LXC，cloudfoundry采用本身开发的基于cgroup的warden。基于轻量级的隔离机制提供给用户PaaS服务是比较常见的作法 - PaaS 提供给用户的并非OS而是runtime+service，所以OS级别的隔离机制向用户屏蔽的细节已经足够。而docker的不少分析文章提到『可以运行任何应用的“PaaS”云』只是从image的角度说明docker能够从经过构建 image实现用户app的打包以及标准服务service image的复用，而很是见的buildpack的方式。

因为对Cloud Foundry和docker的了解，接下来谈谈笔者对PaaS的认识。PaaS号称的platform一直以来都被当作一组多语言的runtime和一组经常使用的middleware，提供这两样东西  
　　便可被认为是一个知足需求的PaaS。然而PaaS对能部署在其上的应用要求很高:

• 运行环境要简单 - buildpack虽然用于解决相似问题，但仍然不是很理想
• 要尽量的使用service - 经常使用的mysql, apache倒能理解，可是相似log之类的若是也要用service就让用户接入PaaS平台，让用户难以维护
• 要尽量的使用"平台” - 单机环境构建出目标PaaS上运行的实际环境比较困难，开发测试工做都离不开"平台”
• 缺乏可定制性 - 可选的中间件有限，难于调优和debug。

综上所述部署在PaaS上的应用几乎不具备从老平台迁移到之上的可能，新应用也难以进入参数调优这种深刻的工做。我的理解仍是适合快速原型的展示，和短时间应用的尝试。

然而docker确实从另外一个角度(相似IaaS+orchestration tools)实现了用户运行环境的控制和管理，然而又基于轻量级的LXC机制，确实是一个了不得的尝试。  
　　笔者也认为IaaS + 灵活的orchestration tools(深刻到app层面的管理 如bosh)是交付用户环境最好的方式。

国内也已经开始出现基于Docker的PaaS。2015年3月11日，云雀Alauda云平台正式开启内测，对外提供基于Docker的PaaS服务。

 

Open Solution

前文也提到docker存在disk/network不便限额和在较低版本kernel中(如RHEL的2.6.32)AUFS不支持的问题。

disk/network quota

虽然cgroup提供IOPS之类的限制机制，可是从限制用户能使用的磁盘大小和网络带宽上仍是很是有限的。

Disk/network的quota有两种思路:

• 经过docker run -v命令将外部存储mount到container的目录下，quota从Host方向限制，在device mapper driver中更采用实际的device所以更好控制。  ^[15] 
• 经过使用disk quota来限制AUFS的可操做文件大小。相似cloud foundry warden的方法， 维护一个UID池，每次建立container都从中取一个user name， 在container里和Host上用这个username建立用户，在Host上用setquota限制该username的UID的disk. 网络上因为docker采用veth的方式，能够采用tc来控制host上的veth的设备。  ^[16]  

RHEL 6.5

这里简单介绍下device mapper driver的思路：

docker的dirver要利用snapshot机制，起初的fs是一个空的ext4的目录，而后写入每一个layer。每次建立image其实就是对其父image/base image进行snapshot，

而后在此snapshot上的操做都会被记录在fs的metadata中和AUFS layer，docker commit将 diff信息在parent image上执行一遍.

这样建立出来的image就能够同当前container的运行环境分离开独立保存了。  

Docker Datacenter

Docker Datacenter将五个以前独立的产品组合在一块儿，使用统一的Docker管理接口：管理用的Universal Control Plane；安全方面的Content Trust；编排用的Swarm；容器运行时的Engine；以及Trusted Registry。目标是填补两处空白，一处是使用Docker在开发、测试、质量保证和生产环境间打包应用，另外一处是容器管理还不直接的传统IT运维。  

 

部署

1.Docker镜像 
　　
　　Docker 1.3 如今支持数字签名来确认官方仓库镜像的起源和完整性。因该功能仍在开发中因此Docker将抛出警告但不会阻止镜像的实际运行。  
　　一般确保镜像只从受信库中检索而且不使用—insecure-registry=[]命令项。 
　　2.网络命名空间
　　
　　在默认状况下，Docker REST API用来控制容器经过系统Docker守护进程是惟一可以经过Unix域套接字的方式暴露出来。在Docker上开启一个TCP端口（即 当引导Docker守护进程时必须使用 -H 选项绑定地址）将容许任何人经过该端口访问容器，有可能得到主机上的root访问权限以及在某些场景下本地用户所属的Docker组。 
　　3.日志和审核 
　　
　　收集和归档与Docker相关的安全日志来达到审核和监督的目的。从host[8]，可使用下面的命令来访问容器外的日志文件： 
　　docker run -v /dev/log:/dev/log/bin/sh 
　　使用Docker命令内置： 
　　docker logs ... (-f to follow log output) 
　　日志文件也能够从持续存储导出到一个使用压缩包里面： 
　　docker export ...

　　 4.SELinux 或 AppArmor 
　　
　　Linux的内部安全模块，例如经过访问控制的安全策略来配置安全加强型Linux（SELinux）和AppArmor，从而实现强制性的访问控制（MAC）一套有限的系统资源的限制进程，若是先前已经安装和配置过SELinux，那么它可使用setenforce 1在容器中被激活。Docker程序的SELinux支持是默认无效的，而且须要使用—selinux功能来被激活。经过使用新增的—security-opt来加载SELinux或者AppArmor的策略对容器的标签限制进行配置。该功能已经在Docker版本1.3[9]中介绍过。例如：  
　　docker run --security-opt=secdriver:name:value -i -t centos bash 
　　5.守护特权 
　　
　　不要使用--privileged命令行选项。这原本容许容器来访问主机上的全部设备，并为容器提供一个特定的LSM配置（例如SELinux或AppArmor），而这将给予如主机上运行的程序一样水平的访问。避免使用--privileged有助于减小主机泄露的攻击面和潜力。然而，这并不意味着程序将没有优先权的运行，固然这些优先权在最新的版本中仍是必须的。发布新程序和容器的能力只能被赋予到值得信任的用户上。经过利用-u选项尽可能减小容器内强制执行的权限。例如： 
　　docker run -u-it/bin/bash 
　　Docker组的任何用户部分可能最终从容器中的主机上得到根源。 
　　6.cgroups 
　　
　　为了防止经过系统资源耗尽的DDoS攻击，可使用特定的命令行参数被来进行一些资源限制。 
　　CPU使用率： 
　　docker run -it --rm --cpuset=0,1 -c 2 ... 
　　内存使用： 
　　docker run -it --rm -m 128m ... 
　　存储使用： 
　　docker -d --storage-opt dm.basesize=5G 
　　磁盘I/O： 
　　目前不支持Docker。BlockIO*属性能够经过systemd暴露，而且在支持操做系统中被用来控制磁盘的使用配额。 
　　7.二进制SUID/GUID 
　　
　　SUID和GUID二进制文件不稳定的时候容易受到攻击，而这个时候是很危险的，，致使任意代码执行（如缓冲区溢出），由于它们会进程的文件全部者或组的上下文中运行。若是可能的话，禁止SUID和SGID使用特定的命令行参数来下降容器的功能。 
　　docker run -it --rm --cap-drop SETUID --cap-drop SETGID ... 
　　另外一选择，能够考虑运用经过安装有nosuid属性的文件系统来移除掉SUID能力。 
　　最后一个选择是从系统中完全删除不须要的SUID和GUID二进制文件。这些类型的二进制文件能够在Linux系统中运行如下命令而找到： 
　　find / -perm -4000 -exec ls -l {} \; 2>/dev/null 
　　find / -perm -2000 -exec ls -l {} \; 2>/dev/null 
　　可使用相似于下面的[11]命令将SUID和GUID文件权限删除而后： 
　　sudo chmod u-s filename sudo chmod -R g-s directory 
　　8.设备控制组(/dev/*) 
　　
　　若是须要，使用内置的设备选项（不使用-v与--privileged参数）。此功能在推出1.2版本[12]。 
　　例如（声卡使用）： 
　　docker run --device=/dev/snd:/dev/snd … 
　　9.服务和应用 
　　
　　若是一个Docker容器有可能被泄露，为了减小横向运动的潜力，考虑隔离极易受影响的服务（如在主机或虚拟机上运行SSH服务）。此外，不要运行容器内不受信任的特许操做的应用程序。 
　　10.安装项 
　　
　　当使用本机容器库时（即libcontainer）Docker就会自动处理这个。 
　　可是，使用LXC容器库时，敏感的安装点最好经过运用只读权限来手动安装，其中包括： 
　　/sys 
　　/proc/sys 
　　/proc/sysrq-trigger 
　　/proc/irq 
　　/proc/bus 
　　安装权限应在之后删除，以防止从新挂载。 
　　11.Linux内核 
　　
　　使用系统提供的更新工具来确保内核是实最新的（如apt-get，yum，等）。过期的内核可能更脆弱，而且被暴露一些漏洞。使用GRSEC或PAX来增强内核，即例如对内存破坏的漏洞来提供更高的安全性。 
　　12.用户命名空间 
　　
　　Docker不支持用户的命名空间，可是目前的一个开发[13]功能。UID映射由LXC程序驱动，但在本机libcontainer库中不被支持。该功能将容许Docker程序像一个没有特权的用户在主机上运行，但显示出来的是和在容器中运行的同样。 
　　13.libseccomp（和seccomp-bpf 扩展） 
　　
　　libseccomp库容许在基于一个白名单的方法上限制Linux内核的系统调用程序的使用。对于系统操做来讲，不是很重要的系统调用程序，最好被禁用，以防止被破坏的容器被滥用或误用。 
　　此功能目前工做正在进行中（LXC驱动程序中已经有了，可是在libcontainer中海没有完成，虽然如今是默认值）。使用LXC驱动程序[14]来重启Docker程序： 
　　docker -d -e lxc 
　　如何生成seccomp配置的说明都在“的contrib”[15]文件夹中的Docker GitHub的资源库。之后能够用下面的命令来建立一个基于Docker容器的LXC： 
　　docker run --lxc-conf="lxc.seccomp=$file"
　　14.性能 
　　
　　只要可能，就将Linux性能下降到最小。Docker默认的功能包括：chown, dac_override, fowner, kill, setgid, setuid, setpcap, net_bind_service, net_raw, sys_chroot, mknod, setfcap, and audit_write. 
　　从控制行来启动容器时，能够经过下述来进行控制： 
　　--cap-add=[] 或者--cap-drop=[]. 
　　例如： 
　　docker run --cap-drop setuid --cap-drop setgid -ti/bin/sh 
　　15.多租环境 
　　
　　因为Docker容器内核的共享性质，责任分离在多租户环境中不能安全地实现。建议容器在那些没有其它的目的，也不用于敏感操做的主机上运行。能够考虑经过Docker控制来将全部服务移动到容器中。若是可能的话，经过使用--icc= false将跨容器通讯降到最低，并必要时指定-link与Docker运行，或经过—export=port，不在主机上发布，而在容器上暴露一个端口。相互信任的容器的映像组来分离机器[17]。 
　　16.彻底虚拟化 
　　
　　使用一个完整的虚拟化解决方案包含Docker,如KVM。这将阻止一个内核漏洞在Docker镜像中被利用致使容器扩为主系统。 
　　Docker镜像可以嵌套来提供该KVM虚拟层，参考Docker-in-Docker utility [18]中所示。 
　　17.安全审核 
　　
　　对你的主系统和容器按期进行安全审核以查明错误配置或漏洞，这些能使你的系统损坏。

 

工具实践

Docker推出的一个名为Docker Content Trust（DCT）的新功能，它可帮助IT专业人士确保Docker的安全性。DCT使用了一个公共密钥基础设施（PKI）的方法，它提供了两个不一样的密钥：一个离线（root）密钥和一个标记（每次入库）密钥，当第一次发布者推出镜像时它可建立和存储客户端。

此举有助于弥补正在使用恶意容器这一最大的漏洞。DCT还生成了一个时间戳密钥，它可保护系统免受重放攻击，即运行过时的标记内容。这解决了上面说起容器具备不一样安全补丁等级的问题。

为了解决针对容器安全性的问题，包括Docker在内的众多公司都为Docker发布了安全基准。这套标准为确保Docker容器的安全性提供了指导。全篇118页的文档囊括了部署Docker容器的84个最佳实践以及一个涉及全部内容的检查清单。

那么，若是你决定自行负责确保Docker容器的安全性，但又不知道从何入手，咱们在这里为你提供了一些建议：

阅读上面说起的Docker安全基准文件。重点关注与如何部署基于容器的应用程序相关的建议和最佳实践。这真的是有助于缓解你的财务压力，认真考虑大部分因糟糕设计而致使的Docker安全性问题。

考虑你的特定安全性需求。这将促使你选择正确的工具和方法。不少使用容器技术的企业对于他们基于容器的应用程序要么安全措施不足，要么安全措施过足。

尽量多地进行测试。容器技术是新技术，所以咱们须要搞清楚哪些是可以发挥做用，哪些是无用的，而要作到这一点的惟一方法就是进行安全性方面的测试，例如渗透测试。

容器安全性的发展趋势可能会与虚拟化安全性同样。虽然安全性从第一台虚拟机部署开始就是一个问题，可是多年以来积累下来的良好安全性实践、架构和工具都证实了其有效性。咱们相信，Docker容器安全性的问题也一样可以获得较好解决。  

使用案例

Docker是一个命令行工具，它提供了中央“docker”执行过程当中所需的全部工具。这使得Docker的操做很是简单。一些例子能够检查运行中的容器的状态：

或检查可用的镜像及其版本的列表：

另外一个例子是显示一个镜像的历史：

上面的命令显示了命令行界面操做的方便快捷。你只须要指定镜像ID的前几个字符就能够。你能够看到只须要“d95”就能显示d95238078ab0镜像的全部历史。

你可能会注意到该镜像很是小。这是由于Docker从父镜像创建增量镜像，只存储每一个容器的更改。所以，若是你有一个300MB的父镜像，若是你在容器中安装了50MB的额外应用或服务，你的容器和生成镜像可能只有50MB。

你能够用Dockerfiles自动化Docker容器的建立过程。Dockerfiles是含有单个容器性能规范的文件。例如，你能够建立一个Dockerfiles来创建一个Ubuntu容器，在新容器内运行一些命令、安装软件或执行其余任务，而后启动容器。

容器网络

Docker早期版本中的网络基于主机桥接，可是Docker 1.0包含了一种新形式的网络，容许容器直接链接到主机以太网接口。默认状况下，一个容器有一个回路以及一个链接到默认内部桥接的接口，可是若是须要的话也能够配制成直接访问。一般，直接访问比桥接的速度更快。

然而，桥接方法在许多状况下是很是有用的。桥接是经过主机自动建立一个内部网络适配器并为其分配一个主机自己还没有使用的子网。而后，当新的容器链接到这座桥，它们的地址进行自动分配。容器启动时你能够将其链接到主机接口或端口，所以运行 Apache的容器可能启动并链接到主机上的TCP端口8080（或随机端口）。经过使用脚本和管理控制，你能够在任何地方启动Docker，链接端口并将其传达到须要使用该服务的应用或服务堆栈的其余部分。  

在Hyper-V服务器上Docker主机备份方法

要在Hyper-V服务器上建立Docker主机，您须要下载而且安装OpenSSH以及Windows版本的Docker Machine。您还应该将OpenSSH二进制文件添加到您的Hyper-V服务器路径以便Docker Machine能够找到它们。

一旦所需的组件就绪，建立Docker主机如同运行一条命令行同样垂手可得。打开命令提示符窗口，定位到包含Docker Machine的文件夹，而后输入可执行文件名称（Docker-machine_windows-amd64.exe），其后输入-d开关、驱动程序的名称（在本例中是Hyper-V）以及您想分配给您正在建立的虚拟机（VM）的名称。例如，该命令可能以下所示：

Docker-machine_windows-amd64.exe -d hyper-v Docker

当运行这个命令的时候，Docker Machine完成几个不一样的任务。其中一些更重要的任务（从备份的角度来看）包括：
　　使用命令行中指定的名称建立虚拟硬盘（virtual hard disk，VHD）；
　　下载名为Boot2Docker.ISO的DVD映像；
　　建立虚拟机；
　　把Boot2Docker.ISO 文件与新建立的VM关联，做为虚拟DVD光驱；
　　把VHD与VM关联；
　　启动VM；
　　向VM分配IP地址和端口号

 

 

 

Docker解决的问题

云计算、大数据，移动技术的快速发展，加之企业业务需求的不断变化，致使企业架构要随时更改以适合业务需求，跟上技术更新的步伐。毫无疑问，这些重担都将压在企业开发人员身上；团队之间如何高效协调，快速交付产品，快速部署应用，以及知足企业业务需求，是开发人员亟需解决的问题。Docker技术刚好能够帮助开发人员解决这些问题。

为了解决开发人员和运维人员之间的协做关系，加快应用交付速度，愈来愈多的企业引入了DevOps这一律念。可是，传统的开发过程当中，开发、测试、运维是三个独立运做的团队，团队之间沟通不顺畅，开发运维之间冲突时有发生，致使协做效率低下，产品交付延迟， 影响了企业的业务运行。Docker技术将应用以集装箱的方式打包交付，使应用在不一样的团队中共享，经过镜像的方式应用能够部署于任何环境中。这样避免了各团队之间的协做问题的出现，成为企业实现DevOps目标的重要工具。以容器方式交付的Docker技术支持不断地开发迭代，大大提高了产品开发和交付速度。

此外，与经过Hypervisor把底层设备虚拟化的虚拟机不一样，Docker直接移植于Linux内核之上，经过运行Linux进程将底层设备虚拟隔离，这样系统性能的损耗也要比虚拟机低的多，几乎能够忽略。同时，Docker应用容器的启停很是高效，能够支持大规模的分布系统的水平扩展，真正给企业开发带来福音。

正如中国惠普云计算集成云技术首席专家刘艳凯所说的那样：“任何一项技术的发展和它受到的追捧，都是由于它可以解决困扰人们的问题，”Docker正是这样的一种技术。Docker的解决问题能力虽然很强，但在企业中的实际应用却并很少，那么是什么问题阻碍了Docker在企业中的实践？

 

Docker将来发展

任何一项新技术的出现，都须要一个发展过程，好比云计算为企业所接受用了将近五年左右时间，OpenStack技术也经历了两、三年才受到人们的承认。所以，虽然Docker技术发展很快，但技术还不够成熟，对存储的灵活的支持、网络的开销和兼容性方面还存在限制，这是Docker没有被企业大范围使用的一个主要缘由。另一个缘由是企业文化是否与DevOps运动一致，只有企业支持DevOps，才能更大地发挥Docker的价值。最后一个缘由就是安全性问题，Docker对于Linux这一层的安全的隔离还有待改进，才能进一步获得企业的承认。惠普刘艳凯认为，这也是Docker须要在下一步中改进的一方面。

 

实现企业价值

目前，虽然Docker还未在企业中大规模采用，但已有很多企业进入了尝试阶段；而Docker做为工具，如何让它快速帮助开发人员达到他们指望的目标，才是最重要的，惠普在Docker支持方面都作了 哪 些努力？

Docker价值的最大致如今于对企业DevOps的支持，对原生云应用大规模水平扩展的支持。在惠普Helion云战略中包括了对DevOps服务和原生云应用的支持，而这一战略的具体落地，与Docker技术有着紧密的联系。所以，惠普团队一直积极地参与OpenStack社区中和Docker项目相关的开发活动中，努力改进Docker技术中存在的不足。同时，惠普产品中也集成了Docker，例如，惠普开发平台产品集成了Docker，使用Docker做为应用的容器；以及惠普最新发布的CloudSystem 9.0也增长对Docker的支持，用户能够像使用其它的虚拟化资源同样，选择Docker做为应用的承载容器。刘艳凯认为，惠普很是承认Docker给用户带来的一些价值，那也但愿经过本身努力，使更多的用户使用到Docker这样的先进的技术。   

 

Docker Hub 服务

双方在开源容器技术以及发展方向上共同努力，并提供本地化的 Docker 服务。Docker 公司选择阿里云平台做为其DockerHub 在中国运营的基础服务。阿里云也得到 DockerEngine 商用版以及 DockerDataCenter 运营权，并为 Docker 客户提供企业级支持和咨询服务。同时，阿里云将成为 Docker 官方支持的云服务提供商。

阿里云总裁胡晓明表示，经过和 Docker 的战略合做，阿里云将更好地为企业级客户提供完善的云服务，使能客户，并实现时代转型。  

 

技术局限

网络限制：容器网络（Docker Network ）让你能够方便地在同一主机下对容器进行网络链接。加上一些其余的工做，你就能够跨主机使用叠加网络功能。然而，也就到此为止了。网络配置操做是受限的，并且到目前为止能够说这些手段都是人工的。尽管容器脚本化能够规模化，由于你必须给网络定义增长预分配实例，每次提供容器时还须要额外步骤，这容易引发错误。

库控制受限：库已经成为任何容器会话的中心议题。公共库是最有价值的，由于他贡献了大量的预置容器，节省了许多的配置时间。然而，在沙盒里使用它是有风险的。在不知道谁以及如何建立镜像的状况下，可能会存在任意数量的有意或无心的稳定性和安全性风险。对于企业来讲，有必要创建和维护一个私有库，这个库的创建挑战不大，但管理是个问题。Docker为大型库的镜像管理提供了一个有限的元数据模型，确保将来实例如预期的能力受限，也没有叠加功能。

没有清晰的审计跟踪：提供容器是很简单的，但知道提供容器的时间、缘由、方式以及提供方却不容易。所以，在提供以后，你并不掌握多少出于审计目的的历史。

运行实例的低可见性：若是没有通过深思熟虑的行动，实例提供后很难接触到运行容器的对象，也很难知道哪些应该出如今那里，哪些不该该出如今那里。  

 

Docker环境安全

Docker的势头在过去的12个月里十分火热，不少人表示不多见如此可以吸引行业兴趣的新兴技术。然而，当兴奋转化为实际部署时，企业须要注意Docker的安全性。

了解Docker的人都知道，Docker利用容器将资源进行有效隔离。所以容器至关于与 Linux  OS和hypervisor有着几乎相同的安全运行管理和配置管理级别。但当Docker涉及到安全运营与管理，以及具备保密性、完整性和可用性的通用控件的支持时，Docker可能会让你失望。

当Docker运行在云提供商平台上时，Docker安全性变得更加复杂。你须要知道云提供商正在作什么，或许你正在于别人共享一台机器。

Docker虽然容器没有内置的安全因素，并且像Docker这样的新兴技术很难有比较全面的安全措施，但这并不意味着之后也不会出现。

 

容器部署安全

也有专家将Docker安全问题的实质定位于配置安全，认为Docker目前的问题是很难配置一个安全的容器。虽然如今Docker的开发人员经过建立很是小的容器来下降攻击面，但问题在于大型企业内部在生产环境中运行Docker容器的员工须要有更多的可见性和可控性。

企业在部署数千或数万台Docker容器时，可以确保这些Docker容器都遵照企业安全策略进行配置是相当重要的事情。

Docker为解决这个问题，就须要增长Docker容器部署的实时可见性，同时实施企业制定的安全策略。也有一些厂商为此推出解决方案，给运营商提供了实时可见性并帮助他们执行容器级别的虚拟基础设施的安全策略。  

 

 

 

 

学习笔记，未完待续