常见问题，必看！！！

一定要添加一个节点

尽管我们跑AgileConfig最少只需要一个节点。但是从架构上来说，一个完整的AgileConfig包含2个部分，一个是数据节点，一个是管理控制台。
所以就算单节点跑也请把当前节点添加到节点列表，以便进行管理。
如果不加入节点管理列表，那么配置的修改不会热更新会有延时。

如果是docker运行的，添加的节点IP千万不要用localhost

大量的同学给我反馈添加节点后节点始终显示离线状态。99%的问题都是因为使用docker跑AgileConfig，但是添加节点的时候使用了localhost。
这里给大家解释下为什么使用localhost会有问题，这其实是docker的知识，看起来不科普不行。 比如使用docker run -p 6000:5000 这样映射端口来跑AgileConfig。 大家可以把docker想象成一个小型虚机（当然这个不准确，请不要介意这点），这个虚机里运行了AgileConfig的实例程序，监听虚机的5000端口。宿主机的6000端口被映射到虚机的5000口，这个时候你在宿主机使用http://localhost:6000可以访问到我们的AgileConfig网站了。然后如果这个时候添加节点为http://localhost:6000 ，那么虚机里的实例会开始进行健康检测，会往http://localhost:6000发送请求测试是不是在线。
但是这里有个问题这个localhost会被虚机解析为本机，也就是虚机其实是在给自己（虚机）的6000口发送请求，于是乎一直失败，节点就一直显示离线状态。
正确的做法是使用宿主机的IP代替localhost。节点的离线造成的问题跟上面一样，配置不能实时热更新。

为什么配置的修改不能实时更新，要过一段时间更新

不能实时更新先看上面2个问题。这里解释下为什么会过一段时间更新。AgileConfig为了防止实时热更新失败，做了冗余机制。AgileConfig Client连上节点后每30s会跟节点心跳一次。每次心跳都会比较Client上所有配置的hash跟服务端的所有配置的hash是否一致，如果不一致那么会全量刷新一次配置。这就是为什么配置会间隔一段时间才生效。如果节点不是离线状态，理论上配置是可以实时热更新的。

网络环境存着nginx代理的情况下客户端连接不上节点

如果节点是nginx的下游服务，请检查nginx是否开启支持websocket协议，默认是不支持的。参考NGINX as a WebSocket Proxy 。

源代码直接运行为什么没界面

因为源码里的react app没有编译，请先编译react-ui-antd项目把dist内的产物复制到apisite项目的wwwroot/ui目录下。

npm install
npm run build

ui 项目基于 ant-design-pro4 开发，如想要修改可以先了解这项目。

IIS 下运行不起来

首先下载源码，使用dotnet publish发布后，参考网上的教程使用iis发布即可。但是有可能碰到一些问题。这里提供一些排错的思路：

1. 检查aspnetcoremodulev2是否安装正确
2. 在 webconfig 配置文件上删除 inprocess 属性
3. 如果程序运行起来了，但是client连不上，检查IIS的websocket支持是否开启

关于多环境配置

关于多环境配置

MySql 连接失败

某些版本的 mysql 可能连接不上，那是因为官方的 mysql 驱动兼容性不是太好，建议尝试 mysqlconnector 驱动来连接 mysql 。
本地代码请使用 mysqlconnector 分支，docker 请使用 kklldog/agile_config:mysqlconnector 镜像 。

SqlServer 连不上的问题

升级到net6后连某些版本的 sqlserver 会报：

(A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 35 - An internal exception was caught))

使用最新版本的 agileconfig 镜像后还需要在连接串上加上 TrustServerCertificate=True; #71

关于 JWT 的问题

在 1.6.8 版本之前，有个安全漏洞。agileconfig 使用 jwt 做 token 来做认证的校验。原来 jwt 的 SecurityKey 是在 appsettings.josn 里写好的。所以导致所有的用户加密出来的 jwt 在任何实例上都是合法的。比如我在公司部署了2套 agileconfig，一套开发环境，一套生产环境。那么开发环境的 admin 登录后生成的 token，原则上在生产环境上是合法的，因为所有的 jwt 相关的参数都是一样的。虽然这个问题可以通过手工修改 appsettings.json 或者通过环境变量来修改 SecurityKey 来规避。但是实际上大部分人是不会去修改的，因为大家对项目不熟悉也不会意识到这种安全问题。所以从 1.6.8 版本开始 appsettings.josn 里的 JwtSetting:SecurityKey 默认为空了。如果你需要自己定义这个 SecurityKey 可以手工修改 appsettings.json 里对应的配置。如果使用 docker 运行，那么使用 -e JwtSetting__SecurityKey 来指定。如果用户不自己定义，那么系统在启动的时候会默认随机生成一个 SecurityKey ，并且存在数据库的 settings 表里面。 #91