假设我创建WordPress的网站，这是在弹性魔豆运行。 现在，在运行的应用程序，我将创造职位/页，上传图片等。也就是说，在数据库中的一些数据，视频，文件和记录将被加入到运行的应用程序。
3个问题：
如果WordPress是在弹性魔豆运行多个亚马逊EC2实例实际运行我的WordPress安装，然后将这些文件自动传播到所有正在运行的实例？ 并将这也发生，如果一个新的EC2实例被激发起来 - 例如，以处理增加的负载？
从我在AWS控制台中看到的，我可以部署不同版本的app--，但按照上述方案，如果我部署一个新的版本，不会我失去了直接上传的所有文件到运行的应用程序（如文件和数据库记录）？ 如何保持这些，并在同一时间部署我的应用程序的新版本？
WordPress的团队持续发出升级。 我可以直接升级我跑步的WordPress安装，通过Web界面？ 还是我必须先升级我的WordPress的本地版本，然后再上传应用程序的新版本魔豆？ 如果我要升级我的本地版本，然后上传，然后我再次回到1点，即用户直接到旧版本上运行的应用程序进行了变更。 我如何保存这些变化？
我一直对这个问题，以及，并学到一两件事情是与此有关 - 你对特别上传问题一直在我的脑海：
（1）处理上传的最佳方式，在我看来，是要么去NFS / NAS路线像你建议，但有比这更好的方法是使用Amazon S3的WordPress插件，让任何上传自动复制了到S3和你的WordPress媒体库中的URL反映桶的FQDN，而不是特定的网站。 这样，你可以在你的魔豆和媒体一个或十个WP节点/图像是独立于任何一个服务器的。
（2）你绝对应该在这里使用RDS。 几件事情更容易和无压力的多AZ，保留MySQL的RDS实例工作。 如果不是这样，你自己的EC2运行MySQL是独立的魔豆，但为什么运行RDS时是如此容易？
（3）是你一定要首先提交更改您的Git仓库或本地文件（新的插件，改变主题，WP升级），然后上传/安装的修订魔豆代码。 否则，你通过网络接口一个节点进行更改永远不会在一个新的节点新的负载 - 事实上你将有一个升级的数据库，但旧的一套在魔豆的应用程序代码，所以很可能创造一些这样或那样的错误。
我花了一个AWS架构当然，和他们的EC2咨询与魔豆是开始考虑服务器实例非常一次性 - 所以你应该去想想你的箱子简便的方法来提供自己在引导过程，并采取在上只有一个框，彼此没有任何的宝贵资源工作。 所以，失去一个实例不应该是一个大问题。 （这绝对不是我们的物理服务器，在这里我们把一切都调整了“只是让”世界怎么想。）
祝好运！
好吧，我不是专家，但因为没有人回答，我给我最好的拍摄。
你是绝对正确的 - 种。 虽然每个EC2实例确实有一些本地存储，它被摧毁，并与每一个新的实例复位。 正因为如此，亚马逊之类的弹性块存储和S3的持久性文件。 我不知道怎么一会配置WP利用这一点，但是这可能会是解决方案。
我觉得这个问题是我的回答解决了＃1。 至于数据库，所有的EC2实例应该由同一RDS位置拉。 同样，虽然你可能对每个EC2实例运行MySQL，在持久的兴趣，有一个单独的数据库更有意义。
你再次拥有大部分的一切权利。 地方发展总应先现场部署。 本地升级然后推到直播服务器将确保所有情况下的保持一致。
在学习这一切也正如我所说的过程真相的被告知，我还在，我不是专家。 希望别人会来提供一个更明智的答案。 然而 ，这里的关键概念的障碍是弹性可扩展性的想法-并把这一理念的最关键的一点是什么之间是有弹性的/可扩展性/一次性的，什么是持久的元素分离。
希望帮助。
部署WordPress的AWS弹性魔豆确实需要这里提到了几次一些零钱正常WordPress的部署。 要回答你的问题，这里是一个伟大的教程解释无状态应用程序以及如何部署到弹性魔豆：
通过ElasticBeanstalk部署WordPress的亚马逊Web服务AWS EC2和RDS
我已经部署于EB，S3和RDS小的WordPress站点。 S3持有的所有静态数据，如媒体上传。 这是通过一个插件。 RDS保存数据库。 EB拥有最新部署的应用程序。 该应用程序是从我的开发环境部署，以构建脚本。 这样一来，我只需要按下一个按钮，我重新部署。
我在这里写了一个关于它的文章： http://www.cortexcode.com/wordpress-to-aws-code-example/
虽然它是在第一次恼人的工作，AWS的速度很不错，现在它比以往任何时候都更容易。 它曾经是我不得不上传一堆超过的FTP文件，这是方式更有效。 :-)
好吧，我研究了这一具体问题很多，而这也正是我learned--
（1）如果一个WordPress用户上传一些文件，那么他的文件将被上传只对实际服务他当时要求的虚拟机。 例如，如果目前WordPress站点是云部署和使用5台虚拟机，现在当用户发出请求，他被引导到一个虚拟机 - 一个具有最低负载在这一点......他的上传在只有存储服务器。 当前的平台即服务解决方案（如亚马逊弹性青苗和App雾）不必更改传播到所有正在运行的实例的能力。 如果不是这样（更改传播到所有服务器）或所有正在运行使用公用存储instances--它们是仅有的2解决问题的对策。 （通用存储的例如将所有5上运行使用网络连接存储（NAS）虚拟机...）
（2）随着裁判目前提供像亚马逊弹性青苗和App雾平台，例如，即使用户所做的更改直接运行APP-这些平台依靠当地版本的代码（管理员最初部署到云） - 和有没有办法更新的代码运行app--因此，这些变化即，文件同样lost--用户所做的更改本地版本（管理员的电脑上），在数据库更改用户运行的应用程序也lost--除非管理员使用完全相同的数据库，他在当地的应用程序（即他部署到云）
（3）对正在运行的应用的任何更改首先要在本地应用程序来进行管理的PC上，然后推到云中。
我工作的一个云的PaaS能够解决所有这些concerns--即更新可以运行的应用程序进行，在运行的应用程序代码做修改也被更新在用户访问的代码库...概念证明是准备好了，希望它会好，因为我希望它应该是:) - 目前这是唯一的东西其实有网站（anyacloudpanel.com） - 设计工作是怎么回事:)
如果有一些我不应该提及我的网站（安雅云面板）规则 - 那么我很抱歉 - 请随时编辑和我的答案删除我的网站的网址:)
谢谢，阿尔温德。
作为除了所有已经伟大的答案：
1）我强烈推荐EFS也S3媒体文件，所以他们从高可用性区域与CloudFront的组合服务。 为WordPress有一个插件，它真的加速了这种 （不附属于他们，只是真的很喜欢插件）。 还有一个资产的插件，如果你想成为JS，从S3 CSS文件。 对于EFS的解决方案，来看看在AWSlabs文档上的git，具体这个文件对如何安装上传文件。
在一般情况下，EBS是WordPress的真的很棒，但你需要相比，认为在不同的思维方式，其他的托管解决方案（共享主机，主机托管）。
如果你从themeforest使用一个主题，例如要小心。 其中有些是与WordPress插件S3不兼容。 然后，你就完蛋了，你不能部署在云上的WordPress。
