在環(huán)境中存儲配置
通常乔遮，應用的配置在不同部署(預發(fā)布扮超、生產(chǎn)環(huán)境、開發(fā)環(huán)境等等)間會有很大差異蹋肮。這其中包括：
- 數(shù)據(jù)庫出刷，Memcached，以及其他后端服務(wù)的配置
- 第三方服務(wù)的證書括尸，如 Amazon S3巷蚪、Twitter 等
- 每份部署特有的配置，如域名等
有些應用在代碼中使用常量保存配置濒翻，這與 12-Factor 所要求的代碼和配置嚴格分離顯然大相徑庭屁柏。配置文件在各部署間存在大幅差異，代碼卻完全一致有送。
判斷一個應用是否正確地將配置排除在代碼之外淌喻，一個簡單的方法是看該應用的基準代碼是否可以立刻開源，而不用擔心會暴露任何敏感的信息雀摘。
需要指出的是裸删，這里定義的“配置”并不包括應用的內(nèi)部配置，比如 Rails 的 config/routes.rb阵赠，或是使用 Spring 時代碼模塊間的依賴注入關(guān)系涯塔。這類配置在不同部署間不存在差異，所以應該寫入代碼清蚀。
另外一個解決方法是使用配置文件匕荸，但不把它們納入版本控制系統(tǒng)，就像 Rails 的 config/database.yml 枷邪。這相對于在代碼中使用常量已經(jīng)是長足進步榛搔，但仍然有缺點：總是會不小心將配置文件簽入了代碼庫；配置文件的可能會分散在不同的目錄，并有著不同的格式践惑，這讓找出一個地方來統(tǒng)一管理所有配置變的不太現(xiàn)實腹泌。更糟的是，這些格式通常是語言或框架特定的尔觉。
12-Factor推薦將應用的配置存儲于環(huán)境變量中（ env vars, env ）凉袱。
環(huán)境變量可以非常方便地在不同的部署間做修改，卻不動一行代碼穷娱；與配置文件不同绑蔫，不小心把它們簽入代碼庫的概率微乎其微；與一些傳統(tǒng)的解決配置問題的機制（比如 Java 的屬性配置文件）相比泵额，環(huán)境變量與語言和系統(tǒng)無關(guān)。
目前特別流行的docker是可以很容易地滿足這個需求
配置管理的另一個方面是分組携添。有時應用會將配置按照特定部署進行分組（或叫做“環(huán)境”）嫁盲，例如Rails中的 development,test, 和 production 環(huán)境。這種方法無法輕易擴展：更多部署意味著更多新的環(huán)境烈掠，例如 staging 或 qa 羞秤。 隨著項目的不斷深入，開發(fā)人員可能還會添加他們自己的環(huán)境左敌，比如 joes-staging 瘾蛋，這將導致各種配置組合的激增，從而給管理部署增加了很多不確定因素矫限。
12-Factor 應用中哺哼，環(huán)境變量的粒度要足夠小，且相對獨立叼风。它們永遠也不會組合成一個所謂的“環(huán)境”取董，而是獨立存在于每個部署之中。當應用程序不斷擴展无宿，需要更多種類的部署時茵汰，這種配置管理方式能夠做到平滑過渡。
總結(jié)
使用代碼常亮的壞處：
- 修改配置必須修改代碼
- 部署時需要不同配置孽鸡，無法進行代碼的管理
使用配置文件的壞處：
- 容易提交到代碼庫里
根據(jù)環(huán)境對配置進行分組的壞處：
- 不正交
計算機中的正交
在計算技術(shù)中蹂午，該術(shù)語用于表示某種不相依賴性或者解耦性。如果兩個或者更多事物中的一個發(fā)生變化彬碱，不會影響其他事物豆胸。這些事物就是正交的。在設(shè)計良好的系統(tǒng)中堡妒，數(shù)據(jù)庫代碼與用戶界面是正交的：你可以改變界面配乱，而不影響數(shù)據(jù)庫，或者更換數(shù)據(jù)庫，而不用改變界面搬泥。
12-Factor推薦將應用的配置存儲于 環(huán)境變量 中桑寨，保證配置排除在代碼之外，有如下好處：
- 環(huán)境變量是一種清楚忿檩、容易理解和標準化的配置方法
- 環(huán)境變量可以非常方便地在不同的部署間做修改尉尾，卻不動一行代碼
- 與配置文件不同，不小心把它們簽入代碼庫的概率微乎其微
- 與一些傳統(tǒng)的解決配置問題的機制（比如 Java 的屬性配置文件）相比燥透，環(huán)境變量與語言和系統(tǒng)無關(guān)
- 存儲在環(huán)境變量中的另一個好處是沙咏，方便和Docker配合使用
參考：
