博客链接： http://blog.linjunhalida.com/blog/server-architecture-configuration-management/

现在有一些服务器自动化配置工具，比如 ansible，chef，puppet 等， 利用它们，可以实现我的一个想法：用配置文件定义服务器架构。

比如用 ansible，我们可以用一个 YAML 文件申明一台服务器上面有什么：安装了什么应用，存在什么配置文件，跑了什么服务。 然后用命令行工具，比如 ansible-playbook，就可以构建出来这样的服务器。

这样操作的优点：

• 可视化：原先服务器手工构建，其他人，甚至构建者自己都会不清楚服务器的状况。现在有了配置文件，大家就可以知道服务器上面有什么，是如何配置的。
• 自动化：可以一条命令构建服务器，修改配置文件之后可以批量改动影响到的服务器，增加带有同样应用的服务器也非常简单，只要拷贝配置即可。如何搭建应用的知识可以复用。
• 版本控制架构变更：可以用 git 版本库管理服务器配置文件，我们可以记录每次服务器架构的变更了。

具体操作：针对一组服务器架构，比如一个 Rails 应用以及附属的各个服务器， 可以创建一个 git 版本库记录所有的 ansible playbook， 然后把敏感的配置文件，放到另外一个私密 git 版本库里面， 加密存储，保障安全性。

我搭建了一个演示用例，包括：

• 一个 Rails 应用
• ansible 配置
• 私密配置（仅限于演示）

里面包含几台服务器：

• app.yml 搭建 Rails 服务器，包括 mysql 数据库，nginx，systemd 自动启动和监控脚本。
• backup.yml 自动备份 mysql 数据库
• zabbix.yml 对应的监控服务器（未完工）

私密配置版本库里面存放了所有的配置文件，构建一些应用需要的用户名和密码，一些初始化数据等。 在 playbook 里面会去读取这些配置文件，或者拷贝这些文件到服务器上面去。

管理 Rails 应用还需要一些其他的功能，限于时间，我就没有实现了，包括：

• jenkins 自动化测试
• sandbox，staging 环境
• mysql 多主从架构
• 多 app 负载均衡

综上所述，一个复杂的多服务器应用架构，可以用上面的几个版本库定义出来，并且可以根据需要动态进行修改。 这种配置方式适用于几十台机器之内的半静态架构，并且可以多人同时管理。

更进一步，如果利用 aws 或者 digitalocean 的 api，服务器创建也可以采用配置文件定义。 不过我觉得使用起来并不是很方便，就没有这样做了。

如果机器数量多，或者需要动态伸缩，配置文件可能就不太适合了，可以用 ansible-tower 这种在线配置管理工具。 不过我觉得大多数的公司都不会达到这样的级别，因此配置文件就够用了。