Amazon EC2 上的 Java EE 应用程序部署
我们有一个 Java EE 应用程序（EAR 文件部署在 JBoss、MySQL、MongoDB），我们希望将其部署在 Amazon EC2 实例上。我有几个关于部署最佳实践的问题。
- 最常用的 Linux AMI 是什么，我们可以依靠它来进行稳健的部署（有Linux 变体很多，我不确定常用的是哪种 AMI，是 Fedora、CentOS、Red Hat、SUSE ...）
- 我们如何处理生产升级（EAR 文件修改或架构升级）。是否有任何工具可用于处理此安装或回滚这些更改。
- 数据库有哪些数据备份能力？
- 我是否应该依赖 Amazon RDS 来获得 MySQL 支持？
- 我应该如何处理对 MongoDB 的支持？
这是我第一次托管网络应用程序，并且希望获得一些有关如何管理生产实例的意见。
We have a Java EE application (EAR file deployed on JBoss, MySQL, MongoDB) which we would like to deploy on an Amazon EC2 instance. I have several questions regarding deployment best practices.
- What is the most commonly used Linux AMI which we can rely on for a robust deployment (There are so many Linux variants, and I am not sure which AMI is commonly used, is it Fedora, CentOS, Red Hat, SUSE ...)
- How do we handle production upgrades (EAR file modifications or schema upgrades). Are there any tools which are available to handle this installation or rollback of these changes.
- What kind of data backup capability is available for the database?
- Should I rely on Amazon RDS for MySQL support?
- How should I handle support for MongoDB?
This is the first time, I am hosting an web-app and would appreciate some inputs on how to manage the production instance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我有一个通用映像，它是我所做的每个版本部署的基础。我有 www.mysite.com 指向一个弹性 IP，这样我就可以决定它转到哪个实例。通用映像包含我需要安装的所有软件（Postgres/Postgis/Tomcat/等），但数据库和 Web 服务器数据文件夹以及符号链接到弹性块存储 (EBS) 实例。
当需要进行部署时，我会启动一个新实例，冻结生产环境中的 EBS 卷并为其创建快照，然后创建新卷。我将新实例指向新卷，然后将我需要的任何内容安装到该实例上。一旦我成功地对所有内容进行了冒烟测试，我就可以将弹性 IP 切换到指向新实例，一切都会继续进行。
我会注意到，我目前的优势是只有我可以修改数据库；没有用户可以。这很快就会成为一个问题。
如果您在 EBS 卷之上使用 XFS 文件系统，那么您可以告诉 XFS 冻结文件系统（因此不会发生更新），然后调用 EC2 api 对卷进行快照，然后解冻文件系统。结果是快速拍摄快照并将其发送到 S3。我有一个夜间脚本可以执行此操作。
如果 RDS 看起来适合您的需求，那么就使用它。 Amazon 正在快速构建大量可靠的工具，这将缓解您的可扩展性问题（如果您有任何问题）。
对不起，我不知道。
I have a common image which is the base of every version deploy I do. I have www.mysite.com pointing to an Elastic IP so I can decide which instance it goes to. The common image has all the software I need installed (Postgres/Postgis/Tomcat/etc) but the database and web server data folders and symlinked to Elastic Block Store (EBS) instances.
When it comes time to do a deploy I start a new instance up, freeze and snapshot the EBS volumes on production and make new volumes. I point my new instance at the new volumes and then install whatever I need to onto that. Once I've smoke tested everything successfully I can switch the Elastic IP to point to the new instance and everything keeps on going.
I'll note that I currently have the advantage where only I can modify the database; no users can. This will become a problem shortly.
If you use the XFS filesystem on top of the EBS volume then you can tell XFS to freeze the file system (so no updates happen) then call the EC2 api to snapshot the volume then unfreeze the file system. The result is that the snapshot is taken quickly and sent to S3. I have a nightly script which does this.
If RDS looks like it will suit your needs then use it. Amazon is building lots of solid tools quickly and this will ease your scalability issues if you have any.
I'm sorry, I have no idea.
好问题！
1) 我建议您使用您最喜欢的任何 Linux 版本。如果你有人真正热衷于 CentOS，那就跟着他吧。选择 AMI 后，即可使用它并通过配置您想要的方式对其进行自定义。然后将该 AMI 保存为您的基本布局。它将使推出新机器变得更加容易，并且在 EC2 出现故障时可以挽救您的生命。
2) 使用 EC2 进行升级非常酷。不要升级实时系统，而是使用预配置的 AMI，更新它并将该 AMI 保存为 myAMI-1.1（或其他）。这样，您几乎可以立即切换到新系统，并回滚到以前的版本，以防出现问题。您还可以将数据库实例备份到 S3。价格便宜，约为每月 0.10 美元/GB。
3）这取决于您存储数据库的位置。如果您将其存储在 EC2 实例上，您就会遇到麻烦。 EC2 实例没有持久性存储。所以如果你的机器崩溃了，你就会失去一切。我不熟悉 Amazon DB 系统，但您也应该研究一下 Elastic Block Store。它基本上是一个可以写入的实际硬盘。当您想要升级架构时，请将完整数据库转储到 S3，然后升级实际架构。如果出现问题，您可以从 S3 中提取以前的版本。
4）& 5）我从未使用过这些，所以我无法帮助你。
Good question!
1) I would recommend going with whatever Linux variant you are most comfortable with. If you have someone who is really keen on CentOS, go with that. Once you have selected your AMI, take it and customize it by configuring how you want it. Then save that AMI as you base-layout. It will make rolling out new machines much easier and save your bacon if EC2 goes down.
2) Upgrades with EC2 can be tres cool. Instead of upgrading a live system, take your pre-configured AMI, update that and save that AMI as myAMI-1.1 (or whatever). That way, you can flip over to the new system almost instantly AND roll back to a previous version in case something breaks. You can also back-up DB instances to S3. It's cheap at about $0.10/GB/Month.
3) It depends where you are storing your DB. If you are storing it on your EC2 instance you are in trouble. The EC2 instances have no persistence storage. So if your machine crashes, you lose everything. I'm not familiar with Amazon DB system but you should also look into Elastic Block Store. It's basically an actual hard-drive you can write to. When you want to upgrade your schema, do a full DB dump to S3 and then do an upgrade of your actual schema. If something goes wrong, you can pull the previous version out of S3.
4) & 5) I have never used those so I can't help you.
如果您可以接受在 TomEE 而不是 JBoss 上部署 Java EE 应用程序，那么 Boxfuse 可以满足您的需求。
对于您的 Java EE 应用程序，您实际上只需要执行（TomEE 使用 war 文件而不是 Ear 文件）：
这将
任何后续更新都将作为零停机蓝/绿部署完成。
更多信息：https://boxfuse.com/blog/javaee-aws
If you can live with deploying your Java EE application on TomEE instead of JBoss, Boxfuse does what you want.
For you Java EE application you literally only have to execute (TomEE uses war files instead of ear files):
This will
Any subsequent update will be done as a zero downtime blue/green deployment.
More info: https://boxfuse.com/blog/javaee-aws