太好了。不，那将非常完美。再次感谢！非常感谢。
1 个赞
命令现在为 ./discourse-setup --two-container
刚才按预期运行成功了 
2 个赞
好眼力！它是否打印了一条消息，让你很容易就发现了这个问题？
我一直想整理一下这个话题，毕竟情况已经变了。
1 个赞
是的，非常有用，谢谢。
2 个赞
是否有计划从旧的“容器链接”功能迁移到使用自定义网络、将两个容器连接其中的正确配置方式？根据 Docker 文档，“链接”属于遗留功能，未来可能会被移除。
1 个赞
这听起来是个不错的主意。
除非有人抢先一步，我会考虑为子单元提交一个拉取请求，以切换到网络或套接字（有些人本来就倾向于这种方式），并编写一份操作指南，说明如何将现有配置转换为新配置。
5 个赞
@pfaffman 我不知道你是否已经处理了，但如果你处理了，想在这里链接到它吗？
3 个赞
我们应该在这些命令的末尾添加 && ./launcher cleanup 吗？
我发现在切换到双容器安装后，很快就会用旧镜像填满可用存储空间。
1 个赞
我强烈推荐在我的指南中这样做……很多人都在像 DO 虚拟机这样的小型系统上部署，我知道我曾帮助过一些不清楚他们的空间去向的人。
2 个赞
@pfaffman，您好！
几天前，我安装了带有单个容器的 AWS EC2，一切正常。但我需要完全是双容器配置，web_only 在 EC2 上，data 在 AWS RDS 上（PostgreSQL 15.3 端口 5432 => 我无法选择其他版本，并且数据库没有 DB_NAME 参数）。作为 Redis 集群，我尝试使用 AWS ElastiCache，但之后在 data.yml 中留下了一个指向现有模板的链接：
#- "templates/postgres.template.yml"
- "templates/redis.template.yml"
在成功引导 data 和 web_only 后，我无法打开网页。“此网站无法访问”。
我没有对 DNS 记录进行任何更改，也没有更改 AWS 安全组（Web 和数据库防火墙）中的访问设置。
成功引导，启动请使用 ./launcher start data
root@ip-172-31-3-68:/var/discourse# ./launcher start data
检测到 x86_64 架构。
+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -h ip-172-31-3-68-data -e DOCKER_HOST_IP=172.17.0.1 --name data -t -v /var/discourse/shared/data:/shared -v /var/discourse/shared/data/log/var-log:/var/log --mac-address <...> local_discourse/data /sbin/boot
27b66e577d250e4178f5e145c9962be7b5f2d905cfacd233d3d2278e7b83aa93
成功引导，启动请使用 ./launcher start web_only
root@ip-172-31-3-68:/var/discourse# ./launcher start web_only
检测到 x86_64 架构。
+ /usr/bin/docker run --shm-size=512m --link data:data -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=2 -e UNICORN_SIDEKIQS=1 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET= -e DISCOURSE_DB_HOST=database-discourse.<...>.rds.amazonaws.com -e DISCOURSE_DB_PORT= -e LETSENCRYPT_DIR=/shared/letsencrypt -e DISCOURSE_FORCE_HTTPS=true -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -e DISCOURSE_HOSTNAME=talk.furtherium.com -e DISCOURSE_DEVELOPER_EMAILS=hello@furtherium.com -e DISCOURSE_SMTP_ADDRESS=email-smtp.us-east-2.amazonaws.com -e DISCOURSE_SMTP_PORT=587 -e DISCOURSE_SMTP_USER_NAME=A<...>S -e DISCOURSE_SMTP_PASSWORD=B<...>M -e DISCOURSE_NOTIFICATION_EMAIL=noreply@talk.furtherium.com -e LETSENCRYPT_ACCOUNT_EMAIL=me@example.com -e DISCOURSE_DB_NAME= -e DISCOURSE_DB_USERNAME=postgres -e DISCOURSE_DB_PASSWORD=7<...>1 -e DISCOURSE_REDIS_HOST=data -h ip-172-31-3-68-web-only -e DOCKER_HOST_IP=172.17.0.1 --name web_only -t -p 80:80 -p 443:443 -v /var/discourse/shared/web-only:/shared -v /var/discourse/shared/web-only/log/var-log:/var/log --mac-address <...> local_discourse/web_only /sbin/boot
1233f1c660eb7cecc48d2a840aae037b46ecfd7afe029ef89b2e686b136b9886
- 我使用 telnet 检查了从 SSH 到数据库的连接 - 正常
- 我可以在 AWS RDS 控制面板中看到数据库连接
- 我已重启实例 3 次
- 我已运行 rebuild 3-4 次，没有错误
- 我检查了活动容器和镜像列表，清理了不必要的
容器 ID 镜像 命令 创建时间 状态 端口 名称
1233f1c660eb local_discourse/web_only “/sbin/boot” 18 分钟前 运行中 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp web_only
27b66e577d25 local_discourse/data “/sbin/boot” 47 分钟前 运行中 data
我还能做什么？感谢您的努力和时间！
你不需要。你只需要 Web 容器，并删除 Postgres 和 Redis 模板。在我看来，Elasticache 非常昂贵，所以如果你使用的是单台主机，可以在你的 EC2 上运行它。
只需将环境变量添加到你现有的 app.yml 中，并删除不必要的模板。我最近听说这个网站运行在 PG15 上，所以应该没问题。
感谢您的回复，Jay（@pfaffman）。我想澄清一下：
- 我应该使用单容器
app.yml安装，并在关于数据库和 Redis 的行中添加注释吗？另外，在app.yml的 ENV 字段中，然后添加 AWS 远程数据库的行（DB_USER 等 - 从 web_only 开始）？ - 或者我应该保持原样，但停止数据容器，只保留 web-only？
- 如果我不使用 ElastiCache，那么我需要保留“templates/redis.template.yml”行吗？
从标准容器更改为双容器几乎顺利。我浪费了很多时间，因为 yml 文件中缺少一些空格，这让我认为我遇到了本地化问题（远非如此），但那是我自己的错误。
但当我启动论坛时，我发现它是一个全新的论坛。修复起来相当容易，因为我在 S3 中有最新的备份，但我现在想知道它为什么会发生——有什么猜测吗？
我的意思是，如果我安装一个全新的双容器设置，然后从备份中恢复它，可能会节省一些时间。或者不，因为我仍然需要编辑 yml，至少要添加插件、修复电子邮件设置、maxmind 等。
1 个赞
[与上面的帖子无关]
我想知道使用双容器设置有什么优势？为什么不使用普通的单容器？
我认为这是为了在升级/安装插件进行重建时，避免您的论坛离线。
2 个赞
对我来说，已经提到了短暂的停机时间。另外，我经常升级，至少每周一次，所以我的设置很容易遇到 bug——虽然不经常，但偶尔还是会遇到。
那些原因是一个插件的时候——不经常，大多数时候是某个组件——我需要三到四轮才能解决有问题的那个。当每一轮都需要接近 30 分钟时，我的论坛就会停机太久，即使它很小而且是基于兴趣的。
第三个原因是，因为我能做到。
2 个赞
如果重建失败导致我的网站宕机，我会觉得压力极大。基本上，这需要我立即（有时是长时间）关注来解决/找到一个变通方法。一点也不好玩！！！
双容器安装将这种情况转化为一个小麻烦，而且通常可以在方便的时候解决根本问题。此外，导致问题的根本原因通常在此阶段已经得到解决。
如果使用 stable，我可能不会费心。但使用 tests-passed 更接近前沿，在重建/更新期间，它提供的弹性是无价的。
2 个赞
啊，我明白了。谢谢你的解释！
我都忘了我发过这个了！
1 个赞
很棒的教程。我花了 5 分钟，用一个新服务器，创建和恢复备份，然后运行 ./discourse-setup --two-container。
谢谢。
2 个赞
有人能解释一下，如果您正在转换一个具有健康数据库的现有服务器，为什么这个步骤是必要的吗？
我明白在迁移前创建一个安全的异地备份是良好的实践，但为什么要下载呢？
2 个赞