配置
软件开发过程中，配置文件是不可少的，我们一般会用来配置一些数据库信息、接口域名、其它服务接口域名、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这个文件以前我们是由各开发人员自己来维护的，跟代码一起提交，这种开发模式也存在过比较长一段时间，但是期间出现过很多问题，如下：
- 开发人员写配置写错了，
prod.example.com:3306定成prod.examples.com:3306- 配置冗余，
A服务是个基础服务，上面A,B两个项目都依赖了，所以每个项目都写了一个配置- 配置和项目的依赖关系，规范点的话，大家可能会用一个文档记下来，
A服务依赖的项目有A,B项目，不规范的话，可能就是全凭记忆记了，说实话我已经不太相信自己的记性了，这玩意如果过了半年，大家还能记住，我只能说牛逼，但是如果这个开发人员离职了呢，交接的时候忘记交接了，那么这个时候就已经埋下一个坑了，现在我们服务要迁移，域名规范下，相关服务修改下，服务用service.example.com域名,A服务改成a.service.example.com，这个时候基本会出问题- 配置更新后，要
push一下代码，重新部署项目- 这个主要针对前端，如果把配置信息写到项目中，那么按
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要做的功能有两个
- 根据配置描述信息返回对应的值
- 记录配置和项目的依赖关系
配置使用
.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：
服务端
前端
全文完
