三大核心组件：镜像，容器和库
1.docker镜像（image）
镜像是创建docker容器的基础， docker镜像类似于虚拟机镜像，可以将它理解为一个面向docker引擎的只读模块，包含文件系统。
创建镜像有三种方法：
（1）基于已有镜像的容器创建。主要是利用docker commit命令。
（2）基于本地模板导入。推荐利用OpenVZ提供的模板来创建。
（3）基于dockerfile创建。首先按照dockerfile的格式，编写好dockerfile文件，之后通过docker build命令来创建镜像。docker build会读取制定的 dockerfile，由docker服务器来创建镜像。
2.docker容器（container）
容器是从镜像创建的应用运行实例，容器之间是相互隔离、互不可见的。可以把容器看做一个简易版的linux系统环境（包括root权限、进程空间、用户空间和网络空间等），以及运行在这个环境上的应用打包而成的应用盒子。
镜像自身是自读的，容器从镜像启动的时候，docker会在镜像的最上层创建一个可写文件层，镜像本身保持不变。
可以利用docker create命令创建一个容器，创建后的的容器处于停止状态，可以使用docker start命令来启动它。也可以直接李东docker run命令来直接从镜像启动运行一个容器。docker run = docker creat + docker start。
当利用docker run创建并启动一个容器时，docker在后台的标准操作包括：
（1）检查本地是否存在指定的镜像，不存在就从公有仓库下载。
（2）利用镜像创建并启动一个容器。
分配一个文件系统，并在只读的镜像层外面挂载一层可读写层。
（4）从宿主机配置的网桥接口中桥接一个虚拟的接口到容器中。
（5）从地址池中配置一个IP地址给容器。
（6）执行用户指定的应用程序。
（7）执行完毕后容器终止。
3.docker仓库（Repository）
仓库是存放docker镜像的地方。仓库和注册服务器（Registry）还是有区别的。注册服务器是存放仓库的地方，在其中存放了很多仓库，每个仓库存放一类镜像文件。
仓库分为公有仓库和私有仓库，DockerHub是目前最大的公有仓库。可以通过docker push/pull命令从仓库中上传和下载镜像，docker search命令来搜索镜像。
容器是完全使用 沙箱 机制，相互之间不会有任何接口（类似 iPhone 的 app）。几乎没有性能开销,可以很容易地在机器和数据中心中运行。最重要的是,他们不依赖于任何语言、框架包括系统。
Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现 虚拟化。
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最独特的地方。
上述几个问题，docker设想是交付运行环境如同海运，OS如同一个货轮，每一个在OS基础上的软件都如同一个集装箱，用户可以通过标准化手段自由组装运行环境，同时集装箱的内容可以由用户自定义，也可以由专业人员制造。这样，交付一个软件，就是一系列标准化组件的集合的交付，如同乐高积木，用户只需要选择合适的积木组合，并且在最顶端署上自己的名字(最后个标准化组件是用户的app)。这也就是基于docker的PaaS产品的原型。
在docker的网站上提到了docker的典型场景：
- Automating the packaging and deployment of applications
- Creation of lightweight, private PAAS environments
- Automated testing and continuous integration/deployment
- Deploying and scaling web apps, databases and backend services
由于其基于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之类的虚拟化方案相比能够更加快速和占用更少资源
Docker并不是全能的，设计之初也不是KVM之类虚拟化手段的替代品，简单总结几点：
- Docker是基于Linux 64bit的，无法在32bit的linux/Windows/unix环境下使用
- LXC是基于cgroup等linux kernel功能的，因此container的guest系统只能是linux base的
- 隔离性相比KVM之类的虚拟化方案还是有些欠缺，所有container公用一部分的运行库
- 网络管理相对简单，主要是基于namespace隔离
- cgroup的cpu和cpuset提供的cpu功能相比KVM的等虚拟化方案相比难以度量(所以dotcloud主要是按内存收费)
- 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版本)
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 (ns)
LXC所实现的隔离性主要是来自kernel的namespace, 其中pid, net, ipc, mnt, uts 等namespace将container的进程, 网络, 消息, 文件系统和hostname 隔离开。
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
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。
确保Docker容器安全性的工具与最佳实践
Docker推出的一个名为Docker Content Trust（DCT）的新功能，它可帮助IT专业人士确保Docker的安全性。DCT使用了一个公共密钥基础设施（PKI）的方法，它提供了两个不同的密钥：一个离线（root）密钥和一个标记（每次入库）密钥，当第一次发布者推出镜像时它可创建和存储客户端。
此举有助于弥补正在使用恶意容器这一最大的漏洞。DCT还生成了一个时间戳密钥，它可保护系统免受重放攻击，即运行过期的标记内容。这解决了上面提及容器具有不同安全补丁等级的问题。
为了解决针对容器安全性的问题，包括Docker在内的众多公司都为Docker发布了安全基准。这套标准为确保Docker容器的安全性提供了指导。全篇118页的文档囊括了部署Docker容器的84个最佳实践以及一个涉及所有内容的检查清单。
那么，如果你决定自行负责确保Docker容器的安全性，但又不知道从何入手，我们在这里为你提供了一些建议：
阅读上面提及的Docker安全基准文件。重点关注与如何部署基于容器的应用程序相关的建议和最佳实践。这真的是有助于缓解你的财务压力，认真考虑大部分因糟糕设计而导致的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为解决这个问题，就需要增加Docker容器部署的实时可见性，同时实施企业制定的安全策略。也有一些厂商为此推出解决方案，给运营商提供了实时可见性并帮助他们执行容器级别的虚拟基础设施的安全策略。
