apollo-config-node
v2.2.4
Published
Apollo 配置工具
Downloads
9
Readme
Apollo配置
目前使用 Apollo 进行存储配置
功能列表
基础功能
- 获取namespace已发布配置
- 更新配置 (待发布状态)
- 删除配置 (待发布状态)
- 新增配置 (待发布状态)
- 发布配置
- 导出配置为本地文件
- 配置信息可通过配置文件 apollo.config.js / 实例化参数 赋值
- 可选展示debug关键信息
命令行工具
apc
- 导出配置
- 命令行注入apc参数
- debug -d
- 设置获取配置的环境变量key -ek | --env-key
- 设置获取配置的环境变量value -ev | --env-value
- 设置 Apollo 配置文件本地地址 -p | -path
- 命令行注入注入Apollo连接配置
安装
# 安装
npm i -D apollo-config-node
# 全局安装,可通过命令行使用
npm i -g apollo-config-node
如何使用
新增配置文件
配置文件默认为项目根目录的 apollo.config.js
也可以通过 apc -p=对应配置文件地址,来重新制定配置文件
module.exports = {
// apollo 连接信息, 可以包含 prod | release | test | dev
// 如果没有通过 -ek | -ev | middleware.env | 实例化options.env 等方式指定环境,则默认使用 test 配置
connect: {
test: {
// [必填] Apollo 对应项目 appId
"appId": '',
// [必填] Apollo 对应项目的第三方应用token, 需要找 Apollo 平台管理员获取。token 权限为 namespace 即可
"token": '',
// [必填] Apollo 平台地址
"portalAddress": "",
// [必填] Apollo 项目想要获取配置的namespace,这个很重要,我们存的数据,都是存在对应namespace
"namespace": '',
// [必填] 做各种非get 操作时,需要有操作人,为 Apollo 平台的登陆人
"author": "test"
//[可选] [默认 default] Apollo项目对应的集群,一个项目可以有很多集群
"cluster": "default",
"exportFile": "./env.js",
},
prod: {
"appId": '',
"token": '',
"portalAddress": "",
"cluster": "default",
"exportFile": "./env.js",
"namespace": '',
"author": "test"
},
release: {
},
dev: {
}
},
// 用于各个配置的自定义操作
middleware: {
/**
* 用于获取上面对应连接的配置信息。
* 这个一般用于node环境上,想通过各种情形来确认自己到底想要什么配置。比如通过环境变量
* 根据 return, 会决定匹配哪一个配置作为最终配置。如果没有匹配上对应的配置文件,默认为 test
* @returns string - prod | test | release | dev | other(会作为test处理)
*/
env () {
},
/**
* 用于设置项目对应集群。一般通过配置、env进行动态设置
* @param connectConfig 当前的配置信息
* @param env 当前对应的环境
* @returns string 要使用的集群
*/
cluster (connectConfig, env) {
// 泳道
if (env.indexOf('feature') > -1) return env.split('/')[1]
return 'default'
},
// 同上
namespace (connectConfig, env) {
},
},
// 为 true, 可以展示debug打印信息
debug: false
}
middleware 说明
env
用于设置具体环境,Apollo连接具体取哪个配置,由 env 决定。可返回 prod | master | test | qa | release | dev | 其他的字符串
prod | master:
Apollo连接会使用 connect.prod
配置
test | qa:
Apollo连接会使用 connect.test
配置
release:
Apollo连接会使用 connect.release
配置
dev:
Apollo连接会使用 connect.dev
配置
其他的字符串:
Apollo连接会回退使用 connect.test
配置
cluster
用于设置项目对应集群。一般用于集群是动态添加、不确定集群数量、名字的情况,可通过配置、env进行动态设置。
namespace
同cluster,动态确定
参数优先级
env
apc 命令行方式
cli注入方式 -ev > cli注入方式 -ek > middleware.env > 默认的test
apc 实例化调用
middleware.env > new ApolloConfig(config, {env: env}) > 默认的test
cluster
apc 命令行方式
cli注入方式 --cluster > middleware.env > 配置文件 >默认的default
apc 实例化调用
middleware.cluster > new ApolloConfig({cluster: cluster}) > 配置文件 > 默认的default
namespace
apc 命令行方式
cli注入方式 --namespace > middleware.namespace > 配置文件
apc 实例化调用
middleware.namespace > new ApolloConfig({namespace: namespace}) > 配置文件
exportFile
apc 命令行方式
cli注入方式 --exportFile > 配置文件 > 默认的apollo.export.js
apc 实例化调用
new ApolloConfig({namespace: namespace}) 配置文件 > 默认的apollo.export.js
API
getConfig
获取当前配置信息
声明信息
getConfig(): Promise<any>;
使用
import ApolloConfig from 'apollo-config-node';
const apolloConfigInstance = new ApolloConfig();
if (!apolloConfigInstance.isReady) return;
let config = await apolloConfigInstance.getConfig();
addConfigItem
向配置添加一个字段,暂存状态,需调用 publishConfig 进行发布
声明信息
addConfigItem(config: {
key: string;
value: any;
comment?: string;
}): Promise<void>;
使用
import ApolloConfig from 'apollo-config-node';
const apolloConfigInstance = new ApolloConfig();
if (!apolloConfigInstance.isReady) return;
await apolloConfigInstance.addConfigItem({
key: "name",
value: "123",
})
await apolloConfigInstance.publishConfig();
delConfigItem
删除配置中的某一个字段,暂存状态,需调用 publishConfig 进行发布
声明信息
delConfigItem(config: {
key: string;
}): Promise<void>;
使用
import ApolloConfig from 'apollo-config-node';
const apolloConfigInstance = new ApolloConfig();
if (!apolloConfigInstance.isReady) return;
await apolloConfigInstance.delConfigItem({
key: "name",
});
await apolloConfigInstance.publishConfig();
editConfigItem
更新配置的一个字段,暂存状态,需调用 publishConfig 进行发布
声明信息
editConfigItem(config: {
key: string;
value: any;
comment?: string;
}): Promise<void>;
使用
import ApolloConfig from 'apollo-config-node';
const apolloConfigInstance = new ApolloConfig();
if (!apolloConfigInstance.isReady) return;
await apolloConfigInstance.editConfigItem({
key: "name",
value: "456",
});
await apolloConfigInstance.publishConfig();
publishConfig
发布配置
声明信息
publishConfig(): Promise<void>;
使用
import ApolloConfig from 'apollo-config-node';
const apolloConfigInstance = new ApolloConfig();
if (!apolloConfigInstance.isReady) return;
await apolloConfigInstance.editConfigItem({
key: "name",
value: "456",
});
await apolloConfigInstance.publishConfig();
exportConfig
导出配置信息为独立文件。
优先级:
apc 命令行方式 cli注入方式 --exportFile > 配置文件 > 默认的apollo.export.js
apc 实例化调用 new ApolloConfig({namespace: namespace}) 配置文件 > 默认的apollo.export.js
声明信息
exportConfig(path?: string): Promise<void>;
使用
import ApolloConfig from 'apollo-config-node';
const apolloConfigInstance = new ApolloConfig();
if (!apolloConfigInstance.isReady) return;
apolloConfigInstance.exportConfig()
命令行使用方式
目前命令行功能仅仅支持导出
命令:apc
直接导出。使用项目根目录配置文件apollo.config.js
# 全局安装
apc
# 项目内安装
npx apc
通过命令行参数注入apc自身相关配置
# 默认使用全局安装命令,如未全局安装,使用 npx apc
# 打印关键连接信息
apc -d | apc --debug
# 指定apc拿取apollo.config.js 中对应的 connect[env] 的env
apc -ev=对应env的值 | apc --env-value=对应env的值
# 指定从环境变量的key。apollo-config 会通过key去拿取对应值。这个值会作为env
apc -ek=对应env的key | apc --env-key=对应env的key
# 指定配置文件路径。默认为 apollo.config.js
apc -p=配置文件路径 | apc --path=配置文件路径
通过命令行注入Apollo连接信息
这种方式注入的配置,优先级最高
通过 -- 进行分割,拿取--后面的配置,且不以 -开头,比如 -a=3,将被忽略
apc -- appId=对应appId
apc -- token=对应token
apc -- portalAddress=对应地址
apc -- namespace=对应空间
apc -- cluster=对应cluster
apc -- author=对应author
apc -- exportFile=对应要导出的文件
# 多个配置之间,通过空格进行分割
apc -- appId=对应 token=对应token portalAddress=对应地址 namespace=对应空间 cluster=对应cluster author=对应author exportFile=对应要导出的文件
# 当然也可以使apc自身配置和Apollo连接配置一起使用
apc -p=配置文件路径 -d -ev=对应env的值 -- appId=对应 token=对应token portalAddress=对应地址 namespace=对应空间 cluster=对应cluster author=对应author exportFile=对应要导出的文件
注意: apc自身配置,只能放在 -- 之前,否则将被忽略
背景
ConfigCentre配置中心
通过git仓库的方式,保存配置信息。包含 prod、qa 两套仓库。prod、qa分别为仓库的 master 分支。泳道分支为 qa master 拉取的 feature 分支
日常操作
- 建立泳道时,会自动拉取对应泳道的 feature 分支,并且根据文本替换规则,把 qa 相关替换为对应 feature 相关
- 拉取分支到本地(测试环境、生产环境分别拉取)
- 更改、推送到远程分支
- Jenkins打包通过 wget 拉取 git 仓库的文件
- 替换至对应文件夹
缺点
- 拉取、推送麻烦
- 通过git来管理配置,不方便快速修改、发布
- 整套流程不太规范化,git仓库不太适合用来做配置管理
- 团队配置方式不统一
TODO
[] webpack 插件化 [] test