配置

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

服务端

前端

全文完