隨著 Puppet Server 越來越龐大 Scaling 也是很重要的環節之一，在 Puppet 官方文件也有提到「Scaling Puppet Server with compile masters」的一些作法，還有在 Puppet Enterprise 文件中的「High availability overview」
先談談官方 Puppet Enterprise 的 HA
- Active / Standby 的架構，透過 Replica sync data。
- 最少需 2 台 instances。
這種架構上你可以允許 1 台 Puppet Master 故障，但你可用的 Puppet cluster 並不會增加，你必須採用更高的規格才能支撐更大量的 Puppet Node。
- 把 Compile Master 分離出來，讓 Puppet Agent 接的 Compile Master 可以 Scaling。
- 最少需 4 台 instances。
Puppet Master 的角色還是維持 Active / Standby，讓 Compile Master 去搞定繁忙的工作。
在 Puppet Enterprise 的 HA 好處是可以 replica data 到另一台，你的 config 可以在 Manage console 上進行編輯，不用擔心容錯時遺失設定。
再來談談 Open Source Puppet 的作法：
- Using round-robin DNS
# IP address of master 1:
puppet.example.com. IN A 192.0.2.50
# IP address of master 2:
puppet.example.com. IN A 198.51.100.215
這個方法其實很直接又簡單 … 直接替 Compile Master 加上多個 DNS A record，然後你就擁有自動負載均衡的架構，不過如果其中一台 Compile Master 掛了還是有機會跑到掛掉的那台，但 DNS 可以做 health check 這又是後話了 …
- Using a hardware load balancer
更直覺的方式就是用可以 TCP 的 Load balancer 設備來做。
- Using DNS SRV Records
# Site A has two masters – master-1 is beefier, give it 75% of the load:
_x-puppet._tcp.site-a.example.com. IN SRV 0 75 8140 master-1.site-a.example.com.
_x-puppet._tcp.site-a.example.com. IN SRV 0 25 8140 master-2.site-a.example.com.
_x-puppet._tcp.site-a.example.com. IN SRV 1 5 8140 master.site-b.example.com.# For site B, prefer the local master unless it’s down, then fail back to site A
_x-puppet._tcp.site-b.example.com. IN SRV 0 5 8140 master.site-b.example.com.
_x-puppet._tcp.site-b.example.com. IN SRV 1 75 8140 master-1.site-a.example.com.
_x-puppet._tcp.site-b.example.com. IN SRV 1 25 8140 master-2.site-a.example.com.
還有 DNS SRV record 的方式來告訴 Agent 有哪些 endpoint，比 round-robin DNS 好的是可以做到 fail over，並且指定權重。
manifests 和 modules 的同步
但是上述方法都會用 manifests 和 modules 不同步的問題，所以 Puppet 官方建議用版控的工具或是 r10k 來同步所有 config，這就有關 CI / CD 了，把 CI / CD 做好環境 manifests and modules 一致性就沒問題。
除此之外，Puppet 最重要的就是 CA 憑證，如果你的 CA 憑證丟了，全部 Puppet agent 都要清掉 certificate 重來一次 …，所以上述的作法所有的 Puppet Master 都要存放相同的 ca 憑證，不然不會動 …，certufucate trust 的部份就用 auth sign policy 自動重新簽發就好了。
把 CA Server 拆出來做備援
另外也支援 ca_server 這個參數讓你指定 CA Server，所以在 CA 這塊你又可以另外拆出來做備援。Creating and configuring compile masters
上述講這麼多 Puppet 官方提供的 HA Solution 後，在下面會講我的 HA 實作案例。
AWS 上實作 Puppet Master 的 Auto Scaling
*** 以下實作必須具備 AWS 操作 EC2、AutoScaling、S3、IAM 的能力。
先說這個作法相同在 Docker、OpenStack 等平台其實也都能輕鬆達成，只是因為身在 AWS 環境，只要善用 Autoscaling 這個 API，就可以很簡單的做到 Puppet Master 的 Scaling。
Step 1. 先打好一個基本的 Puppet Master template AMI 這個 AMI 要做好幾件事情：
- 安裝好 Puppet Master
- puppet.conf 完成 certname、server 等 Domain 資訊
- 針對效能調整的 JVM Heap size、max-active-instances 等
詳細可以參考 安裝初始化
Step 2. 處理最重要的 CA 憑證
把既有的 CA 憑證打包丟到 S3，這是最重要的動作，你也可以放在任何可以儲存的地方。
$ cd /etc/puppetlabs/puppet $ sudo tar zcvf /tmp/puppetserver-ca.tar.gz ssl $ aws s3 cp puppetserver-ca.tar.gz s3://shaziinfo_puppetserver/
Step 3. 提供 S3 bucket 權限給要 Puppet Server instance 的 Role
因為準備在 Autoscaling launch instance 的時候從 S3 把 CA 取回來。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1487528506002",
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::shaziinfo_puppetserver/*"
]
}
]
}
Step 4. manifests and modules 就透過 CI / CD 自動 deployment 到 instances
Step 5. 建立 Launch configuration，選擇已經建立好的 Puppet Server AMI，在這邊必須特別在 User-data 把 CA 憑證抓回來
#!/bin/bash cp /tmp; aws s3 cp s3://shaziinfo_puppetserver/puppetserver-ca.tar.gz . sudo tar zxvf puppetserver-ca.tar.gz sudo cp -R ssl/* /etc/puppetlabs/puppet/ssl/ # cleanup rm -rf puppetserver-ca.tar.gz ssl
Step 6. 建立 Autoscaling，記得 Join NLB or ELB。
Step 7. 測試
這時 Autoscaling 會自動 Launch instances，必須檢查以下項目：
- Puppet Server 有自動 Join 到 NLB or ELB。
- CI / CD 有將 manifests 和 modules deploy 到 instance
- 寫在 user-data 的動作有把 CA 從 S3 抓到 /etc/puppetlabs/puppet/ssl
- Puppet agent 重新和 Puppet Master 要 catalog 皆正常。
上面實作方式說明的有點籠統，但在 AWS 上就是點點點就好了，之後再補上完整的 Terraform config !
這種方式將 CA、compile、Master 都集成到 Puppet Server 上，就不用特別把某一部分拆開，用 Autoscaling 來達成萬台的架構。
