一個都不能少: DevOps的3大核心基礎架構

DevOps的涵蓋面很是廣，由於這個概念的火熱，又有不少文章和技術都在把DevOps的帽子扣在本身頭上，讓不少人疑惑不解。其實，DevOps的知識體系若是從頂層上來分解，只有2塊：方法論和工具鏈。方法論這塊，由於DevOps的不少理念脫胎于敏捷，因此你所能瞭解到的各類敏捷理念，實踐和方法均可以做爲DevOps知識體系的一部分，關於這部分後續我單獨寫一篇文章來談。今天想要和你們聊聊的關於DevOps工具鏈這塊內容。

前段時間看到有人整理了一個這樣的DevOps工具鏈週期表，說實話，上學的時候就最煩背元素週期表了，看着這個玩意兒我只是想吐（聲明：不是說這個玩意兒很差哈，挺好的東西，就是戳中了吐點而已）。

人類不善於記憶複雜的數據和零散的知識，因此須要簡化簡化再簡化，一圖解千言：

簡而言之，實現DevOps工具鏈你只須要3個核心基礎架構：
– SCM 配置管理系統
– Automation 自動化系統
– Cloud 雲（或者說可伸縮的，自服務的，虛擬化系統）

SCM 配置管理系統

配置管理是DevOps最底層的基礎設施，不管是Configuration As Code 仍是 Infrastructure As Code 強調的都是用管理代碼的方式來管理環境，將環境版本化對於不管快速建立，仍是可穩定的重複建立這些DevOps的基本要求來講都是最重要的基礎。

在週期表的左側第二列所列出的就是各類可供選擇的配置管理系統，如：GIT, SVN, Mercurial, GitHub, Bitbucket 等。對於實施DevOps來講，選擇哪一種SCM的一個重要考慮點就是後續的Automation和Cloud這兩個環節中的其它工具對這些工具的集成狀況如何。做爲這兩年的明星Git來講，這一切都不是問題，固然是最好的選擇。

SCM中所放置的內容又能夠再分紅2個層次，分別爲

• AppCode：就是你的應用代碼
• EnvCode：就是環境相關的代碼，這部份內容又能夠進一步細化成環境配置(Config)和配置數據(ConfigData)。
  • 環境配置：是那些針對當前應用基本上固定的環境配置
  • 環境數據：是那些須要在部署的同時根據狀況調整的數據，如：配置文件，開發／測試／生產環境的地址等等。

Automation 自動化系統

自動化在DevOps中的做用不用多說了，這部分的主線通常由各類類型的Build系統來實現，如：Jekins, Team City, Travis CI, CC等等。但僅僅有這些還不夠，爲了可以完成應用從開發環境到生產環境的遷移，咱們還必須處理如編譯，自動化測試，依賴恢復，容器構建，打包，編排等不少操做，因此還須要配置如：Junit, Xunit, FitNesse, Selenium, NuGet, NPM，JMeter等許多其它的工具來實現；但這些工具都只是在自動化系統中實現某一部分的功能，通常都是由Build系統來驅動，並依賴於SCM中所提供的各類代碼來實現的。

在個人那張圖中，全部這些內容最終會彙總到一個叫作MOF的節點，做爲後續進入環境的起點。MOF是DMTF這個標準化組織提出的一個工具和廠商無關的描述性語言，當前已經被不少廠商所接受並正在工具中逐步實現，DMTF的廠商列表能夠在這裏查到：

http://www.dmtf.org/cn/about/list

說實話，各類DevOps部署工具的標準化作的很是很差，基本上你使用了某種工具就被綁定了，雖然DMTF提出了這個標準一段時間了，一些主流的工具對它的支持仍然有限，如：Puppet 和 Chef等。對於用戶來講，熟悉了某種工具也不太願意更換其它的，因此對於DMTF的前景我是持懷疑態度的。這是一場博弈，對於用戶來講，有標準總比沒有好，多瞭解一些老是好事。

Cloud雲

虛擬化和雲計算的出現應該是催生DevOps的重要因素，沒有云所提供的彈性，自服務等特性，不少DevOps的理念只能停留在紙面上。

對於實施DevOps來講，咱們須要瞭解的就是各類雲所提供的API，由於不管是自動化系統仍是前面的SCM的產出最終都須要調用這些API來完成最終應用部署。

這部分的內容不少，就不展開了。

---

寫這篇文章的緣由很簡單，就是以爲東西太多，須要梳理，其中若有不妥之處，還望各位多多指正。但願這篇文章至少能幫你們找到了解DevOps工具鏈的入手之處，造成本身的知識體系，逐步擴展。

請關注微信公衆號 【devopshub】，獲取更多關於DevOps研發運維一體化的信息

​