谢谢——所以是 ./launcher rebuild web_only（或 rebuild data）而不是 ./launcher rebuild app，并且我需要仔细阅读更新以查看何时更新 postgres 或 redis 以便手动更新它们。与独立部署相比，主要优势在于重建不需要等待数据库关闭然后再重新启动，回滚事务（如果它被终止）。
但是，随着 Falco 的最新更改，数据库永远不会被终止，除非它需要超过 10 分钟才能关闭，而这肯定不会发生，除非我们获得更多的用户。因此，更新不会因为这个问题而失败，主要影响只是使更新花费额外几分钟的时间。
我的理解是，最终这个更改增加了大量的复杂性和精神负担，但收益却非常小。如果我错了，请纠正我，这并非讽刺/等等。
只是作为一点背景，这项更改必须提供实质性的好处才能值得付出这种额外的努力，因为这一切都是我无偿提供的（现在已经持续了 15 年以上，但仍然如此），这不是我的工作。那里的情况确实因人而异。
没错。
很多人都有这种看法，但我仍然觉得很惊讶。Postgres 升级一年不到一次，而且通常延迟几个月后再进行初始更改也没有什么坏处。拥有一个 2 容器的设置意味着比单容器更容易延迟升级 postgres，这对我来说似乎是另一个优势。
使用 2 容器的设置，您可以
./launcher bootstrap web_only && ./launcher destroy web_only; ./launcher start web_only
并且（通常）停机时间不到一分钟。
但您不想这样做，所以就不要这样做。
推迟 PostgreSQL 升级过去只需更改一个简单的配置文件 yaml，除非你们打算停止支持这种方式。我们可以承受升级时多几分钟的停机时间，在我看来，这比依赖一个人（就是我！）来维护一个不那么标准、更复杂的配置要风险小。
从我的角度来看，两个容器的主要优势在于减少了停机时间——就像你一样，我认为每隔几个月停机 20-30 分钟是可以接受的。但很容易看出，对于一些论坛来说，这太多了。
当然。即使我们讨论的是 90 分钟的独立停机时间与 5 分钟的分散停机时间，我可能仍然不认为这个改变是值得的，尽管如果需要这么长时间，我可能会选择在深夜而不是方便的中午进行升级。我们不是一个实时股票交易平台，我们是一个关于电子游戏的免费论坛。
采用双容器设置后，您甚至无需了解进行此简单更改。您将完全不会遇到启动升级然后发现您已经开始升级 PostgreSQL 的情况。
但我花了将近 35 年的时间在 shell 中工作。
现在我有一个仪表板，可以自动执行这些命令行升级（并处理 PostgreSQL 升级以及许多其他事务）。
但“没坏就别修”，我理解移动东西和可能弄坏东西是令人恐惧的。
我当初也是从 Slackware 开始的，我只是觉得论坛维护不是一个有趣的工程，想让它消失，这样我就可以继续钻研如何将 Google Home 与 Home Assistant 集成（或者我那周感兴趣的任何其他东西）了。