手动部署与Amazon Elastic Beanstalk

通过使用Elastic Beanstalk相对于通常创建EC2实例，设置tomcat服务器并为典型的Java Web应用程序进行部署等，我们有什么优势。负载平衡，监视和自动缩放是唯一的优势吗？

假设使用数据库的Web应用程序将数据库安装在EC2实例本身中。自动缩放发生时，将在新创建的实例中创建数据库，还是将访问在主实例中创建的数据库...如果自动缩放发生时仅创建副本，实例之间将如何进行数据同步？

您提到的所有内容（例如负载平衡，监视和自动缩放）绝对是优势。

但是，您必须这样考虑：在真正的平台即服务（PAAS）中，目标是将应用程序与平台分开。作为开发人员，您只需要担心您的应用程序。该平台已“出租”给您。平台“实例”将自动为您更新，管理，缩放，平衡等。您只需上传WAR文件，它就可以正常工作（至少在理论上是这样）。

EC2本身不是PAAS。它更像是IAAS（基础架构即服务）。您仍然必须照顾服务器实例，在它们上安装软件，保持它们更新等。

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

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

在PAAS系统中，DBMS是一项单独的服务。对于Amazon，它将是Amazon RDS。就像使用Elastic Beanstalk一样，您不必担心应用程序服务器，而只需上载WAR文件，而使用RDS，就不必担心DBMS，而只需部署数据库。

Elastic Beanstalk和RDS可以很好地协同工作，尤其是当部署在同一可用性区域中时，该区域的延迟将非常低。

最后，使用Elastic Beanstalk不会比部署资源（EC2实例和负载平衡器）花费更多。但是，RDS并不便宜，而且肯定比在应用程序服务器和DBMS中使用单个EC2实例贵。

Elastic Beanstalk不仅要做负载平衡，监视和自动缩放。

1）通过存储和管理应用程序的不同版本来管理应用程序版本，从而使您可以轻松地在应用程序的不同版本之间来回切换。

2）每个应用程序都有“环境”的概念，允许您在每个环境中部署不同版本的应用程序。例如，如果您要设置单独的QA和DEV环境，并且想轻松地首先在DEV中部署构建，然后在QA团队准备进行下一个构建时在QA中部署相同版本的应用程序，则这非常方便。

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

4）通过控制台查看应用程序日志文件，并将日志文件自动滚动和归档到S3。（诚​​然，此功能目前较弱。）

我在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中的自动部署。我不得不编写脚本来自动化脚本，这很好，因为它只有一次。