Discourse 实例位于 GFW 之后，因此我们使用 SOCKS5 代理进行 Git 操作。我们安装了几个插件，因此重建或引导应用程序会一遍又一遍地克隆所有这些仓库。不幸的是，克隆经常导致超时，因此整个过程会从头开始，即使最新的代码库已经克隆。我已经尝试了 40 多次，浪费了大约五个小时。最后的障碍是容器内的 yarn 子进程，它通常会超时，导致升级失败。
有没有办法构建 app.yml，至少可以避免调用整个插件克隆过程？克隆到 docker-manager 代码和 discourse 代码库的成功率约为 50/50，后续克隆的成功率约为 1/3。我不知道是什么导致 yarn 子进程失败，但目前似乎无法通过现有方法让 Discourse 恢复运行。
当然，我愚蠢地调用了 launcher destroy app，因为我想手动引导它，所以我甚至无法运行 launcher enter app 来尝试手动运行 yarn 命令。有人有什么想法吗？感谢您的建议。
我在这方面不是专家，但我认为解决方案是为你要下载的东西设置一个缓存代理。
有一个 web.china.template.yml，你正在使用它吗？
当然。我在所有 Rails 应用程序中都使用中文 Ruby 源，至少很高兴有这个。让我感到困惑的是：所有仓库（包括插件的仓库）现在都已经克隆了，只有这个 yarn 子进程调用了以下命令：
INFO -- : cd /var/www/discourse && [ ! -d 'node_modules' ] || su discourse -c 'yarn install --production && yarn cache clean'
出于某种原因，GFW 不喜欢一个接一个地进行太多的 git 克隆进程，并在某个时候终止连接。如果我能让启动器运行一个标志，说“好的，代码在这里，不需要克隆……现在只需要引导”，
编辑：真不敢相信。就在我们打字的时候，我的第 78 次尝试在 11 小时后终于成功了。我改用了 sshuttle，这也花了大约 12 次尝试，但无论出于何种原因，GFW 对我可怜的灵魂表示了仁慈。
你的缓存代理应该就能做到这一点（至少我是这么想的）。你可以看看 squid。然后你就会发现启动器是从你的镜像拉取的，而不是从实际的源拉取的。
launcher 没有代码，因为它会把它克隆到一个没有代码的新容器里，所以它每次都会下载所有代码。每一次。每一次。
是的，我们在很大程度上都有使用 Squid 的经验。无论如何，这都需要一个通用的解决方案，因为我不能每次都花几个小时手动升级 Discourse。几个月以来，使用常规的 socks5 代理一直有效，但与 GFW 的斗争一直在持续，而且自 10 月初以来访问 GitHub 变得很困难。难怪 gitee.com 这个网站上有大量的克隆。
感谢您对启动器的解释，我对 Docker 相当不了解，我以为它会在本地克隆 git 仓库，然后将它们覆盖到某个容器中。
我一定会研究 Squid 的选项，因为这也许也能帮助解决我的第二个痛点：fonts.googleapis.com
那不应该是 git clones，而是从 NPM 包注册表中安装。当然，肯定有类似于 bundle config mirror.https://rubygems.org https://gems.ruby-china.com/ 的 NPM/Yarn 的等效命令。
哦，紧接着就进行了一个克隆某个东西但失败的子进程。可惜我现在无法重现错误日志了。它肯定是从 GitHub 拉取了什么东西，因为错误消息是相同的 TLS 握手错误/超时。不过现在不重要了。通常 npm 出于某种原因在这里从不超时。防火长城漫长而充满神秘！
也许是这样
你太棒了！正是这个破坏了我的升级。
这相当稳定，我们现在有机会将其推送到 NPM 注册表吗？@pmusaraj
好的，没问题，我们这样做。
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.