歡迎光臨
每天分享高質量文章

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 –


    赞(0)

    分享創造快樂