导读
本文讨论了配置管理从物理机过渡到私有云时遇到的问题和解决思路。
背景
私有docker容器环境(下文简称为弹性云)在发布、回滚、漂移时，容器会销毁重建，容器上配置数据会被销毁。
目前常用的物理机模式的配置下发，以 用户单次触发 为主。比如，发一个部署单子等。
如果配置下发期间容器正好被重建，该容器的这次配置发下的正常流程会失败；如果重试时间跨度小于 容器启动耗时，配置下发的重试策略也会失败。这样，当容器启动完成后，配置数据可能会遗漏掉最新的配置。
另一个常见的决策难题是，重建的容器应该使用哪一次触发对应的配置，无论选择”最新生效中”还是”最后一次成功”都会有问题：最新生效中的配置 有正确性问题（最新的配置不正确、被回滚了），最后一次成功有最新配置无法生效的问题。
问题分析
上述问题，主要有两个关键点:
- 缺乏配置最终一致性的保证手段（触发式的通病）
- 缺乏明确的配置定义，即 “容器应该使用哪一版本的配置”
上述两个问题，在物理机时代也存在。因为物理机销毁重建的机会少很多，所以问题一般不太严重。
解决思路
结合上述问题，以及长期积累下来的优秀实践经验，相比于物理机时代云上配置管理应该具备如下特征:
- 明确的配置定义
- 保证配置最终正确性
- 支持配置的分级发布
其中，分级发布和配置定义分别代表了推拉模式，如何保障配置最终正确性是产品设计时应该重点考虑的事项。一种可行的实现方案如下，
- 常态下的配置变更通过人工触发(推)来实现，常见的方式是人通过变更工单实现配置分级发布；
- 分级维度可以分为服务、集群、分组、实例；
- 实例定时从配置中心拉取配置，来保障配置的最终正确性；正确的定义，分为如下几个情况说明，
- 工单发布完成后，工单对应的配置版本即为正确配置，扩容、失败重建的实例都应该使用使用这个配置；
- 工单被回滚后，不论被回滚的工单是否已经执行完成，使用回滚到的工单作为正确配置；
- 工单发布过程中，新扩容的实例，使用上一个已发布完成的工单作为正确配置；
- 工单发布过程中，失败重建的实例，如果尚未被当前工单执行到，则使用上一个已发布完成的工单作为正确配置；
- 工单发布过程中，失败重建的实例，如果已经被当前工单执行到（不论执行结果成功与否），则使用当前工单作为正确配置；
在该方案中，使用变更工单来明确的定义配置，通过实例定期同步来保障最终正确性，分级发布通过变更工单来实现。
PS：云上配管的问题，本质还是微服务架构不够完善的问题，只是在云时代被快速放大了。