摘要:而又因为我的分享,也引来了该工具的作者关注,并互加了好友。在经过探讨以及作者的指点之后,我决定在上一篇分享的基础上,对教程进一步的完善下,送给有需要的小伙伴~
哈楼小伙伴们好,我是Stark-C~
我前天分享了一款最近发现的可以部署在NAS上的反向代理工具『OpenResty Manager』。
因为并没有过多的研究,所以文中有些小纰漏,我对此也是深感抱歉~
而又因为我的分享,也引来了该工具的作者关注,并互加了好友。在经过探讨以及作者的指点之后,我决定在上一篇分享的基础上,对教程进一步的完善下,送给有需要的小伙伴~
项目Github地址(别忘了点点小星星支持作者哦~):https://github.com/Safe3/openresty-manager
关于yml文件配置问题
上个教程给出的yml文件路径映射不能和常规的命令一样,映射到NAS的本地实际路径。主要是因为常规命令使用的路径映射为bind模式,而OpenResty Manager使用的是volume模式。
如果我们直接更改为bind模式,它就会把容器中的文件替换掉,导致容器不能启动(反正就是这么个意思,太专业的知识我也解释不出来)。
好在作者也说了并不是不能改,而是需要重新启用新的yml文件配置。具体操作如下:
🔺先在极空间的文件管理器中Docker目录新建一个“OpenResty Manager”的文件夹,然后在该文件夹下再建acme、data、nginx三个子文件夹。
🔺接着在nginx子文件夹下面再建一个conf文件夹,在conf文件夹内再建sites、certs、upstreams三个子文件夹。
🔺然后回到Docker管理器中,在原OpenResty Manager容器中“重新构建”以下yml文件配置:
services:openresty-manager:
image:uusec/openresty-manager:latest
# image: swr.cn-south-1.myhuaweicloud.com/uusec/openresty-manager:latest # 网络不好时可以用这个
container_name:openresty-manager
restart:always
network_mode:bridge
ports:
-"1180:80"# 前面端口本地不冲突
-"11443:443"# 前面端口本地不冲突
-"34567:34567"# 前面端口本地不冲突
environment:
-TZ=Asia/Shanghai
volumes:
-./data/acme:/opt/om/acme# 冒号前面为acme子文件夹绝对路径
-./data/data:/opt/om/data# 冒号前面为data子文件夹绝对路径
-./data/nginx/conf/sites:/opt/om/nginx/conf/sites# 冒号前面为sites子文件夹绝对路径
-./data/nginx/conf/certs:/opt/om/nginx/conf/certs# 冒号前面为certs子文件夹绝对路径
-./data/nginx/conf/upstreams:/opt/om/nginx/conf/upstreams# 冒号前面为upstreams子文件夹绝对路径
以上代码需要根据我给出的中文注释自行修改,其它的可以默认不用管即可,网络不好的请自行换成第二个镜像。
🔺之后就能看到容器正常运行不报错了。因为现在是映射了NAS硬盘的绝对路径,所以后期迁移还是很方便的。(虽说之前的方案也可以迁移,但是对于我们非专业的NAS用户来说,个人觉得这种绝对路径迁移会更加方便)
🔺因为新的yml文件的配置路径发生改变,所以之前的配置已经没有了,我们进来之后还要重新配置一遍~。
关于证书申请问题
🔺还有个纰漏就有点小严重了~,我上个教程说OpenResty Manager不支持非80/443端口的泛域名证书申请,其实它是完美支持的。我们只需要在“新建证书”的时候选择“申请免费证书”,然后开启“DNS-01挑战”,再输入自己DDNS域名以及泛域名,最后选择域名服务商,输入服务商给到的对应ID与KEY就可以顺利的申请到支持自动续期的Let's Encrypt证书了,非常方便~
🔺申请速度还是挺快的,不到半分钟就成功了~。
其它就没啥可说的了,因为这个工具面世时间并不长,而作者也会一直更新和打磨的。顺便给各位小伙伴剧透下:OpenResty Manager下一版本将会支持主机管理和容器管理功能,有兴趣的可以持续关注哈!
最后谈谈我分享这款工具的初衷。
我其实在上一篇文中已经说了,我这篇文章的前提是我们已经正在使用极空间自带的DDNS功能,然后通过这款工具来弥补极 空间目前还没有的反向代理功能。也就是说,我的本意其实是将它当做一个纯粹的反向代理工具分享给大家。
不过评论区貌似有用户对此很是不屑,并说出一些轻蔑的话语,还说为什么不推荐Lucky,搞得我很是无语~
我的老粉应该知道,Lucky我早就分享过,并且在我之前的教程中都推荐过不下十次了。不仅如此,我和Lucky的作者**@古大羊**大佬在评论区也有过互动,并且人家Lucky官网还引用了我的分享文章,我怎么就没推荐了?
我无意引战,只是为了给大家多一个的选择,所以还请各位大佬们口下留情~。当然,如果大佬自己开发的也有这类工具,且认为比分享的这个工具还要好,我也可以为你免费宣传。
来源:小方科技论