持续交付

说在前面 在《持续交付》的第二章配置管理的小结里说到： 配置管理是本书其他内容的基础。没有配置管理，根本谈不上持续集成、发布管理以及部署流水线。它对交付团队内部的协作也会起到巨大的促进作用。 再怎么强调配置管理的重要性也不为过，特别是在多环境下。然而大家都知道重要，又少有人告诉我们具体如何做，所以实在难受。 本文总结了我在多环境配置管理实践方面的一点心得，希望对大家有帮助。 Ansible 介绍 你可以简单地把它理解为一个自动化运维工具。本文将会使用这个工具下 inventory 概念来实现多环境配置。简单一点来说，inventory是一个文本文件，你可以在这个文件里记录下所有的机器，并对这些机器进行分组（分类）。 当然，其它的自动化运维工具也可以使用同样的思路来实践。本文只以 Ansible 为例。 例子 比如我们有两个环境，分别有一台机器。使用Ansible的 inventory 来管理这些机器，就会像下面这样： ## inventory [aws-prod-app] 10.171.32.158 [aws-test-app] 10.161.158.221 所有的 app 应用都是同一份代码，而且都会涉及操作数据库。当然，不同环境下的 app 读取的数据库的配置项的值是不样的。比如 aws-test 环境下配置是 db: url: test.mysql.url username: testu1 password: passwordtest 而生产环境 aws-prod 环境下配置： db: url: prod.mysql.url username: produ1 password: passwordprod 这时，因为机器少，我们可以使用 Ansible 的 inventory 变量实现不同环境的配置隔离，比如： ## inventory [aws-prod-app] 10.171.32.158 ## [分组名:vars] 这样的写法是 Ansible inventory的约定 ## 按照这个约定来写，Ansible就可以识别了 [aws-prod-app:vars] db.url = test.mysql.url db.username = testu1 db.password = passwordtest [aws-test-app] 10.161.158.221 [aws-test-app:vars] db.url = prod.mysql.url db.username = produ1 db.password = passwordprod 接着，如果环境上要部署新应用呢？而且还是很多呢？我们的 inventory 就会变成这样： ...