你是專案裡的那條龍嗎？

假設我們都不是一人統包開發, 而且工作的環境也不是開發到正式一個環境的狀況下, 那在工作上可能會配合到網路、資料庫、雲端部署等相關的外單位, 由這些單位提供的id, password, ip, domain或api的連線資料可能會不定期地更換, 若是每次更換時都要重新修改程式, 雖然只是一點點修改時間, 但是修修改改好幾回也是一種成本, 另外每次去異動程式就會有上錯版本的風險, 所以我們會把常異動的或是可以調整的參數獨立出來做成環境變數。

專案離開本機到共用環境之後, 從服務的port到資料庫、redis、外部API等連線都會因為不同的環境而需要有不同的設定, 把這些設定參數收攏成可以由外部餵入參數的env, 這樣在更換環境時只需要設定該環境底下的env就可以讓同一個bin檔在不同的環境啟動。

設定檔套件目前使用過兩種：

• urfave/cli

  • 這套可以在啟動時直接添加全局的flag, 依照指定的flag動作, ex: 定義start為啟動時要init的function, 再指定-e 來讀取設定檔 path, 那啟動時下的指令就會是：./test start -e .env
  • 啟動方式直覺又快速, 可以在本機按照不同的.env 啟動多個服務做比較
  • 缺點是編寫的.env 只能是一維的key-value

• viper

  • 可以從多種格式中讀取設定檔, ex:JSON, YAML..., 也可以綁定flag,
    會需要在程式中指定要讀取的設定檔名稱和格式

    config.SetConfigType("yaml")
    config.SetConfigName("config")
    config.AddConfigPath(".")
    

    啟動的指令會是：./test, 預設會讀取專案資料夾底下的 config.yaml
  • viper 支援多維的yaml設定檔編寫, env相較之下比較好閱讀

兩套都很好上手，這次會使用到的設定項目不多, 所以採用 urfave/cli。
通常會被列在設定檔的項目有：

• 服務本身的 api port
• 工具連線host, id, password及相關設置, 包含 mysql, scylla, redis, nsq ... 等
• 相依服務的位址, 包含 grpc service, http service
• go worker 數量

異動性高的項目跟需要保有彈性的項目都可以列到設定檔, 另外還有一套spf13/cobra可以參考, 這個看起來也差不多, 有機會再來使用看看。