混合云上的基础设施服务

微博混合云的资源分为两个部分：内网主机和阿里云ECS，我们的目标是对上层业务提供统一、不可变的基础环境。但是如果彻底不可变，反而带来了不小的麻烦。还有人提出拒绝SSH，目的也是如此。试想仅仅需要临时改变一个系统参数，就必须完整构建一次环境，并且重新部署，这是令人难以接受的。

因此我们决定将不可变的范围缩小，那些耗时相对较长，修改频率又很低的模块纳入不可变范围，这些模块的变更需要重新制作整个环境；而另一些模块放到实时的配置管理系统中，以便在需要的时候进行更新。这样既能保证构建速度，又不带来过高的变更成本的方案，同时解决上面的问题。

正视差异化

不同业务对环境的不同需求是客观存在的，理论上也不可能完全抹平差异，因此我们的服务必须支持各类用户定制自己的环境，自下而上包括三部分：主机环境、配置管理脚本和基础容器（见图2）。

图2

最下层是我们认为不可变的部分，而中间的配置是可能变更的模块，最上面是一些标准的容器，包括面向业务的JAVA和PHP，也包括面向运维的OPS。这样明确各层的职责，便于分别进行管理。

环境一致性

一致性包括两个方面：

●资源在使用过程中，环境保持不变：内网主机随着时间推移，会不可避免地被修改，因此我们制作了一个运维使用的基础Docker镜像，即上面的OPS镜像，包括一些工具软件和业务脚本，并将docker.sock挂载进去。这样就可以在容器内部操作Docker Daemon，而其他修改也仅仅只在容器内部，不会污染主机环境。公有云的使用场景原则上不会发生环境漂移的现象，毕竟每次新建的资源使用时间不会超过12小时，同时使用上述运维镜像，更加没有必要操作宿主机。

●重新创建的和已经在运行的资源环境一致：即使配置未变更，也可能出现不一致的问题，尤其在使用外部软件仓库的情况下，比如脚本中yum update或者yum install docker类似的命令。因此我们使用了内部搭建的软件仓库，可自己对软件的更新频率和范围进行控制，同时也要求脚本中所有安装软件的命令带上版本号，如yum install docker-1.6.2。

基础资源版本化

基础设施即服务，服务即代码，自然可以进行版本化管理。

可以看到图3中以CentOS 7发行版加基础配置为起点，类似Git中分支的概念，衍生出两个不同的基础环境A和B，而从A又产生了新的分支C。每种环境都有自己的版本，在必要的时候可以回滚。需要注意的一点是，各环境的第一个版本在制作时我们需要进行更全面的测试，因为它是后面环境变更的基础，万一出问题，并没有更老的版本可供回滚。