在 Elastic Beanstalk 上部署 WordPress？答案

【问题标题】：Deploying WordPress on Elastic Beanstalk?在 Elastic Beanstalk 上部署 WordPress？
【发布时间】：2012-09-10 18:22:11
【问题描述】：

假设我在 Wordpress 中创建了一个站点，该站点在 Elastic Beanstalk 上运行。现在，在正在运行的应用程序上，我将创建帖子/页面，上传图片等。也就是说，数据库中的一些数据、视频、文件和记录将被添加到正在运行的应用程序中。

3 个问题：

如果 WordPress 在 Elastic Beanstalk 上运行，并且多个 Amazon EC2 实例实际运行我的 WordPress 安装，那么这些文件会自动传播到所有正在运行的实例吗？如果启动新的 EC2 实例（例如，为了处理增加的负载）也会发生这种情况吗？
WordPress 团队不断发布升级。我可以通过 Web 界面直接升级正在运行的 WordPress 安装吗？还是我必须先升级本地版本的 WordPress，然后将新版本的应用程序上传到 Beanstalk？如果我必须升级我的本地版本然后上传，那么我又回到第 1 点，即用户直接对正在运行的应用程序的旧版本进行的更改。如何保留这些更改？

【问题讨论】：

标签： amazon-web-services amazon-elastic-beanstalk

【解决方案1】：

我也一直在研究这个问题，并且在这里学到了一些相关的东西——我特别想到了你关于上传的问题：

(1) 在我看来，处理上传的最佳方式是按照您的建议走 NFS/NAS 路线，但比这更好的方法是为 WordPress 使用 Amazon S3 插件，以便任何上传自动复制到 S3，并且您的 WordPress 媒体库中的 URL 反映您的存储桶的 FQDN，而不是您的特定站点。这样一来，您的 Beanstalk 中可以有一个或十个 WP 节点，并且媒体/图像独立于这些服务器中的任何一个。

(2) 您绝对应该在这里使用 RDS。很少有东西像多可用区、保留的 MySQL RDS 实例那样更容易使用和无压力。要么是那个，要么是你自己的 EC2 运行独立于 Beanstalk 的 MySQL，但是当 RDS 如此简单时，为什么还要运行它呢？

(3) 是的，您绝对必须首先提交对 Git 存储库或本地文件的更改（新插件、主题更改、WP 升级），然后上传/安装为 Beanstalk 的修订版代码。否则，您通过 Web 界面对一个节点所做的所有更改将永远不会出现在新节点的新负载中——事实上，您将拥有一个升级的数据库，但 Beanstalk 应用程序中有一组旧代码，所以很可能制造某种错误。

我参加了 AWS 架构课程，他们对 EC2 和 Beanstalk 的建议是开始将服务器实例视为一次性的——因此您应该尝试考虑让您的盒子在引导过程中自行配置的简单方法并在没有任何宝贵资源的情况下在一个盒子上接管彼此的工作。所以丢失一个实例永远不会是什么大不了的事。（这绝对不是我们在物理服务器世界中的想法，我们对所有东西都进行了“恰到好处”的调整。）

祝你好运！

【讨论】：

【解决方案2】：

好吧，我不是专家，但由于没有人回答，我会尽力而为。

你是绝对正确的——有点。虽然每个 EC2 实例确实都有一些本地存储，但它会随着每个新实例而被销毁和重置。正因为如此，亚马逊拥有弹性块存储和用于持久文件的 S3 之类的东西。我不知道如何配置 WP 来利用它，但这可能是解决方案。
我认为这个问题可以通过我对#1 的回答来解决。至于数据库，您的所有 EC2 实例都应该从同一个 RDS 位置提取。同样，虽然您可以在每个 EC2 实例上运行 MySQL，但为了持久性，拥有一个单独的数据库更有意义。
再一次，你几乎所有事情都是正确的。本地开发应始终先于实时部署。在本地升级然后推送到实时服务器将确保您的所有实例保持相同。

说实话，我也还在学习这一切的过程中，正如我所说，我不是专家。希望其他人会出现并给出更明智的答案。然而，这里的关键概念障碍是弹性可扩展性的概念——而这个概念的重点是弹性/可扩展/一次性和持久性之间的元素分离。

希望对您有所帮助。

【讨论】：

请看我的回复——我现在正在自己开发一个云 PaaS（名为 Anya Cloud Panel），因为现有的解决方案有局限性:(

【解决方案3】：

我在 EB、S3 和 RDS 上部署了一个小型 Wordpress 站点。 S3 保存所有静态数据，例如媒体上传。这通过插件工作。 RDS 保存数据库。 EB 拥有最新部署的应用程序。该应用程序是从我的开发环境中部署的，带有一个构建脚本。这样，我只需按一个按钮即可重新部署。

我在这里写了一篇关于它的文章：http://www.cortexcode.com/wordpress-to-aws-code-example/

虽然起初使用起来很烦人，但 AWS 的速度非常好，现在比以往任何时候都更容易。以前我必须通过 FTP 上传一堆文件，这样效率更高。 :-)

【讨论】：

【解决方案4】：

作为所有优秀答案的补充：

1) 对于媒体文件，我强烈推荐 EFS，但也推荐 S3，因此它们由高可用性区域提供服务，结合云端。对于 Wordpress，有一个 plugin that really speeds up this（不隶属于他们，就像插件一样）。还有一个资产插件，如果你想从 S3 提供 JS、CSS 文件。对于 EFS 解决方案，请查看 git 上的 AWSlabs docs，特别是 this file 了解他们如何挂载上传文件。

总的来说，EBS 非常适合 Wordpress，但与其他托管解决方案（共享托管、托管托管）相比，您需要以不同的思维方式进行思考。

【讨论】：

【解决方案5】：

好的，我对这个特定问题进行了很多研究，这就是我学到的——

(1) 如果 wordpress 用户上传了一些文件，那么他的文件将只上传到当时实际为他的请求提供服务的虚拟机。例如，如果当前 wordpress 站点是云部署的并且正在使用 5 个虚拟机，那么现在当用户提出请求时，他将被定向到一个虚拟机——当时负载最低的那个......他的上传只存储在那个服务器。当前的平台即服务解决方案（如 Amazon Elastic Beanstalk 和 App Fog）无法将更改传播到所有正在运行的实例。要么（将更改传播到所有服务器）要么由所有正在运行的实例使用公共存储——这是解决此问题的唯一两种解决方案。（例如，公共存储将是所有 5 个使用网络附加存储 (NAS) 运行的虚拟机...）

(2) 参考目前可用的平台，例如 Amazon Elastic Beanstalk 和 App Fog，即使用户直接对正在运行的应用程序进行了更改，这些平台也依赖于本地版本的代码（管理员最初将其部署到云中） )- 并且无法使用用户对正在运行的应用程序所做的更改来更新本地版本的代码（在管理员的 PC 上）——因此这些更改即文件丢失——同样，用户在数据库中对运行的更改应用程序也丢失了——除非管理员为他的本地应用程序使用完全相同的数据库（他部署到云）

(3) 对正在运行的应用程序的任何更改都必须首先在管理员的 PC 上对本地应用程序进行，然后再推送到云端。

我正在开发一个解决所有这些问题的云 PaaS - 即可以对正在运行的应用程序进行更新，对正在运行的应用程序所做的代码更改也会在用户可访问的代码存储库中更新......概念证明已经准备就绪，希望它会像我希望的那样好:) -- 目前唯一实际存在的就是网站 (anyacloudpanel.com) -- 设计工作正在进行中:)

如果有一些规则我不应该提及我的网站（Anya Cloud Panel）——那么我很抱歉——请随时从我的答案中编辑和删除我的网站 URL :)

谢谢，阿文德。

【讨论】：

您可以通过为您的 WordPress 媒体使用 S3/CloudFront 类型的插件来解决问题 #1。这会从您的 EC2 实例中卸载所有图像/媒体文件，并且您可以随意扩展/缩小，而不必担心媒体并发性。这是一个这样的插件：wordpress.org/plugins/amazon-s3-and-cloudfront/screenshots

【解决方案6】：

将 WordPress 部署到 AWS Elastic Beanstalk 确实需要对正常的 WordPress 部署进行一些更改，如此处所述几次。为了回答您的问题，这里有一个很好的教程，解释了无状态应用程序以及如何部署到 Elastic Beanstalk：

Deploying WordPress to Amazon Web Services AWS EC2 and RDS via ElasticBeanstalk

【讨论】：

链接失效

【解决方案7】：

例如，如果您使用来自 themeforest 的主题，请务必小心。其中一些与 wordpress S3 插件不兼容。那你就完蛋了，你不能在云端部署你的 wordpress。

【讨论】：