環境變數配置

目錄:

• 摘要
  • 問題
  • 決策
  • 狀態
• 詳情
  • 假設
  • 約束
  • 立場
  • 論證
  • 影響
• 相關內容
  • 相關決策
  • 相關需求
  • 相關製品
  • 相關原則
• 備註

摘要

問題

我們希望應用的可配置性超出製品/二進位制檔案/原始碼的範圍,使同一個構建能夠根據其部署環境表現出不同的行為。

• 為此,我們希望使用環境變數配置。

• 我們希望透過可以進行版本控制的檔案來管理配置。

• 我們希望提供一些開發者體驗上的便利,例如瞭解哪些內容可以配置以及相關的預設值。

決策

決定採用 .env 檔案,並配有相關的預設值檔案和模式檔案。

狀態

已決定。對出現的新功能持開放態度。

詳情

假設

我們傾向於將應用程式碼與環境程式碼分離。我們假設應用需要在不同的環境中以不同的方式工作,例如開發環境、測試環境、演示環境、生產環境等。

我們推崇業界的「12 要素應用」(12 factor app)實踐,更推崇與之相關的「15 要素應用」(15 factor app)實踐。

我們以往的許多專案都沿用了 .env 檔案或類似 .env 目錄的約定。通常的做法是不將這些檔案納入版本控制,而是透過其他方式來部署、版本管理和管理它們。

約束

我們希望將金鑰排除在原始碼管理(SCM)版本控制系統(VCS)之外。

我們希望相容流行的軟體框架和庫。例如,Node 有一個用於讀取環境變數配置的模組“dotenv”。

立場

我們考慮了幾種方法:

• 將配置儲存在應用中,例如儲存在 config.js 檔案中。

• 將配置儲存在環境中,例如儲存在 .env 檔案中。

• 從已知位置獲取配置,例如從許可證伺服器獲取。

論證

我們選擇了 .env 檔案的方法,因為:

• 它很流行,包括在專家中也是如此。

• 它遵循 .env 檔案的模式,我們的團隊在許多專案中已多次成功使用過。

• 它很簡單。需要特別說明的是,對於我們看到的重大權衡(例如與許可證伺服器的方法相比缺少審計能力),我們目前可以接受。

影響

我們需要想出一種方法,將公開的環境變數配置與任何金鑰管理分離開來。

相關內容

相關決策

我們期望所有應用都採用這種方法。

我們計劃升級任何使用能力較弱的方法的應用,例如將配置硬編碼在二進位制檔案或原始碼中。

對於任何使用能力更強的方法(例如許可證伺服器)的應用,我們將保持原樣。

相關需求

我們將為這些檔案增加 DevOps 能力,包括鉤子、測試和持續整合。

我們需要就這一決策對所有開發人員隊友進行培訓。

相關製品

我們進行部署的每個區域都需要自己的 .env 檔案和相關檔案。

相關原則

易於撤銷。

備註

範例檔案 .env:

NAME=Alice Anderson
EMAIL=alice@example.com

範例檔案 .env.defaults:

NAME=Joe Doe
EMAIL=joe@example.com

僅包含鍵的範例檔案 .env.schema:

NAME
EMAIL