目录
Docker概述
Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。
一个完整的Docker包括以下部分：
①dockerClient客户端
②Docker Daemon守护进程
③Docker Image镜像
④DockerContainer容器
Docker容器中可以包含多个Docker镜像
※虚拟化概述：
是指通过虚拟化技术将一台计算机虚拟为多台逻辑计算机。在一台计算机上同时运行多个逻辑计算机，每个逻辑计算机可运行不同的操作系统，并且应用程序都可以在相互独立的空间内运行而互不影响，从而显著提高计算机的工作效率。虚拟化使用软件的方法重新定义划分IT资源，可以实现IT资源的动态分配、灵活调度、跨域共享，提高IT资源利用率，使IT资源能够真正成为社会基础设施，服务于各行各业中灵活多变的应用需求。
※沙箱机制：
沙箱机制，其实就是Sandboxie，Sandboxie自带一个快捷方式，就是在沙盘中运行IE。Sandboxie是一款专业的虚拟类软件，它的工作软件：通过重定向技术，把程序生成和修改的文件，定向到自身文件夹中。当然，这些数据的变更，包括注册表和一些系统的核心数据。通过加载自身的驱动来保护底层数据，属于驱动级别的保护。
※镜像：
镜像（Mirroring）是冗余的一种类型，一个磁盘上的数据在另一个磁盘上存在一个完全相同的副本即为镜像。镜像是一种文件存储形式，可以把许多文件做成一个镜像文件，与GHOST等程序放在一个盘里用GHOST等软件打开后，又恢复成许多文件，RAID 1和RAID 10使用的就是镜像。常见的镜像文件格式有ISO、BIN、IMG、TAO、DAO、CIF、FCD。
Docker是开源的应用容器引擎。
Docker可以让你将所有应用软件以及它的依赖打包成软件开发的标准化单元。
Docker容器将软件以及它运行安装所需的一切文件（代码、运行时、系统工具、系统库）打包到一起，这就保证了不管是在什么样的运行环境，总是能以相同的方式运行。就好像Java虚拟机一样“一次编写，到处运行（Write once, run anywhere）”， 而Docker是“一次构建，到处运行（Build once，run anywhere）”。
※kernel：操作系统内核。操作系统内核是指大多数操作系统的核心部分。它由操作系统中用于管理存储器、文件、外设和系统资源的那些部分组成。容器映像是一个软件的轻量级独立可执行软件包，包含运行它所需的一切：代码，运行时，系统工具，系统库，设置。
不管环境如何，集装箱化软件都可以运行相同的Linux和Windows应用程序。容器将软件与其周围环境隔离开来，例如：开发环境和登台环境之间的差异，并有助于减少在同一基础架构上运行不同软件的团队之间的冲突。
Docker起源
Docker 是 PaaS 提供商 dotCloud 开源的一个基于 LXC 的高级容器引擎，源代码托管在 Github 上, 基于go语言并遵从Apache2.0协议开源。Docker自2013年以来非常火热，无论是从 github 上的代码活跃度，还是Redhat在RHEL6.5中集成对Docker的支持, 就连 Google 的 Compute Engine 也支持 Docker 在其之上运行。
一款开源软件能否在商业上成功，很大程度上依赖三件事：①成功的user case(用例)②活跃的社区③一个好故事Cloud 自家的 PaaS 产品建立在docker之上，长期维护且有大量的用户，社区也十分活跃，我们看看以下的关于Docker的故事：
1、环境管理复杂 - 从各种OS到各种中间件到各种app, 一款产品能够成功作为开发者需要关心的东西太多，且难于管理，这个问题几乎在所有现代IT相关行业都需要面对。
2、云计算时代的到来-AWS的成功, 引导开发者将应用转移到cloud上, 解决了硬件管理的问题，然而中间件相关的问题依然存在 (所以openstack HEAT和 AWS cloudformation 都着力解决这个问题)。开发者思路变化提供了可能性。
3、虚拟化手段的变化-cloud时代采用标配硬件来降低成本，采用虚拟化手段来满足用户按需使用的需求以 及保证可用性和隔离性。然而无论是KVM还是Xen在 docker 看来,都在浪费资源，因为用户需要的是高效运行环境而非OS, GuestOS既浪费资源又难于管理, 更加轻量级的LXC更加灵活和快速。
4、LXC的移动性 - LXC在 linux 2.6 的 kernel 里就已经存在了，但是其设计之初并非为云计算考虑的，缺少标准化的描述手段和容器的可迁移性，决定其构建出的环境难于迁移和标准化管理(相对于KVM之类image和snapshot的概念)。docker就在这个问题上做出实质性的革新。这是docker最独特的地方。（Docker一个显著的功效就是支持环境的迁移☆☆☆☆☆）
面对以上的故事，Docker设想是：
交付运行环境如同海运，OS如同一个货轮，每一个在OS基础上的软件都如同一个集装箱，用户可以通过标准化手段自由组装运行环境，同时集装箱的内容可以由用户自定义，也可以由专业人员制造。这样，交付一个软件，就是一系列标准化组件的集合的交付，如同乐高积木，用户只需要选择合适的积木组合，并且在最顶端署上自己的名字(最后一个标准化组件是用户的app)。这也就是基于docker的PaaS产品的原型。
※LXC：Linux Container容器是一种内核虚拟化技术，可以提供轻量级的虚拟化，以便隔离进程和资源。而且不需要提供指令解释机制以及全虚拟化的其他复杂性。
Docker与集装箱
Docker的思想来自于集装箱，集装箱解决了什么问题？在一艘大船上，可以把货物规整的摆放起来。并且各种各样的货物被集装箱标准化了，集装箱和集装箱之间不会互相影响。那么我就不需要专门运送水果的船和专门运送化学品的船了。只要这些货物在集装箱里封装的好好的，那我就可以用一艘大船把他们都运走。
Docker就是类似的理念。现在都流行云计算了，云计算就好比大货轮。Docker就是集装箱。
Docker架构原理
1、架构
Docker使用客户端-服务器(C/S)架构模式，使用远程API来管理和创建Docker容器。Docker容器通过Docker镜像来创建。容器与镜像的关系类似于面向对象编程中的对象与类。
Docker采用 C/S架构 Docker daemon 作为服务端接受来自客户的请求，并处理这些请求（创建、运行、分发容器）。客户端和服务端既可以运行在一个机器上，也可通过socket或者RESTful API 来进行通信。Docker daemon 一般在宿主主机后台运行，等待接收来自客户端的消息。Docker 客户端则为用户提供一系列可执行命令，用户用这些命令实现跟 Docker daemon 交互。
2、原理
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解决的。
总结：
Docker在本质上是一个附加系统。使用文件系统的不同层构建一个应用是有可能的。每个组件被添加到之前已经创建的组件之上，可以比作为一个文件系统更明智。分层架构带来另一方面的效率提升，当你重建存在变化的Docker镜像时，不需要重建整个Docker镜像，只需要重建变化的部分。可能更为重要的是，Docker旨在用于弹性计算。每个Docker实例的运营生命周期有限，实例数量根据需求增减。在一个管理适度的系统中，这些实例生而平等，不再需要时便各自消亡了。针对Docker环境存在的不足，意味着在开始部署Docker前需要考虑如下几个问题。首先，Docker实例是无状态的。这意味着它们不应该承载任何交易数据，所有数据应该保存在数据库服务器中。
其次，开发Docker实例并不像创建一台虚拟机、添加应用然后克隆那样简单。为成功创建并使用Docker基础设施，管理员需要对系统管理的各个方面有一个全面的理解，包括Linux管理、编排及配置工具比如Puppet、Chef以及Salt。这些工具生来就基于命令行以及脚本。
3、特性
docker的网站上提到了docker的典型场景：
①使应用的打包与部署自动化
②创建轻量、私密的PAAS环境
③实现自动化测试和持续的集成/部署
④部署与扩展webapp、数据库和后台服务
由于其基于LXC的轻量级虚拟化的特点，docker相比KVM之类最明显的特点就是启动快，资源占用小。因此对于构建隔离的标准化的运行环境，轻量级的PaaS(如dokku), 构建自动化测试和持续集成环境，以及一切可以横向扩展的应用(尤其是需要快速启停来应对峰谷的web应用)
①构建标准化的运行环境，现有的方案大多是在一个baseOS上运行一套puppet/chef，或者一个image文件，其缺点是前者需要base OS许多前提条件，后者几乎不可以修改(因为copy on write 的文件格式在运行时rootfs是read only的)。并且后者文件体积大，环境管理和版本控制本身也是一个问题。
②PaaS环境是不言而喻的，其设计之初和dotcloud的案例都是将其作为PaaS产品的环境基础
③因为其标准化构建方法(buildfile)和良好的REST API，自动化测试和持续集成/部署能够很好的集成进来
④因为LXC轻量级的特点，其启动快，而且docker能够只加载每个container变化的部分，这样资源占用小，能够在单机环境下与KVM之类的虚拟化方案相比能够更加快速和占用更少资源
4、局限
Docker并不是全能的，设计之初也不是KVM之类虚拟化手段的替代品，简单总结几点：
①Docker是基于Linux 64bit的，无法在32bit的linux/Windows/unix环境下使用
②LXC是基于cgroup等linux kernel功能的，因此container的guest系统只能是linux base(linux为基础)
③隔离性相比KVM之类的虚拟化方案还是有些欠缺，所有container公用一部分的运行库
※KVM：是一个开源的系统虚拟化模块，自Linux 2.6.20之后集成在Linux的各个主要发行版本中。它使用Linux自身的调度器进行管理，所以相对于Xen，其核心源码很少。KVM的虚拟化需要硬件支持（如Intel VT技术或者AMD V技术)。是基于硬件的完全虚拟化。
④网络管理相对简单，主要是基于namespace隔离
⑤cgroup的cpu和cpuset提供的cpu功能相比KVM的等虚拟化方案相比难以度量(所以dotcloud主要是按内存收费)
※Cgroups是control groups的缩写，是Linux内核提供的一种可以限制、记录、隔离进程组（process groups）所使用的物理资源（如：cpu,memory,IO等等）的机制。cgroups实现了对资源的配额和度量。 cgroups的使用非常简单，提供类似文件的接口，在/cgroup目录下新建一个文件夹即可新建一个group，在此文件夹中新建task文件，并将pid写入该文件，即可实现对该进程的资源控制。具体的资源配置选项可以在该文件夹中新建子subsystem，{子系统前缀}.{资源项}是典型的配置方法如memory.usage_in_bytes 就定义了该group 在subsystem memory中的一个内存限制选项。cgroups中的 subsystem可以随意组合，一个subsystem可以在不同的group中，也可以一个group包含多个subsystem
⑥Docker对disk(磁盘)的管理比较有限
⑦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版本)
※kernel：操作系统的内核
Docker并非适合所有应用场景，Docker只能虚拟基于Linux的服务。Windows Azure 服务能够运行Docker实例，但到目前为止Windows服务还不能被虚拟化。可能最大的障碍在于管理实例之间的交互。由于所有应用组件被拆分到不同的容器中，所有的服务器需要以一致的方式彼此通信。这意味着任何人如果选择复杂的基础设施，那么必须掌握应用编程接口管理以及集群工具，比如Swarm、Mesos或者Kubernets(K8s)以确保机器按照预期运转并支持故障切换。
Docker 的优点：
①轻量级：所有容器在一台机器上共享同一个操作系统内核，这样他们立即开始，并更有效地利用内存。Image是从分层文件系统的构建，这样他们能够共享公共文件，使得磁盘使用率和Image的下载更加高效。
②开放：Docker容器基于开放标准，可在所有主要Linux发行版，Microsoft Windows以及任何基础架构（包括虚拟机，裸机和云中）上运行。
③安全：Docker容器将应用程序彼此隔离并从底层基础架构中分离出来。Docker提供了最强大的默认隔离功能，可以将应用程序问题限制在一个容器中，而不是整个机器上。
Docker与虚拟机的区别：
容器与虚拟机有着类似的资源隔离和分配的优点，但不同的架构方法使容器能够更加便携，高效等虚拟机是将一台服务器变成多台服务器的物理硬件的抽象。每个虚拟机都包括应用程序、必要的二进制文件和库以及一个完整的客户操作系统(Guest OS)，尽管它们被分离，它们共享并利用主机的硬件资源，将近需要十几个GB的大小。
虚拟化技术特点：
cpu：不同虚拟机的计算资源不混用
内存：不同虚拟机的内存不共享
网络：每个虚拟机有自己的网络栈
文件系统：每个虚拟机独享自己的文件系统传统的虚拟化消耗了一些系统资源，换来了对cpu、内存、网络和文件系统的隔离。换句话说，一个服务不会影响另一个服务的资源。于是自然的会想到，一个服务的依赖可以做成一套随着服务一起发布的文件系统，用时加载、停时弃置；也可以把需要不同资源的服务可以部署在一起以节约成本等等，隔离给了虚拟化真正的价值。容器包括应用程序及其所有的依赖，但与其他容器共享内核。它们以独立的用户空间进程形式运行在主机操作系统上。他们也不依赖于任何特定的基础设施，Docker容器可以运行在任何计算机上，任何基础设施和任何云上。容器占用的空间少于虚拟机（容器映像的大小通常为几十MB），并且几乎立即启动。
相对于传统的虚拟技术，Docker提供的容器化方案优势在于：
①虚拟化额外的资源占用更少了
②部署、启动和销毁的时间更短了
③部署、启动和销毁的工作量更少了
但相对于不使用容器化方案来说：
①占用的资源更多了（可以忽略）
②启动、销毁的时间增加了（可以忽略）
③部署的时间和工作量变少了
重：相对于不使用容器化的方案，Docker在效率方面主要的贡献是可以在不增加性能消耗的情况下，降低部署服务的工作量，提高部署效率。
虚拟机的架构
容器的架构
LXC与虚拟机区别：
Docker的容器利用了LXC，管理利用了namespaces来做权限的控制和隔离，cgroups来进行资源的配置，并且还通过AUFS来进一步提高文件系统的资源利用率，而这些技术都不是Docker独创。LXC与虚拟机的不同之处在于，它是一个操作系统级别的虚拟化环境，而不是硬件虚拟化环境。他们都做同样的事情，但LXC是操作系统级别的虚拟化环境，虚拟环境有它自己的进程和网络空间，而不是创建一个完整成熟的虚拟机。
因此，一个LXC虚拟操作系统具有最小的资源需求，并启动只需几秒钟。正如可以在下图中看到的，左侧是LXC虚拟的Ubuntu ，默认安装使用 11 MB 大小。
Docker与Microservices的关系
Microservices（微服务）依赖于“基础设施自动化”，而Docker正是“基础设施自动化”的利器。可以说Docker的火爆，一定程度上也带动了微服务架构的兴起，而微服务的广泛应用也促进了Docker繁荣。可以说两者相辅相成。有关微服务的介绍，可以详细参照《简述 Microservices（微服务）》。
参照URL： http://www.importnew.com/24651.html
关于Linux Namespace
LXC所实现的隔离性主要是来自kernel的namespace, 其中pid,net,ipc,mnt,uts等namespace将container的进程,网络,消息,文件系统和hostname隔离开。
1、pid namespace
之前提到用户的进程是lxc-start进程的子进程, 不同用户的进程就是通过pidnamespace隔离开的，且不同namespace中可以有相同PID。具有以下特征：
①每个namespace中的pid是有自己的pid=1的进程(类似/sbin/init进程)
②每个namespace中的进程只能影响自己的同一个namespace或子namespace中的进程
③因为/proc包含正在运行的进程，因此在container中的pseudo-filesystem的/proc目录只能看到自己namespace中的进程
④namespace允许嵌套，父namespace可以影响子namespace的进程，所以子namespace的进程可以在父namespace中看到，但是具有不同的pid。
正是因为以上的特征，所有的LXC进程在docker中的父进程为docker进程，每个lxc进程具有不同的namespace。同时由于允许嵌套，因此可以很方便的实现 LXC in LXC
2、net namespace
有了pid namespace,每个namespace中的pid能够相互隔离，但是网络端口还是共享host的端口。网络隔离是通过net namespace实现的，每个net namespace有独立的network devices, IP addresses, IP routing tables, /proc/net 目录。这样每个container的网络就能隔离开来。LXC在此基础上有5种网络类型，docker默认采用veth的方式将container中的虚拟网卡同host上的一个docker bridge连接在一起。
3、ipc namespace
container中进程交互还是采用linux常见的进程间交互方法(interprocess communication - IPC), 包括常见的信号量、消息队列和共享内存。然而同VM不同，container 的进程间交互实际上还是host上具有相同pid namespace中的进程间交互，因此需要在IPC资源申请时加入namespace信息 - 每个IPC资源有一个唯一的 32bit ID
3、mnt namespace
类似chroot，将一个进程放到一个特定的目录执行。mnt namespace允许不同namespace的进程看到的文件结构不同，这样每个namespace中的进程所看到的文件目录就被隔离开了。同chroot不同，每个namespace中的container在/proc/mounts的信息只包含所在namespace的mount point。
4、uts namespace
UTS(“UNIX Time-sharing System”) namespace允许每个container拥有独立的hostname和domain name,使其在网络上可以被视作一个独立的节点而非Host(主机)上的一个进程。
5、user namespace
每个container可以有不同的 user 和 group id，也就是说可以以container内部的用户在container内部执行程序而非Host(主机)上的用户。
总结：
有了以上6种namespace从进程、网络、IPC、文件系统、UTS和用户角度的隔离，一个container就可以对外展现出一个独立计算机的能力，并且不同container从OS层面实现了隔离。 然而不同namespace之间资源还是相互竞争的，仍然需要类似ulimit来管理每个container所能使用的资源 - LXC采用的是cgroup。
关于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特性的运用。
AUFS原理：
典型的Linux启动到运行需要两个FS - bootfs + rootfs (从功能角度而非文件系统角度)
如图一：
bootfs(boot file system)主要包含bootloader和kernel, bootloader主要是引导加载kernel,当boot成功后kernel被加载到内存中后bootfs就被umount了。mount挂载，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不保存用户状态，可以用于模板、重建和复制。
图4 图5 图6
上层的image依赖下层的image，因此docker中把下层的image称作父image，没有父image的image称作base image，如图6
ID、网络和lxc管理的资源限制等具体container的配置，构成一个docker概念上的container。如图7:
采用AUFS作为docker的container的文件系统，能够提供如下好处：
①节省存储空间 - 多个container可以共享base image存储
②快速部署 - 如果要部署多个container，base image可以避免多次拷贝
③内存更省 - 因为多个container共享base image, 以及OS的disk缓存机制，多个container中的进程命中缓存内容的几率大大增加
④升级更方便 - 相比于 copy-on-write 类型的FS，base-image也是可以挂载为可writeable的，可以通过更新base image而一次性更新其之上的container
⑤允许在不更改base-image的同时修改其目录中的文件 - 所有写操作都发生在最上层的writeable层中，这样可以大大增加base image能共享的文件内容。
以上5条 1-3 条可以通过 copy-on-write 的FS实现, 4可以利用其他的union mount方式实现, 5只有AUFS实现的很好。这也是为什么Docker一开始就建立在AUFS之上。
介绍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。Docker项目提供了构建在Linux内核功能之上，协同在一起的的高级工具。其目标是帮助开发和运维人员更容易地跨系统跨主机交付应用程序和他们的依赖。Docker通过Docker容器，一个安全的，基于轻量级容器的环境，来实现这个目标。这些容器由镜像创建，而镜像可以通过命令行手工创建或者通过Dockerfile自动创建。Dockerfile是由一系列命令和参数构成的脚本，这些命令应用于基础镜像并最终创建一个新的镜像。
步骤5：
配置测试部署。应对在容器中运行的应用程序进行配置，以便于让应用程序知道可以在哪里连接外部资源或者应用程序集群中的其他容器。企业用户可以把这些配置部署在容器中或使用环境变量。对基于容器的应用程序进行测试类似于对其他分布式应用程序的测试。企业可以对每个容器进行组件测试，并将容器集群作为一个整体进行测试。 确定应用程序应如何能够在负载增加的情况下进行扩展。如果用户正在使用一个集群管理器（例如Swarm），则可测试其性能。※※Swarm：一个Web应用程序开发框架，Swarm允许程序分布在多台计算机，从某种程度上让程序对程序员完全透明。Swarm将会观察程序的执行，并计算出如何在计算机之间分配计算量以达到效率最大化。目前还处于早期发展阶段。最后，把容器部署到实际生产环境中。为了积极主动地关注基于容器的应用程序的运行状况，可考虑实施必要的监控和管理机制 。确保打开日志记录功能。很多应用程序迁移至云计算都是采用容器技术的。虽然迁移有一点复杂，但是容器可以保护应用程序投资并赋予了它一个更长的使用寿命。
Docker安全
1、确保环境安全
Docker十分火热，很多人表示很少见如此能够吸引行业兴趣的新兴技术。然而，当兴奋转化为实际部署时，企业需要注意Docker的安全性。了解Docker的人都知道，Docker利用容器将资源进行有效隔离。因此容器相当于与Linux OS和hypervisor有着几乎相同的安全运行管理和配置管理级别。但当涉及到安全运营与管理，以及具有保密性、完整性和可用性的通用控件的支持时，Docker可能会让你失望。当容器运行在本地系统上时，企业可以通过其安全规则确保安全性。但一旦容器运行在云端，事实就不会如此简单了。当Docker运行在云提供商平台上时，安全性变得更加复杂。你需要知道云提供商正在做什么，或许你正在与别人共享一台机器。虽然容器没有内置的安全因素，而且像Docker这样的新兴技术很难有比较全面的安全措施，但这并不意味着以后也不会出现。
※hypervisor：一种运行在物理服务器和操作系统之间的中间软件层，可允许多个操作系统和应用共享一套基础物理硬件，因此也可以看作是虚拟环境中的“元”操作系统，它可以协调访问服务器上的所有物理设备和虚拟机，也叫虚拟机监视器（Virtual Machine Monitor）。他们可以访问服务器上包括磁盘和内存在内的所有物理设备。Hypervisors 不但协调着这些硬件资源的访问，也同时在各个虚拟机之间施加防护。当服务器启动并执行Hypervisor时，它会加载所有虚拟机客户端的操作系统同时会分配给每一台虚拟机适量的内存，CPU，网络和磁盘。
2、部署安全性
也有专家将Docker安全问题的实质定位于配置安全，认为Docker目前的问题是很难配置一个安全的容器。虽然现在Docker的开发人员通过创建非常小的容器来降低攻击面，但问题在于大型企业内部在生产环境中运行Docker容器的员工需要有更多的可见性和可控性。专家认为，大约90%的外部网络攻击并不是超级复杂的，攻击者多是利用了管理员的行为漏洞，比如配置错误或者未及时安装补丁。因此，企业在部署数千或数万台容器时，能够确保这些容器都遵守企业安全策略进行配置是至关重要的事情。为解决这个问题，就需要增加Docker容器部署的实时可见性，同时实施企业制定的安全策略。Docker为解决这个问题，就需要增加Docker容器部署的实时可见性，同时实施企业制定的安全策略。也有一些厂商为此推出解决方案，给运营商提供了实时可见性并帮助他们执行容器级别的虚拟基础设施的安全策略。
3、Docker安全中心
在新的功能中有硬件的部分，可以跨任何基础架构，允许开发和随后的升级中的数字编码签名。构建在Docker Trust框架之上用来进行镜像发布者认证，同时进行新的镜像扫描和官方漏洞检测，以便能够更好地理解容器内部是什么。
☆命名空间是本周发布的另外一个Docker安全升级。允许IT运用来为基于用户群组的容器指派授权，约束了主机的访问根源，并指定了系统管理员，限制了群组对于指定服务的访问。☆
镜像扫描对于Docker Hub上的所有官方版本都可用，同时命名空间和硬件签名则在Docker的实验渠道提供。安全问题仍旧是容器采纳要解决的最大问题，尤其是如果大量容器是便携的，IDC研究经理Larry Carvalho说道。通过硬件解决这个问题很明智，因为这样更难以介入，并且提供了未来可能被使用的大量容器的效率。Carvhalho说：“他们还应该解决的一个问题是容量，你没有办法在软件层面做大量的安全，因为要有很多开支。”
Docker能做什么
Docker 是一种“容器即服务”（Docker Containers as a Service ，简称CaaS），使得开发和IT运营团队可以对于应用的构建、发布、运行更加敏捷和可控。(Caas<=>Paas+Iaas)
概括的说： Docker 是为开发人员和系统管理员用于构建、发布、并运行分布式应用程序的开放式平台。该平台由Docker引擎（一个便携、轻巧的运行时和打包工具）和Docker Hub（一个共享应用程序和自动化工作流的云服务）等组成。Docker可以使应用程序从组件迅速组装并消除了开发、质量保证和生产环境之间的摩擦问题。这样一来，IT部门可以更快地发布，而这些应用程序不管是运行在笔记本电脑、数据中心的虚拟机，还是任何的云，其运行过程和结果都是一致的。看下 Docker 的 Logo 。很明显，这是一只鲸鱼，它托着许多集装箱。我们可以把宿主机可当做这只鲸鱼，把相互隔离的容器可看成集装箱，每个集装箱中都包含自己的应用程序。
为什么要用Docker呢？
1、开发更加敏捷：Docker 让开发人员可以自由定义环境，创建和部署的应用程序更快、更容易，IT 运维人员快速应对变化也更加灵活性。
2、更加可控：Docker使得开发人员保存从基础设施到应用的代码，帮助IT运维人管理拥有标准的、安全的、可扩展的操作环境。
3、高可移植性：Docker允许自由选择，可以是从笔记本电脑到一个团队，从私人基础设施到公共云提供商。 这样，你可以专注于开发应用，其他的繁琐事交给 Docker 去做吧。
Docker都可以干什么？
1、不同的应用程序可能会有不同的应用环境，比如.net开发的网站和php开发的网站依赖的软件就不一样，如果把他们依赖的软件都安装在一个服务器上就要调试很久，而且很麻烦，还会造成一些冲突。比如IIS和Apache访问端口冲突。这个时候你就要隔离.net开发的网站和php开发的网站。常规来讲，我们可以在服务器上创建不同的虚拟机在不同的虚拟机上放置不同的应用，但是虚拟机开销比较高。Docker可以实现虚拟机隔离应用环境的功能，并且开销比虚拟机小，小就意味着省钱了。
2、你开发软件的时候用的是Ubuntu，但是运维管理的都是centos，运维在把你的软件从开发环境转移到生产环境的时候就会遇到一些Ubuntu转centos的问题，比如：有个特殊版本的数据库，只有Ubuntu支持，centos不支持，在转移的过程当中运维就得想办法解决这样的问题。这时候要是有Docker你就可以把开发环境直接封装转移给运维，运维直接部署你给他的Docker就可以了。而且部署速度快。
3、在服务器负载方面，如果你单独开一个虚拟机，那么虚拟机会占用空闲内存的，Docker部署的话，这些内存就会利用起来。
4、Docker是一个便携的应用容器，容器内运行自己的应用（当然可以是任何应用）Docker都提供了一个基础系统镜像作为运行应用时的基础系统。也就是说，只要是 Linux 系统上的应用都可以运行在 Docker 中。
可以在 Docker 里面运行数据库吗？当然可以。
可以在 Docker 里面运行 Node.js 网站服务器吗？当然可以。
可以在 Docker 里面运行 API 服务器吗？当然可以。
Docker并不在乎你的应用程序是什么、做什么，Docker提供了一组应用打包、传输和部署的方法，以便你能更好地在Docker容器内运行任何应用。
5、提供一次性的环境。比如，本地测试他人的软件、持续集成的时候提供单元测试和构建的环境。
6、快速搭建环境
对开发者而言，每天会催生出的各式各样的新技术都需要尝试，然而开发者却不太可能为他们一一搭建好环境并进行测试。时间非常宝贵，正是得益于Docker，让我们有可能在一条或者几条命令内就搭建完环境。Docker 有一个傻瓜化的获取软件的方法，Docker 后台会自动获得环境镜像并且运行环境。并不仅仅是新技术环境搭建用得到 Docker。如果你想快速在你的笔记本上运行一个MySQL数据库，或者一个Redis消息队列，那么使用 Docker 便可以非常容易地做到。例如 Docker 只需要一条命令便可以运行 MySQL 数据库：docker run -d -p 3306:3306 tutum/mysql
※虽然使用命令也能非常快地安装MySQL数据库，但是当用到最新的技术或者非常复杂的技术时，使用Docker便会是个非常好的选择，例如 Gitlab，普通用户大概需要一天的时间去搭建Gitlab平台，而Docker则只需要一条命令。
7、迁移的方便，应对各种演示
现在我经常需要在周末用自己开发的成果对客户活着别人做一两个演示。搭建演示环境的过程非常麻烦。现在我发现Docker已经成为我演示这些工具的最合理的方式。同时，对于客户来说，我可以直接将Docker镜像提供给他们，而不必去做任何环境配置的工作，工作的效果也会和在他们演示中所看到的一模一样，同时不必担心他们的环境配置会导致我们的产品无法运行。
8、灵活管理各种环境及版本
由于Docker搭建环境的快速及良好的隔离性，可以基于Docker创建：开发环境、测试环境、生产环境。并且三个环境上对应好相应的开发代码版本，测试代码版本及生产代码版本。因为环境配置不同，很多人在开发中也会遇到这个情况，甚至开发的软件到了测试人员的机器上便不能运行。但这都不是重点。重点是，如果我们有一个可靠的、可分发的标准开发环境，那么我们的开发将不会像现在这么痛苦。Docker 便可以解决这个问题。Docker镜像并不会因为环境的变化而不能运行，也不会在不同的电脑上有不同的运行结果。可以给测试人员提交含有应用的 Docker 镜像，这样便不再会发生“在我机器上是可以运行的”这种事情，很大程度上减轻了开发人员测试人员互相检查机器环境设置带来的时间成本。
9、提供弹性的云服务。因为 Docker 容器可以随开随关，很适合动态扩容和缩容。
10、组建微服务架构。通过多个容器，一台机器可以跑多个服务，因此在本机就可以模拟出微服务架构。
11、更好的利用资源
虚拟机的粒度是“虚拟出的机器”，而 Docker 的粒度则是“被限制的应用”，相比较而言 Docker 的内存占用更少，更加轻量级。Docker的一个优势：因为我经常在自己电脑中运行多个Docker应用，使用Docker比使用虚拟机更加简单，方便，粒度更细，也能持续地跟踪容器状态。
12、为微服务定制
Docker可以很好地和微服务结合起来。从概念上来说，一个微服务便是一个提供一整套应用程序的部分功能，Docker便可以在开发、测试和部署过程中一直充当微服务的容器。甚至生产环境也可以在Docker中部署微服务。
13、云服务提供商之间移植
大多数的云主机提供商已经全面支持 Docker。对于开发人员来说，这表示你可以很方便地切换云服务提供商，当然也可以很方便地将你本地的开发环境移动到云主机上，不需要本地上配置一次运行环境、在云主机上还配置一次运行环境。全面部署Docker(Docker here and Docker there)作为标准运行环境可以极大地减轻应用上线时的工作量和产生BUG。
14、API端
API 是应用之间的粘合剂，一个合格开发者肯定使用过别人提供的 REST API，或者自己开发过 REST API。需要指出的是，无论是客户端还是 API 提供端，在开发之前都需要先定义一组公共的 API 接口，写成文档，然后才能进行编码。如果服务端和客户端是共同开发的话，那么服务端通常会先实现能返回固定字符串的API接口，在以后的开发中再慢慢去实现API的功能。虽然有人会认为在这里Docker被滥用了，完全可以用"sample.json"这种文件去实现虚拟 API,
但是下面有个实例可以更好地解决前后端分离开发时的 API 问题。为了更好地解释我的意思，给大家提供一个实例：
JSON Server，一个用于提供JSON数据的 REST API。使用过这个容器的人就会知道，既然有这么好用的Docker JSON Server，我们没有理由不用 Docker。
①运行示例的JSON Server，同时使用示例中提供的JSON文件，只需执行一条命令便可以创建一个服务端的API应用。
②使用curl http://127.0.0.1:80/posts即可获取示例文件中的 posts 段，这样在后端没有开发完API的时候，前端一样可以进行协同开发。
Docker的现阶段：
Docker正在快速发展，工具也在不断更新，没有人能预见到未来Docker会是什么样子的。你在复杂的系统中Docker使用的越多，越是可能会发现技术上的空白和未来技术发展的方向。现在还处在Docker的发展期，任何你使用Docker创建的工具都有可能成为社区关注的热点。这是Docker的机会，也是成就你自己的机会。
Docker两个技巧：
①Docker Hub Registry。这是Docker的官方镜像仓库，除了托管着Docker官方的镜像外，和Github一样，你可以在上面上传自己的镜像，也可以在上面搜寻其他有用的镜像，极大地节省自己的时间。例如Oracle-XE-11g镜像，所有的一切都是现成的，完全不需要自己去下载 Oracle XE 11g 安装。这样为你和团队节约了大量的时间成本。如果你不太确定的话，可以去 Docker Hub 上搜有一下有没有自己用得到的镜像。大部分情况下你所需要的镜像在 Docker Hub 上都已经有人构建了。
②多参考IaaS供应商的新闻，虽然我们不能像在他们会议室里那样完全了解他们的公司动态，但是仍然可以从新闻中可以了解到Docker最新的发展方向和技术趋势。可以肯定的是，容器化技术是未来的热点，我们不仅可以在本机运行Docker，不仅仅在一家云服务提供商的主机上运行 Docker，未来所有的云服务提供商都会支持 Docker。
Docker前景很明确，采用Docker只会让开发变得更方便。
总结：
Docker本身带来了什么：
①更高效的服务部署、启动方式。②对cpu、内存、网络和文件系统的简单隔离。由于docker本身带来了这两点好处，通过docker和相关的生态系统，可以更简单的实现：
①系统监控和管理对象由“机器”改为抽象的“资源”
②基于对资源的抽象，提供更灵活的服务部署、调度机制
Docker能做也仅仅是调整天平中众多砝码中的几个而已。更高效的集群管理、更高的资源利用率是目的，Docker的生态系统、服务发现和微服务等都是手段，与其纠结于我们要用docker做什么，不如拆分成两个问题：我们要做什么，docker能帮我们做什么。
kubernets(K8s)与Docker
Kubernetes
https://blog.csdn.net/whdxjbw/article/details/80739529
https://baike.baidu.com/item/kubernetes/22864162?fr=aladdin
http://www.dockone.io/article/932
http://baijiahao.baidu.com/s?id=1602795888204860650&wfr=spider&for=pc
https://gitbook.cn/books/5aadcf4f984e353193a90ddb/index.html?utm_source=dl18041002
基于Docker和Kubernetes的最佳架构实践
http://dockone.io/article/3694
☆Kubernetes主要作用是管理Docker集群☆
CentOS上部署Kubernetes管理docker集群
https://blog.csdn.net/dt763C/article/details/79245663
https://www.cnblogs.com/xhyan/p/6655731.html
ubuntu上部署Kubernetes管理docker集群
https://www.cnblogs.com/lixigang/articles/4952959.html
https://blog.csdn.net/zhenliang8/article/details/78611004
生产环境使用K8s一年之后经验教训
http://www.360doc.com/content/18/0630/22/54185769_766698906.shtml
kubernets(K8s)与Swarm对比：K8s、Swarm与Docker结合上，K8s比Swarm要复杂，维护成本高。Swarm更容易上手，Swarm与Docker有天然集成部分。
K8s轻量级、实施快、以实现核心功能为重，比较适合小规模部署，Swarm则是企业级、功能全、支撑场景多，适合做企业级docker云方案。swarm偏重的是容器的部署，而k8s更高一层：应用的部署。
Swarm自带的负载均衡机制应用不广，大部分还是采用nginx+consul。kubernetes的负载均衡要完善很多，内部集成了负载均衡。
K8S作为一款企业级的容器云方案，更值得我们进行研究。套用业界流行的话：swarm懂容器，但K8S更懂管理。
K8s与Swarm详细参照URL：
https://www.cnblogs.com/i6first/p/9399213.html
https://yq.aliyun.com/articles/679005
https://blog.csdn.net/dt763C/article/details/78818672
K8s离线安装zookeeper和kafka
https://www.kubernetes.org.cn/tags/zookeeper
Docker总结
Docker推出的一个名为Docker Content Trust（DCT）的新功能，它可帮助IT专业人士确保Docker的安全性。DCT使用了一个公共密钥基础设施（PKI）的方法，它提供了两个不同的密钥：一个离线（root）密钥和一个标记（每次入库）密钥，当第一次发布者推出镜像时它可创建和存储客户端。此举有助于弥补正在使用恶意容器这一最大的漏洞。DCT还生成了一个时间戳密钥，它可保护系统免受重放攻击，即运行过期的标记内容。这解决了上面提及容器具有不同安全补丁等级的问题。为了解决针对容器安全性的问题，包括Docker在内的众多公司都为Docker发布了安全基准。这套标准为确保Docker容器的安全性提供了指导。全篇118页的文档囊括了部署Docker容器的84个最佳实践以及一个涉及所有内容的检查清单。 如果你决定自行负责确保Docker容器的安全性，但又不知道从何入手，这里为你提供了一些建议：
1、阅读上面提及的Docker安全基准文件。重点关注与如何部署基于容器的应用程序相关的建议和最佳实践。这真的是有助于缓解你的财务压力，认真考虑大部分因糟糕设计而导致的Docker安全性问题。
2、考虑你的特定安全性需求。这将促使你选择正确的工具和方法。很多使用容器技术的企业对于他们基于容器的应用程序要么安全措施不足，要么安全措施过足。
3、尽可能多地进行测试。容器技术是新技术，因此我们需要搞清楚哪些是能够发挥作用，哪些是无用的，而要做到这一点的唯一方法就是进行安全性方面的测试，例如渗透测试。
※渗透测试：
为了证明网络防御按照预期计划正常运行而提供的一种机制。不妨假设，你的公司定期更新安全策略和程序，时时给系统打补丁，并采用了漏洞扫描器等工具，以确保所有补丁都已打上。如果你早已做到了这些，为什么还要请外方进行审查或渗透测试呢？因为，渗透测试能够独立地检查你的网络策略，换句话说，就是给你的系统安了一双眼睛。而且，进行这类测试的，都是寻找网络系统安全漏洞的专业人士。说白了渗透测试是一种利用模拟黑客攻击的方式，来评估计算机网络系统安全性能的方法。评估计算机网络系统安全性能的方法。
通常的黑客攻击包括预攻击、攻击和后攻击三个阶段：
1、预攻击阶段主要指一些信息收集和漏洞扫描的过程；
2、攻击过程主要是利用第一阶段发现的漏洞或弱口令等脆弱性进行入侵；
3、后攻击是指在获得攻击目标的一定权限后，对权限的提升、后面安装和痕迹清除等后续工作。与黑客的攻击相比，渗透测试仅仅进行预攻击阶段的工作，并不对系统本身造成危害，即仅仅通过一些信息搜集手段来探查系统的弱口令、漏洞等脆弱性信息。为了进行渗透测试，通常需要一些专业工具进行信息收集。渗透测试工具种类繁多，涉及广泛，按照功能和攻击目标分为网络扫描工具、通用漏洞检测、应用漏洞检测三类。
1、网络扫描工具
网络扫描是渗透测试的第一步，其目的在于发现目标的操作系统类型、开放端口等基本信息，为后续的扫描工作做基础。事实上，利用操作系统本身的一些命令如ping、telnet、nslookup等也可以对目标的信息进行判断，但是利用专业的 工具可以给出更加全面和准确的判断。常用的工具有如下：
NMap、SuperScan、Wireshark等
2、通用漏洞检测
在获取了目标主机的操作系统、开放端口等基本信息后，通常利用通用漏洞扫描工具检测目标系统所存在的漏洞和弱口令。常用的工具有如下：
Nessus、X-Scan、Metasploit等
3、Web应用漏洞检测
随着信息网络的发展，人们的信息安全意识日益提升，信息系统的安全防护措施也逐渐提高。通常在服务器的互联网边界处都会部署防火墙来隔离内外网络，仅仅将外部需要的服务器端口暴露出来。采用这种措施可以大大的提高信息系统安全等级，对于外部攻击者来说，就像关闭了所有无关的通路，仅仅留下一个必要入口。但是仍然有一类安全问题无法避免，就是web应用漏洞。目前的大多数应用都是采用B/S模式，由于服务器需要向外界提供web应用，http服务是无法关闭的。web应用漏洞就是利用这个合法的通路，采用SQL注入、跨站脚本、表单破解等应用攻击方式来获取服务器的高级权限。在目前的网络环境下，威胁最大的漏洞形式就是web应用漏洞，通常是攻击者攻陷服务器的第一步。常见的漏洞包括SQL注入、跨站脚本攻击和编码漏洞等，表单破解主要是针对服务器用户的弱口令破解。常用工具：AppScan、溯雪、Pangolin
Docker解决问题
在了解Docker解决的问题之前，需要先了解一个概念，什么叫DevOps？
DevOps是Development和Operations合成单词。DevOps是一种软件开发方法，涉及软件在整个开发生命周期中的持续开发、持续测试、持续集成、持续部署、持续监控。云计算、大数据，移动技术的快速发展，加之企业业务需求的不断变化，导致企业架构要随时更改以适合业务需求，跟上技术更新的步伐。毫无疑问，这些重担都将压在企业开发人员身上；团队之间如何高效协调，快速交付产品，快速部署应用，以及满足企业业务需求，是开发人员亟需解决的问题。Docker技术恰好可以帮助开发人员解决这些问题。为了解决开发人员和运维人员之间的协作关系，加快应用交付速度，越来越多的企业引入了DevOps这一概念。但是，传统的开发过程中，开发、测试、运维是三个独立运作的团队，团队之间沟通不畅，开发运维之间冲突时有发生，导致协作效率低下，产品交付延迟，影响了企业的业务运行。Docker技术将应用以集装箱的方式打包交付，使应用在不同的团队中共享，通过镜像的方式，应用可以部署于任何环境中。这样避免了各团队之间的协作问题的出现，成为企业实现DevOps目标的重要工具。以容器方式交付的Docker技术支持不断地开发迭代，大大提升了产品开发和交付速度。此外，与通过Hypervisor把底层设备虚拟化的虚拟机不同，Docker直接移植于Linux内核之上，通过运行Linux进程将底层设备虚拟隔离，这样系统性能的损耗也要比虚拟机低的多，几乎可以忽略。同时，Docker应用容器的启停非常高效，可以支持大规模的分布系统的水平扩展，真正给企业开发带来福音。
Docker未来发展
任何一项新技术的出现，都需要一个发展过程，比如云计算为企业所接受用了将近五年左右时间，OpenStack技术也经历了两、三年才受到人们的认可。因此，虽然Docker技术发展很快，但技术还不够成熟，对存储的灵活的支持、网络的开销和兼容性方面还存在限制，这是Docker没有被企业大范围使用的一个主要原因。另外一个原因是企业文化是否与DevOps运动一致，只有企业支持DevOps，才能更大地发挥Docker的价值。最后一个原因就是安全性问题，Docker对于Linux这一层的安全的隔离还有待改进，才能进一步得到企业的认可。
实现企业价值
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 Network ）让你可以方便地在同一主机下对容器进行网络连接。加上一些其他的工作，你就可以跨主机使用叠加网络功能。然而，也就到此为止了。网络配置操作是受限的，而且到目前为止可以说这些手段都是人工的。尽管容器脚本化可以规模化，因为你必须给网络定义增加预分配实例，每次提供容器时还需要额外步骤，这容易引起错误。
②库控制受限：库已经成为任何容器会话的中心议题。公共库是最有价值的，因为他贡献了大量的预置容器，节省了许多的配置时间。然而，在沙盒里使用它是有风险的。在不知道谁以及如何创建镜像的情况下，可能会存在任意数量的有意或无意的稳定性和安全性风险。对于企业来说，有必要建立和维护一个私有库，这个库的建立挑战不大，但管理是个问题。Docker为大型库的镜像管理提供了一个有限的元数据模型，确保未来实例如预期的能力受限，也没有叠加功能。
③没有清晰的审计跟踪：提供容器是很简单的，但知道提供容器的时间、原因、方式以及提供方却不容易。因此，在提供之后，你并不掌握多少出于审计目的的历史。
④运行实例的低可见性：如果没有经过深思熟虑的行动，实例提供后很难接触到运行容器的对象，也很难知道哪些应该出现在那里，哪些不应该出现在那里。
微服务与弹性调度
怎么更大限度的提高资源的利用率？又是显而易见的，要提高资源利用率，就得降低资源的浪费，而浪费来源于两方面：
服务自身和依赖环境对资源的浪费、服务没有利用到的空闲资源。一般来说，一个服务内聚越高，对资源的浪费就越少但现实情况下资源被拆分成一台台计算机，服务也要跟着拆分。当服务的拆分不能保证和资源拆分相同的粒度时，空闲资源就产生了。服务拆分的粒度越粗，与资源不匹配的矛盾会越激烈；拆分粒度越细，带来的资源浪费也就越多。另一方面，服务内聚提高会带来更高的耦合度和风险，反之会带来更高的部署和维护成本，等等。所以服务拆到多细这件事本身没有定论，Docker能做到的只是降低其中一两个砝码的权重而已。
集群管理与服务发现
在一个资源上启动了服务之后，接下来的问题是：启动了这个服务有什么用？因为在启动服务之后，服务只是“可用”的，并没有提高资源的利用率。需要有一种机制，让可用的服务变成被使用的服务，有很多方法可以实现，比如通过配置文件指定访问的ip和端口，大部分场景下，手工配置的方式已经足够了。但是伴随着系统越来越复杂，配置也越来越负责，渐渐的手工配置已经有些吃力了。而伴随着虚拟化和容器化，配置的修改也越来越频繁和复杂，甚至已经超过了启动服务本身的难度。单纯启动一个服务没有意义，需要通过一个足够可靠和高效的机制把“可用”的服务变成“被用”的服务，服务发现担当了这个任务。Docker做到了一些提高资源利用率方面。
1038
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
