DevOps ≠ Chef/Puppet · DevOps的概念與實踐（2014年）

> 作者阮志敏發布于 2014年2月17日 DevOps是一個熱詞，但是毫無疑問，也是未來的趨勢（注1）。高效率的IT組織常常貼著DevOps的標簽，是人們討論的焦點和學習的對象。2009年時，人人都在討論如何像Flickr一樣一天內完成十幾次的部署（注2）。今天，人人都談論如何像Netflix/Pinterest一樣基于云基礎設施構建大規模、高可用、可伸縮的服務（注3）。如何才能實現DevOps呢？很多人會不假思索地告訴你，使用Chef/Puppet，你就能實現DevOps。于是，DevOps變成了一個簡單的問題，選擇Chef還是Puppet。這并不奇怪，在開源軟件盛行的今天，各種軟件聲稱自己是DevOps工具，而人們通常不會去思考一項新技術或者新思路背后的緣由，人們需要的是“銀彈”。如同Agile，把DevOps等同于工具層面的Chef/Puppet，是錯誤的，會嚴重束縛人們的思維。在國內CloudNative應用開發時代即將開啟的今天，充分認識DevOps是很有必要的（注4）。 ## （一）DevOps不僅僅是工具 DevOps是Agile的延伸，Ailge依靠Dev& Biz部門緊密協作，通過增量交付的方式來解決需求多變的難題。DevOps則進一步延伸到IT運維，通過Dev& Ops的緊密協作提高軟件交付的質量和頻率。人的重要性大于流程，流程的重要性大于工具。這個結論適應于Agile,也同樣適用于DevOps。工具帶來的影響是短期的和片面的，流程和人所產生的影響是長期的和全面的。 ![](https://box.kancloud.cn/2015-07-17_55a872903e08b.png) 事實上，大部分人都知道這個道理，只是在潛意識中仍然把DevOps當成Chef/Puppet等工具。建設DevOps的正確步驟應該是充分理解DevOps的原則，認真分析自身需求和條件，選擇正確的方法和流程，最后才是選擇或構建適當的工具。LearnByExample仍然是學習和建設DevOps的重要途徑。在今后的各種會議上，分享DevOps經驗會越來越多。我們應該不僅僅關注講演中提到的工具，更要多關注流程、組織結構和文化方面的分享。 DevOps不僅僅是工具，即便是工具，其也是建設DevOps所需工具鏈中的可選工具。 ## （二）Chef/Puppet只是DevOps工具鏈中的可選工具 DevOps目的是打造標準化的、可重復的、完全自動化的DeliveryPipeline,其范圍涵蓋需求，設計，開發，構建，部署，測試和發布。除了需求、設計和開發外，其他的四個步驟都是可以自動化的。自動化是提高可測試性，一致性，穩定性和交付頻率的核心。下圖來自IBM [Agile,ITITL, Cloud How DevOps brings it all together](http://www.slideshare.net/CloudOps/agile-itil-cloud-mit-devops-in-die-zukunft)。該圖非常清晰地解釋DevOps如何實現交付的自動化（注5）。 ![](https://box.kancloud.cn/2015-07-17_55a8729049812.png) 圖中DevOps流程所需要用到的工具和環境有： 1. 源代碼版本控制工具：比如SVN， Git等。 1. 持續集成工具：比如Jenkins, Bambo等。 1. Artifact存儲倉庫：持續集成構建后的artifact都統一放在一個倉庫中，比如Nexus/Artifactory, 當然也可以是FTP, S3等。 1. 配置和部署工具：Chef/Puppet/CFEngine, Fabric/ControlTier，也包括新興的Docker等。 1. Cloud Provision工具：在云環境下，由于任何IT Infra資源都以編程接口提供，意味著Full-Stack Automation (from “bare-metal to running business services”)成為了可能。Cloud provision工具可以自己通過API構建(如Netflix Asgard)，也可以直接使用IaaS服務商提供的擴展服務如AWS CloudFormation & Opsworks，也可以使用第三方工具如Ringscale/Scalr等。相當一部分Cloud Provision本身也集成了Chef/Puppet來實現后續的部署和配置。 1. 測試工具：除了傳統的測試工具外，還需要模擬Infra災難、驗證系統健壯性的工具，如Netflix的Chao Monkey。 1. 發布工具：一般情況下，人們需要擁有DTAP四個環境，即開發環境、測試環境、Staging環境和生產環境。每種環境的作用，部署方式和代碼版本等是不一樣。比如開發環境是持續部署的，測試環境是定期如每天晚上自動部署，Staging和生產環境是手動觸發的。 1. 云基礎設施：包括AWS/Azure等公有云，Cloudstack/Openstack等私有云。因此，我們看到，Chef/Puppet只是實現DevOps工具鏈的可選工具，可以用來實現配置和部署自動化。但是僅靠Chef/Puppet本身無法實現Full-Stack部署自動化。 ## （三）僅靠Chef/Puppet本身無法實現Full-Stack部署自動化如果要實現Full-stackAutomation，那么就必須實現環境創建自動化，軟件安裝和配置自動化，應用部署和配置自動化，監控和告警自動化，故障檢測和恢復自動化，擴展自動化，如下圖所示（注6）。 ![](https://box.kancloud.cn/2015-07-17_55a872905be6b.png) 1. 環境創建：創建VMs、網絡、存儲、負載均衡，協調不同角色VMs的創建過程和配置。 1. 軟件安裝和配置：操作系統配置，比如創建用戶、組，設置ulimit參數等；基礎軟件安裝和配置，比如mysql/nginx。這些軟件的特點是變動不頻繁。對于Chef/Puppet來說，這個步驟的自動化是其最擅長的。它們都提供大量現成的Recipes，并抽象各種異構系統之間的差異。 1. 應用部署和配置：部署應用代碼，比如war包、db腳本、php/rails代碼等。這部分的變動是頻繁的。對于Chef/Puppet來說，其是可以做這個工作的，但是很多人認為用Fabric/Glu等更為合適。另外，對于復雜的系統來說，如果保證升級期間系統的可用性，系統的各個應用組件需盡量是無狀態和松耦合的。如果系統的組件之間是有依賴的，那么升級期間必須動態地協調(Orchestration)、控制好相關組件的行為。 1. 監控和告警：包括OS級別和應用級別的可用性和性能監控。如果發現異常，需要能夠自動發出告警信息。 1. 健康檢測和恢復：為了應付云基礎設施故障，系統需要Design By Failure. 在異常發生時，系統可以發現并進行自動處理。 1. 自動伸縮：一般情況下，業務存在高峰期和低估期。為了節省成本，系統應該是可以自動伸縮的。對于上述的每一個步驟，看似都存在現成的工具可以用來實現自動化。但是，實現Full-Stack部署自動化從來就不是一件容易的事情，絕非簡單通過選擇、拼湊相關工具即可實現。Autodesk中國研發中心最近在InfoQ上分享了他們[基于AWS](http://www.infoq.com/cn/articles/automated-deployment-practice-based-on-aws)[的自動化部署實踐](http://www.infoq.com/cn/articles/automated-deployment-practice-based-on-aws)。文章詳細闡述了業務目標，設計目標和限制，和最終的實現方案，是一個非常好的案例。在這里，我們再來分析一下兩種差異較大的實現方式。 ## (1)基于PaaS的實現方式(以CloudFoundry為例)。 <table cellpadding="0" border="1" cellspacing="0" class="calibre32"><tbody class="calibre33"><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 環境創建 </td> <td width="492" class="calibre35"> 用戶不需要創建物理資源環境，Cloud Foundry會自動創建并分配資源給各個租戶，用戶無法控制底層OS等 </td> </tr><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 軟件安裝和配置 </td> <td width="492" class="calibre35"> 用戶不需要軟件安裝。Cloud Foundry已經安裝好相關軟件，只是支持的類型和版本有限 </td> </tr><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 應用部署和配置 </td> <td width="492" class="calibre35"> Cloud Foundry提供接口，用戶調用接口進行應用部署和配置。應用類型必須是Cloud Foundry支持的，只能進行有限的配置，比如Tomcat的配置參數等 </td> </tr><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 監控和告警 </td> <td width="492" class="calibre35"> Cloud Foundry提供監控服務，但是Metric類型有限，無法支持自定義Metric </td> </tr><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 健康檢測和恢復 </td> <td width="492" class="calibre35"> Cloud Foundry提供Container級別的健康檢測和恢復 </td> </tr><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 自動伸縮 </td> <td width="492" class="calibre35"> 基于Cloud Foundry 提供的monitoring 接口和應用控制接口，可以實現instance級別的自動伸縮 </td> </tr></tbody></table> 貌似這種方式是最完美的方案，CloudFoundry基本替你實現了上述的所有自動化步驟，應用開發人員只需專注于應用邏輯本身的開發。然而，CloudFoundry也限制了用戶的選擇權和控制權，特別是大型的、復雜的、分布式系統，開發人員需要的是Full-Stack可控制性。 ## (2)Netflix的實現方式。 <table cellpadding="0" border="1" cellspacing="0" class="calibre32"><tbody class="calibre33"><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 環境創建 </td> <td width="492" class="calibre35"> 通過自己研發的<a href="http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html">Asgard</a>管理和部署工具實現 </td> </tr><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 軟件安裝和配置 </td> <td width="492" class="calibre35"> 基礎軟件和配置都打包成AMI，基于Netflix自己的打包工具<a href="http://techblog.netflix.com/2013/03/ami-creation-with-aminator.html">Aminator</a> </td> </tr><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 應用部署和配置 </td> <td width="492" class="calibre35"> 同上，應用代碼和配置也打包進AMI（注7） </td> </tr><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 監控和告警 </td> <td width="492" class="calibre35"> Leverage AWS Cloudwatch, 同時也將通過自己開發的<a href="http://techblog.netflix.com/2012/02/announcing-servo.html">Servo</a> Lib將custom metric 發送至Cloudwatch. </td> </tr><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 健康檢測和恢復 </td> <td width="492" class="calibre35"> Leverage Atoscaling group，健壯性測試有Netflix自己開發的<a href="http://techblog.netflix.com/2012/07/chaos-monkey-released-into-wild.html">Chaos Monkey</a>工具 </td> </tr><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 自動伸縮 </td> <td width="492" class="calibre35"> Leverage AWS AutoScaling Group </td> </tr></tbody></table> Netflix除了LeverageAWS的CloudWatch/AutoScalingGroup/ELB等服務外，自己也開發了一序列工具完成了Full-Stack部署自動化。這些工具通過[Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html)這個可視化云管理和部署控制臺集成起來。另外，Deployableimage這種部署模式雖可簡化部署并確保一致性，但是一部分復雜性轉移到了應用層面（注7）。系統的各個組件是無狀態和松耦合，同時還需要[Eureka](http://techblog.netflix.com/2012/09/eureka.html)這種服務來實現中間層的負載和failover。在上述兩個案例中，我們都看不到Chef/Puppet的影子。即便是CloudFoundry自身的部署工具Bosh，但也不是基于Chef/Puppet。所以，盡管Chef/Puppet非常流行，并且有很多成功案例，但是我們決不能把DevOps= Chef/Puppet。它們只是建設DevOps所需工具鏈中的可選工具，僅此而已。 ## 參考文檔注1: [What’sDevOps?](http://dev2ops.org/2010/02/what-is-devops/) 注2: [10+Deploys Per Day: Dev and Ops Cooperation at Flickr](http://velocityconf.com/velocity2009/public/schedule/detail/7641) 注3: [Ops,DevOps and PaaS (NoOps) at Netflix](http://perfcap.blogspot.it/2012/03/ops-devops-and-noops-at-netflix.html) 注4: [對國內云計算三個現象的思考](http://www.csdn.net/article/2013-08-27/2816726) 注5:[Agile, ITITL, Cloud How DevOps brings it all together](http://www.slideshare.net/CloudOps/agile-itil-cloud-mit-devops-in-die-zukunft) 注6: [“It’sthe App, Stupid!” on Orchestration, DevOps Automation andWhat’s in Between](http://www.slideshare.net/uri1803/openstack-israel-summit-2013-its-the-app-stupid?ref=http://cloudifysource.tumblr.com/post/51957539224/its-the-app-stupid-uri-cohens-presentation-from) 注7: [Netflixdeployable image](http://techblog.netflix.com/2011/08/building-with-legos.html) ## 關于作者阮志敏，AWS認證架構師，目前在三星中國研究院從事PaaS相關工作。感謝[丁雪豐](http://www.infoq.com/cn/author/丁雪豐)對本文的審校。查看原文：[DevOps≠ Chef/Puppet](http://www.infoq.com/cn/articles/devops-is-not-equal-chef-puppet)