如何在相對復雜的基礎架構中正確自動擴展AWS EC2 Instances組？

Question

我正在努力在Amazon Cloud上遷移我們的服務器，理由是自動擴展可能性，成本，服務等等。

到目前為止，我正在努力嘗試並試圖深入研究全功能的文檔，但由於沒有以前的經驗，我有很多問題。

設想的基礎設施如下：

                                  +-----+
                                  | ELB |
                                  +--+--+
                                     |
                +--------------------|--------------------+
                |            Auto-Scaling Group           |
                |--------------------|--------------------|
                |                    |                    |
                |  +---------+       |       +---------+  |
                |  | varnish |<------+------>| varnish |  |
                |  +----+----+               +---------+  |
                |       |                         |       |
                +-----------------------------------------+
                        |                         |
                        |                         |
                        |     +------------+      |
                        +---->|Internal ELB|<-----+
                              +------+-----+
                                     |
                +-----------------------------------------+
                |            Auto-Scaling Group           |
                |-----------------------------------------|
                |  +---------+       |       +---------+  |
                |  | Apache  |<------+------>| Apache  |  |
                |  +----+----+               +----+----+  |
                |       |                         |       |
                +-----------------------------------------+
                        |         +-----+         |
                        +-------->| RDS |<--------+
                                  +-----+

換句話說，我會使用Elastic LoadBalancer將流量發送到Varnish實例，Varnish實例又將流量發送到內部Elastic LoadBalancer，后者將流量發送到Apache前端。

現在，我發現了AWS工具，比如CloudFormation服務似乎能夠在給定模板的情況下引導實例，這看起來很棒，但它似乎只能引導。

對Puppet有一點經驗（並考慮到AWS在這個問題上的推薦）我參加了Puppet Master這個很棒的工具。

我的想法，可能不可行或不現實，是使用CloudFormation模板創建一個“Puppet節點堆棧”，它將根據需要配置實例並連接要配置的puppet master。

一旦我准備好堆棧，我就想知道如何為Varnish和Apache實例配置/創建Auto-Scaling組。

CFN似乎有資源配置自動擴展組和策略，所以我想我可以為每個創建兩個不同的模板。

但AS功能是否會通過CFN服務運行，然后執行所有init事務（並執行user-data ）？

我也在這里和那里讀到Puppet可以使用EC2標簽，也許一個通用的堆棧模板與相應的標簽（如角色）可以做到這一點？

這種架構是否真實可行？ 你有什么反饋意見嗎？

謝謝你的建議。

Answer 1

自動縮放基於啟動配置創建新節點。 因此，您將擁有兩個單獨的自動縮放組和兩個單獨的啟動配置。 即

"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。

Answer 2

您可能需要考慮使用像packer（ http://www.packer.io/ ）這樣的工具預先構建您的AMI，而不是使用“Puppet Node Stack”，這可以為機器配置puppet並創建AMI。 然后將配置的AMI添加到您的雲信息模板中。

正如Peter H.所說，cloudformation可以處理堆棧的更新。 因此，當您對puppet設置進行更改時，您可以構建新的AMI並在cloudformation中更新啟動配置。 自動擴展將開始使用新的AMI進行自動擴展新實例。

將puppet從cloudformation中取出可以讓您分清基礎架構和服務器配置之間的關注點。

使用預先構建的AMI（已經有Apache / Varnish設置）可以更快地進行擴展。

無主木偶設置也有優勢。 即。 權力下放，沒有將puppetmaster作為失敗點等。請參閱https://serverfault.com/questions/408261/pros-and-cons-of-a-decentralized-puppet-architecture