AWS OpsWorks 与 CloudFormation

Question

我想了解OpsWorks 的确切局限性——我们可能无法做到或无法达到最佳状态的事情。 这将需要 go 到下一个级别 - CloudFormation。 当然，我们可以使用 OpsWorks + CloudFormation - 两全其美 - 最佳实践。

我知道 OpsWorks 的一些限制是 - 它无法提供所有东西 - 例如 EMR、S3 等 - 但从未在详尽的列表中找到。 OpsWorks 的 AutoScaling 配置也有限制。 与 OpsWorks 不同，CloudFormation 让我们可以对环境进行版本控制。 请理解有大量的重叠，而 CloudFormation 确实增加了复杂性。

之前有过讨论，但没有明确分界线。

Answer 1

OpsWorks是与CloudFormation完全不同的服务。

OpsWorks专注于管理作为堆栈分层的应用程序，并利用厨师的食谱来设置和部署应用程序。

CloudFormation是一种用于创建AWS基础架构集的描述性语言。

看起来似乎很明显，但事实是，每当您希望管理应用程序及其部署周期时，OpsWorks服务都更适合。 当然，您可以使用云形成来定义OpsWorks中的整个应用程序和层，这将允许您复制整个应用程序层集（用于测试环境等）。

了解每种服务的边界的唯一好方法是使用它们来满足您的需求，然后您将发现Opsworks的优势所在，以及Cloudformation在哪里补充或使您的Opsworks设置自动化。

关于版本控制，CF使您可以对基础结构堆栈进行版本控制，这可能与您通过opsworks管理的代码版本无关。

问候

Answer 2

在许多情况下，CloudFormation 与 OpsWorks 一起使用； 其中 CloudFormation 用于配置基础架构，OpsWorks 用于配置创建的资源。 OpsWorks（通过 Chef 或 Puppet）在配置应用程序堆栈时提供了一组更丰富的功能，然后是 CloudFormation 提供的简单 shell 脚本。 因此，通常 CloudFormation 用于部署 AWS 资源，而 OpsWorks 用于对应用程序/操作系统进行详细配置。

在某些方面，可以说 CloudFormation 更侧重于 AWS 基础设施资源的集合，而不是应用程序本身。 但是正如您所暗示的那样，两种服务可以互换地完成某些事情。

此AWS 链接可能有助于它指出：

“与 AWS CloudFormation 相比，AWS OpsWorks Stacks 支持范围更窄的面向应用程序的 AWS 资源类型，包括 Amazon EC2 实例、Amazon EBS 卷、弹性 IP 和 Amazon CloudWatch 指标。”

这当然不是 CloudFormation 的限制。