Docker GitHub 网站中 Readme.md 以技术者的角度翻译

Docker 是一个开源的轻量级容器项目，用于让你的应用在它上面打包、集装和运行。
Docker 运行的环境既包含未知硬件也包含未知操做系统。这句话的意思是它能够运行在任何地方，小到你的笔记本大到一个大型的云计算实体，除此以外也不须要你掌握或用到任何特定的开发语言、框架或者打包系统。这使得他们可以在不依赖任何特定堆栈或者提供者的状况下部署可扩展的web应用程序、数据库或者后台服务。
Docker 的前身是dotCloud旗下的一款开源的部署引擎的实现，一款很受欢迎接口服务平台。它成功直接收益于积累了多年的大规模操做和支持数十万应用程序和数据库
安全披露
安全对咱们来讲是很是重要的。若是你遇到任何问题涉及到安全，请负责任的披露这些信息到邮箱：security@docker.com,请不要在GitHub建立问题。
比虚拟机更强
一个共同的方法是用虚拟机去构建应用程序和沙箱环境去运行验证。典型的虚拟机格式是VMware的VMDK，Oracle VirtualBox的VDI，和亚马逊的EC2 AMI。从理论上讲，这些格式须要容许每个开发者将他们的应用程序自动打包成一个“machine”,以便分发和部署；实际状况是，有一些因数让这几乎不会实现：
一、大小：VMs很是大，这使得它没法方便存储和传输。
二、性能：运行VMs会消耗大量的CPU和内存，这使得它在一些状况下变得不切实际，例如本地部署大量机器来开发多层应用程序或大规模部署CPU和内存密集型应用程序。
三、可移植性：处于竞争关系的VM环境不会很好的兼容彼此。即便转换工具存在，他们也会收到一些限制，而且会增长额外开销。
四、硬件中心：VMs设计之初更多的考虑操做系统层面，并非软件开发层面。所以，他们提供了极少的、用于建立、测试、运行开发软件的工具给开发人员。举个例子，VMs 没有提供设施和工具用于应用程序版本控制，监控、配置、日志和服务发现。
经过对比，Docker经过依赖不一样的沙箱方法来实现集装箱。不像传统的虚拟化，集装箱在内核级运行，大多数现代操做系统内核如今支持必要的集装箱的原语，这些操做系统包括Linux 的 openvz,vserver 和最近的 lxc，Solaris 的 zones，和 FreeBSD的jails.
Docker基于这些低级原语为开发人员提供了一个便携式的格式和运行环境，解决了四个问题。并且Docker容器很小（他们的传输能够在层级间优化），它在内存和CPU上的开销几乎为0，它是彻底便携式，而且基于应用程序为中心的设计。
或许它是最好的，由于Docker运行在操做系统层，它也能够运行在VM中！
和其余玩的很好
Docker不要求你购买到一个特定的编程语言，框架，包装系统，或配置语言。
是一个UNIX进程申请的？它使用文件、TCP链接、环境变量、标准UNIX流和命令行参数做为输入和输出？而后Docker能够运行它。
您的应用程序的构建能够被表示为这样的命令序列吗？而后Docker能够建造它。
从依赖的地狱中逃脱
一个常见的问题是开发人员很难在一个简单而自动化的方式下管理他们的应用程序的依赖关系。
一般状况下这些困难是由一下几方面缘由致使的：
一、跨平台依赖。现代应用程序一般依赖于一个组合的系统库和二进制文件，特定的语言包，框架的具体模块，内部组件开发也开发过另外一个项目等。这些依赖关系，存活在不一样的“世界”，须要不一样的工具，这些工具一般相互配合不是很好，须要尴尬的定制集成。
二、相互依赖。不一样的应用程序可能依赖于同一依赖的不一样版本。包装工具处理这些状况有不一样程度的缓解-但他们都处理他们在不一样的和不兼容的方式，这又迫使开发人员作额外的工做。
三、自定义依赖项。开发人员可能须要准备一个自定义版本的应用程序的依赖。一些包装系统能够处理自定义版本的依赖，其余都不能作，而且他全部处理的自定义版本依赖也很困难。
Docker给开发者一个简单的方法来在一个地方表达本身全部的应用程序的依赖关系解决相依性地狱的问题，同时简化组装过程。若是这让你以为XKCD 927，别担忧。Docker不会取代你最喜欢的包装系统。它只是协调他们的使用在一个简单的和可重复的方式。它是怎么作到的？在层级间吗。
Docker定义创建运行一系列的UNIX命令，一前一后，在同一个容器。生成命令修改容器的内容（一般是在文件系统上安装新文件），下一个命令会对它进行一些修改，等等。由于每一个生成命令继承了之前命令的结果，命令执行的顺序表示依赖关系。

下面是一个典型的Docker创建过程：
FROM ubuntu:12.04
RUN apt-get update && apt-get install -y python python-pip curl
RUN curl -sSL https://github.com/shykes/helloflask/archive/master.tar.gz | tar -xzv
RUN cd helloflask-master && pip install -r requirements.txt

注意，Docker不关心依赖是怎么创建的-只要他们建造能够运行在容器中的UNIX命令。

原文

Docker is an open source project to pack, ship and run any application as a lightweight container.

Docker containers are both hardware-agnostic and platform-agnostic. This means they can run anywhere, from your laptop to the largest cloud compute instance and everything in between - and they don't require you to use a particular language, framework or packaging system. That makes them great building blocks for deploying and scaling web apps, databases, and backend services without depending on a particular stack or provider.

Docker began as an open-source implementation of the deployment engine which powered dotCloud, a popular Platform-as-a-Service. It benefits directly from the experience accumulated over several years of large-scale operation and support of hundreds of thousands of applications and databases.

 

Security Disclosure

Security is very important to us. If you have any issue regarding security, please disclose the information responsibly by sending an email to security@docker.com and not by creating a GitHub issue.

Better than VMs

A common method for distributing applications and sandboxing their execution is to use virtual machines, or VMs. Typical VM formats are VMware's vmdk, Oracle VirtualBox's vdi, and Amazon EC2's ami. In theory these formats should allow every developer to automatically package their application into a "machine" for easy distribution and deployment. In practice, that almost never happens, for a few reasons:

• Size: VMs are very large which makes them impractical to store and transfer.
• Performance: running VMs consumes significant CPU and memory, which makes them impractical in many scenarios, for example local development of multi-tier applications, and large-scale deployment of cpu and memory-intensive applications on large numbers of machines.
• Portability: competing VM environments don't play well with each other. Although conversion tools do exist, they are limited and add even more overhead.
• Hardware-centric: VMs were designed with machine operators in mind, not software developers. As a result, they offer very limited tooling for what developers need most: building, testing and running their software. For example, VMs offer no facilities for application versioning, monitoring, configuration, logging or service discovery.

By contrast, Docker relies on a different sandboxing method known as containerization. Unlike traditional virtualization, containerization takes place at the kernel level. Most modern operating system kernels now support the primitives necessary for containerization, including Linux with openvz, vserver and more recently lxc, Solaris with zones, and FreeBSD with Jails.

Docker builds on top of these low-level primitives to offer developers a portable format and runtime environment that solves all four problems. Docker containers are small (and their transfer can be optimized with layers), they have basically zero memory and cpu overhead, they are completely portable, and are designed from the ground up with an application-centric design.

Perhaps best of all, because Docker operates at the OS level, it can still be run inside a VM!

Plays well with others

Docker does not require you to buy into a particular programming language, framework, packaging system, or configuration language.

Is your application a Unix process? Does it use files, tcp connections, environment variables, standard Unix streams and command-line arguments as inputs and outputs? Then Docker can run it.

Can your application's build be expressed as a sequence of such commands? Then Docker can build it.

Escape dependency hell

A common problem for developers is the difficulty of managing all their application's dependencies in a simple and automated way.

This is usually difficult for several reasons:

• Cross-platform dependencies. Modern applications often depend on a combination of system libraries and binaries, language-specific packages, framework-specific modules, internal components developed for another project, etc. These dependencies live in different "worlds" and require different tools - these tools typically don't work well with each other, requiring awkward custom integrations.

• Conflicting dependencies. Different applications may depend on different versions of the same dependency. Packaging tools handle these situations with various degrees of ease - but they all handle them in different and incompatible ways, which again forces the developer to do extra work.

• Custom dependencies. A developer may need to prepare a custom version of their application's dependency. Some packaging systems can handle custom versions of a dependency, others can't - and all of them handle it differently.

Docker solves the problem of dependency hell by giving the developer a simple way to express all their application's dependencies in one place, while streamlining the process of assembling them. If this makes you think of XKCD 927, don't worry. Docker doesn't replace your favorite packaging systems. It simply orchestrates their use in a simple and repeatable way. How does it do that? With layers.

Docker defines a build as running a sequence of Unix commands, one after the other, in the same container. Build commands modify the contents of the container (usually by installing new files on the filesystem), the next command modifies it some more, etc. Since each build command inherits the result of the previous commands, the order in which the commands are executed expresses dependencies.

Here's a typical Docker build process:

FROM ubuntu:12.04
RUN apt-get update && apt-get install -y python python-pip curl
RUN curl -sSL https://github.com/shykes/helloflask/archive/master.tar.gz | tar -xzv RUN cd helloflask-master && pip install -r requirements.txt

Note that Docker doesn't care how dependencies are built - as long as they can be built by running a Unix command in a container.