介绍
通常有许多障碍阻碍了您的应用程序在开发周期中的轻松移动，并最终进入生产环境。 除了开发应用程序以在每个环境中进行适当响应的实际工作外，您还可能面临跟踪依赖关系，扩展应用程序以及更新单个组件而不影响整个应用程序的问题。
Docker容器化和面向服务的设计试图解决很多这些问题。 应用程序可以分解为可管理的功能组件，单独打包其所有依赖项，并轻松部署在不规则架构上。 缩放和更新组件也被简化。
在本指南中，我们将讨论容器化的好处，以及Docker如何帮助解决我们上面提到的许多问题。 Docker是分布式容器部署的核心组件，提供轻松的可扩展性和管理。
Linux容器化的简史
容器化和隔离不是计算世界中的新概念。 一些类Unix操作系统已经利用了成熟的容器化技术十多年了。
在Linux中，LXC是构建后续容器化技术基础的构建块，它在2008年添加到内核。LXC结合使用内核cgroups（允许隔离和跟踪资源利用率）和命名空间（允许分组，不能“看到”彼此）实现轻量级进程隔离。
后来，Docker被引入作为一种简化创建和管理容器所需的工具的方法。 最初它用LXC作为其默认的执行驱动程序（它已经开发了一种名为库libcontainer用于此目的）。 Docker虽然没有引入许多新的想法，但通过简化流程并在接口上实现标准化，使他们可以被普通的开发人员和系统管理员访问。 它激发了对开发人员在Linux世界中的容器化的重新兴趣。
虽然我们将在本文中讨论的一些主题是更一般的，我们将主要集中在Docker容器化，由于其压倒性的人气和标准采用。
什么容器化带来的图片
容器对开发人员和系统管理员/操作团队都有很多非常有吸引力的好处。
下面列出了一些最大的好处。
远离容器化应用程序的主机系统的抽象
容器意在完全标准化。 这意味着容器使用定义的接口连接到主机和容器外部的任何东西。 容器化应用程序不应依赖或关注底层主机资源或体系结构的详细信息。 这简化了关于操作环境的开发假设。 同样，对于主机，每个容器是一个黑盒子。 它不关心应用程序内部的细节。
易于扩展
在主机系统和容器之间的抽象的一个好处是，给定正确的应用设计，缩放可以是简单和直接的。 面向服务的设计（稍后讨论）与容器化应用程序相结合，提供了易于扩展的基础。
开发人员可以在他们的工作站上运行几个容器，而该系统可以在分段或测试区域中水平缩放。 当容器投入生产时，它们可以再次向外扩展。
简单依赖关系管理和应用程序版本化
容器允许开发人员将应用程序或应用程序组件及其所有依赖项捆绑为一个单元。 主机系统不必关心运行特定应用程序所需的依赖关系。 只要它可以运行Docker，它应该能够运行所有Docker容器。
这使得依赖关系管理变得容易，并且还简化了应用程序版本管理。 主机系统和操作团队不再负责管理应用程序的依赖性需求，因为除了依赖相关容器之外，它们都应该包含在容器本身内。
非常轻巧，隔离的执行环境
虽然容器不提供与虚拟化技术相同的隔离和资源管理级别，但是它们从交易中获得的是一个非常轻量级的执行环境。 容器在进程级别被隔离，共享主机的内核。 这意味着容器本身不包括完整的操作系统，导致几乎即时的启动时间。 开发人员可以轻松地从他们的工作站运行数百个容器，而不会有问题。
共享分层
容器是轻量级的，在不同的意义上，它们是在“层”提交。 如果多个容器基于同一层，则它们可以共享底层而不重复，从而导致对于稍后的映像的非常小的磁盘空间利用。
可合成性和可预测性
Docker文件允许用户定义创建新容器图像所需的确切操作。 这允许您像执行环境一样编写执行环境，如果需要，可将其存储在版本控制中。 在同一环境中构建的同一个Docker文件将总是产生相同的容器映像。
使用Dockerfiles进行可重复，一致的构建
尽管可以使用交互式过程创建容器映像，但是一旦知道必要的步骤，通常最好将配置步骤放在Dockerfile中。 Dockerfiles是简单的构建文件，它描述了如何从已知的起点创建容器图像。
Dockerfiles是非常有用的，相当容易掌握。 他们提供的一些好处是：
- 简易版本 ：该Dockerfiles本身可以被提交到版本控制跟踪变更并恢复任何错误
- Predicatability：从Dockerfile建立图像有助于从图像创建过程去除人为错误。
- 责任 ：如果您打算共享图像，它往往是提供创建图像，以此为其他用户进行审核的过程中Dockerfile一个好主意。 它基本上提供了创建图像所采取的步骤的命令历史。
- 灵活性 ：从Dockerfile创建图像，您可以覆盖互动构建给出的默认值。 这意味着您不必提供尽可能多的运行时选项来使映像按预期方式运行。
Dockerfiles是一个伟大的工具，用于自动化容器图像构建以建立一个可重复的过程。
容器化应用程序的架构
当设计要在容器中部署的应用程序时，关注的第一个领域之一是应用程序的实际架构。 通常，当实现面向服务的设计时，容器化的应用程序工作得最好。
面向服务的应用程序将系统的功能打破成通过界限良好的接口相互通信的分立组件。 容器技术本身鼓励这种类型的设计，因为它允许每个组件独立扩展或升级。
实现这种类型设计的应用程序应具有以下特性：
- 他们不应该关心或依赖于主机系统的任何细节
- 每个组件应提供一致的API，消费者可以使用这些API来访问服务
- 每个服务在初始配置期间应该从环境变量中提取
- 应用程序数据应存储在已安装卷或容器中的容器外部
这些策略允许每个组件独立地换出或升级，只要API被维护。 由于每个组件可以根据所经历的瓶颈而缩放的事实，它们也适合于集中的水平可伸缩性。
而不是硬编码特定值，每个组件通常可以定义合理的默认值。 组件可以使用这些作为回退值，但应该喜欢它可以从其环境收集的值。 这通常通过服务发现工具的辅助完成，组件可以在其启动过程期间查询。
将配置从实际容器中取出并将其放置到环境中允许对应用程序行为的容易改变，而不重建容器图像。 它还允许单个设置影响组件的多个实例。 一般来说，面向服务的设计与环境配置策略很好地配合，因为它们允许更灵活的部署和更直接的扩展。
使用Docker注册表进行容器管理
一旦将应用程序拆分为功能组件并配置为适当地响应环境中的其他容器和配置标志，下一步通常是通过注册表使您的容器映像可用。 将容器映像上传到注册表允许Docker主机通过简单地知道映像名称来下拉图像和旋转容器实例。
有各种Docker注册表可用于此目的。 一些是公共注册表，任何人都可以查看和使用已提交的图像，而其他注册表是私有的。 可以对图片进行标记，以便它们可以方便地进行下载或更新。
结论
Docker提供了分布式容器部署所需的基本构件。 通过将应用程序组件打包在自己的容器中，水平扩展变成了旋转或关闭每个组件的多个实例的简单过程。 Docker提供了必要的工具，不仅构建容器，而且还管理和与新用户或主机共享它们。
虽然容器化的应用程序提供必要的过程隔离和封装以帮助部署，但是存在在分布式主机集群上充分地管理和缩放容器所需的许多其他组件。 在我们接下来的指南中，我们将讨论服务发现和分布在全球各地门店的配置如何促进集群容器部署。
