方法用於管理

Question

問題的多個環境之間的配置文件

我們用java WAR文件並保存配置文件中的S3桶。我們的環境：DEV，QA，Stage和PROD都有自己的配置文件和s3桶。如果我添加了一個新的字段，比如「Polling_RATE = 5000」，，它必須手動添加到每個env，因爲這些配置文件也存儲密碼，因此它們不能綁定到應用程序或保存在Github內。並非每個工程師都可以訪問每個env，因此您必須記得在產品部署日期之前通知上級工程師（DEVOPS），以便爲應用程序添加新的字段。目前它是一個非常混亂的過程。

問題

有沒有打算處理這個實用程序或建築設計模式？你如何「版本控制」你不能存儲在github中的敏感配置字段？

Answer 1

可識別的問題。

通常配置字段的密碼等敏感信息的變化比非敏感配置字段的變化少很多。一個可能的解決方案是將配置分爲兩部分：

1. 配置這是環境特定的但不包含敏感信息。我建議您將這些文件與源代碼放在一起，如果可能的話，生成文件並自動上傳到配置存儲（在您的情況下爲S3）。它們必須進行版本控制並綁定到應用程序的版本。
2. 包含敏感信息的配置。回顧這個問題，並不是所有的團隊成員都可以讀寫這些信息。您可以在S3中存儲這些具有特定訪問權限的文件，以便只有授權的成員才能訪問它們。您需要一種機制在部署時將這些文件重新連接在一起，或者將應用程序更改爲從不同的配置文件中讀取。
   但是，這隻會解決您的部分問題。操作人員仍然需要在敏感的配置密鑰更改時執行更改。這是否可以接受取決於敏感配置密鑰的更改頻率。

S3的替代方案可能是運行私有Git存儲庫（例如AWS的CodecCommit）。由於您已經在使用Git，因此您可以擁有更好的版本控制，並且可以更輕鬆地訪問開發人員進行更改。您仍然必須修復開發者和操作者之間的分離訪問權限，或者放手（因爲DevOps關於信任和合作，這可能是一個好主意）。如上所述，您可以在這裏應用類似的模式。

另一種解決方案可能是將敏感值的配置從屬性文件移動到系統配置。當你已經使用Puppet或Chef等供應系統時，這對操作人員來說會很自然。或者將所有敏感值（如密碼）設置爲環境變量，並讓應用程序將其讀取爲系統屬性。

希望這會有所幫助！

Answer 2

我們一直在使用dynamodb來保持配置值。這種方法的優點是可以從控制檯輕鬆讀取值並進行驗證。 另一個優點是，我們定期檢查dynamodb的值，所以如果需要更改任何值，我們只需更改它，應用程序會自動選擇新值，而不是再次啓動它。 使用KMS密鑰加密存儲敏感值，並且只有運行該應用程序的ec2角色有權使用該密鑰進行解密。 我們增強了Netflix archiaus項目以適應我們的需求。也許你可以檢查一下。