自动应用AWS Elastic Beanstalk的安全更新

自从成立以来,我一直是Heroku的粉丝。 但是我喜欢AWS Elastic Beanstalk让您可以更好地控制实例的特性。 我喜欢Heroku的一件事是我可以部署一个应用程序,而不用担心pipe理它。 我假设 Heroku确保所有操作系统安全更新及时应用。 我只需要确保我的应用程序是安全的。

我对Beanstalk的最初研究表明,尽pipe它为您构build和configuration实例,但在此之后,它转向更人工的pipe理过程。 安全更新不会自动应用于实例。 看来有两方面的担忧:

  • 新的AMI发布 – 当新的AMI发布时,似乎我们想要运行最新的(推测是最安全的)。 但是我的研究似乎表明你需要手动启动一个新的设置来查看最新的AMI版本,然后创build一个新的环境来使用这个新版本 。 是否有一个更好的自动化方法将您的实例转换为新的AMI版本?
  • 在发行版之间将会发布针对软件包的安全更新。 似乎我们也想升级这些。 我的研究似乎表明人们安装命令偶尔运行yum更新 。 但是由于新实例是基于用法创build/销毁的,因此新实例似乎并不总是具有更新(即实例创build和第一个yum更新之间的时间)。 所以偶尔你会有没有修补的实例。 而且你还将不断修补自己,直到应用新的AMI版本。 我的另一个担心是,这些安全更新可能没有经过亚马逊自己的评论(像AMI版本一样),它可能会让我的应用程序自动更新它们。 我知道Dreamhost曾经有一个12小时的中断,因为他们完全自动地应用debian更新,没有任何审查。 我想确保同样的事情不会发生在我身上。

所以我的问题是亚马逊是否提供了像Heroku一样提供完全托pipe的PaaS的方式? 或者,AWS Elastic Beanstalk实际上更像是一个安装脚本,然后您自己(除了他们提供的监视和部署工具)?

首先,要清楚的是,没有Elastic Beanstalk不像您正在考虑的那样PaaS。 如果你把它分解成几块,那更像是虚拟化的实例模板和像puppet或者chef这样的应用程序部署自动化。 除此之外,您还可以自动访问敬畏的负载均衡器服务和云监控监控,从而使您可以启动新的应用程序服务器或根据指标closures现有服务器。

PaaS的感觉是,主要卖点是应用程序部署系统,它将您的代码复制到群集中的所有应用程序服务器上。

有些人对PaaS的投诉之一是,PaaS供应商为您做出关于应用程序环境的决定。 这在我看来就像PaaS的价值主张:作为一个客户,您将专注于应用程序function,并将所有其他细节留给PaaS供应商。 您正在为其他人付费来pipe理基础架构并提供系统pipe理。 为了简单起见,你要付出高昂的代价,就像在Her2上运行基础架构的Heroku一样,只是对你来说透明。

亚马逊真的提供Ec2和他们的REST API的Elastic Beanstalk,而不是做很多的努力来隐藏你的。 这是因为他们正在通过IaaS赚钱,而EB正在协调安排一组您可以自己设置的ec2资源,只要时间和知道如何。

现在,就AMI的具体情况而言,AMI也是用于促进EB的许多ec2组件之一。 EB AMI没有什么神奇的 – 它只是一个预先configuration好的与EB一起工作的亚马逊linux ami。 像任何其他AMI一样,您可以在EC2中启动它,调整它,从运行的实例中派生一个新的定制AMI。 亚马逊Linux基本上是Centos和Fedora之间的一个交叉,具有准虚拟化补丁,以及由亚马逊维护的预先configuration的yum repos。

如您所知,Amazon linux已经configuration为在启动时安装安全修补程序。 但是,就修补而言,正在运行的实例与任何其他服务器没有区别。 修补可能会中断服务。 如果您非常关心安全补丁,可以使用容器命令和安装程序cron以某种周期运行yum update –security。

您也可以使用EB API来改变EBconfiguration,或者自动创build一个新的EB环境,然后可以在它准备好之后进行交换,然后closures旧环境。 这在这里描述: http : //docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html

与AWS的其他部分一样,有一种以编程方式访问和控制每个非SaaSfunction的方法,所以没有任何东西可以阻止您创build修补后的AMI,然后使用它们创build新的EB环境并将其展开。 EB不会强制你的configuration细节,也不会为你提供一个系统pipe理组来维护基础架构。

所有Beanstalk应用程序和环境都可以通过EBEXTENSIONS文件进行configuration,这些文件通过基于YAML的configuration与应用程序部署包(例如Java应用程序的WAR文件)打包,以更新或重新configuration应用程序,容器,操作系统等的任何部分。Beanstalk PaaS,因为它是一个平台,允许您部署应用程序,而不必担心底层的IaaS。 所有PaaS提供商在一天结束时通过某种forms的自动化模糊了底层的IaaS。 然而,由于这是计算机科学,我们正在谈论的是,没有一个适用于所有应用程序的最佳状态,并且无法在PaaS下调整IaaS,因此您受PaaS服务提供商的束缚,向您保证您的应用程序能够平稳运行,快速和安全。

Heroku使用不同的pipe理层在AWS上运行。 然而,当你不得不做一些事情来保护你的应用程序时,它会变成一件痛苦的事情。 虽然他们尽最大努力有效地pipe理他们的解决scheme,并保持安全等,他们不能也不会在一天结束时承担应用程序中的漏洞的风险和后果。 他们希望尽可能地做他们的服务。

调整平台下的IaaS的能力是Beanstalk IMO的优势和吸引力。