教您如何使用GitLab漂亮的管理项目配置数据

lsekfe

配置
　　软件开发过程中，配置文件是不可少的，我们一般会用来配置一些数据库信息、接口域名、其它服务接口域名、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镜像。

1. 　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文件中，把不要的配置删除了，千万别手写，千万别手写，千万别手写，怕写错。
　　日志管理
　　做了个简单的日志管理，编辑，删除会记录日志。