如何基於GitLab優雅的管理項目配置數據

配置

軟件開發過程當中，配置文件是不可少的，咱們通常會用來配置一些數據庫信息、接口域名、其它服務接口域名、key信息，以服務端爲例子，咱們配置文件格式是ini的，之前咱們是這樣配置的

A項目【數據庫配置，依賴服務（A服務）配置】

[PROD]
dbHost = "prod.example.com:3306"
dbName = "prod_example"
dbUser = "prod"
dbPwd = "prodpwd"
serverA_Domain = "prod.a.example.com"
[TEST]
dbHost = "test.example.com:3306"
dbName = "test_example"
dbUser = "test"
dbPwd = "testpwd"
serverA_Domain = "test.a.example.com"
複製代碼

B項目【依賴服務（A服務）配置】

[PROD]
service_a_domain = "prod.a.example.com"
[TEST]
service_a_domain = "test.a.example.com"
複製代碼

用一個section來區分環境，通常狀況咱們有測試環境,正式環境，某些狀況下，有可能有客戶須要咱們整套方案獨立部署，就會有客戶定製環境,這個後面說。

conf.ini這個文件之前咱們是由各開發人員本身來維護的，跟代碼一塊兒提交，這種開發模式也存在過比較長一段時間，可是期間出現過不少問題，以下：

1. 開發人員寫配置寫錯了，prod.example.com:3306定成prod.examples.com:3306
2. 配置冗餘，A服務是個基礎服務，上面A,B兩個項目都依賴了，因此每一個項目都寫了一個配置
3. 配置和項目的依賴關係，規範點的話，你們可能會用一個文檔記下來，A服務依賴的項目有A,B項目，不規範的話，可能就是全憑記憶記了，說實話我已經不太相信本身的記性了，這玩意若是過了半年，你們還能記住，我只能說牛逼，可是若是這個開發人員離職了呢，交接的時候忘記交接了，那麼這個時候就已經埋下一個坑了，如今咱們服務要遷移，域名規範下，相關服務修改下，服務用service.example.com域名,A服務改爲a.service.example.com，這個時候基本會出問題
4. 配置更新後，要push一下代碼，從新部署項目
5. 這個主要針對前端，若是把配置信息寫到項目中，那麼按F12的時候，你們能夠找到其它環境的域名配置信息，這裏我實際上是不太願意讓別人知道的(咱們的測試環境也在外網部署了)

方案

能不能把配置從項目中獨立出來，作成一個服務，項目中只保存配置的描述信息，具體配置的值由各開發人員在配置服務中維護，相關項目須要的話，直接引用，並自動記錄配置和項目的依賴關係呢？配置更新後自動部署依賴項目，上面的例子變成這樣

A項目【數據庫配置，依賴服務（A服務）配置】

projecta:
 - dbHost
 - dbName
 - dbUser
 - dbPwd
serviceA:
 - domain
複製代碼

B項目【依賴服務（A服務）配置】

serviceA:
 - domain
複製代碼

是否是簡潔不少了？

問：這只是個描述文件，怎麼獲取配置具體的值啊？創建引用關係啊？ 那咱們在當前描述基礎上，加個project來描述當前項目信息，branch來描述須要獲取哪一個分支（也就是環境，通常test分支對應測試環境，master或tag對應正式環境）的配置的值，再加個些描述format表示要輸出的文件格式和itemFormat處理配置名的方式（好比：A項目有domain，B項目也有domain，若是直接用配置名作key的話，確定會有問題）

A項目【數據庫配置，依賴服務（A服務）配置】

format: ini
itemFormat: 用逗號拼接
project:
 name: ${CI_PROJECT_NAME}
 description: ${CI_PROJECT_TITLE}
 id: ${CI_PROJECT_ID}
branch: ${CI_COMMIT_REF_NAME}
configs:
 projecta:
 - dbHost
 - dbName
 - dbUser
 - dbPwd
 serviceA:
 - domain
複製代碼

B項目【依賴服務（A服務）配置】

format: ini
itemFormat: 用逗號拼接
project:
 name: ${CI_PROJECT_NAME}
 description: ${CI_PROJECT_TITLE}
 id: ${CI_PROJECT_ID}
branch: ${CI_COMMIT_REF_NAME}
configs:
 serviceA:
 - domain
複製代碼

這樣就差很少了，而後咱們再寫一個接口根據這些描述信息輸出配置具體的值,假設配置服務叫$GITLAB_CONFIG_SERVER,咱們把這步操做放到CI/CD的時候來作，把服務輸出重定向到項目配置文件中，而後再部署或者製做成docker鏡像。

curl "$GITLAB_CONFIG_SERVER" --fd "`cat .config.yml`" > conf/app.conf
複製代碼

$GITLAB_CONFIG_SERVER要作的功能有兩個

1. 根據配置描述信息返回對應的值
2. 記錄配置和項目的依賴關係

配置使用

.config.sh文件

#!/bin/bash
config=" format: ini project: name: ${CI_PROJECT_NAME} description: ${CI_PROJECT_TITLE} id: ${CI_PROJECT_ID} itemFormat: project_without_dot configs: projecta: - dbHost - dbName - dbUser - dbPwd serviceA: - domain branch: ${CI_COMMIT_REF_NAME} "
curl "${GITLAB_CONFIG_SERVER}" -fd "$config"
複製代碼

注意：爲何這裏我用.config.sh，而不用.config.yml呢？之前在使用.config.yml使用過程當中，你們通常會複製其它項目的文件，而後直接改configs下面的信息，而忘記改project信息了，致使依賴關係錯亂，因此後面改爲用shell的時候來設置配置描述信息，這樣你們只須要改configs下面的信息了，其它信息能夠從gitlab的環境變量裏面讀到

.gitlab-ci.yml

image: docker:git
stages:
 - build
 - deploy

build_test:
 stage: build
 image: golang:1.13
 script:
 - chmod a+x .config.sh
 - ./.config.sh > conf/dev/app.conf #生成配置 - go build -o $CI_PROJECT_NAME main.go  artifacts:
 expire_in: 2 days
 paths:
 - $CI_PROJECT_NAME
 - conf
 only:
 - test

deploy_test:
 stage: deploy
 image: sebble/deploy
 script:
 - 部署代碼
 only:
 - test
複製代碼

配置服務後臺

配置管理

藍色區域顯示依賴該配置的項目

綠色區域顯示配置在不一樣分支（環境）對應的值

暫存有時候一次可能要編輯好幾個配置，若是每編輯一次都自動部署就太頻繁了，因此作了個暫存，全部配置編輯好後再點紅色區域的保存，若是點了自動部署依賴，就會建立依賴項目的pipeline達到自動部署的目的

項目一開始是沒有配置的，選中項目後，點添加配置，按格式說明輸入。

配置的編輯,刪除功能只有該gitlab項目MaintainerAccess級別以上的用戶有，其它用戶只能夠查看，若是須要某個項目的配置，點導出配置，再粘帖到你的.config.sh文件中，把不要的配置刪除了，千萬別手寫，怕寫錯。

日誌管理

作了個簡單的日誌管理，編輯，刪除會記錄日誌

---

配置服務項目連接，歡迎star：

服務端

前端

全文完