我正在亚马逊云上迁移我们的服务器，原因显然是自动扩展的可能性、成本、服务等等。
到目前为止，我正在努力尝试，并试图深入了解功能齐全的文档，但由于之前没有经验，我有很多问题。
设想的基础设施如下：
+-----+
| ELB |
+--+--+
|
+--------------------|--------------------+
| Auto-Scaling Group |
|--------------------|--------------------|
| | |
| +---------+ | +---------+ |
| | varnish |<------+------>| varnish | |
| +----+----+ +---------+ |
| | | |
+-----------------------------------------+
| |
| |
| +------------+ |
+---->|Internal ELB|<-----+
+------+-----+
|
+-----------------------------------------+
| Auto-Scaling Group |
|-----------------------------------------|
| +---------+ | +---------+ |
| | Apache |<------+------>| Apache | |
| +----+----+ +----+----+ |
| | | |
+-----------------------------------------+
| +-----+ |
+-------->| RDS |<--------+
+-----+
换句话说，我会有一个Elastic LoadBalancer，它将向Varnish实例发送流量，然后将流量发送到内部Elastic LoadBalancer中，后者将流量发送给Apache前端。
目前，我已经发现了AWS工具，比如CloudFormation服务，它似乎能够在给定模板的情况下引导实例，这看起来很棒，但似乎只能引导。
有了一点Puppet的经验（并考虑到AWS对这个主题的建议），我投入了木偶大师的工作，这是一个很好的工具。
我的想法可能不可行或不现实，是使用CloudFormation模板创建一个"Puppet Node Stack"，它将根据需要配置实例并连接要提供的Puppet master。
一旦我准备好了堆栈，我想知道如何为Varnish和Apache实例配置/创建自动缩放组。
CFN似乎有资源来配置自动缩放组&策略，所以我想我可以为每个策略创建两个不同的模板。
但是，AS功能是否会通过CFN服务运行，然后执行所有初始化操作（并执行user-data）？
我还到处读到Puppet可以使用EC2标签，也许一个带有相应标签（比如角色）的通用堆栈模板可以做到这一点？
这种架构是否现实可行？你有什么反馈吗？
谢谢你的建议。
自动缩放基于启动配置创建新节点。因此，您将拥有两个独立的自动缩放组和两个独立启动配置。即
"VarnishScalingGroup" : {
"Type" : "AWS::AutoScaling::AutoScalingGroup",
"Properties" : {
"LaunchConfigurationName" : {"Ref" : "VarnishLaunchConfiguration" },
"LoadBalancerNames" : {"Ref" : "ELB"},
...
}
},
"VarnishLaunchConfiguration" : {
"Type" : "AWS::AutoScaling::LaunchConfiguration",
"Properties" : {
...
"UserData" : {
....
},
"MetaData" : {
...
}
},
"ApacheScalingGroup" : {
"Type" : "AWS::AutoScaling::AutoScalingGroup",
"Properties" : {
"LaunchConfigurationName" : {"Ref" : "ApacheLaunchConfiguration" },
"LoadBalancerNames" : {"Ref" : "InternalELB"},
...
}
},
"ApacheLaunchConfiguration" : {
"Type" : "AWS::AutoScaling::LaunchConfiguration",
"Properties" : {
...
"UserData" : {
....
},
"MetaData" : {
...
}
}
您想要添加的另一件事是为每个扩展组添加单独的扩展策略，以及要匹配的适当CloudWatch指标。
CloudFormation还可以启动对堆栈的更新。如果作为用户数据的一部分，您使用cfn-hup，那么它将定期（您决定）检查堆栈元数据中的更改，然后执行您喜欢的任何内容。我倾向于启动另一个版本的cfn-init，它将解析和更新任何元数据。
关键点-如果您沿着cfn-hup路径，它将不会再次执行userdata，除非CloudFormation堆栈需要删除并创建新实例。
还有一点，如果您希望对LaunchConfiguration进行更新，则需要确保LaunchConfiguration也应用了UpdatePolicy。
与其使用"Puppet Node Stack"，不如考虑使用打包器之类的工具预构建AMI(http://www.packer.io/)，可以为机器提供木偶并创建AMI。然后将提供的AMI添加到云信息模板中。
正如Peter H.所说，cloudformation可以处理堆栈的更新。因此，当您对木偶设置进行更改时，您可以构建一个新的AMI，并在cloudformation中更新您的启动配置。自动缩放将开始使用新的AMI来自动缩放新实例。
将puppet从云信息中移除，可以将基础设施和服务器配置之间的问题分离开来。
使用已经安装了Apache/Varnish的预构建AMI，扩展速度会更快。
一个没有技巧的木偶设置也有好处。即去中心化，没有木偶师作为失败点等。参见https://serverfault.com/questions/408261/pros-and-cons-of-a-decentralized-puppet-architecture