一个简单的基于gitlab的配置服务

时间  2019-11-16
标签 一个 简单 基于 gitlab 配置 服务 栏目 Git 繁體版
原文   原文链接

要什么样的配置服务

咱们的项目之前都是由各开发人员本身写一个config.js或者app.conf来管理项目的配置信息，常常出现下面的问题，我须要一个配置服务来解决它html

1. 杜绝犯低级错误

若是没犯低级错误的话，通常也不会出现什么问题，什么是低级错误呢，就拿前端来讲，之前引入配置通常这样前端

if( env === 'dev' ){
    configs = import('./dev.config')
}else if( env === 'test' ){
    configs = import('./test.config')
}else{
    configs = import('./prod.config')
}
复制代码

本地为了解决测试环境的一个bug，原本env应该为dev的，结果为了用测试环境的配置，强制把env设置为test了，而后问题解决了，测试环境测试也没问题了，发布的时候就直接更新到正式环境了，结果就gg了，一查原来是env忘记改了。node

2. 不但愿当前环境看到其它环境的配置值

接着杜绝犯低级错误，上面那样写前端配置还会有个问题，就是前端按F12能够看到咱们测试服务器的一些信息，好比某个网页的测试前端域名，这些信息我其时是不想外面看到的linux

3. 配置冗余问题

假如我有一个基础服务A，B和C模块依赖服务A的域名，那么就要在这两个模块下各写一个域名配置nginx

export default {
    A_Domain:"https://xxx.readboy.com"
}
复制代码

看起来是没问题，其实这里我以为问题不少，假如个人A模块域名更新了，我只知道B模块依赖这个域名，通知了B模块开发人员修改，而后更新了，旧域名移除了，那么C模块确定会有问题，若是能由各开发人员维护本身的配置，依赖项目不须要设置，直接配置依赖，直接引用就行了git

4. 创建配置和项目依赖

这个问题是基于配置冗余问题的，我但愿我能够知道这个配置（A模块域名）有哪些项目依赖了，若是这个配置更新了，我但愿依赖的项目能自动拉取最新的配置并部署es6

总结

基于上面的问题，网上大概找了下相关的解决方案都不太满意（本身能力太水^-^），golang

  1. 我不想要运行时动态拉取配置，总感受这个可靠性不强（小厂，资源有限）
  2. 获取配置要足够简单，不要再配环境，还要装什么客户端，我但愿一个http就能解决，来吧，搞起来

配置服务实现的基本功能

项目管理

新建一个项目，指定这个项目有哪些环境，通常固定prod,env,dev docker

项目管理

配置管理

项目指定几个环境，相应项目下的配置就有相应的环境，开发人员填入相应的值就行 shell

配置管理

这基本就完成了项目的配置存储功能，怎么用呢？这个时候就须要定义一个配置描述文件(.config.yml)了，基本内容就是你要哪些项目的哪一个配置，由配置服务接口根据描述文件自动返回配置值

运行效果（gif图，有点大）

配置更新自动部署全部依赖的项目

自动部署 

format: json
itemFormat: 配置key处理规则，看下面
envBranch: 
 test: test
 prod: master
project:
 name: readboyconfig
 description: 项目描述
 id: gitlab项目ID
configs:
 projecta:
 - configa
 - configb
 - configc
 projectb:
 - configb
 - configc
 - configd
env: test(环境在部署的时候动态写入)
    
复制代码

format

表示输出文件格式，值以下：

js(es6)

json

ini

yml

project

表示工程信息，主要是相关配置更新后用于重启服务用的

id 项目在gitlab中的ID

name 项目名称

description 项目描述信息

envBranch

环境和分支的对应关系，主要是相关配置更新后用于重启服务用的

格式： env: branch name

env

表示要输出的环境配置，值对应后台录入的env

itemFormat

表示生成配置项的方式，取值以下

ignore 忽略项目名

prefix 项目名+配置名

dot 项目名+ . +链接配置

tree 保持层级结构

project_without_prefix 当前项目不加前缀，其它项目同 prefix

project_without_dot 当前项目不用.链接，其它项目同 dot

project_without_tree 当前项目不保持层级结构，其它项目同 tree

configs

项目配置信息，具体参考后台数据

CI配置

全部配置信息更新后，会触发依赖项目的CI并携带参数 readboy_trigger=config，若是某些阶段在自动触发的CI中不要执行，能够在CI文件中加上条件

only:
  variables
    - $readboy_trigger == 'config'
复制代码

或

except:
  variables
    - $readboy_trigger == 'config'
复制代码

yml格式说明结束

获取配置

curl "${CONFIG_SERVER}" -fd "`cat .config.yml`" > src/config/index.js
复制代码

CONFIG_SERVER这个接口要实现功能主要有：

  1. 根据环境来获取描述文件的值
  2. 创建相关配置和gitlab项目的依赖关系，当相关配置更新的时候，本身触发相关项目的gitlab CI，实现自动拉取最新配置，自动部署

获取配置

自动部署

配置管理后台的配置值更新的时候，程序会检测哪一个环境的值变了，并获取依赖该属性的gitlab项目信息，利用gitlab的API，API连接，自动建立一个pipeline来拉取配置，部署程序。至此，一个简单的基于gitlab的配置服务就完成了。

固然要彻底把这个配置服务利用起来，还须要跟开发人员作要求，配置使用，依赖项目的配置绝对不要再写一遍，否则配置变了，更新就会出问题。

一些CI配置

前端CI文件

image: node:8.9.3
stages:
  - build
  - buildImage  
  - deploy

variables:
  ALI_REGISTRY_HOST: ""
  ALI_REGISTRY_IMAGE: ""
  ALI_SERVICE_NAME: ""
  PROD_NAMESPACE: ebag-prod
  BETA_IMAGE: beta-$CI_COMMIT_SHA
  BETA_LATEST: beta-latest

masterbuild:
  stage: build
  script:
    - printf "\nenv:" >> .config.yml
    - printf " prod" >> .config.yml
    - curl "${CONFIG_SERVER}" -fd "`cat .config.yml`" > src/config/index.js
    - npm install --no-optional
    - npm run build
    - node ./tools/generate.config.js
    - qshell='./tools/qshell-linux-x64'
    - chmod a+x "${qshell}"
    - ${qshell} account "${QINIU_AK}" "${QINIU_SK}"
    - ${qshell} qupload 8 ./qiniuconfig
  only:
    - master
  artifacts:
    expire_in: 1 week
    paths:
      - dist
      
imagebuild:
  stage: buildImage
  image: docker:latest
  script:
    - docker login -u $ALI_REGISTRY_USER -p $ALI_REGISTRY_PASSWORD $ALI_REGISTRY_HOST
    - docker build -t $ALI_REGISTRY_IMAGE:$BETA_IMAGE -t $ALI_REGISTRY_IMAGE:$BETA_LATEST -f docker/Dockerfile .
    - docker push $ALI_REGISTRY_IMAGE:$BETA_IMAGE
    - docker push $ALI_REGISTRY_IMAGE:$BETA_LATEST
  only:
    - master

复制代码

前端Dockerfile

FROM nginx:latest
COPY dist /usr/share/nginx/html
COPY docker/default.conf /etc/nginx/conf.d

复制代码

服务端CI文件

image: docker:git
stages:
  - build
  - deploy

variables:
  ALI_REGISTRY_IMAGE: "..."
  ALI_SERVICE_NAME: "readboyconfig"

build_test:
  stage: build
  script:
    - echo `date "+%Y%m%d%H%M%S"` > ./datetime
    - docker build --build-arg APP_ROOT=/go/src/$CI_PROJECT_NAME --build-arg EXPOSE_PORT=6381 --build-arg DREAM_ENV=test --build-arg TAG_NAME=${CI_COMMIT_SHA} --build-arg CONFIG_SERVER=${CONFIG_SERVER}  -t ${ALI_REGISTRY_IMAGE}:latest -t ${ALI_REGISTRY_IMAGE}:${CI_COMMIT_SHA}_`cat ./datetime` -f docker/Dockerfile .
    - docker login -u $ALI_REGISTRY_USER -p $ALI_REGISTRY_PASSWORD $ALI_REGISTRY_HOST
    - docker push ${ALI_REGISTRY_IMAGE}:${CI_COMMIT_SHA}_`cat ./datetime`
    - docker push ${ALI_REGISTRY_IMAGE}:latest
  artifacts:
    expire_in: 2 days
    paths:
      - datetime
  only:
    - test

deploy_test:
  stage: deploy
  variables:
    IMAGE_NAME: ${ALI_REGISTRY_IMAGE}:${CI_COMMIT_SHA}
  image: ...
  before_script:
    - mkdir -p ~/.kube
    - echo "$TEST_KUBERNETES_CONFIG" > ~/.kube/config
    - echo "$TEST_KUBERNETES_CA" > ~/.kube/ca.crt
  script:
    - kubectl -n ebag-test set image deployment/${ALI_SERVICE_NAME} ${ALI_SERVICE_NAME}=${IMAGE_NAME}_`cat ./datetime`
  only:
    - test

复制代码

服务端Dockerfile文件(去掉一些非必要信息)

FROM golang:1.9.2 AS gobuild
WORKDIR ${APP_ROOT}
RUN curl "${CONFIG_SERVER}" -fd "`cat .comfig.yml`" > ./conf/dev/app.conf
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main ./main.go
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o migrate ./migrate.go

FROM alpine:latest
ARG APP_ROOT
ARG DREAM_ENV
ARG EXPOSE_PORT
WORKDIR /app
EXPOSE ${EXPOSE_PORT}
USER root
RUN mkdir -p ./conf/dev && touch ./conf/dev/app.conf
RUN mkdir -p ./log
VOLUME ["/app/log"]
COPY --from=gobuild ${APP_ROOT}/migrate ./migrate
COPY --from=gobuild ${APP_ROOT}/main ./main
COPY --from=gobuild ${APP_ROOT}/conf/ ./conf/
COPY --from=gobuild ${APP_ROOT}/migration/ ./migration/
COPY --from=gobuild ${APP_ROOT}/docker/start.sh ./start.sh
COPY --from=gobuild ${APP_ROOT}/bin ./bin
ENTRYPOINT ["/app/start.sh"]

复制代码

注意

curl必定要把-f加上，否则你的CONFIG_SERVER有bug的话，会部署一个空的配置文件到服务器上，出现服务不可用的问题，加上-f，若是你的CONFIG_SERVER有bug，返回500了，CI会中断执行，不会把有问题的程序部署到服务器

为何有要datetime

若是内容没变，编译出来的镜像名称是同样的，从新部署pod会失败，因此为了保证每次编译出来的镜像名称不同，用datetime来记录时间，保证部署成功

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程