在官方的环境以及现在泛滥的教程所使用的环境,都是清一色的全新环境,但在我实际部署的时候发现一个问题:
真正有能力购置独立机或者是像我这样自己买硬件然后装PVE做虚拟化的并不多,大多数都是部署在一台服务器上,既跑着自己的博客,又跑其他的什么东西
大多数学生党都在使用雨云等高性价比的服务商,用雨云的应该是最多的,毕竟
在其他教程中都是介绍的全新环境安装,不会介绍怎么解决端口占用问题,这就导致在部署Discourse时被部署工具检测到端口占用,无法部署,那么真的没办法了么?
在完成git clone后,在samples目录下存在一些yml配置文件,打开验证一下,确实是docker compose的文件,在其中,standalone.yml就是主要更改的文件了,参考官方文章,不难发现需要更改的内容
Run other websites on the same machine as Discourse – Documentation / Self-Hosting – Discourse Meta
官方给出了两种部署方式,如果你只是想单纯的换个端口,只需要不启用SSL、更改一下暴露出来的冲突端口就好,但是如果你使用nginx作为入口,更推荐不暴露端口,使用套接字进行反向代理
为弥补官方给出的方案对于小白来说不易懂,本文会探讨两种方案的实施
但是跟着官方文档走,很快就发现了问题,即使更改了这些配置文件,部署脚本依然会检测到端口占用拒绝部署
为了解决这个问题,我尝试了更改samples/web_only.yml,但没有任何效果,事实证明,这些conpose文件仅仅只是compose,跟部署脚本检测端口占用没有一点关系,那么既然是基于docker compose的,我们完全可以手动up起来,不用依赖它的脚本
但是别忘了,在部署阶段会有这么一个东西
是的,这不光是一个docker compose up -d的脚本,而是一个完整的配置工具,我们还要靠他来生成一个配置文件
那么我们只能想办法曲线救国了,我们用file看一下部署脚本的文件类型
它成功的识别出了这是个shell script,证明我们可以编辑它来更改、绕过端口占用的检测
在310行上下,找到了我们看到的熟悉的提示,我们著需要让他永远认为端口不被占用就好了(不推荐),更推荐更改他的检测端口
例如我这里使用41280作为入口,因为要做外部反向代理,所以注释掉443端口的检测,只使用41280端口即可(使用套接字代理直接全部注释掉即可,因为套接字依赖的是文件而不是端口)
再次执行,成功了
很棒的解决方案!期待看到更多这样的技术心得
这确实不错,绝大多数人一般都是部署在一个服务器上,程序之间端口冲突并不少见,最好的办法不过就是换端口了,或者是去除无必要的项目