优维科技EASYOPS | Docker是传统应用发布管理的终结

自2013年发布以来，Docker已经成为很多人（尤其系统管理员和IT财务管控人员）眼中的宠儿。那么，Docker是传统应用程序发布管理的终结者吗？

开门见山，Docker可以认为是操作环境地址空间内的分区功能。通过允许分区直接使用主机OS，即使该OS驻留在分区（称为容器）之外，启动时间也大大降低，容器管理的资源要求（似曾相识）。

A

系统管理员和IT财务管控人员就很喜欢这点了……先说财务方面，一个着眼长远的企业肯定会有优先考虑正版软件，但授权费需要开销很多。举个例子，用付费系统的企业，出现Docker之后，获取操作环境许可证的成本可以大大减少，因为理论上，不是应用程序本身的一部分的每个组件都可以驻留在容器之外。这意味着只需要采购一个许可证，而不是每个VM使用一个许可证。

说得容易，如何执行？

理论上一个特殊文件（称为DockerFile）包含有关如何创建容器的一个或多个说明。DockerFile用作在文件系统上生成容器的进程的一部分，该容器可以包含一个单个应用程序及其关联的二进制文件。然后将该容器（文件系统中的一个子目录）传送到目标环境，因为任何一组文件将使用Docker运行时启动，可以通过命令行界面或API（通常基于REST，有其他实现方式）。

B

这就来到了技术层面，之前说到系统管理员也喜欢这个就是这个原因。因为容器易于部署和维护，REST接口可以轻松集成到任何现代的基础架构管理平台中。

企业级发布自动化解决方案的要求

不好的消息的是，当尝试使用它作为真正的应用发布管理的替代品时，这个Docker概念就不抗打了。可以用几个词描述应用发布管理：

who：不要是个组织中的人都能把应用部署到环境里。按理说，即使是那些权限允许的人，部署之前也应该有批准决定，而且有记录/监督可以复盘。

what：对于真正接受业务灵活性概念的组织来说，大概很不能接受的就是每次都部署完整的应用吧。而被认为是低风险（如内容更新）的组件或文件可以立即部署，而高风险动作则需要等待大量测试验证才被释放。Docker和这个有些天然关系，但有一点局限性，下面讲。

where：部署的目标环境常常与应用在从开发到生产的过程中所触及的每个环境不同，这些差异通常在部署应用的配置包中做更改修正来统一解决。

when：发布窗口不是个新东西/概念。即使在非生产环境中也可以建立一个发布窗口，因为环境通常在同一功能内的多个团队之间甚至跨功能有共享（即测试和开发可能用相同的环境）情况。

how：这可能是集成到组织体现运营能力时候（装X）最可能发生问题的步骤，因为部署应用的过程不仅仅是简单地了解如何安装和配置。举个栗子，跟ITSM应用程序集成以确保更改请求已输入并处于正确状态，这里就必须纳入部署过程中，以便始终充分了解操作环境的状态。下面讲。

在上面的关键词中，Docker只解决了其中一个问题，而且还不是最有效的方式。一个位于欧洲的知名银行，目前每月有超过一千个生产版本，肯定这些升版本都不可能是高风险版本。在“what”下的例子中，某些类型的动作影响最小，因此可以加快这些工件类型的部署发布，这有助于确保该银行面向客户的资产始终满足其客户的需求。

然后，敲黑板的地方来了。如果他们在用Docker，无论实际批准释放部署的文件风险评估如何，都要重建整个应用。而且大多数公司完全不接纳未经批准的二进制文件被发布到生产中所产生的风险。这就是其中一个 - Docker对其他四个没有任何意义。

应用发布管理不止于应用

在应用方面只考虑应用发布管理是很有吸引力，有一定的成就感。但是从业务角度来看，只记得应用发布管理却忽略了更多的潜在内容。在上面的“how”部分提到了ITSM，这其实不是发布过程必须集成的唯一技术。事实上，SDLC工具链中散布着大量满足特定需求的解决方案：Hudson和Jenkins持续集成; Git和Subversion源代码管理;人工神经管理工具;Chef and Puppet配置管理等等。

此外，在整个生命周期中释放应用的过程通常包括特定于进程的治理，但本身不属于进程的一部分。然而，交付建设时就必须考虑这些阶段以缩小风险，同时又要拿捏好交付节奏发布，这些阶段包括批准，验证和其他类型的活动，以及你认为还有必要加上的一些风控。

自动化是一切的关键

最终用户需要新能力/修复，而发布对于应用游走商场来说非常重要。开发团队生成新包并提供给最终用户的速度决定了新体验快速转化为收入的快慢。

此外，交付过程的重复性一定程度上能提供更高的应用部署成功率。相反，在分类和修复过程中，应用生产实例处于关闭状态时，部署失败会让公司损失成本。有分析师在过去3年的两项研究确定，财富1000强企业因变更、配置或其他切换相关问题导致应用中断，成本在$200k - 400k/小时之间。

工具在应用构建和发布过程的一小部分内具有相关性。类似地，Docker解决了与应用发布相关联的工件管理，使得它可以简化这些工件的部署，不过也仅于此了。这些和其他解决方案能力的协调必须由业务流程解决方案进行管理，特别是针对应用发布自动化的目标协作。

总结

总而言之，Docker是个好东西，可视为存在于整个应用发布周期中的简单机制。但不应将其视为替代明确定义的方法，不仅包括“what”，还包括“who”，“where”，“when”和“how”。

而企业投资自动化（包括资产管理、持续交付、监控、负载分析而设计的企业级自动化解决方案）不仅可以提高部署效率，还能增加公司数字转型速度，支撑创新以及加速创新。