本文摘抄自：DevOps的概念與實踐??

目錄

Chef/Puppet 只是DevOps工具鏈中的可選工具

僅靠Chef/Puppet本身無法實現Full-Stack部署自動化

兩種實現方式

基于PaaS的實現方式 （以Cloud Foundry為例）

Netflix的實現方式

---

DevOps不僅僅是工具

DevOps是Agile的延伸，Agile依靠Dev & Biz部門緊密協作，通過增量交付的方式來解決需求多變的難題。DevOps則進一步延伸到IT運維，通過Dev & Ops的緊密協作提高軟件交付的質量和頻率。 人的重要性大于流程，流程的重要性大于工具。 這個結論適應于Agile，也適用于DevOps。 工具帶來的影響是短期的、片面的，流程和人產生的影響是長期而全面的。

?

Chef/Puppet 只是DevOps工具鏈中的可選工具

?DevOps的目的是打造標準化的、可重復的、完全自動化的Delivery Pipeline，其范圍涵蓋需求、設計、開發、構建、部署、測試、發布。除了需求、設計和開發，其他都是可以自動化的，自動化是提高可測試性、一致性、穩定性和交付頻率的核心。

DevOps流程所需要用到的工具和環境有：

源代碼版本控制工具： SVN、Git等

持續集成工具： Jenkins、 Bambo等

Artifact存儲倉庫：持續集成構建后的artifact 都統一放在一個倉庫中，比如Nexus/Artifactory，也可以是FTP、S3等

配置和部署工具：Chef/Puppet/CFEngine, Fabric/ControlTier，也包括Docker等

Cloud Provision工具：在云環境下，由于任何IT Infra資源都以編程接口提供，意味著Full-Stack Automation成為了可能。Cloud Provision工具可以自己通過API構建，也可以直接使用IaaS服務商提供的擴展服務，也可以使用第三方工具，相當一部分 ，Cloud Provision本身也集成了Chef/Puppet來實現后續的部署和配置。

測試工具：傳統測試工具，模擬Infra災難、驗證系統健壯性的工具，如Netflix的Chao Monkey

發布工具：一般情況下，需要DTAP四個環境：開發、測試、Staging、生產。每種環境的作用、部署方式、代碼版本等是不一樣的。

云基礎設施：包括AWS/Azure等公有云，CLoudstack/OpenStack等私有云

?

僅靠Chef/Puppet本身無法實現Full-Stack部署自動化

如果要實現Full-Stack Automation，需要實現環境創建自動化、軟件安裝和配置自動化、應用部署和配置自動化、監控和告警自動化、故障檢測和恢復自動化、擴展自動化。

環境創建：創建VMs、網絡、存儲、負載均衡，協調不同角色VMs的創建過程和配置

軟件安裝和配置：操作系統配置，基礎軟件安裝和配置，這些軟件的特點是變動不頻繁。對Chef/Puppet來說，這個步驟的自動化是最擅長的，提供大量現成的Recipes，并抽象各種異構系統之間的差異

應用部署和配置：部署應用代碼，這部分代碼的變動是頻繁的。另外，對于復雜的系統來說，如果保證升級期間系統的可用性，系統的各個應用組件需盡量是無狀態和松耦合的。如果系統的組件之間是有依賴的，那么升級期間必須動態地協調、控制好相關組件的行為。

監控和告警：包括OS級別和應用級別的可用性和性能監控。如果發現異常，需要能夠自動發出告警信息。

健康檢查和恢復：為了應付云基礎設施故障，系統需要Design By Failure。在異常發生時，系統可以發現并進行自動處理。

自動伸縮：一般情況下，業務存在高峰期和低估期。為了節約成本，系統應該是可以自動伸縮的。

每一步都有工具來實現自動化，但實現Full-Stack 部署自動化不是通過簡單的拼湊工具就可以的。

兩種實現方式

基于PaaS的實現方式 （以Cloud Foundry為例）

環境創建：用戶不需要創建物理資源環境，Cloud Foundry 會自動創建并分配資源給各個租戶，用戶無法控制底層OS等

軟件安裝和配置：用戶不需要軟件安裝，Cloud Foundry已經安裝好相關軟件，但支持的類型和版本有限。

應用部署和配置：Cloud Foundry提供接口，用戶調用接口進行應用部署和配置。應用類型必須是Cloud Foundry支持的，只能進行有限的配置，如Tomcat的配置參數等

監控和告警：Cloud Foundry提供監控服務，但Metric類型有限，無法支持自定義Metric

健康監測和恢復：Cloud Foundry 提供Container級別的健康監測和恢復

自動伸縮：基于Cloud Foundry提供的monitoring接口和應用控制接口，可以實現instance級別的自動伸縮

Cloud Foundry基本實現了所有自動化步驟，應用開發人員只需專注應用邏輯本身的開發，但Cloud Foundry也限制了用戶的選擇權和控制權，特別是大型的、復雜的、分布式系統，開發人員需要的是Full-Stack可控制性

Netflix的實現方式

?環境創建：通過自己研發的Asgard管理和部署工具實現

軟件安裝和配置：基礎軟件和配置都打包成AMI，基于Netflix自己的打包工具Aminator

應用部署和配置：同上，應用代碼和配置也打包進AMI

監控和告警：Leverage AWS Cloudwatch， 同時也將通過自己開發的Servo Lib將custom metric發送至Cloudwatch

健康監測和恢復：Leverage Atoscaling group， 健壯性測試有Netflix自己開發的Chaos Monkey工具

自動伸縮：Leverage AWS AutoScaling group

Netflix除了Leverage AWS的CloudWatch/Auto Scaling Group/ ELB等服務外，自己也開發了一系列工具完成Full-Stack部署自動化。這些工具通過Asgard這個可視化云管理和部署控制臺集成起來。 另外，Deployable image這種部署模式雖可簡化部署并確保一致性，但一部分復雜性轉移到了應用層面。系統的各個組件是無狀態和松耦合，同時還需要Eureka這種服務來實現中間層的負載和failover。

Cloud Foundry和Netflix都沒有用到Chef/Puppet。

總結

以上是生活随笔為你收集整理的DevOps--Chef/Puppet的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。