在Elastic Beanstalk上部署WordPress？

Question

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

3个问题：

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

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

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

Answer 1

我也一直在研究这个问题，并且已经学到了一些与此相关的内容 - 特别是关于上传的问题一直在我的脑海中：

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

（2）你绝对应该在这里使用RDS。很少有东西比多可见区，保留的MySQL RDS实例更容易使用和无压力。运行MySQL的那个或你自己的EC2是独立于Beanstalk的，但为什么在RDS更容易的时候运行它呢？

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

我参加了AWS架构课程，他们对EC2和Beanstalk的建议是开始考虑服务器实例是非常一次性的 - 所以你应该考虑让你的盒子在引导过程中自行配置的简单方法并且在一个盒子上没有任何宝贵资源的情况下相互接管工作。所以失去一个实例永远不应该是一个大问题。 （这绝对不是我们在物理服务器世界中的想法，我们在那里调整了所有内容'就是这样'。）

祝你好运！

Answer 2

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

1. 你是对的 - 有点儿。虽然每个EC2实例 都有一些本地存储，但它会被销毁并随每个新实例重置。因此，亚马逊拥有Elastic Block Storage和S3等持久性文件。我不知道如何配置WP来使用它，但这可能是解决方案。

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

3. 你再次拥有最重要的一切。本地开发应始终在实时部署之前。在本地升级然后推送到实时服务器将确保所有实例保持相同。

说实话，我仍然在学习所有这些，正如我所说，我不是专家。希望其他人会出现并提供更明智的答案。 然而，这里的关键概念障碍是弹性可伸缩性的概念 - 这个想法的重点在于弹性/可扩展/一次性和持久性之间的元素分离。

希望这有帮助。

Answer 3

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

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

Answer 4

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

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

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

Answer 5

好的，我在这个特定问题上进行了很多研究，这就是我所学到的 -

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

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

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

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

如果有一些规则我不应该提及我的网站（Anya Cloud Panel） - 那么我很抱歉 - 请随时编辑并从我的回答中删除我的网站网址：）

谢谢， Arvind的。

Answer 6

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

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

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

Answer 7

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