DevOps與阿裡雲容器服務（一）

摘要： 前言本篇本文是整個列車中概念最多的一篇，後續本文大部分會以具體的場景為主，但在面對不同的場景前，希望大家記住DevOps不是銀彈，一定要根據自己的需求與場景甚至公司的軟體發展人員的能力與公司級別來選擇具體的方案。## DevOps是什麼首先我們看下wiki百

前言

本篇本文是整個列車中概念最多的一篇，後續本文大部分會以具體的場景為主，但在面對不同的場景前，希望大家記住DevOps不是銀彈，一定要根據自己的需求與場景甚至公司的軟體發展人員的能力與公司級別來選擇具體的方案。

DevOps是什麼

首先我們看下wiki百科的定義：DevOps（英文Development和Operations的群組）代表一種文化、運動或實踐。旨在促進軟體交付和基礎設施變更軟體發展人員（Dev）和IT運維技術保證（Ops）之間的合作和溝通。它的目的是構建一種文化和環境使構建，測試，發佈軟體更加快捷，頻繁和可靠。

剛接觸DevOps的時候，問10個人會有10個不同的答案。在剛開始的一段時間，我一直在思考為什麼每一個DevOps的專家都會有自己的回覆，在瞭解了他們的工作環境與商務後，我逐漸明白了這其中的原因。每個IT環境的不同，開發的工具不同，部署的環境不同，人員的能力不同，要達成的目標不同都會造成Devops的方式不同，那麼對於我而言什麼是DevOps，嚴格的來講DevOps其他的是一種文化，一種從整個產品的生命週期的角度，通過自動化的方式減少因為從前由於流程或者認為干預而造成的開發週期冗長、人員效率低下、軟體品質無法許諾的一種方式與思想。

DevOps沒有規定什麼樣的流程是一個標準的流程，因為DevOps的方案是隨著你的商務場景、人員的能力、軟體發展的複雜度、公司的級別等等變化而變化的，只有對於自己的商務與場景而言的合適與不合適，在本列車的後續本文中將會和大家一起討論一些常見的DevOps的實踐與方案，供大家參考。

瀑布開發圖樣、敏捷開發圖樣與DevOps

在大學的電腦課程上面，軟體工程的老師一定會向大家講述的是敏捷開發與瀑布開發。畢業後進入很多大型的公司後。大家面對的基本是瀑布開發圖樣或者敏捷開發圖樣，瀑布開發圖樣大致的結構如下：

核心的思想就是講軟體的生命週期分割為不同的階段，每個階段完成不同的任務，而且大多數情況下每一個階段是由不同的團隊完成的。這種開發圖樣比較適合傳統大型軟體的開發流程，產品擁有者從專案的開始階段就便於估算，專案開發中的每一個階段都被預先計劃，每一個需求都得到確認，在代碼編寫之前專案的結束標準就能夠確定專案是否成功。這樣就許諾了專案開發的目的明確性。但是瀑布開發圖樣的缺點也是明顯的，如果專案的任何一個階段出現問題都可能導致整個項目的問題。從產品經理的角度來講瀑布流可以提高整個產品的規劃，但是對於開發人員來講通常情況是噩夢一樣的存在，特別是當開發人員在多重專案之間共用的情況。
敏捷開發是另種在工作中場景的開發圖樣，敏捷開發的產生一定程度上解決了瀑布開發圖樣的弊端，將一個大型的瀑布開發流程切分成了非常多的小的子任務，通過連續反覆運算的方式一步一步的完成一個大型專案的開發。

看上去敏捷開發與瀑布開發可以解決大部分的問題，那麼DevOps又要解決什麼問題呢。從軟體發展的角色上面來講一個專案的上線需要有開發的人員、運維的人
員、測試的人員。

而DevOps就是用來如何解決三個不同角色之間緊密協作的方式。這句話是非常堂皇的一句口號。到底如何解決協作的問題呢？通常情況下是圍繞著兩個關鍵字：“全域觀”和“自動化”。

全域觀的理解：要從軟體交付的全域出發，加強各角色之前的合作。具體的來講就是，參與項目的軟體發展人員、運維人員、測試人員需要瞭解整個交付程序的步驟和流程。用一個比較實際的例子解釋：在開發一個伺服器端程式的時候，開發人員需要知道如何編寫測試case、最後部署的環境、復原的方案等等。測試的同學需要知道本期軟體的架構使用什麼樣的測試手段與case可以更好的測試軟體並做到快速阻尼的自動化測試，而運維人員需要能夠提供更好的運維工具與運維系統便於開發人員反覆運算、部署、監控整個項目的生命週期。

自動化的理解：人是創造力最強的生物，但卻又是大部分問題出現的根源，盡可能的利用自動化腳本或者例如puppet、chef、ansible等自動化的工具來覆寫原本需要人工或者半人工的動作。

常見的一些DevOps的例子與資料

為了方便大家更好的理解DevOps，下面一些資料可以供大家進行參考，一些比較場景的DevOps的實踐。

什麼是持續整合
DevOps自動化工具
持續傳遞實踐
更穩定的DevOps之chaosmonkey

容器+ DevOps = ContainerOps

當大家瞭解了什麼是DevOps的理念了之後，我們要上線一個新的元素，那就是Docker。當容器遇上了DevOps是否會有什麼其他的挑戰呢？

關於Docker的內容，在此不做過多的介紹，下面我們來看下ContainerOps與傳統的DevOps的相比面臨了那些問題。
1.對於ContainerOps的場景，container到底是作為環境使用還是作為持續整合的基本單元。
2.原本可以採用自動化部署工具例如ansible，當切換為ContainerOps後該怎麼做，取代的方案是什麼。
3.對於傳統的監控與日誌的方式，容器化了之後如何?。
4.對於現有的持續整合工具，如何同容器相結合
5.如何將一個已有的應用程式進行容器化，並使用containerOps
6.對於複雜的部署場景與流程，如何在容器的場景下實現
等等。這些問題將會在本列車的後續本文中一一為大家揭開答案,在下一篇本文中我們將首先會討論的是如何利用容器hub與阿裡雲的容器服務實現一個簡單的containerOps的實踐。

相關產品：

1. 容器服務(Docker)
2. 阿裡雲辦公
3. 阿裡綠網