让我们来看看Docker的技术特性列表，并检查哪些是由LXC提供的，哪些不是。

特点:

1)文件系统隔离:每个进程容器运行在完全独立的根文件系统中。

提供普通LXC。

2)资源隔离:系统资源如cpu和内存可以使用cgroups不同地分配给每个进程容器。

提供普通LXC。

3)网络隔离:每个进程容器运行在自己的网络命名空间中，具有自己的虚拟接口和IP地址。

提供普通LXC。

4)写时复制:根文件系统是使用写时复制创建的，这使得部署非常快，内存和磁盘成本低。

这是由AUFS提供的，AUFS是Docker所依赖的联合文件系统。您可以使用LXC手动设置AUFS，但Docker将其作为标准使用。

5)日志记录:收集每个流程容器的标准流(stdout/stderr/stdin)并记录，以便实时或批量检索。

Docker提供了这一点。

6)变更管理:对容器文件系统的变更可以提交到一个新的映像中，并重用用于创建更多的容器。不需要模板或手动配置。

“模板或手动配置”是对LXC的引用，在LXC中您需要了解这两件事。Docker允许你像对待虚拟机一样对待容器，而不需要学习LXC配置。

7)交互式shell: docker可以分配一个伪tty并附加到任何容器的标准输入，例如运行一个丢弃的交互式shell。

LXC已经提供了这一点。

我只是刚刚开始学习LXC和Docker，所以我欢迎任何更正或更好的答案。

Docker常见问题解答:

Docker不是lxc的替代品。“lxc”指的是Linux内核的功能(特别是名称空间和控件组)，这些功能允许相互沙箱进程，并控制它们的资源分配。

在内核特性的底层基础之上，Docker提供了一个具有以下几个强大功能的高级工具:

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 (https://registry.hub.docker.com/) 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.

Dockers use images which are build in layers. This adds a lot in terms of portability, sharing, versioning and other features. These images are very easy to port or transfer and since they are in layers, changes in subsequent versions are added in form of layers over previous layers. So, while porting many a times you don't need to port the base layers. Dockers have containers which run these images with execution environment contained, they add changes as new layers providing easy version control.

除此之外，Docker Hub是一个很好的注册表，有成千上万的公共映像，在那里你可以找到安装了操作系统和其他软件的映像。因此，您可以为您的应用程序获得一个很好的开端。

随着LXD的开发继续增强LXC，上述帖子和答案正在迅速过时。是的，我知道道克也没有止步不前。

LXD现在为LXC容器映像实现了一个存储库，用户可以从该存储库中推送或提取映像，从而对其进行贡献或重用。

LXD到LXC的REST api现在可以使用非常简单的命令语法在本地和远程创建/部署/管理LXC容器。

LXD的主要特点是:

设计安全(无特权容器，资源限制和 更) 可伸缩(从笔记本电脑上的容器到数千台计算机 节点) 直观(简单、清晰的API和简洁的命令行体验) 基于图像(没有更多的分发模板，只有良好的，可信的 热迁移

现在OpenStack有NCLXD插件，允许OpenStack利用LXD在OpenStack中部署/管理LXC容器作为虚拟机，而不是使用KVM, vmware等。

但是，NCLXD也支持混合传统HW vm和LXC vm的混合云。

OpenStack nclxd插件支持的特性列表包括:

stop/start/reboot/terminate container
Attach/detach network interface
Create container snapshot
Rescue/unrescue instance container
Pause/unpause/suspend/resume container
OVS/bridge networking
instance migration
firewall support

到2016年4月Ubuntu 16.04发布的时候，将会有额外的很酷的特性，比如块设备支持，实时迁移支持。

为了保持简洁，这个问题在上面已经被问过了。

然而，我想退一步，稍微不同地回答这个问题，docker引擎本身将编排作为其额外功能之一，这是破坏性的部分。一旦你开始运行一个应用程序作为容器的组合，运行在多个容器引擎的“某处”，它会变得非常令人兴奋。健壮性，水平缩放，从底层硬件中完全抽象，我可以列举很多……

这不仅仅是Docker给你的，事实上容器编排标准是Kubernetes，它有很多风格，一个Docker，还有OpenShift, SuSe, Azure, AWS…

然后在K8S下面还有替代的集装箱发动机;有趣的是Docker和CRIO——最近建立的，没有守护进程，是专门为Kubernetes设计的容器引擎，但还不成熟。我认为这两者之间的竞争将是容器引擎真正的长期选择。