We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
现有业务需求是: 1、在主节点修改完配置文件后,只是在本机修改,并-t测试,等到业务上线时,本机先-s reload,完成配置修改,修改后绑定host测试效果。没问题后,批量的去同步这些配置文件到其他子节点并reload对应节点配置。 现有做法是: 1、通过脚本批量的去同步配置文件并reload。 如果想使用nginx-ui平台去做这件事: 我的想法是,可以控制本机和其他子节点,是否reload。 在本机保存配置时,可以选择先不reload,只是保存对应配置文件。 同步到其他节点时,也可以选择不reload保存对应配置文件,需要时批量保存并reload
The text was updated successfully, but these errors were encountered:
这个发布场景确实是存在的,后面我会考虑看看怎么加这个需求,目前还没有想到比较简洁的方案。
Sorry, something went wrong.
嗯嗯,我现在想到的其实就是让-t后的reload让用户可选,这个应该是比较好做,而且能符合需求
我的想法是在网站分类里加手动/自动 reload 的开关,然后如果要批量控制 reload 就在网站分类里手动控制。
No branches or pull requests
现有业务需求是:
1、在主节点修改完配置文件后,只是在本机修改,并-t测试,等到业务上线时,本机先-s reload,完成配置修改,修改后绑定host测试效果。没问题后,批量的去同步这些配置文件到其他子节点并reload对应节点配置。
现有做法是:
1、通过脚本批量的去同步配置文件并reload。
如果想使用nginx-ui平台去做这件事:
我的想法是,可以控制本机和其他子节点,是否reload。
在本机保存配置时,可以选择先不reload,只是保存对应配置文件。
同步到其他节点时,也可以选择不reload保存对应配置文件,需要时批量保存并reload
The text was updated successfully, but these errors were encountered: