1Panel
1Panel copied to clipboard
1Panel-dev
[FEATURE] 简化网站类型
1Panel 版本
v1.7.0
请描述您的需求或者改进建议
目前 1Panel 面板中 网站有 运行环境、一键部署 、反向代理、静态网站 这些类型。
网站区分类型，增加了开发和使用的复杂度，不同网站类型无法相互切换或者功能共存，不同类型的网站只是的配置不同，只需要对网站进行相应配置即可。
所以应该取消网站类型这样的设计，网站类型只在 新建网站 时保留使用。
网站可以任意设置运行环境，删除运行环境即为静态和配置反向代理。 这样每个网站的设置，都是统一的设置选项，而不是不同类型的网站有不同的设置选项。
请描述你建议的实现方案
No response
附加信息
#2408 #2200 同时这些问题可一并解决
不同的网站类型代表的不同的操作逻辑 仅从备份恢复角度考虑
- 一键部署的网站需要同步备份 应用和应用关联的数据库
- 反向代理网站和静态网站只需要备份网站目录
- 运行环境网站需要备份运行环境目录
切换类型 之后，之前备份的网站恢复起来会很麻烦 比如 一键部署切换成静态网站 那之前备份的就无法恢复
其他的操作就更不用说了 所以精简网站类型不是一个很好实现的需求
不同的网站类型代表的不同的操作逻辑 仅从备份恢复角度考虑
- 一键部署的网站需要同步备份 应用和应用关联的数据库
- 反向代理网站和静态网站只需要备份网站目录
- 运行环境网站需要备份运行环境目录
切换类型 之后，之前备份的网站恢复起来会很麻烦 比如 一键部署切换成静态网站 那之前备份的就无法恢复
其他的操作就更不用说了 所以精简网站类型不是一个很好实现的需求
切换类型会造成备份恢复麻烦，所以我支持取消网站类型区分，使用统一的操作逻辑。只在新建时区分网站类型，是为了能让用户方便的建立网站，不管选择哪种网站类型，只是初始配置不同，后续可以任意设置。比如 新建时选择静态站点，后面在网站设置中，可以绑定应用，也可以添加运行环境。对于运行环境、静态网站、反向代理之间区别就是nginx配置不同，至少说静态网站可以完全代替反向代理类型，至于一键部署网站，也无非是反向代理+应用关联信息。对于网站备份则是备份：网站目录 + 站点的OpenResty配置文件 + website.json，如果绑定应用则额外备份应用和数据。对于恢复备份，肯定是要覆盖当前的数据，直接恢复到备份时的状态，这不需要考虑是哪种网站类型。
不同的网站类型代表的不同的操作逻辑 仅从备份恢复角度考虑
- 一键部署的网站需要同步备份 应用和应用关联的数据库
- 反向代理网站和静态网站只需要备份网站目录
- 运行环境网站需要备份运行环境目录
切换类型 之后，之前备份的网站恢复起来会很麻烦 比如 一键部署切换成静态网站 那之前备份的就无法恢复 其他的操作就更不用说了 所以精简网站类型不是一个很好实现的需求
切换类型会造成备份恢复麻烦，所以我支持取消网站类型区分，使用统一的操作逻辑。只在新建时区分网站类型，是为了能让用户方便的建立网站，不管选择哪种网站类型，只是初始配置不同，后续可以任意设置。比如 新建时选择静态站点，后面在网站设置中，可以绑定应用，也可以添加运行环境。对于运行环境、静态网站、反向代理之间区别就是nginx配置不同，至少说静态网站可以完全代替反向代理类型，至于一键部署网站，也无非是反向代理+应用关联信息。对于网站备份则是备份：网站目录 + 站点的OpenResty配置文件 + website.json，如果绑定应用则额外备份应用和数据。对于恢复备份，肯定是要覆盖当前的数据，直接恢复到备份时的状态，这不需要考虑是哪种网站类型。
嗯 我理解你的意思 技术上是没有障碍的 但是逻辑处理起来会很复杂
比如一键部署的备份 包含了数据库和应用，切换到静态网站 ，需要处理是否删除原有的应用和数据库。恢复的时候，也得处理这些逻辑，逻辑复杂之后，出问题的概率也会变大
当然 放开反向代理类型网站 编辑 index 文件夹下的页面 和 静态网站切换为 PHP 类型的网站 还是比较好做的
可以折中一下，比如从产品经理的角度看，实际上”一键部署“这个网站类型的主要用户人群是不熟悉 docker 和建站的小白用户群体，而这一类型也是实现切换类型后的备份逻辑比较复杂的主要原因；”运行环境“、”反向代理“、”静态网站“这三个网站类型的主要用户人群则是会自己手动部署源码、调通环境的人，所以在技术上相较于前者更有操作空间。
所以可以将”一键部署“作为”新手“建站类型，而”运行环境“、”反向代理“、”静态网站“合并成”进阶“建站类型，并且两者不做互通和转换，前者的备份只能前者使用，后者的备份只能后者使用。 这样子既避免了上述备份逻辑复杂的情况，而且也解决了手动部署源码时存在多种网站类型交叉需求的情况。
上面回复提到的关于”运行环境网站需要备份运行环境目录“我其实没太明白到底是备份哪个目录，如果是环境的配置目录的话应该是好做的；如果是环境本身的话，我的看法是备份创建环境时的相关输入参数。
可以折中一下，比如从产品经理的角度看，实际上”一键部署“这个网站类型的主要用户人群是不熟悉 docker 和建站的小白用户群体，而这一类型也是实现切换类型后的备份逻辑比较复杂的主要原因；”运行环境“、”反向代理“、”静态网站“这三个网站类型的主要用户人群则是会自己手动部署源码、调通环境的人，所以在技术上相较于前者更有操作空间。
所以可以将”一键部署“作为”新手“建站类型，而”运行环境“、”反向代理“、”静态网站“合并成”进阶“建站类型，并且两者不做互通和转换，前者的备份只能前者使用，后者的备份只能后者使用。 这样子既避免了上述备份逻辑复杂的情况，而且也解决了手动部署源码时存在多种网站类型交叉需求的情况。
上面回复提到的关于”运行环境网站需要备份运行环境目录“我其实没太明白到底是备份哪个目录，如果是环境的配置目录的话应该是好做的；如果是环境本身的话，我的看法是备份创建环境时的相关输入参数。
感谢建议 你的建议非常不错
”运行环境网站需要备份运行环境目录“ 是当前环境网站是以 docker-compose.yml 启动一个运行环境容器，主要备份的是 docker-compose.yml 这个文件所在的目录，会包含一些配置文件 比如 php.ini ，而静态网站和反向代理则不需要这些，我上面说的备份恢复处理复杂，就是说当前如果是静态网站，想恢复成 PHP 运行环境，需要先创建一个 docker-compose.yml 启动的 PHP 容器，并挂载相关配置文件。而当前我们的备份恢复，都是基于已有资源，就是你必须先存在这个资源，我才能给你恢复，所以要实现 静态网站-PHP运行环境的切换，需要先解决这个问题，其实也就是一个用备份文件导入网站的功能，所以可能会先做导入网站，然后再做切换。
跟我在 #2405 提的差不多(不要把PHP配置放到网站配置里, 应该移到环境那), 环境配置是环境配置, 网站配置是网站配置,
备份时, 环境配置和网站配置也是分开备份.
还原时, 先还原环境配置, 再还原网站配置, 还原网站时如果环境不存在, 直接转成静态网站 (一般应该不会有这种情况, 备份时, 环境配置应该也备份了)
