DevOps≠Chef/Puppet

來源:InfoQ

ID:infoqchina

DevOps是一個熱詞，但是毫無疑問，也是未來的趨勢。高效率的IT組織常常貼著DevOps的標簽，是人們討論的焦點和學習的物件。2009年時，人人都在討論如何像Flickr一樣一天內完成十幾次的部署。今天，人人都談論如何像Netflix/Pinterest一樣基於雲基礎設施構建大規模、高可用、可伸縮的服務。

如何才能實現DevOps呢？很多人會不假思索地告訴你，使用Chef/Puppet，你就能實現DevOps。於是，DevOps變成了一個簡單的問題，選擇Chef還是Puppet。這並不奇怪，在開源軟體盛行的今天，各種軟體聲稱自己是DevOps工具，而人們通常不會去思考一項新技術或者新思路背後的緣由，人們需要的是“銀彈”。

如同Agile，把DevOps等同於工具層面的Chef/Puppet，是錯誤的，會嚴重束縛人們的思維。在國內Cloud Native應用開發時代即將開啟的今天，充分認識DevOps是很有必要的。

（一）DevOps不僅僅是工具

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

事實上，大部分人都知道這個道理，只是在潛意識中仍然把DevOps當成Chef/Puppet等工具。建設DevOps的正確步驟應該是充分理解DevOps的原則，認真分析自身需求和條件，選擇正確的方法和流程，最後才是選擇或構建適當的工具。Learn By Example仍然是學習和建設DevOps的重要途徑。在今後的各種會議上，分享DevOps經驗會越來越多。我們應該不僅僅關註講演中提到的工具，更要多關註流程、組織結構和文化方面的分享。

DevOps不僅僅是工具，即便是工具，其也是建設DevOps所需工具鏈中的可選工具。

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

DevOps目的是打造標準化的、可重覆的、完全自動化的DeliveryPipeline, 其範圍涵蓋需求，設計，開發，構建，部署，測試和釋出。除了需求、設計和開發外，其他的四個步驟都是可以自動化的。自動化是提高可測試性，一致性，穩定性和交付頻率的核心。

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

• 原始碼版本控制工具：比如SVN， Git等。

• 持續整合工具：比如Jenkins, Bambo等。

• Artifact儲存倉庫：持續整合構建後的artifact都統一放在一個倉庫中，比如Nexus/Artifactory,當然也可以是FTP, S3等。

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

• Cloud Provision工具：在雲環境下，由於任何ITInfra資源都以程式設計介面提供，意味著Full-Stack Automation (from “bare-metal to running business services”)成為了可能。Cloudprovision工具可以自己透過API構建(如Netflix Asgard)，也可以直接使用IaaS服務商提供的擴充套件服務如AWS CloudFormation & Opsworks，也可以使用第三方工具如Ringscale/Scalr等。相當一部分CloudProvision本身也集成了Chef/Puppet來實現後續的部署和配置。

• 測試工具：除了傳統的測試工具外，還需要模擬Infra災難、驗證系統健壯性的工具，如Netflix的Chao Monkey。

• 釋出工具：一般情況下，人們需要擁有DTAP四個環境，即開發環境、測試環境、Staging環境和生產環境。每種環境的作用，部署方式和程式碼版本等是不一樣。比如開發環境是持續部署的，測試環境是定期如每天晚上自動部署，Staging和生產環境是手動觸發的。

• 雲基礎設施：包括AWS/Azure等公有雲，Cloudstack/Openstack等私有雲。

因此，我們看到，Chef/Puppet只是實現DevOps工具鏈的可選工具，可以用來實現配置和部署自動化。但是僅靠Chef/Puppet本身無法實現Full-Stack部署自動化。

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

如果要實現Full-stack Automation，那麼就必須實現環境建立自動化，軟體安裝和配置自動化，應用部署和配置自動化，監控和告警自動化，故障檢測和恢復自動化，擴充套件自動化，如下所示：

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

• 軟體安裝和配置：作業系統配置，比如建立使用者、組，設定ulimit引數等；基礎軟體安裝和配置，比如mysql/nginx。這些軟體的特點是變動不頻繁。對於Chef/Puppet來說，這個步驟的自動化是其最擅長的。它們都提供大量現成的Recipes，並抽象各種異構系統之間的差異。

• 應用部署和配置：部署應用程式碼，比如war包、db指令碼、php/rails程式碼等。這部分的變動是頻繁的。對於Chef/Puppet來說，其是可以做這個工作的，但是很多人認為用Fabric/Glu等更為合適。另外，對於複雜的系統來說，如果保證升級期間系統的可用性，系統的各個應用元件需儘量是無狀態和松耦合的。如果系統的元件之間是有依賴的，那麼升級期間必須動態地協調(Orchestration)、控制好相關元件的行為。

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

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

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

對於上述的每一個步驟，看似都存在現成的工具可以用來實現自動化。但是，實現Full-Stack部署自動化從來就不是一件容易的事情，絕非簡單透過選擇、拼湊相關工具即可實現。Autodesk中國研發中心最近在InfoQ上分享了他們基於AWS的自動化部署實踐。文章詳細闡述了業務標的，設計標的和限制，和最終的實現方案，是一個非常好的案例。在這裡，我們再來分析一下兩種差異較大的實現方式：

(1) 基於PaaS的實現方式 (以CloudFoundry為例)。

(2) Netflix的實現方式。

上述兩個案例中，我們都看不到Chef/Puppet的影子。即便是Cloud Foundry自身的部署工具Bosh，但也不是基於Chef/Puppet。所以，儘管Chef/Puppet非常流行，並且有很多成功案例，但是我們決不能把DevOps = Chef/Puppet。它們只是建設DevOps所需工具鏈中的可選工具，僅此而已。

《Linux雲端計算及運維架構師高薪實戰班》2018年11月26日即將開課中，120天衝擊Linux運維年薪30萬，改變速約~~~~

*宣告：推送內容及圖片來源於網路，部分內容會有所改動，版權歸原作者所有，如來源資訊有誤或侵犯權益，請聯絡我們刪除或授權事宜。

– END –

---