如何使用不同的计划管理多个AWS账户的修补

时间:2018-04-06 15:10:33

标签: linux amazon-web-services chef patch aws-opsworks

我正在寻找管理跨AWS账户修补Linux系统的最佳方法,需要考虑以下事项:

  • 按顺序分别通过Dev,QA,Staging和Prod滚动补丁
  • 生产补丁将在批准时发布,而不是自动发布
  • 没有新的补丁可以部署到生产中,而不是已经部署到较低环境的补丁(因为整个月定期出现新的补丁)。

我们已经开始在每个月的第一个星期日缓存所有环境中的所有补丁。那时的目标是从缓存中安装补丁。这有助于防止在产品中安装未经审查的补丁。

大多数(并非所有)实例都由OpsWorks管理,但有许多OpsWorks堆栈。我们还有一些由Chef Server管理的实例。还有一些不是托管的,而只是从EC2控制台创建的简单EC2实例。这意味着,使用配方意味着我们必须在逐个堆栈或逐个实例的基础上启动已批准的补丁。不是最佳的。

最近,我们使用中央AWS账户查看SSM的新功能来管理实例。但是,这会导致某些应用程序出现问题,因为SSM的AssumeRole会向.aws / config文件添加凭据,这会干扰我们需要运行的其他任务。

我们已经考虑过其他工具,例如Ansible,但我们希望探索我们目前拥有的工具集,主要是OpsWorks和Chef Server。我正在寻找更高层次的想法,一个人们将如何处理这种情况的架构。

感谢您的任何想法或想法。

1 个答案:

答案 0 :(得分:-1)

这听起来像是RunCommand专为其设计的场景之一。

您可以根据标记创建多个具有不同计划的服务器组。更重要的是,您不需要依赖部署在任何地方的密钥/密钥。