阅读 991

如何基于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分支对应测试环境,mastertag对应正式环境)的配置的值,再加个些描述format表示要输出的文件格式和itemFormat处理配置名的方式(比如:A项目有domainB项目也有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:

服务端

前端

全文完

关注下面的标签,发现更多相似文章
评论