8

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

3个问题：

  1. 如果 WordPress 在 Elastic Beanstalk 上运行，并且多个 Amazon EC2 实例实际运行我的 WordPress 安装，那么这些文件会自动传播到所有正在运行的实例吗？如果启动一个新的 EC2 实例——例如，为了处理增加的负载，这也会发生吗？

  2. 从我在 AWS 控制台中看到的情况来看，我可以部署不同版本的应用程序——但根据上述情况，如果我部署新版本，我会不会丢失所有直接上传到正在运行的应用程序中的文件（即文件和数据库记录）？如何保留这些并同时部署我的应用程序的新版本？

  3. WordPress 团队不断发布升级。我可以通过 Web 界面直接升级正在运行的 WordPress 安装吗？还是我必须先升级本地版本的 WordPress，然后将新版本的应用程序上传到 Beanstalk？如果我必须升级我的本地版本然后上传，那么我又回到第 1 点，即用户直接对运行应用程序的旧版本所做的更改。我如何保留这些更改？

4

7 回答 7

8

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

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

祝你好运！

于 2013-02-27T13:58:49.643 回答
4

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

  1. 你是绝对正确的——有点。虽然每个 EC2 实例都有一些本地存储，但它会随着每个新实例而被销毁和重置。正因为如此，亚马逊拥有弹性块存储和用于持久文件的 S3 之类的东西。我不知道如何配置 WP 来利用它，但这可能是解决方案。

  2. 我认为这个问题可以通过我对#1 的回答来解决。至于数据库，您的所有 EC2 实例都应该从同一个 RDS 位置提取。同样，虽然您可以在每个 EC2 实例上运行 MySQL，但为了持久性，拥有一个单独的数据库更有意义。

  3. 你，再一次，一切都是正确的。本地开发应始终先于实时部署。在本地升级然后推送到实时服务器将确保您的所有实例保持相同。

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

希望这会有所帮助。

于 2012-10-30T15:16:48.883 回答
1

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

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

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

于 2016-04-13T18:52:43.577 回答
1

作为所有出色答案的补充：

1) 对于媒体文件，我强烈推荐 EFS，但也推荐 S3，因此它们是从高可用性区域与 cloudfront 结合提供的。对于 Wordpress，有一个插件可以真正加快速度（不附属于它们，就像插件一样）。还有一个资产插件，如果你想从 S3 提供 JS、CSS 文件。对于 EFS 解决方案，请查看 git 上的AWSlabs 文档，特别是该文件，了解他们如何挂载上传文件。

In general, EBS is really great for Wordpress, but you'll need to think in a different mindset as compared to other hosting solutions ( shared hosting, managed hosting ).

于 2017-12-17T11:43:37.563 回答
0

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

(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 :)

谢谢，阿文德。

于 2012-10-30T16:41:15.820 回答
0

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

通过 ElasticBeanstalk 将 WordPress 部署到 Amazon Web Services AWS EC2 和 RDS

于 2013-11-06T12:14:08.487 回答
-1

例如，如果您使用来自 themeforest 的主题，请小心。其中一些与 wordpress S3 插件不兼容。然后你就搞砸了，你不能在云上部署你的 wordpress。

于 2013-10-15T13:13:21.667 回答