群晖 DSM 使用 Nginx 提供 Web 和反代服务,虽然方便,但在功能上有许多限制。例如不能批量替换、不能片段复用。这倒还不算什么,难受的是,这内置的 Nginx 反应极其迟钝,修改配置等待重载生效的时间,都够我扒完一碗饭了。更别提配套的证书申请效率低下,即便换用 acme.sh 手动签发证书也十分麻烦(例如这篇、这篇)。总之对我来说并不好用。
我早就对群晖 DSM 的 Docker 和 Shell 深恶痛绝,这次该来整顿整顿这 Nginx 了。下面就让我来教大家如何自立门户,额外安装一个 Nginx,接管群晖的网络反代乃至整个 DSM 内部的网页功能。
你可以在 Nginx 和 Caddy 之间任选其一,挑一个你觉得方便的工具使用。
我推荐在 NAS 上使用 Caddy。在只是作为反代工具的前提下, 没有太多复杂的配置,就连 SSL 证书都可以直接搞定
⚠️ 请注意!
修改系统配置极度危险,若因误操作导致 NAS 宕机,本人概不负责!!
准备工作
以下操作均于搭载 DSM 7.2.1-69057 Update 3 的 DS220+ 中进行,Docker Compose 版本为 2.25.0。
解除端口占用
既然咱都另起炉灶了,那这内置 Nginx 占用的 443
和 80
端口就要先解除掉。
如果你不想执行这一步,可以在后续为自行安装的 Nginx 配置8443
和8080
端口。但本地内网访问还要敲端口我觉得超级麻烦,所以还是建议你先解除端口占用。
使用 root
用户登录 ssh,然后使用以下命令:
sed -i -e 's/80/8080/' -e 's/443/8444/' /usr/syno/share/nginx/server.mustache /usr/syno/share/nginx/DSM.mustache /usr/syno/share/nginx/WWWService.mustache
这一段命令的意思是,将 /usr/syno/share/nginx/server.mustache
、/usr/syno/share/nginx/DSM.mustache
、/usr/syno/share/nginx/WWWService.mustache
文件内的所有 80
替换成 8080
, 443
替换成 8443
。
再重启 Nginx,使修改生效:
synosystemctl restart nginx
如果是 DSM 6 系统,使用以下命令重启:
synoservicecfg --restart nginx
可以在「控制面板 - 网络 - DSM 设置」里随便改一个端口号保存再改回去,就会自动重启 WEB 服务。或者直接重启 NAS 也可以,但耗时较长。
实际使用中重启系统并不会导致配置被覆盖,但以防万一,你可以在「控制面板 - 任务计划」中新增一个「触发的任务」,用户账号选择 root
,事件选择「开机」,然后在「任务设置」内填入以下运行命令:
sed -i -e 's/80/8080/' -e 's/443/8444/' /usr/syno/share/nginx/server.mustache /usr/syno/share/nginx/DSM.mustache /usr/syno/share/nginx/WWWService.mustache
synosystemctl restart nginx
之后保存即可。
关闭 DSM 反代服务
如果你已经在使用内置的反代服务,那么请全部关闭。即删除「控制面板 - 登录门户 - 反向代理服务器」中的所有配置。
⚠️ 请注意!
如果你是正版群晖用户,请关闭 QuickConnect,否则后续无法使用自己安装的 Nginx 接管系统服务,如 Synology Photo、Synology Drive。
使用 Nginx
安装
安装时需要连接 GitHub,请自行解决连接问题,比如使用镜像服务(如 mirror.ghproxy.com)。
使用 Docker 安装 Nginx 和 acme.sh。这里用上我为了水博客容器化而准备的 dnmp:https://github.com/mikusaa/dnmp 。nginx 使用的是包含了 QUIC
、HTTP/3
、Google's brotli compression
的非官方的版本,具体信息可以参考官方文档。acme.sh 则是官方版本。
建议使用非 root 用户安装容器。
首先,登录 SSH,进入 docker 文件夹:
cd /volume1/docker
因为群晖中安装 Docker 需要先创建文件夹,所以咱直接克隆这个仓库,就不手动创建文件夹了:
git clone https://github.com/mikusaa/dnmp.git
如果没有安装 Git 套件,请参考《优化群晖 NAS 的 Shell 使用体验》中的相关步骤安装一下吧!
由于指定使用了名为 dnmp
的网络,所以咱需要先创建一个 docker 网络。当然,也可以修改为任意你想要的网络名称,只是别忘了同时修改后面的 compose 网络配置。
那么,就新建一个名为 nas 的网络吧!
docker network create -d bridge nas
再进入目录:
cd dnmp
复制一份配置文件:
cp docker-compose.yml.example docker-compose.yml
自行注释除 Nginx 和 acme.sh 以外的部分,因为 mysql 和 PHP 在 NAS 中你应该用不到,除非想在 NAS 里建站玩。或者,直接复制下面的内容替换上面的 docker-compose.yml 文件:
services:
acme.sh:
image: neilpang/acme.sh:latest
container_name: acme.sh
command: daemon
environment:
- DEPLOY_DOCKER_CONTAINER_LABEL=sh.acme.autoload.domain=dnmp
# - DEPLOY_DOCKER_CONTAINER_KEY_FILE=""
# - DEPLOY_DOCKER_CONTAINER_FULLCHAIN_FILE=""
- DEPLOY_DOCKER_CONTAINER_RELOAD_CMD=nginx -s reload
- TZ=Asia/Shanghai
volumes:
- ./acme.sh:/acme.sh
- /var/run/docker.sock:/var/run/docker.sock
restart: unless-stopped
networks:
- nas
nginx:
image: macbre/nginx-http3
container_name: nginx
user: root:root
ports:
- 80:80
- 443:443/tcp
# - 443:443/udp #若需使用quic,取消该端口的注释
volumes:
- ./nginx/conf.d:/etc/nginx/conf.d:ro
- ./nginx/nginx.conf:/etc/nginx/nginx.conf:rw
- ./nginx/ssl:/etc/nginx/ssl:rw
- ./nginx/rewrite:/etc/nginx/rewrite:ro
- ./nginx/logs:/home/wwwlogs:rw
- ./nginx/cache:/home/wwwcache:rw
- ./www:/home/wwwroot:rw
environment:
- TZ=Asia/Shanghai
labels:
- sh.acme.autoload.domain=dnmp
restart: unless-stopped
networks:
- nas
networks:
nas:
external: true
启动便可:
docker compose up -d
如果没有 Compose 或者不是最新版本导致报错,使用以下命令快速安装或更新:
DOCKER_CONFIG=${DOCKER_CONFIG:-$HOME/.docker}
mkdir -p $DOCKER_CONFIG/cli-plugins
COMPOSE_VERSION=$(curl -s https://api.github.com/repos/docker/compose/releases/latest | grep 'tag_name' | cut -d\" -f4)
sh -c "curl -L https://github.com/docker/compose/releases/download/${COMPOSE_VERSION}/docker-compose-`uname -s`-`uname -m` > $DOCKER_CONFIG/cli-plugins/docker-compose"
chmod +x $DOCKER_CONFIG/cli-plugins/docker-compose
检查版本:
docker compose version
输出 Docker Compose version v2.25.0
即可。
具体 Compose 的相关使用请参考《原来,群晖也能用 Docker Compose!》或自行搜索文档。
签发证书
后续操作都默认是在 acme.sh 的容器内部终端中执行,否则请自行在命令前加上 docker exec acme.sh
。或者在安装ohmyzsh 后使用 alias 别名,具体参考《优化群晖 NAS 的 Shell 使用体验》。
申请 SSL 证书
acme.sh 是一个用于签发证书的脚本。关于 ACME 协议 的相关知识,你可以自行查找资料。这里直接介绍 acme.sh 的使用方法。
启动容器后,进入 acme.sh 容器内部的终端 sh
:
docker exec -it acme.sh sh
这是一个前台化容器内部终端的指令,你可以直接在此键入命令。
初次申请,需要先创建 ZeroSSL 账户:
acme.sh --register-account -m i@example.com
如果网络不行连接不到 ZeroSSL 的话(具体表现为创建账户或是签发证书的时候卡在 API 连接上),在拥有代理的前提下可以为容器配置 HTTP_PROXY
。在 environment
环境变量中增加两行:
environment:
- TZ=Asia/Shanghai
- HTTP_PROXY=http://代理的IP:端口
- HTTPS_PROXY=http://代理的IP:端口
假设使用的是腾讯的 DNSPOD,在 DNSPOD 控制台创建好密钥后,导入:
export DP_Id="1234"
export DP_Key="sADDsdasdgdsf"
若是使用 CloudFlare 的 DNS,创建令牌后,导入 CF_Token
:
export CF_Token="Y_jpxxxxxxxxxx_qxxxxxxxxxxxxxxxxxxxxxxxxx"
如果是阿里云,前往控制台获取 RAM API key 后,将 AccessKey ID
和 AccessKey Secret
导入:
export Ali_Key="xxxxxxxx"
export Ali_Secret="xxxxxxxxx"
其他服务商的 DNS还请自行参考官方文档,这里不再赘述。
前期工作准备完毕,开始正式申请证书。提前准备好一个用于 NAS 使用的域名,根域也好子域也罢。例如这里我使用 example.com
申请证书,同时申请子域名 *.example.com
的泛域名证书:
acme.sh --issue -d example.com -d '*.example.com' --dns dns_cf
复制 SSL 证书
参考官方文档的步骤,将证书复制到 Nginx 的 ssl
目录中。
export DEPLOY_DOCKER_CONTAINER_KEY_FILE="/etc/nginx/ssl/example.com/example.com.key"
export DEPLOY_DOCKER_CONTAINER_FULLCHAIN_FILE="/etc/nginx/ssl/example.com/fullchain.cer"
acme.sh --deploy -d example.com --deploy-hook docker
在 nginx/ssl
目录下有看到证书文件,就说明证书已经成功复制到了 nginx 内了。
配置 Nginx
打开 nginx 文件夹,当前该文件夹下有如下文件:
nginx
├── cache
├── conf.d
│ └── default.conf
├── example
│ └── enable-ssl.conf
├── logs
├── nginx.conf
├── rewrite
├── ssl
│ ├── quic.conf
│ └── ssl.conf
└── temp
rewrite
、cache
文件夹应该都用不到,我们目前只动 ssl
和 conf.d
这两个文件夹下的东西。
强制使用 HTTPS
首先,修改 nginx/conf.d/default.conf
文件,取消 443
服务的注释,并将 example.com
修改为上面签发证书时用到的域名,例如:
server {
listen 80 reuseport default_server;
server_name _;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl reuseport default_server;
server_name _;
include ssl/ssl.conf;
ssl_certificate_key ssl/example.com/example.com.key;
ssl_certificate ssl/example.com/fullchain.cer;
ssl_reject_handshake on;
}
这段配置的意思是(GPT 说的):
这是一个 Nginx 的服务器配置。它包含两个
server
块,每个块定义了一个虚拟主机。这两个块的作用如下:
- 第一个
server
块监听 80 端口(HTTP),并将所有的请求重定向到 HTTPS(443 端口)。reuseport
参数允许多个套接字(即多个 Nginx worker 进程)在同一个 IP 地址和端口上进行监听,这可以提高性能。default_server
参数表示此服务器块将处理在任何其他服务器块中都没有匹配到的请求。server_name _;
表示匹配任何没有在其他 server 块中定义的服务器名。return 301 https://$host$request_uri;
表示发送一个 301 重定向到客户端,重定向的地址是 HTTPS 协议的当前主机和请求 URI。- 第二个
server
块监听 443 端口(HTTPS)。这个块的配置和第一个类似,但是它包含了 SSL 配置。ssl_certificate_key
和ssl_certificate
指向你的 SSL 证书的私钥和全链证书。ssl_reject_handshake on;
表示如果 SSL 握手失败,则拒绝连接。总的来说,这个配置的目的是强制所有 HTTP 连接升级到 HTTPS,以保证通信的安全。
重载 nginx,看看是否生效:
docker exec nginx nginx -s reload
如果生效,以前直接使用 ip 如 http://192.168.31.2/ 能自动重定向到 https://192.168.31.2:5000,现在应该不行了,并报错:
无法访问此网站网址为 https://192.168.31.2/ 的网页可能暂时无法连接,或者它已永久性地移动到了新网址。
ERR_SSL_UNRECOGNIZED_NAME_ALERT
说明配置生效,nginx 正常运行,继续下一步 SSL 的配置。
SSL 配置
进入 ssl
目录:
cd /volume1/docker/dnmp/nginx/ssl
这里我预创建了一个 ssl.conf
配置文件,里面包含了基础通用的 SSL 配置,包括启用 http2
,但还是需要手动创建俩文件,一个是 dhparam.pem
,一个是 ticket.key
。
使用 openssl 创建这两个文件:
openssl dhparam -out dhparam.pem 2048
openssl rand 80 > ticket.key
这样你就可以在配置域名的时候,直接使用 ssl
目录下的 ssl.conf
和 quic.conf
配置 HTTPS 以及 QUIC 部分了。
反向代理
最后,你就可以添加服务了,比如反代一个 emby。
首先,在 nginx/conf.d
文件夹内新建一个 emby.conf
文件,填入以下内容:
server {
listen 443 ssl; #监听443端口,使用ssl
server_name emby.example.com; #修改这里的域名
#引入ssl配置
include ssl/ssl.conf;
ssl_certificate_key ssl/example.com/example.com.key; #还有这里的域名
ssl_certificate ssl/example.com/fullchain.cer; #还有这里的域名
#反代处理
location / {
proxy_pass http://192.168.31.2:8096; #修改这里为你的emby地址
proxy_set_header X-Forwarded-For $remote_addr; #下面这些可以都不动
proxy_set_header Host $http_host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 86400;
}
access_log /home/wwwlogs/emby.log combined buffer=512k flush=1m;#日志文件
}
如果你已经将 emby 也加到了 nas 网络,这里给出一个详细配置:
services:
emby:
image: amilys/embyserver:beta
container_name: emby
# network_mode: host #如果原先为host模式,记得注释掉改为走nas网络
# ports: #如果想保留端口访问,取消这段和下面端口的注释
# - 8096:8096
environment:
- PUID=1026
- PGID=100
- TZ=Asia/Shanghai
devices:
- /dev/dri:/dev/dri
volumes:
- ./emby:/config
networks: #新增
- nas
networks: #新增
nas:
external: true
然后, 上面的反代部分的配置就可以相应修改为:
location / {
proxy_pass http://emby:8096; #修改这里为你的emby地址
也就是说,nginx 和 emby 在同一个网络里的话,可以使用 容器:端口
形式来反代,而不用知道具体 IP 地址!
具体原因可以看下面这段解释(GPT 说的):
在 Docker 中,当你创建了一个网络(默认或者自定义的),并且你的容器都连接到这个网络,这些容器就可以通过它们的容器名(或者别名)相互通信,无需知道各自的 IP 地址。这是因为 Docker 内部有一个内置的 DNS 服务器,当你尝试从一个容器访问另一个容器时,Docker 的 DNS 服务器会自动解析容器名到其对应的 IP 地址。
在你的例子中,
http://emby:8096
中的emby
应该是你的 Emby 容器的名字(或者别名)。当 Nginx 尝试代理请求到这个地址时,Docker 的 DNS 服务器会将emby
解析为 Emby 容器的 IP 地址,然后 Nginx 就可以将请求代理到这个 IP 地址的 8096 端口。这就是为什么你可以在
proxy_pass
指令中使用http://emby:8096;
,即使你的 Nginx 和 Emby 都是使用 Docker 部署的。只要它们都连接到同一个 Docker 网络,就可以使用容器名进行通信。
保存后,先测试配置是否有错误:
docker exec nginx nginx -t
输出:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
说明没问题,然后重载 nginx:
docker exec nginx nginx -s reload
如果没有报错,并输出类似以下内容的话:
2024/03/24 19:38:27 notice 1073#1073: signal process started
尝试访问这个地址,如果能打得开,就说明已经成功用自己安装的 Nginx 反代了 emby!!是不是很开心呢?😆
后续只要照着这个猫画其他老虎,就可以轻松反代 nas 内的项目和服务了!!
甚至,你可以反代和 nas 在同一个网络内的路由器!
假设你使用的是小米路由器,路由器地址为 http://192.168.31.1,那么可以这样反代:
server {
listen 443 ssl;
server_name router.example.com;
include ssl/ssl.conf;
ssl_certificate_key ssl/example.com/example.com.key;
ssl_certificate ssl/example.com/fullchain.cer;
location / {
proxy_pass http://192.168.31.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
access_log /home/wwwlogs/router.log combined buffer=512k flush=1m;
}
增加其他端口
但是现在只能在内网访问,如果你像我一样懒惰,想直接通过路由器转发 NAS 端口,然后用公网访问 NAS 服务的话,例如使用 8443
端口。那么,就在 server
段内增加一段监听端口:
server {
listen 443 ssl;
listen 8443 ssl; #新增8443端口
server_name emby.example.com; #修改这里的域名
#后续不用改,省略……
然后,在 compose 配置中增加一段端口映射:
nginx:
image: macbre/nginx-http3
container_name: nginx
user: root:root
ports:
- 80:80
- 8443:8443/tcp #新增
# - 8443:8443/ucp #若需使用quic,取消该端口的注释
- 443:443/tcp
# - 443:443/udp #若需使用quic,取消该端口的注释
使用 docker compose up -d
重启容器时映射生效。
你就会发现,你已经可以使用 https://emby.example.com:8443 访问你的 emby 了!!
使用 Caddy
后来,C佬 教会了我如何使用 Caddy 接管反代服务,不仅部署较 Nginx 简单,配置还十分方便,我也就在换用 PVE 的时候改用 Caddy 了。
另水一文不太现实,就一并写在这里吧!
这里使用的是 C佬 配置的 Xm798/docker-caddy,内置比较流行的 cloudflare、dnspod、alidns 三家 DNS 提供商,简单配置开箱即用。你也可以参考 C佬写的 文档 进一步配置 Caddy。
安装
首先,登录 SSH,进入 docker 文件夹:
cd /volume1/docker
克隆仓库:
git clone https://github.com/Xm798/docker-caddy.git
文件结构如下:
docker-caddy
├── Caddyfiles
│ └── Caddyfile
├── docker-compose.yml
├── Dockerfile
├── README.md
└── README_ZH.md
我们需要适当修改原 docker-compose.yml 配置才可使用:
services:
caddy:
container_name: caddy
# image: xm798/caddy:latest
image: registry.cn-shanghai.aliyuncs.com/xm798/caddy:latest
user: 1026:100
dns:
- 8.8.8.8
- 1.1.1.1
- 1.0.0.1
- 223.5.5.5
- 119.29.29.29
networks:
- caddy_default
ports:
- "80:80"
- "443:443"
volumes:
- ./Caddyfiles:/etc/caddy
- ./data:/data
- ./config:/config
- ./log:/log
- ./srv:/srv
restart: always
networks:
caddy_default:
external: true
较原文件有两处改动:
- 取消
user
注释,并将其改为 DSM 默认用户的1026:100
- 取消国内加速镜像的注释,并注释掉 dockerhub 源
配置中使用到了名为 caddy_default
的网络,需要在启动容器前手动创建:
docker network create -d bridge caddy_default
另外,还要创建挂载用到的文件夹:
mkdir data config log srv
这样才可以使用 docker compose up -d
启动 Caddy。
配置
这里只是简单演示,更具体的操作还请参考官方文档。
配置 Caddy 没有 Nginx 那么繁琐,也不用另行配置 acme。只要先写好全局配置,后续就可以一劳永逸。
首先,编辑 Caddyfiles 目录下 Caddyfile 文件,在头部的全局配置段中添加你正在使用的 DNS 提供商的信息,方便后续自动申请 SSL 证书。
{
http_port 80
https_port 443
## 修改下面这两处
# email YOUR_EMAIL
# acme_dns cloudflare "YOUR_CLOUDFLARE_TOKEN"
}
Cloudflare:
email user@example.com
acme_dns cloudflare "YOUR_CLOUDFLARE_TOKEN"
阿里 DNS:
email user@example.com
acme_dns alidns {
access_key_id "YOUR_KEY"
access_key_secret "YOUR_ID"
}
DNSPOD:
email user@example.com
acme_dns dnspod "APP_ID,APP_TOKEN"
DNS 配置完成后,就可以编写反代配置了。
在 Caddyfiles 文件夹中新建一个以 .Caddyfile
结尾的文件,例如 emby.Caddyfile
,启动一个反代服务。
当然也可以在 Caddyfile 中直接添加,但分文件更便于管理。
例如反代 emby,并启用日志:
emby.example.com, emby.example.com:8443 {
import log emby #启用日志,名为 emby
reverse_proxy http://emby:8096
}
在域名后加端口即可启动一个指定端口的反代服务,但需要注意在 compose.yml 配置中映射该端口。
或者反代后端是 HTTPS 的服务,比如 DSM 的 5001
端口:
https.example.com {
reverse_proxy https://dsm:5001
}
以下配置段可以启动一个后端是 HTTPS 的代理,并且忽略证书验证,这对一些不受信任的自签证书很有效。
https.example.com {
reverse_proxy {
to https://10.0.0.10:443
transport http {
tls
tls_insecure_skip_verify
}
}
}
修改 Caddyfile 后,可以使用以下命令来重载配置:
docker exec -w /etc/caddy caddy sh -c "caddy fmt --overwrite && caddy reload"
重载配置之后,等待证书申请成功,就可以访问你的服务了。
你可以使用如下命令实时查看 caddy 的运行状况:
docker logs caddy
Caddy 的其他操作,需要参考官方文档。
总结
现在,你应该明白如何干掉 DSM 内置的 Nginx 了吧?快行动起来,自由地反代任何服务,无论是使用 Nginx 还是 Caddy!!
参考
- Free 80,443 Ports On Synology NAS (DSM)
- 群晖解除默认的 80/443 端口占用
- Debian Server 初始化设置 SOP
- Xm798/docker-caddy
- Caddy 文档:https://caddyserver.com/docs/
- Caddy 文档(第三方):https://caddy2.dengxiaolong.com/docs/
本文作者:mikusa
本文链接:https://www.himiku.com/archives/use-your-own-nginx-in-synology-nas.html
版权声明:所有文章除特别声明外均系本人自主创作,转载及引用请联系作者,并注明出处(作者、原文链接等)。
群晖本身的nginx版本不低,重启慢是群晖会去生成nginx模板再重启
修改/usr/syno/share/nginx/nginx.mustache配置,添加cond.d路径后
可以自由添加需要的nginx配置
很好奇使用 HTTP/3 的效果如何?我看国内运营商不太喜欢 UDP 流量,很好奇家宽映射出去会不会被封 UDP 端口?
效果很差。博客测试过一段时间,有人遇到图片打不开的情况。
所以最后还是关掉了 (⌐■_■)
我发现群晖的 web station 可以直接反代 docker 镜像 expose 的端口,这样就可以不用额外开一个反代的容器了,但是有一个 bug 就是如果群晖是先启动的 ws 再启动 docker 可能会出现 ws 找不到容器的 bug,可能需要在计划任务中设置一下重新启动 ws 的命令。不知道用 ws 反代容器能不能让容器获取到用户的真实 ip,不知道博主有没有兴趣测试一下
web station?我早就干掉了。能docker就全docker,何乐而不为呢?
那在 docker 配置反向代理吗,如果反向代理的容器用 host 模式那想访问后端的容器就得先将后端的端口映射到宿主机(如果容器默认的端口有重复那就得映射到宿主机另外的端口)不仅不好记,而且因为这些端口不会直接访问,还会显得很“乱”
如果反代的容器用 bridge 模式,访问上级程序就可以直接用容器名,这个很方便,但是上级获取到的访问者地址就成了 docker 的 gateway 并不是真实 ip,就是这个真实 ip 一直困扰着我
刚刚试了一下,web station 反代后获取到的也是 docker 的 gateway,人都麻了
别管这真实ip了,这是dsm系统层面的问题,出发群晖自己修好。
总之,如果host模式那就nas ip+端口,如果不是那就把nginx加到同一个bridge网络里用容器名+端口自动寻址,连端口都不用映射出来,就不会有端口重复的烦恼了。
看你应该不是白群吧?直接换成pve,安装虚拟机的dsm,再整个debian专门跑docker。这样既解决了realip 的问题,也解决了dsm docker一坨的问题。(虽然我没试过但群里大佬是这么做的,我也想这么做试试,我真是受够了dsm 的docker了
要不要是因为群晖的 cloudsync 也不会用群晖,没办法,这个算是硬需求,需要一个支持双向/单向同步的软件
小主机本身就只有 4 核,搞个 pve 怕是有点负担不起,而且我就两块硬盘,一块 机械,一块 m.2,如果搞 pve 的话 m.2 就要分给 pve 了,机械直通给群晖,感觉结构也不是特别合理
那就无视realip吧,没有办法的事 ╮(╯▽╰)╭
那一般debian系统怎么配置能获得realip,nginx和上游程序都放在docker网桥就可以吗
直接就行,proxy里加个 X-Real-IP 配置就行的样子
问几个关于docker的问题,也是在群晖的 docker 中遇到的
1.我的容器只连接自己创建的docker网络会连不上互联网,必须要额外加入默认的bridge网络才能连上互联网(之前是单加入自建的docker网络就能连接互联网,后面突然不行了,中间的操作也没怎么乱搞,就是创建了几个docker网络后面删除了,反正回过头来就已经连不上互联网了)
2.我所有的服务都通过docker网络进行相互访问,只留了一个nginx映射到物理机给用户访问,但是后端的app检测到无论是局域网的用户还是来自外网的用户显示的ip都是docker网络Gateway的局域网ip地址,这个有没有解决方法,让后端服务正确识别到用户的ip
名字打错了……麻了
第一个问题我是按文中那样创建了个名为nas 的bridge网络,把所有不用host的应用一股脑塞了进去,所以就没遇到过没有网络的问题。
第二个问题,我也是这样,应该是nginx不用host的话,就读取不到真实ip,这是群晖自己的问题。可以用 synology nginx realip 关键词谷歌搜一下,我有找到过一个解决方法,但效果不佳,能用一会儿之后就又不行了。这个地址我回头翻一下历史记录看看。
综上,可以的话用pve装多个虚拟机,群晖只负责存储,docker让debian来,用群晖只会让人痛苦😖
一开始我也是全扔进了 自己新建的 docker 网桥……但后面删了网桥又重新创建回来了(想给网桥配置 ipv6,但是失败了,一开始我以为 nginx 代理后获取不到真实 ip 是因为我是 v6 访问nginx 然后转发到后端服务上的导致获取不到真实地址)然后重新创建 docker网络后就发现docker 网络没办法连接互联网了……需要再加入 bridge 才行……
我是用 macvlan 配的 ipv6,参考这篇:https://blog.xm.mk/posts/73f9/
如果还是没网的话,不如卸了docker重装看看,反正数据都在compose重新部署很快
我用的不是 docker compose,确实是时候考虑 迁移到 docker compose 了,不过知道了真实 ip 不是因为 ipv6 的问题的话那我也不打算弄那个 macvlan 了
另外我在 Google 上搜索到了群晖realip 的一些解决方案,似乎是因为防火墙 iptable 引起了,按照给的命令但实际上没有效果,不知道是不是群晖 7.2 修改了?毕竟是四年前的解决方案
最近更新频率好高啊。
我之前也想改掉自带的来着,局限性有点大。这篇教程真及时呀 (◍•ᴗ•◍)❤
已经榨干了,一滴都不剩了 (⌐■_■)