手动部署与Amazon Elastic Beanstalk

Question

通过使用Elastic Beanstalk来为典型的Java Web应用程序创建EC2实例并设置tomcat服务器和部署等,我们可以获得哪些优势.负载均衡,监控和自动扩展是唯一的优势吗？

假设我的Web应用程序使用数据库,我在EC2实例本身安装了数据库.当发生自动调整时,数据库将在新创建的实例中创建,或者它将访问我在主实例中创建的数据库...如果在自动调标发生时只创建副本,那么实例之间会发生数据同步吗？

Answer 1

您提到的所有内容,如负载平衡,监控和自动扩展,绝对是优势.

但是,您必须以这种方式思考:在真正的平台即服务(PAAS)中,目标是将应用程序与平台分开.作为开发人员,您只需担心您的应用程序.该平台被"租借"给您.平台"实例"会自动更新,管理,缩放,平衡等.您只需上传您的WAR文件,它就可以正常工作(至少在理论上).

EC2本身不是PAAS.它更像是IAAS(基础设施即服务).您仍然需要处理服务器实例,在其上安装软件,保持更新等.

Elastic Beanstalk是一个PAAS系统.所以,是的App Engine和Azure的在许多其他之中.

在真正的PAAS系统中,DBMS是与Web应用程序服务器分开的组件.原因很明显:DBMS不可能安装在用于应用程序服务器的实例上,因为在根据您的流量创建和销毁实例时,DBMS将丢失!无论如何,将DBMS和应用程序服务器放在同一台机器/实例上通常都不是一个好主意.

在PAAS系统中,DBMS是一个单独的服务.对于亚马逊,它将是亚马逊RDS.就像使用Elastic Beanstalk一样,您不必担心应用程序服务器,只需使用RDS上传WAR文件,您就不必担心DBMS而只需部署数据库.

Elastic Beanstalk和RDS可以很好地协同工作,尤其是在部署在相同可用区域时,延迟会非常低.

最后,使用Elastic Beanstalk不会比部署的资源(EC2实例和负载均衡器)花费更多.但是,RDS并不便宜,并且肯定比使用单个EC2实例同时用于应用程序服务器和DBMS更昂贵.

Answer 2

Elastic Beanstalk不仅仅是负载平衡,监控和自动扩展.

1)通过存储和管理应用程序的不同版本来管理应用程序版本,使您可以轻松地在不同版本的应用程序之间来回切换.

2)每个应用程序都有"环境"概念,允许您在每个环境中部署不同版本的应用程序.这很方便,例如,如果您想要设置单独的QA和DEV环境,并且您希望在DEV中首先轻松部署构建,那么当您的QA团队为下一个构建做好准备时,可以在QA中部署相同版本的应用程序.

3)将重要的容器配置属性(例如Tomcat内存设置)外部化到Elastic Beanstalk控制台和API.因此,您可以轻松保存设置并在环境之间复制它们.

4)通过控制台查看应用程序日志文件,并自动将日志文件滚动和存档到S3.(不可否认,这个功能目前有点弱.)

Answer 3

我在EC2专用服务器（Nginx和Gunicorn）和Beanstalk环境（CentOS和Apache2）中都部署了一个应用程序。

我的观察：

• BeanStalk是Paas。手动创建EC2实例（IAAS）就像从头开始做所有事情一样，但是您拥有可靠的控制权。

• BeanStalk默认附带CentOS和Apache（Httpd）。您可以在专用实例中选择操作系统。

• 这些对我来说很重要的事情

  • 在Beanstalk环境中显示了很多504错误。
  • 当BeanStalk服务器崩溃时，很难调试，因为日志也不会显示并且无法ssh进入计算机。这个非常重要。
  • 安装/配置诸如Celery，Redis（需要运行另一个端口）等工具。在专用实例中要容易得多。

• 就我而言，我必须扩展（Beanstalk）服务器以运行某些软件包（如pandoc）的安装。这些事情在Ubuntu中更加简单。

• 在BeanStalk中，扩展更加容易。在BeanStalk中，克隆服务器非常简单。

• 在这两种情况下（专用和Beanstalk），我都接受了微型注射。我觉得专用的微实例更好。

• Beanstalk中的自动部署。我不得不编写脚本来自动执行脚本，这很好，因为它只有一次。