如何基于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：

服务端

前端

全文完