如何基于GitLab优雅的管理项目配置数据

配置

软件开发过程中,配置文件是不可少的,我们一般会用来配置一些数据库信息、接口域名、其它服务接口域名、key信息,以服务端为例子,我们配置文件格式是ini的,以前我们是这样配置的

A项目【数据库配置,依赖服务(A服务)配置】

[PR/ ( 7 [ ; ; M ~ )OD]
dbHost = "prodA 2 + u V 9 2 -.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"
dg + ; z W G Q h rbPwd = "test/ H ; * jpwK l /  R ^d"
serverA_Domain = "test.a.example.com"

B项目【依赖服务(A服务)配置】

[PROD]c R M u f 3 n
service_a_domain = "prod.a.example.com"
[TEST]
service_a_I 8 6 adomainD 2 G D = "test.a.example.com"

用一个sectiou | q H kn来区分环境,一般情况我们有测试环境,正式环境,某些情况下,有可能有客户需要我们整套方案独立部署,就会有客户定制环境,这个后面说。

conf.ini这个文件以前我们是由各开发人员自己来维护的,跟代码一起提交,这种开发模式T ! i C h p o y I也存在过比较长一段时间,但是期间出现过{ T 1 $ _ N 很多问题,如下:

  1. 开发人员写配置写错了,k E Q 0 b g Rp3 h q % F Wrod.example.com:3306定成prod.examples.com:3306
  2. 配置冗余,A服务是个基础服务,上面A,B两个项目都依赖了,所以每个项目都写了一个配置
  3. 配置g p x y l和项目的依赖关系,规范点的话,大家可能会用一个文档记下来,A服务依赖的项目有AK D L b * . i `,B项目,不规范的话,可能就是全凭记忆记了,说实话我已经不太相信自己W ) h 5 t的记性了,这玩意如果过了半年,大家还能记住,我只能说牛逼,但是如果这个开发人员离职了呢,交接的时候忘记交接了,那么这个时候就已经z [ k埋下一个坑了,现在我们服务要迁移,域名规范下,相关服务修改下,服务用service.examplV 7 h i P j *e.com域名,A服务改成a.service.eD 8 | d k ~ fxample.com,这个时候基本会出问题
  4. 配置更新后,要push一下代码,重新部署项目
  5. 这个主要针对前端,如果把配置信息写到项目中,那么按F12的时候,大家可以找到其它环境的域名配置信息,这里我其实是不太愿意让别人知道的(我们的测试环境也在外网部署了)

方案

能不能把配置从项目中独立出来,做成一个服务,项目中只保存配置的% X P | v描述信息,具体配置的值由各开发人员在配置服务中维P l B 0 [ B ~ h护,相关项目需要的话,直接引用,并自动记录配置和项目的依赖关系呢?配置更新后自动部署依赖项目,上面的例子变成这样

A项目【数据库配置,依赖服务(A服务)配置】

projecta:
- dbHost
- dbName
- dbUser
- dbPwd
serZ 7 z f AviceA:
- domain

B项目【依赖服务(A服务)配置】

serviceA:
- domain

是不是简洁很多了?

:这只是个描述文件,怎么获取配置具体的值啊?建立引用关系啊?
那我们在当前描述基础上,加个project来描述当前项目信息,branch来描述需要获取哪个分支(也就是环境,一般testr [ M Y 2 C x % T支对应测试环境,mastertagG B h V Z 8 )应正式环境)的配置的值,再加个些描述format表示要输出的文件格式和itemFormat处理配置名的方式(比如:A项目有domainB项目也有domain,如果直接用配置名做key的话,肯定会有问题)

Ax ? - 6项目【数据库配置,依赖服务(A服务)配置】

format: ini
itemFo, q ! ! L O f N nrmat:W 0 q @ B R 用逗号拼接
project:
name:t a H X = ${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_NAy 5 = t j ? U r +ME}
descript* J fion: ${CI_7 + v 9 YPROJECT_TITLE}
id: ${CI_PROJECT_ID}
branch: ${CI_COMMIT_REF_NAME}
configs:
serviS ! i [ Y yceA:
- domain

这样就差不多了,然后我们再写一个接口根据这些描述信息输出配置具体的值,假设配置服务叫$GITLAB_CONFIG_SERVER,我们把这步操作放到CI/CD的时候来做,把服务输出重定向到项目配置文件中,然后再部署或者制作成docker镜像。

curl "$GITLAB_CONFIG_SERVER" --fd "`cat .p . T Iconw Z hfig.yml`" > conf/app.conf

$GITLAB_CONFIG_SERVER要做( F q O O _的功能有两p u F个

  1. 根据m E E U )配置描述信息返回对应的值
  2. 记录配置和项目的依赖关系

配置使c K 0 6 5 8 { g

.cR 3 K {onfig.sh文件

#!/bin/bash
config="
format: ini
project:
name: ${CI_PROJECT_NAME}
descriptio? [ 2 A n: ${Ci L ! U + M Z =I_PROJECT_TITLE}
id: ${CI_PROJECT_ID}
itemFormat: project_without_dot
configs:
projecta:
- dbHost
- dbName
- dbUseW o - 6 6 q g ] ~r
- dbPwd
serviceA:
- domain
branch: ${CI_^ _ [ 6 n | Z = &COMMIT_REF_NAME}
"
curl "${GITLAB_CONFIG_SERVER}" -s l /fd "$config"

注意:为什么这里我用.config.sh,而不用.conV U & Xfig.yml呢?以前在使用.config.yml使用过程中,大家一般会复制其它项目的文件,然后直接改configs下面的信息,而忘记改project信息了,导致依赖关系错乱,所以后面改成用shell的时候来设置配置描述信息,这样大家只需要改configs下面的信息了,其它信息可以从gitlab的环境变量里面读到

.gitlab-ci.yml

image: docker:git
stages:
- build
- deploy
build_test:
stage: buil) Q i ] Od
image: golang:1.13
script:
- chmod a+x .J ) * wconfig.sh
- ./.config.sh > conf/dev/app.conf  #生成配置
- go build -o $CI_PROJECT_NAME main.go
artifacts:
ef 8 Sxpire_in: ^ | f ~ L: 2 days
paths:
- $CI_PROJECT_NAME
- conf
only:
- test
deploy_test:
stage: deploy( 2 m Q
image: sebble/deploy
script:! | N ? M ?
- 部署代码
only:
- test

配置服务后台

配置管理

蓝色区域显示依赖该配置的项目n g e

绿色区域显示配置在不同分支(环境)对应的值

7 _ ^ M y有时候一次可能要编辑好几个配置,如果每( g J 编辑一次都自动部署就太频繁了,所以做了个a m Z F z e T n 2暂存,所有配置编辑好后再点红色区域的保存,如果点了自动部署依赖,就会创建依赖项目的pipeline达到自动部署的目的

如何基于GitLab优雅的管理项目配置数据

r K 4目一开始是没有配置的,选中项目后,点添加配置,按格式说明输入。

配置的编辑,删除功能只有该gi| [ ( ]tlab项目MaintainerAccess级别以上的用户有,其它用d t c + g ! m a户只可以查看,如果需要某个项目的配置,点导出配置,再J ] 7 S U #粘帖到你的N M 8 R.config.sh文件中,把H c o y不要的配置删除了,s * Q F c千万别手写,怕写错V t ~。

日志管理

做了个简单的日志管理,编辑删除会记录日志

如何基于GitLab优雅的管理项目配置数据

配置服务项目链接,欢迎star:

服务端

前端

4 # ! Y | i A Q文完