使用 Nginx Proxy Manager 管理多个 Discourse 站点

编辑:@pfaffman@tophee 之前撰写的内容重写为一个独立主题。我尚未对此进行测试,并且调整了 Chris 的措辞,因此任何错误很可能归因于 @pfaffman

是否有理由不使用 NGINX Proxy Manager,而是按照 Run other websites on the same machine as Discourse 中的描述手动操作?

我已经在使用了。我在家庭服务器上运行它已经有一段时间了。当我将 Discourse 实例迁移到新的云服务器时,我意识到自己已经忘记了四年前在旧服务器上设置的 NGINX 反向代理的大部分细节,于是我想:为什么不使用 NGINX Proxy Manager 呢?令我惊讶的是,我发现它在 Meta 论坛上被提及的次数非常少,因此我开始怀疑是否有什么缺点是我可能遗漏的……

确实,这需要一些试错,但我按以下方式使其正常工作(不保证这是最佳方法——事实上,我知道肯定有更好的方法——所以非常欢迎纠正和改进):

首先,访问您的 Discourse 实例有两种方式:1. 通过暴露端口,2. 通过 WebSocket。我相信我在这个论坛的某个地方了解到 WebSocket 更快/更高效,所以我使用的是 WebSocket,但暴露端口应该容易得多,所以如果您无法让 WebSocket 正常工作,请尝试暴露端口。因此,为了避免混淆:要通过端口访问 Discourse,请遵循下面的步骤 0、1、2、3、4 和 8。如果您想使用 WebSocket,请遵循步骤 0、1、5、6、7、8 和 9。

0. 起点

因此,假设您已经完成了 30 分钟标准安装,并且假设您尚未让 Discourse 获取 Let’s Encrypt 证书——因为在使用反向代理时不需要它。NGINX Proxy Manager 会处理此事。不过,如果您已经有了证书也没关系。NGINX Proxy Manager 会简单地获取一个新证书。

1. 安装 NGINX Proxy Manager

下一步是安装 NGINX Proxy Manager,这样您就会多运行两个 Docker 容器(NGINX Proxy Manager 及其数据库容器)。

接下来是您询问的棘手部分。

第一个障碍是 Discourse 运行在默认的 Docker bridge 网络上,而 NGINX Proxy Manager 默认运行在默认的“用户创建网络”上(在我的情况下称为 npm_default),这意味着 NGINX Proxy Manager 无法看到 Discourse。:cry:

2. 将所有容器移至默认 bridge 网络

因此,只要 我不知道 Discourse 是否可以移动到自定义网络以及如何进行,我们就必须将 NGINX Proxy Manager 移动到默认的 bridge 网络。我们可以通过在 Docker Compose 文件 中的两个 NGINX Proxy Manager 容器添加 network_mode: bridge 来实现这一点。

3. 使用 IP 地址而不是服务名称

接下来的问题是,如果您只是将其移动到 bridge 网络,标准的 Docker Compose 文件将不再起作用。NGINX Proxy Manager 将无法再找到其数据库容器。这是因为服务名称的内部 DNS 解析(Docker Compose 文件依赖于此)仅在用户创建的网络上可用,而在默认 Docker 网络上不可用。因此,我们不得不使用硬编码的 IP 地址(这就是为什么这绝对不是最佳解决方案,因为如果您的容器 IP 发生变化,它将失效)。所以您需要启动容器,即使您知道它无法工作,记下 NGINX Proxy Manager 数据库容器的 IP,并将 Docker Compose 文件中的 DB_MYSQL_HOST: "db" 替换为 DB_MYSQL_HOST: "<db_container_IP>"

现在所有容器都应该在默认的 bridge 网络上,以便 NGINX Proxy Manager 能够看到 Discourse 及其数据库。

4. 使 Discourse 可访问

但是,“看到”Discourse 和能够访问它并不是一回事。因此,您需要确保 Discourse 会接受 NGINX Proxy Manager 转发给它的任何流量。如果您不在乎使用 WebSocket,我想您可以直接将 NGINX Proxy Manager 指向 Discourse 容器 IP 的 80 端口(而不是 443 端口),如下所示:

不过我还没有测试过这一点。正如我所提到的,我使用的是 WebSocket 设置,这需要一些额外的步骤。请注意,当您使用 WebSocket 时,上述主机名/IP 和端口将被忽略。

5. 配置 app.yml 以使用 WebSocket

这已在 原始帖子 中解释,因此我不再赘述。

6. 在 NGINX Proxy Manager 容器中挂载 WebSocket

我们需要通过将其挂载为卷来让 NGINX Proxy Manager 访问 WebSocket:- /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock。这是对默认 NGINX Proxy Manager Docker Compose 文件的最终更改,因此以下是对我有效的最终版本:

version: '3'
services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    network_mode: bridge
    ports:
      - '80:80'
      - '81:81'
      - '443:443'
    environment:
      DB_MYSQL_HOST: "172.17.0.6"
      DB_MYSQL_PORT: 3306
      DB_MYSQL_USER: "npm"
      DB_MYSQL_PASSWORD: "my-super-safe-pwd"
      DB_MYSQL_NAME: "npm"
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
      - /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock
  db:
    image: 'jc21/mariadb-aria:latest'
    restart: unless-stopped
    network_mode: bridge
    environment:
      MYSQL_ROOT_PASSWORD: 'my-super-safe-pwd'
      MYSQL_DATABASE: 'npm'
      MYSQL_USER: 'npm'
      MYSQL_PASSWORD: 'my-super-safe-pwd'
    volumes:
      - ./data/mysql:/var/lib/mysql

7. 配置 NGINX Proxy Manager 以使用 WebSocket

最后一步:告诉 NGINX Proxy Manager 使用 WebSocket。据我回忆,仅开启“WebSocket 支持”是不够的,因此我将 原始帖子中的 NGINX 位置 复制到了“高级”选项卡中,如下所示:

我在“自定义位置”选项卡下无法使其工作。

8. 不要忘记激活 SSL

我没有在 NGINX Proxy Manager 中提及 SSL 配置,因为它看起来非常显而易见,而且我认为在过程中的哪个点激活它并不重要。所以如果您还没有这样做,我的配置如下所示:


9. 注意事项

tl;dr 每当您重启 Discourse 容器时,您也需要重启主 NGINX Proxy Manager 容器(无需重启数据库)。
如果您通过 WebSocket 访问 Discourse,需要注意,当您重建 Discourse 容器时(为了更新基础镜像,每几个月就需要这样做一次),之前的 WebSocket 将被删除并创建一个新的。因此,NGINX Proxy Manager 将失去与 Discourse 实例的联系并抛出 502 错误。也许未来的 NGINX Proxy Manager 更新能够自动找到新的 WebSocket,但目前(2022 年 1 月),除非您重启 NGINX Proxy Manager,否则它无法找到您重建的 Discourse 容器。

解释

如果您想知道为什么上述说明将 WebSocket 与端口结合起来,简单的原因是我在撰写此帖子时突然想到,当我们使用 WebSocket 时,NGINX Proxy Manager 和 Discourse 甚至可能不需要在同一个 Docker 网络上。当这一点得到确认后,没有人觉得有必要完全重写说明。

这是支持论坛最迷人的方面之一:很好地描述您的问题往往会引导您找到解决方案,甚至无需发布您的问题。在这种情况下,我正在回答别人的问题,但也可能找到了自己问题的答案。:smiley:

9 个赞

讨论应该使用哪种反向代理显然超出了支持范围。:wink: 但在查看 NGINX Proxy Manager 大约 12 秒或更久之后,我认为它应该能胜任。我之前也见过讨论另一个自动化的 NGINX 代理工具,但凭借我对 NGINX Proxy Manager 的“渊博”知识,我认为它可能更好。我可能会去看看它,因为我正逐渐对 Traefik 感到失望。

编辑:现在我已经看了它 3 分钟。我更喜欢能促进自动化的工具,因此 Traefik 和 https://hub.docker.com/r/jwilder/nginx-proxy(我找到的)更符合我的需求,它们允许你向 Docker 容器添加一些标签或环境变量,从而无需在 Web 界面中点击。看起来要让那个工具工作,你必须使用 Web 界面,或者想办法手动更新数据库以添加要添加的主机。但如果你愿意像个“普通人”(而不是系统管理员“人士”)那样在 Web 界面上点击和折腾,那么那个工具看起来可能正是你所寻找的。

4 个赞

我尝试安装了 Nginx Proxy Manager,但我不明白如何“链接”(代理?抱歉,我对系统管理还比较生疏)Discourse 容器,以便通过 Web 访问时能看到 Discourse。
能否提供一些提示?Discourse 容器是否需要暴露 80 和 443 端口,就像这个论坛主题所建议的那样?

1 个赞

确实,这需要一些试错,但我按如下方式使其生效(不保证这是最佳方法——事实上,我知道肯定有更好的方法——所以非常欢迎更正和改进):

pfaffman 移至 OP 的说明

首先,有两种方式可以访问您的 Discourse 实例:1. 暴露端口,2. 通过 WebSocket。我相信我在这个论坛上某处学到过,WebSocket 更快/更高效,所以我正在使用它,但暴露端口应该要容易得多,所以如果您无法让 WebSocket 工作,请尝试暴露端口(下面会详细介绍)。

因此,假设您已经完成了 30 分钟标准安装,并且假设您尚未让 Discourse 获取 Let’s Encrypt 证书——因为在使用反向代理时您不需要它。NPM 会处理此事。不过,如果您已经有了证书也没关系。NPM 只需获取一个新的证书即可。

1. 安装 NPM

下一步是安装 NPM,这样您就会多运行两个 Docker 容器(NPM 及其数据库容器)。

接下来就是您询问的棘手部分。

第一个障碍是 Discourse 运行在默认的 Docker bridge 网络上,而 NPM 默认运行在默认的“用户创建的网络”上(在我的例子中称为 npm_default),这意味着 NPM 无法看到 Discourse。:cry:

2. 将所有容器带入默认的 bridge 网络

因此,只要 我不知道 Discourse 是否可以移动到自定义网络,我们就必须将 NPM 移动到默认的 bridge 网络。我们可以通过在 Docker Compose 文件 中的两个 NPM 容器添加 network_mode: bridge 来实现这一点。

3. 使用 IP 地址而不是服务名称

下一个问题是,如果您只是将其移动到 bridge 网络,标准的 Docker Compose 文件将不再起作用。NPM 将无法再找到其数据库容器。这是因为服务名称的内部 DNS 解析(Docker Compose 文件依赖于此)仅在用户创建的网络上可用,而在默认 Docker 网络上不可用。因此,我们不得不使用硬编码的 IP 地址(这就是为什么这绝对不是最佳解决方案,因为如果您的容器 IP 发生变化,它就会失效)。因此,您需要启动容器,即使您知道它无法工作,记下 NPM 数据库容器的 IP,并在您的 Docker Compose 文件中将 DB_MYSQL_HOST: "db" 替换为 DB_MYSQL_HOST: "<db_container_IP>"

现在,所有容器都应该位于默认的 bridge 网络上,以便 NPM 可以看到 Discourse 及其数据库。

4. 使 Discourse 可访问

但是,“看到”Discourse 和能够访问它并不是一回事。因此,您需要确保 Discourse 会接受 NPM 转发给它的任何流量。如果您不在乎使用 WebSocket,我想您可以直接将 NPM 指向 Discourse 容器 IP 的 80 端口(而不是 443 端口),如下所示:

不过我还没有测试过这个。正如我所提到的,我使用的是 WebSocket 设置,这需要一些额外的步骤。请注意,当您使用 WebSocket 时,上述主机名/IP 和端口将被忽略。

5. 配置 app.yml 以使用 WebSocket

这在 OP 中有所解释,所以我不再赘述。

6. 在 NPM 容器中挂载 WebSocket

我们需要通过将其挂载为卷来让 NPM 访问 WebSocket:- /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock。这是对默认 NPM Docker Compose 文件的最终更改,因此以下是适用于我的最终版本:

version: '3'
services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    network_mode: bridge
    ports:
      - '80:80'
      - '81:81'
      - '443:443'
    environment:
      DB_MYSQL_HOST: "172.17.0.6"
      DB_MYSQL_PORT: 3306
      DB_MYSQL_USER: "npm"
      DB_MYSQL_PASSWORD: "my-super-safe-pwd"
      DB_MYSQL_NAME: "npm"
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
      - /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock
  db:
    image: 'jc21/mariadb-aria:latest'
    restart: unless-stopped
    network_mode: bridge
    environment:
      MYSQL_ROOT_PASSWORD: 'my-super-safe-pwd'
      MYSQL_DATABASE: 'npm'
      MYSQL_USER: 'npm'
      MYSQL_PASSWORD: 'my-super-safe-pwd'
    volumes:
      - ./data/mysql:/var/lib/mysql

7. 配置 NPM 以使用 WebSocket

最后一步:告诉 NPM 使用 WebSocket。据我回忆,仅仅开启“WebSocket 支持”是不够的,所以我从 OP 中的 NGINX 位置 复制到了“高级”选项卡,如下所示:

我在“自定义位置”选项卡下未能使其工作。

8. 别忘了激活 SSL

我没有在 NPM 中提到 SSL 配置,因为这似乎显而易见,而且我不认为在过程的哪个阶段激活它很重要。所以如果您还没有这样做,我的配置如下所示:


9. 最终免责声明

在我写这篇文章时,我突然想到,当我们使用 WebSocket 时,NPM 和 Discourse 甚至可能不需要在同一个 Docker 网络上。我现在没有时间检查这一点,但如果这是真的,那么您可以直接忘记上面的第 2、3 和 4 步,它应该就能工作。

支持论坛最迷人的方面在于:很好地描述您的问题往往会引导您找到解决方案,甚至无需发布您的问题。在这种情况下,我正在回答别人的问题,但也可能找到了自己问题的答案。:smiley:

4 个赞

非常感谢您提供详尽而精彩的回答!我会尽快尝试您的建议。顺便问一下,NPM 中要填写的 IP 是服务器的 IP(即访问服务器的外部 IP),还是 Docker 内部的 IP(我注意到 Docker 为容器使用的是 172… 这类地址)?
抱歉如果我的问题显得太基础,我对网络相关事项还不太熟悉。

1 个赞

我建议您使用 WebSocket。这样,您可以随意填写 IP,因为它不会被使用。否则,应填写容器的内部 IP,而不是主机的公网 IP。

顺便一提:看起来您的“通过邮件回复”未被正确渲染。或许您想编辑(缩短)上面的帖子?

2 个赞

是的,我看到了。我使用了邮件中的“回复”功能,它试图包含所有原始消息,但我找不到修改它的方法。这可能吗?即使是作为用户,我也是 Discourse 的新手……:pensive:

1 个赞

您可以使用消息底部的铅笔图标编辑您的帖子。不过……信任等级 1 及以下用户默认只有 24 小时的编辑时间,而信任等级 2 及以上用户默认有 30 天。

看来您目前处于 TL1 基础等级,但您可以了解如何“升级”的更多信息,请访问 信任等级:+1:

2 个赞

抱歉,距离上次提问已经过了相当长的时间,但我按照您的建议尝试了很长时间,却毫无进展。

当我修改了 app.yml 并根据您的更改重新构建应用后,日志中开始显示 “config/unicorn_launcher: line 71: kill: (898) - No such process”。无论我如何尝试,都无法阻止这种行为。我还尝试将应用还原到原始状态(暴露端口、不使用 websocket),并停止 npm,但依然无济于事,“unicorn” 根本没有运行。

我也尝试了谷歌上关于此问题的所有搜索结果(这似乎是一个普遍存在的问题),但无论如何都无法弄清楚如何重新构建一个正常运行的 Discourse 容器。目前的问题是(这也是最让我头疼的问题之一,我几乎要对 Discourse 放弃希望了):由于某种不明且混乱的原因,内部的 PostgreSQL 数据库总是在“重启”。

我不知道为什么会这样。我只是按照您的建议进行了修改并重新构建了应用,从那以后,“unicorn” 就彻底挂了。

有什么办法可以修复这个 PostgreSQL 的问题吗?为什么会发生这种情况?还有可能(我担心完全不可能!)保留我在 Discourse 正常运行时所做的所有更改吗?

顺便问一下,每次进行微小的更改或尝试修复某些问题时,是否都会导致其他东西无法工作?这是正常的吗?

我并不是在生气,问题全出在 Discourse 上,而不是您的建议:我花费了大量时间试图让这个“看似”不错的论坛正常运行,但每次都会出现新的问题。这让我越来越觉得 Discourse 的可靠性非常低。

1 个赞

如果您之前安装的是标准版本,您应该能够将系统恢复至该状态,并确保所有功能正常运行。

Postgres 问题可能与 PostgreSQL 13 更新有关?

如果您在开始操作之前已创建备份,可以在新服务器上安装并恢复该备份。这应是最坏情况下的解决方案。

2 个赞

如何判断 PostgreSQL 问题是否与 13 版本更新有关?我并未主动选择更新,只是输入了“./launcher rebuild app”,随后便发生了各种状况。
是的,当前版本是 13。经过数小时在互联网上查阅其他遇到相同问题的人的讨论后,我发现这可能是问题所在,但我尚未找到让 Discourse 恢复运行的方法。

1 个赞

那么这就不是问题了。抱歉。

1 个赞

很抱歉听到您遇到了这些麻烦。我理解那种花费数小时试图修复某件事却无果的沮丧感。但每次您都能学到一些东西,即使通往解决方案的道路很少是笔直的……

很抱歉,我不是能帮助您解决这个问题的合适人选。我没有 postgres 或 unicorn 的使用经验。在遇到这种“什么都不管用”的情况时,我通常通过以下三种方式度过难关:1. 做好备份,以便随时可以恢复到原始状态。2. 每次只尝试或更改一件事,并先在非生产环境(或不太重要的论坛)上测试。3. 投入更多时间试图搞清楚问题所在。

顺便提一下:多次撰写详细的问题描述或支持工单帮助我解决了问题。我甚至不需要提交工单,只是写下来就让我看到了解决方案。

所以在您的情况下,我会尝试理解的是:在什么情况下,修改 app.yml 然后再将其改回原始状态,会导致与原始结果不同的结果?在研究这个问题时,您要么会意识到自己实际上并没有完全恢复原始状态,要么会明白还需要“重置”哪些其他内容才能使其正常工作。

5 个赞

非常抱歉,但我确实不明白:首先你问我 PostgreSQL 问题是否与 PostgreSQL 13 更新有关,当我回答“是的,是 13 版本”时(我发誓我不知道之前的版本,因为很久没有重建应用了),你却回答说这不是问题……那么,为什么 PostgreSQL 总是处于“启动中”状态,而 Discourse 却无法正常运行?

1 个赞

@Wanderer。我无法确定您具体遇到了什么问题,因此关于 PostgreSQL 升级的推测纯属猜测。我相当确定,如果您正在运行 PostgreSQL 13,那么问题并非出在您无法从版本 10 或 12 升级。因此,虽然 PostgreSQL 本身可能存在某些问题,但这很可能与升级到 PostgreSQL 13 无关。

对于非专业人士,我最推荐的方案是执行全新安装,并恢复您最近的备份。

如果您希望针对您的具体问题获得更详细的帮助,并且有相关预算,您可以联系我或在 Marketplace 频道发帖。

我计划着手改进 Nginx Proxy Manager 的操作指南,但我猜测,您的问题虽然是在尝试迁移到这种复杂配置时暴露出来的,但很可能并非由于这些指南存在缺陷所致。(我不确定,但这只是我的最佳推测。)

2 个赞

这是我自己的版本。我差点放弃,但 @tophee 链接到我(!?)写的一篇帖子,提供了必要的“魔法”!现在,配置 Nginx Proxy Manager 以支持 Discourse 变得非常简单。我认为这使其与 Run other websites on the same machine as Discourse - #396 类似。

按照其说明安装 Nginx Proxy Manager

移除 SSL 和 Let’s Encrypt 模板:

确保您的 yml 文件中的以下行已被注释掉或删除:

## 如果您想添加 Lets Encrypt (https),请取消注释这两行
#- "templates/web.ssl.template.yml"
#- "templates/web.letsencrypt.ssl.template.yml"

让 Discourse 使用 npm-default 网络。

如果您盲目遵循 Nginx Proxy Manager 的安装说明,它将创建一个名为 npm_default 的 Docker 网络。

将以下段落添加到您的 yml 文件(或多个文件)中。如果您有独立的 web_onlydata 容器,则需要将此项添加到每个容器中(我未测试 mail-receiver 容器)。docker_args 不需要缩进。

docker_args: |
  --network npm_default

无需暴露任何端口

从您的 yml 文件中注释掉或删除以下行:

# expose:
#  - "80:80"   # http
#  - "443:443" # https

然后您可以重新构建您的容器,并按如下方式配置 Nginx Proxy Manager:

image

启动第二个 Discourse 站点的一种简单(但不一定推荐)的方法如下:

cd /var/discourse/containers
cp app.yml othersite.yml
# 以某种方式编辑 othersite.yml 中的主机名(至少)
./launcher rebuild othersite

然后像上面一样将其添加到 NPM,但使用 othersite 代替 app

我在一个 app.yml 加上两个 web_only 类型容器和一个单独的 data 容器以及一个单独的 othersite-redis 容器上测试了此方法,该容器是仅包含 redis 模板的 data 容器的副本。(但更简单的解决方案是将额外的 redis 放入 web_only 容器中)。

2 个赞

经过一番努力,我终于让所有东西都运行起来了。

首先说明一下:虽然我是一位“老一代”开发者(出生于 1980 年代),但我一直追求最佳和最新的发展或管理方式。因此,在 2021 年,我实在讨厌编写那些充满晦涩选项的奇怪命令,就像旧时代的 CP/M 和 DOS 那样。我总是寻找能让我的生活更轻松、更清晰的界面。

因此,我使用例如 Portainer 来管理容器。它允许我随时启动、停止、编辑或复制所有容器,而无需在文件系统中“上下折腾”去寻找那“百万分之一”的文件。例如,要更改容器网络,只需从列表中选择并点击一下即可;添加参数或卷(如 @tophee 示例中所示)也是如此。出于这个原因,我尝试了 NPM,因为我更喜欢将我的 Nginx 代理“容器化”,而且据说只需点击几下,在充分理解自己在做什么的同时,也无需记住一套新的奇怪命令和选项。

回到我的 Discourse 容器,我不得不重新运行"discourse-setup"。一切顺利,“邪恶”的 Postgres 已安装为版本 13,没有出现“醉醺醺的独角兽”(抱歉,但想到“独角兽”在我的服务器上运行就让我忍不住发笑!:laughing:)。总之,一切进展顺利。然后,我进行了修改以使 Discourse 支持 WebSocket:这次也一切正常。幸运的是,之前的 Discourse 设置已自动备份,因此只需点击几下,我就恢复了所有内容(我使用 Discourse 越多,就越喜欢它!)。

我多次尝试 NPM 的配置,起初在证书方面遇到了一些问题,但最终也运行良好。

我还添加了第二个代理,指向我的 WordPress 容器(是的,我“容器化”了所有内容,我喜欢拥有一个更干净的服务器,所有主要包都托管在一个受管理的地方的想法),它也运行良好。

最终,我的服务器(一台 VPS)上运行着邮件服务器(我也曾尝试将其“容器化”,但经过数周的激烈斗争后放弃了),Discourse 指向它,WordPress 在另一个容器中运行,而 NPM 管理着两者:所有这些都运行在我的服务器上,无需依赖其他(且昂贵得多)的服务来进行部署、邮件发送等。

下一步,从“老而好的 Phpbb"导入数十万篇帖子:准备好迎接我的更多帖子吧!:grinning_face_with_smiling_eyes:

非常感谢 @tophee@pfaffman 的帮助。我能理解,当人们像我这样以非标准方式工作时,提供帮助是多么困难。

3 个赞

很高兴您能成功使用 Websocket 实现功能。对于其他在此问题上遇到困难的人,请采用 @pfaffman不使用 websocket 的操作指南

我不清楚导致您问题的具体原因,但这似乎是一个需要向 Discourse 管理新手澄清的点:您需要理解在默认安装(无外部代理)中 Let’s Encrypt 证书的工作原理,以及在使用 NPM 时的工作原理(如果您好奇为何称之为“外部”代理,也需要自行弄清楚这一点)。

由于我最初是手动设置外部代理并手动配置 Let’s Encrypt 的,因此我对 Discourse 和 NPM 为您执行的所有自动化操作(使 HTTPS 正常工作)有了深入理解,从而在从 Discourse 管理的证书切换到 NPM 管理的证书时,能够避开各种陷阱。

我不太明白您为何要将邮件服务器置于 NPM 之后……

1 个赞

不,Christoph,不是放在 NPM 后面,只是放在一个容器中。我试过 Zimbra,但结果一团糟。然后尝试了一个简单的“容器化”Postfix,但也没有成功。那时我刚开始接触 Linux(我仍然是一名初学者,但至少在某些管理概念方面越来越有信心),所以我放弃了,直接在服务器上安装。它启动时没有遇到太大问题,所以我选择了这种方式,尽管配置 Discourse 以使用我的邮件服务器相当困难。但现在,一切似乎都正常了。

2 个赞

安装听起来不错,直到我在 npm 与 discourse 主机通信时卡住;您提到在 npm compose 文件中的 mySQL 主机中放入数据容器的 IP 地址

 environment:
      DB_MYSQL_HOST: "db"
      DB_MYSQL_PORT: 3306
      DB_MYSQL_USER: "npm"
      DB_MYSQL_PASSWORD: "npm"
      DB_MYSQL_NAME: "npm"

但是当我将 (DB_MYSQL_HOST) 更改为数据容器时,它显示连接被拒绝。

connect ECONNREFUSED 172.17.0.2:3306 <-- npm 在 discours 网络(network_mode: bridge)中时出错。
getaddrinfo ENOTFOUND db <-- 当 npm compose 文件中的 mySQL 定义为“db”时出错。

有什么建议可以让我完成第三步吗?

1 个赞