Docker 实现的是镜像内部的小环境一致性，它保证了一个应用程序在一台机器上使用 Jetty 9，在另一台机器上也使用Jetty 9（通过封装软件中间件如 Jetty 9）。然而大中型企业用户很快意识到，真正的难点在于如何保证“大环境”一致，即整个业务系统中众多容器、组件、服务之间如何配置、互联、依赖，如何保证开发、测试、生产环境能相互转化、克隆等。这些环境、配置在容器概念之上，是容器自身无法解决的，只能依赖集群层面的管理工具。
发布管理远大于 CI/CD
如今谈到发布，大家想到的就是持续集成（CI）和持续发布（CD）。然而我们在谷歌内部实践的发布管理系统还包括很多其他的方方面面，例如：
- 如何将镜像的构建与代码库的分支构建相整合
- 如何做微服务架构中的联合发布（最重要的是保证新老版本的API能够平滑兼容）
- 如何做版本管理（哪个镜像版本运行在哪个数据中心上）
- 如何做灰度发布（根据不同的时间节点、步调来有策略的调整新版本的上线比率，自动比对新旧版本的用户行为等）
DevOps 包含方方面面，其中诸多实践都是 Docker 自身层面所不能企及的，以谷歌为例：
- 配置管理：要做到真正的大环境一致，必须将配置完全与代码分离，这里的配置远不仅仅是服务之间的 IP 地址（通过 DNS 服务发现可以解决），还包括不同环境下对于不同服务、应用的配置参数等。对于这些状态、配置、数据、文件的维护则需要额外的配置管理系统。
- 分布式测试：测试是 Devops 中不可或缺的一环，但是在大规模应用系统中，如何有效地、智能地快速自动运行系统测试则需要额外的系统；在谷歌内部我们构建了分布式测试系统，能够基于 Borg，有选择地识别出收到某个 commit 影响的测试集进行高效自动化测试。
- 智能预警：Docker 或容器只是应用运行的载体，而 Docker 自身失效后需要第三方系统来检测并预警。谷歌打造了复杂、灵活的预警系统，可以支持自定义的预警规则和报警行为。
- 智能故障定位：微服务架构的分布式天性将系统问题调试变得更加复杂，一个用户的请求在系统内部要遍历多个服务模块，而在出现问题时如何帮助系统管理员自动定位故障也需要额外的工具和系统来完成。
若有收获，就点个赞吧
0 人点赞
