微博混合云架构实践之不可变基础设施

“

与常见的灵活部署环境背道而驰，微博混合云架构上的不可变基础设施服务有哪些特别？

不可变，顾名思义就是一旦创建，便不再修改。这听起来和我们常见的诉求——灵活的部署环境，似乎背道而驰。对于DCP中的基础设施而言，这并不矛盾，因为创建后就没有必要去修改了。整个基础环境作为一种版本化管理的资源，和代码类似。运行时如果有一定要变更的部分，那么直接更新源码，重新创建资源即可。老版的环境依然存在，可以在需要时用于回滚。

• 能够快速获取所需的资源；

• 业务应用和基础资源之间相互独立。

微博私有云的传统基础设施

正如概述中所说，私有云的设备申请和环境部署流程过于繁杂，如下图所示：

1. 不同业务部门的环境需求差异非常大，甚至操作系统版本都不同，难以统一管理；

1. 随着运行时间增加，即使最初两台主机环境相同，到后来也无法保证一致性，最坏的情况可能造成业务应用部署失败；

1. 环境的回滚几乎不可能，只有重装操作系统。

微博混合云上的基础设施服务

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

正视差异化

环境一致性

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

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

基础资源版本化

架构演进

初试：Docker Machine

1. docker-machine create

1. 配置自定义的系统环境

2. 部署服务

• Docker启动参数无法完全自定义，当时只能配置少数几个参数，如--insecure-registry。

• 命令行对应的几个函数都是不可导出的，因此无法通过API调用，只能进行二进制依赖。

• 官方宣布不支持CentOS 6.x及之前的版本，而微博内部还有一小部分CentOS 6.5的服务器。

• Docker的安装使用的官方脚本，超时问题比较严重。

• 不够稳定，当时还处于开发阶段，版本迭代过于频繁。

改进：VM Image & Ansible

FROM weibo_plat_init:1.0

INCLUDE user.yml

INCLUDE config.yml

ROLE hongbao

• 使用镜像创建ECS后，ntpd的配置会恢复为阿里云默认值，如果使用自定义的需要再次修改。

• 如果在构建镜像时挂载了数据盘，生成镜像前需要删除/etc/fstab中自动挂载的配置，否则该镜像将由于找不到第二块硬盘的分区而无法启动。

• 开启SSH参数，pipelining和ControlPersist；

• 优化playbook，除去非必要模块，减少远程依赖；

• callback模块异步化，Ansible自身会等callback结束才执行后续命令，这点可以大大降低高并发时的耗时；

• 将需要网络传输的操作，如安装软件包、拉取Docker镜像等，内置到ECS镜像中。

基础设施发布

1. 在DCP申请阿里云资源；

1. 根据选择的VM镜像创建ECS；

1. 待ECS启动完成后下发Ansible命令进行初始化；

2. 交付上层业务使用。

Ansible Scheduler

部署公共组建

• DNS；

• Yum Repository；

• Docker Registry；

• Ansible Scheduler。

基础监控

总结