配置中心设计

基础模型

• 项目 project
• 应用 application
• 环境 environment
  对应的机器或集群（k8s集群提供kubeconfig文件）

机器分组 ip+port

管理应用配置文件

[路径]+内容

制品

id，开发签名，测试签名

功能描述

1. 配置源管理

代码仓库的ykcfg文件夹存储配置信息，分子文件夹，每个子文件夹对应一个环境

└── yk_config
    ├── README.txt
    ├── neozhao+launch
    │   ├── config
    │   │   └── godemo.conf
    │   └── inventory.yaml
    ├── pre
    │   ├── config
    │   │   └── godemo.conf
    │   └── inventory.yaml
    ├── prod
    │   ├── config
    │   │   └── godemo.conf
    │   └── inventory.yaml
    ├── sync_conf.py
    └── test
        ├── config
        │   └── godemo.conf
        └── inventory.yaml

2. 更新策略

配置来源于同步git仓库，因为不同分支使用临时配置有不同，所以同步时只更新和添加不删除，删除需要在UI上操作

3. 授权问题

• 粒度
  • 项目:应用，应用作为最小授权单位
    意思是：用户只要能看到应用就能看到应用下的所有环境配置信息
    用户不能编辑，只要能看就能删除（反正删除后代码仓库可以恢复，即使删除了代码，也可以从历史版本中恢复）
  • 项目下的应用
    要么单个指定 projA:appB
    要么全部授权 projA:*
• 哪些地方需要授权
  • 用户可以查看和删除配置
  • jenkins能读写配置中心

使用

更新时，提交触发jenkins，jenkins将ykcfg的所有文件同步到配置中心

开发提测时，jenkins触发给制品记下开发签名
通过测试时，jenkins触发给制品记下测试签名
部署环境时，jenkins读取配置文件和目标环境，将配置文件推送到目标环境，然后再执行剩下的部署操作
部署环境时，如果是CD，需要签名验证，然后才是部署

配置信息管理：

需要推送到目标环境（机器/集群）的配置文件，路径+文件内容
项目-环境名称-环境对应的资源(host/k8s集群)-配置信息-制品签名信息
部署时，将环境相关的配置信息全部推送的到目标环境
如果是k8s就是configure map和secrets卷，直接apply -f
如果是传统方式，就是将文件写到指定的服务器目录（与具体ip相关）