我想把 WordPress —— 全部 —— 放在 EFS 上。我是不是该？

Question

我有一个 WordPress 网站，截至目前，我完全在Amazon Lightsail实例上运行。它得到了正确的备份；可用性还可以；安全性好；这是一个易于维护的简单设置。没关系。

我想通过将站点移至Amazon Elastic Beanstalk并对站点的后端进行一些其他重大更改（使站点数据库独立于 PHP 服务器、移至 nginx 等）来提高可用性和加载时间。这有很多好处，其中最主要的原因是：EBS 只是比 Lightsail 更强大的服务器设置。

在亚马逊提供的教程创建魔豆上一个WordPress站点只建议安装/wp-content/uploads/上的亚马逊弹性文件系统，默认的配置脚本这样做的客户。这样做的缺点是核心 WordPress 文件不会在 EC2 实例之间共享；相反，它们会在每个实例上复制，因此在您的站点上运行 WordPress 更新过程意味着某些实例实际上并未更新，从而产生不良行为。

本教程建议通过使用 WordPress 的（测试版）导出工具导出所有网站内容并在运行的新 Beanstalk 环境中使用（测试版）导入工具重新导入它的可怕过程来更新 WordPress（和插件）。更新了 WordPress。

我并不完全反对自动化这个过程，以便更新 WordPress 对我来说更容易，但我重视保持最新的更新，所以我想为此进行优化，我怀疑这对我（或任何客户）来说是最好的解决方案是在更新系统或插件的过程中使用 WordPress 的 beta 导入导出工具。

例如，有时这些更新是 WordPress 为其提供自动修补系统的安全更新，这对于最大限度地提高站点安全性非常理想。但是，如果由于我已经概述的更新挑战而未在 EC2 实例之间共享核心 WordPress 文件，则自动修补将无法按预期工作。

综上所述：

如果我将所有 WordPress 文件（而不仅仅是/wp-content/uploads/目录）放在共享 EFS 存储上，我可能会遇到哪些架构或系统问题？

当然，我会进行自己的测试以了解事情的进展情况，但我想知道要注意什么（如果有的话），以及在尝试这样做时应该在哪里设定我的期望。

Answer 1

（注意：我不是专家，但我正在寻找一个未解答的问题，以便我可以回馈 serverfault.com）

我首先会追求扩展 Lightsail。文档 ( https://aws.amazon.com/lightsail/features/ ) 讨论了使用负载均衡器的多个实例。你尝试过吗？查看 CloudWatch 监控以了解您的实例的繁忙程度。水平扩展可以为您带来更快的响应时间。此外，您还可以扩展 Lightsail 以使用独立数据库实例。

在我看来，Word Press 在计算效率方面堪称野兽。它可以加载一百个脚本来执行单个请求。修剪一下会有帮助。有什么不需要的插件吗？代码可以组合成更少数量的模块吗？可能有优化/分析工具可以帮助您加快网站速度。

另外，请考虑您的网站有多少是静态文件服务与计算服务。将静态文件卸载到 AWS S3 是一个很好的解决方案。此外，实施 CDN 缓存（例如 AWS CDN）可以让您在非计算性页面加载时获得更快的响应时间，并有可能将内容移动到更靠近用户所在的位置。最后，但经常被忽视的是，用户需要发出多少 HTTP 请求才能加载给定页面。您是否有很多 JS 库需要加载？考虑将它们合并到一个可以在单个事务中加载的文件中。使用 Chrome 或 Firefox 中的浏览器开发工具确实可以帮助您查明延迟的来源。

如果您想采用管理服务器的方法，那么更新 WP 可以通过更简单的方式完成。我建议您开始使用 Docker 容器。然后，您只需在 N 个服务器上运行一个映像，并保持每一个映像都是最新的。对您的映像使用 AWS ECR。当您想要更新 WP 或插件时，您可以构建新的容器镜像版本。然后使用 AWS EKS 或 Fargate 以滚动方式推出新版本。这是宠物与牛话题的一部分。您不对单个服务器（容器）进行维护，但如果发生更改，您将丢弃旧的并部署新的。

但是，毕竟，如果你仍然想走普通存储的路线，我不建议你使用EFS。这样你就得不到安全感。相反，我会在每台服务器上运行 S3 文件缓存。每当 S3 中的文件发生更改时，它都会将文件拉到本地，以便每个人都能获得更改。示例缓存为https://github.com/s3fs-fuse/s3fs-fuse/wiki/Fuse-Over-Amazon。

我会进行测试，看看在运行时是否有对 WP 文件的写入。如果存在并且写入的内容取决于实例，则您必须将这些目录保留为服务器上的本地目录。