【烧脑式Kubernetes实战训练营】本次培训理论结合实践，主要包括：Kubernetes架构和资源调度原理、Kubernetes DNS与服务发现、基于Kubernetes和Jenkins的持续部署方案 、Kubernetes网络部署实践、监控、日志、Kubernetes与云原生应用、在CentOS中部署Kubernetes集群、Kubernetes中的容器设计模式、开发Kubernetes原生应用步骤介绍等。
Docker是在一个操作环境地址空间中的分区能力。通过允许分区直接使用宿主的操作系统，即使操作系统位于分区之外（分区在这里称为容器），启动时间得以缩短，管理容器所需要的资源同样得以缩减（如果你熟悉z/OS，你会发现这个概念有点熟悉） 。
财务人士会喜欢这点，因为获取操作环境licenses的花费会实质性的减少，理论上，每一个非应用部分的组件都能驻留在容器以外。这意味着只需要购买一个Windows licenses，而不是每一个虚拟机上都要购买一个（如果不使用Docker，这是必要的过程）。
概念看似简单，但是如何工作呢？
本质上，一个特殊的文件（称为一个Docker文件），包含一条或多条关于如何创立一个容器的指令。这个Docker文件作为程序的部分，在文件系统中产生容器，其包含一个单独的应用以及相关联的二进制代码。这个容器（文件系统中的一个子目录）作为任意的文件集会被传送到目标环境并在目标环境中利用Docker的运行时库开始运行，运行时库可以通过命令行接口或者一个API（典型的基于REST，但是还有其他的实现）。
系统管理员会很喜欢这点，因为容器易于部署（通过XCOPY命令就可以？）和维护（REST接口会很容易地集成到任何现代基础架构管理平台中）。
企业级发布自动化解决方案的需求
很不幸，当人们试图使用它作为真正的应用发布管理的替代品时，这个概念又不行了。我们能够使用每个人在高中学会的六个词中的五个词还描述应用发布管理：Who：并不是组织中的任何人都可以将某一个应用部署到某个环境中。实际上，即使对于那些专职从事这个工作的人，也需要其他人的许可才能进行部署工作。
What：对于那些想真正引入敏捷业务概念的组织， 每一次都部署一个完整的应用也是不可接受的。那些被认为是低风险的工件（artifacts）（如内容更新）可以及时部署，而高风险的工件则需要在进行大量的测试和其他验证工作后，排队等待进行发布。Docker就属于后者，但是还有一些限制，这会在后面提到。
Where：一个应用从开发到生产所经历的环境经常与部署的目标环境是不同的。这些差异会在应用进行部署以后，通过更改应用的配置来解决。
When：发布窗口不是一个新概念。甚至在非生产环境中，也需要各自建立发布窗口，因为环境经常被同一个功能或者夸功能的多个团队所共享（例如：测试和开发可能会使用相同的环境）。
How：作为很可能是最难以完全集成到一个组织运行能力中的环节，部署一个应用的过程远不是简单的理解如何安装或者配置它。例如，与一个IT服务管理（ITSM）应用集成，以确保所有的需求改变都已输入并且处于正确的状态，这些被吸纳进部署过程以便操作环境的状态一直被明确的理解。这个会在下面进行详细的讨论。
对于上面的5个疑问词，Docker 只解决了其中的一个，而且是并没有采用最有效的方式。以一个欧洲著名银行为例，他们现在每个月发布的产品已经过千，这也只有在所有发布的产品都不是高风险的才能实现，在这个例子里，这意味着这些工件都是低风险类型。因此，这些类型工件的发布会很迅速，这有助于确保这个银行的客户的资产满足他们的需要。
然而，如果他们在使用Docker，无论这些类型的工件是否获得生产许可，整个应用都需要重建。对于大部分公司来说，直接将未获许可的二进制文件发布到产品中而带来的风险是不可接受的。这只是对于上面5项之一——Docker对于解决其他4项无能为力。
应用发布管理不只是应用
只从应用的角度考虑应用发布管理是很有趣的，而从业务的角度来看，忘记应用是更大场景的一部分。在上面How部分里，提到了ITSM，这不只是发布过程必须要集成的唯一技术。事实上，还有SDLC工具链与一系列适合特定需要的解决方案可供选择：适用于连续集成的Hudson 和Jenkins；用于源代码管理的Git和Subversion；用于工件管理的Nexus和Artifactory；用于配置管理的 Chef 和 Puppet 等等。此外，在应用的生命周期中，发布应用的过程通常包括针对这过程的治理，但是这却不是该过程的一部分。然而，这些构建应用所要经历的阶段都是必要的，这可以将高节奏进行发布的风险降到最低，这包括许可、验证和其他类型的活动。
自动化是一切的关键
我们提到的每一件事对于应用发布来说都是关键的，但是，最后结果是什么。终端用户需要新的功能，应用开发团队能够以什么样的速度开发出新的功能并把它最终交付到终端用户手上，决定了新的功能能以多快的速度变成附加的收入。此外，过程的可重复性能够保证应用发布更高的成功率，相反的，失败的部署会消耗你的公司资金，在诊断和修复过程中开发的应用数量也会受影响而下降。过去3年，分析公司的两项研究表明，财富1000强公司因变更、配置或其他与之相关的问题而导致应用中断的成本在$200k-400k/小时。
上述部分中的每一个工具只与应用开发和发布过程的一小部分有关系。类似地，Docker解决了与应用程序发布相关的工件管理，这样就可以简化这些工件的部署，确实如此。这些与其他解决方案的协调能力，必须要通过一个统一的方案来进行管理，这就是应用发布自动化的目标。
总结
总的来说，Docker是一项令人兴奋的技术，它应该被单纯看作是在整个应用程序发布周期中存在的另一种机制。但是它不应该被看作是一个定义良好方法的替代品，它不仅包括“what”，还包括“who”、“where”、“when”以及“how”。投资于企业级自动化解决方案，实现关键任务应用的自动发布，不但可以提高部署应用的速度，而且能提高公司数字化转型的程度，随着更多的应用发布通过自动化完成，也会为公司带来更多的盈利。
原文链接：Is Docker the End of Traditional Application Release Management? 翻译：（夜风轻扬）
原文发布时间为：2017-09-07
本文作者：李颖杰
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：Docker是传统的应用发布管理的终结者么？