gan*_*est 1 configuration chef amazon-web-services
我很好奇预构建二进制文件（安装包）并仅使用厨师进行配置管理是一个好策略。理论上，当我们需要新机器（流量高峰）时，它应该加快 init 过程，特别是如果我们使用像 AWS 这样的云，我们可以在其中创建我们自己的 AMI（图像），同时它在其他食谱方面可能不灵活工作..
我期待您对这个问题的想法以及最佳实践、经验和想法！
频谱的两端各有优缺点，中间的区域也是如此。
A. 在启动时使用具有动态系统配置的标准公共 AMI
(+) 不需要学习如何构建 AMI。
(+) 不需要学习如何管理稳定的历史 AMI。
(+) 通过编辑配置并运行新实例，可以轻松更改和测试系统配置。
(+) 通过共享配置文件轻松管理跨区域、帐户。
(+) 通过调整启动配置规则，可以轻松运行配置的变体。
(-) 系统的初始启动可能很慢，也可能很慢，这取决于您的启动配置过程需要完成多少工作。
(-) 需要了解如何自动启动配置，尤其是与 Auto Scaling 或 Spot 实例一起使用时。
B. 预构建自定义 AMIS
(+) 初始启动很快，因为不需要进行配置步骤。
(+) 适用于 Auto Scaling 和 Spot 实例。
(-) 需要学习如何有效地构建和管理 AMI。
(-) 每次所需的配置更改时都需要构建新的 AMI。
(-) 每次发布操作系统安全补丁时都需要构建一个新的 AMI。
(-) 更改配置时的长编辑/构建/测试循环
(-) 不同区域、不同账户（除非共享）、不同的配置变体、不同的实例架构需要多个 AMI。
C. 介于两者之间
您可以通过在中间做一些事情来获得这两种策略的一些好处（和一些缺点）：创建一个基本自定义 AMI，其中包含您的实例所需的大部分内容，然后在运行时运行动态配置以进行更新并完成配置，应用所需的任何特定变化。
这加快了启动时间，可能会加快很多，但也提供了一些灵活性，并且不必经常重建 AMI。
建议
首先创建自动化脚本（或 Chef 配方），这些脚本将采用公共 AMI 并将其配置为您所需的系统。
只要对您有用，就将自动化配置与公共 AMI（上面的方法 A）一起使用。
何时何地遇到启动性能问题，请使用自动化配置创建自定义 AMI（上述方法 B）。尽可能自动化此过程，以便您可以根据需要经常运行它。
如果您在同一个基本基础之上有多个系统变体，请构建自定义基础 AMI 并使用上面的方法 C 来运行不同的系统风格。
| 归档时间： |
|
| 查看次数： |
278 次 |
| 最近记录： |