DevOps介紹

DevOps(Deveplopment和Operations的簡稱)，中譯為開發運維一體化，可定義為是一種過程、方法、文化、運動或實踐，主要是為了通過一條高度自動化的流水線來加強開發和其他IT職能部門之間的溝通和協作，加速軟體和服務的交付。

在一個較成熟的軟體和服務交付的團隊裡，就技術層面來說主要分為三個組成部分:開發、測試和運維。DevOps的作用就是將這三個部分緊密的連線起來，提供一條從軟體開發到質量保障到技術運營的自動化流水線，加強不同角色之間的溝通和協作，基於使用者需求實現軟體和服務的快速交付。

"開發的這群傻叉新給的釋出包又把系統CPU搞到100%了，應用又夯住了，都是些什麼水平的人啊..."

"運維的這幫傻鳥技術太差，維護的是些什麼稀爛的系統，在我這跑得好好的，上他們那應用就掛..."

"這是開發的鍋..."

"這是運維的盤..."

描述得略顯浮誇...但這種踢皮球的事情在IT公司裡面真的是隨處可見。無謂對錯，也無鍋可背，都是由開發和運維的基因所決定，但是最終的受害者卻是使用者。偏偏比較有意思的就是，開發和運維人員所做的這些也都是為了使用者，開發人員必須根據使用者的需求對應用的功能進行不停的變更，運維人員也必須根據使用者的需求提供穩定和持續的服務。各司其職的同時也在兩者之間形成了一面無形的牆，阻礙了開發和運維之間的溝通和協作，而DevOps的出現就是為了擊碎這堵無形之牆。

DevOps落地的思考

技術層面

DevOps不是一個工具，但它需要被工具來實現，好在現今已經有了很多商業版和開源版的軟體來形成一個有效的工具鏈來作為DevOps技術層面的支撐。但是光有工具還不夠，再好的工具沒人會用也沒意義，所以需要有熟悉這個工具鏈的IT人員來提供技術支援，利用工具實現DevOps的高度自動化。

流程層面

DevOps是一條從開發到運維的流水線，想要流水線能夠高效的自動執行，必須要設定一系列的流程和規範來進行管控。IT的管理者需要有基於軟體或服務交付的全域性觀，能夠清晰的認識到交付週期中不同角色的痛點在哪裡，進而定製出合適的協作流程。

組織層面

DevOps並不是簡單的將開發部門和運維部門合併，而是加強開發部門和運維部門之間的協作和溝通。這需要管理者們對企業的IT部門有著足夠的重視並且願意去推動DevOps這種開發和運維間高效協作的模式，並且開發和運維的人員之間也需要有開放、接納和協作的意識。

DevOps是一個虛無縹緲的玩意兒，它並不能被工具或軟體來簡單的定義或量化。但工具或軟體卻是實現DevOps的一個重要組成部分，而Docker就是實現DevOps最合適的工具之一。

Docker介紹

Docker是一個分散式應用構建、遷移和執行的開放平臺，它允許開發或運維人員將應用和執行應用所依賴的檔案打包到一個標準化的單元(容器)中執行。

容器是一個非常早期的技術，Unix的chroot功能可以說是容器的雛形，而後到大家所熟知的基於Namespace和Cgroups技術的LXC(Linux Container)，最後到現在如日中天的Docker。站在前人的肩膀之上，Docker最妙的地方就是將容器的使用簡單化和標準化，再配合一波開源，網際網路，雲端計算，大資料的浪潮，可謂是時代的寵兒。

很多人都喜歡拿容器和虛擬機器對比，其實容器和虛機都是屬於虛擬化技術的一種實現。兩種架構在底層上相同，需要物理硬體和作業系統的支援。不同的是虛擬機器場景中，Hypervisor(如KVM)作為作業系統到虛擬機器的中間層,而容器場景中Docker Engine(以Docker為例)作為作業系統到容器的中間層。虛機封裝作業系統和應用，而容器則直接封裝應用，這也是為什麼容器要比虛機輕量的原因。

上圖中將虛擬機器和容器的特性進行了對比，可以看出容器相對於虛擬機器比較有優勢的地方就是輕量、靈活、資源利用率高。缺點主要就是隔離性不如虛擬機器，也就是一直被無限放大的容器的安全性問題。但偏偏就是因為容器沒有完全被隔離到一個密封的小黑屋裡面，所以才能帶來比虛擬機器更好的資源利用率。

個人認為容器在短期之內還取代不了虛機，在未來很長一段時間內會是容器和虛機並存的情況。而到最終誰替代誰，取決的不是技術本身，而是使用者體驗時代的需求。

PS:希望有朋友能夠發現此圖中的一點小漏洞。

Docker基本元件介紹

• Docker Image 
  Docker映象是一個執行容器的只讀模板。
• Docker Container 
  Docker容器是一個執行應用的標準化單元。
• Docker Registry 
  Docker註冊伺服器用來存放映象。
• Docker Engine 
  Docker引擎用來在主機上建立，執行和管理容器。

瞭解Docker的朋友都知道,Docker將自身最主要的特點以下面這一句話來描述"Build,Ship and Run Any App Anywhere"。Build出Image，然後使用Registry來Ship映象，最終使用Engine將Container和包含的App在任意平臺(Anywhere)上執行起來。

Docker原生工具介紹

• Docker Machine 讓使用者在基礎架構平臺快速部署Docker宿主機
• Docker Swarm 讓使用者在叢集環境中排程和執行容器
• Docker Compose 讓使用者在叢集環境中編排和部署應用

這三個工具構成了Docker的原生環境，加上比較火的k8s,Mesos,Rancher,etcd等外部生態，構建出了一個比較完整的Docker容器生態圈。對於原生工具和外部工具，個人覺得工具或技術並沒有好壞之分，主要還是看適用場景和客戶需求。而正是有這些生態的合作和競爭造就的亂世，才促進了容器技術的高速發展和逐步成熟。

Docker適用的場景

• 持續整合和持續交付
• 開發運維一體化
• 容器雲
• 大資料 
  

Docker官方給的Use Case是CI/CD,DevOps,Big Data和Infrastructure Optimization(Cloud)。

這裡比較有意思的就是，這幾個使用場景似乎正好描繪著Docker當前的發展史。

起初Docker的出現主要面向的物件是開發者，為開發者提供應用快速開發和測試的環境，這就是CI/CD所在的場景。

隨後的發展使得Docker不再僅僅只關注開發層面的東西，而在向運維層面邁進，就出現了DevOps的場景。

既然有了運維，那肯定避免不了接觸到基礎架構的東西，而現今的基礎架構基本都是圍繞著雲端計算來展開，所以Docker又涉及到了基礎架構優化的層面，也就是Container Cloud。

基礎架構的容器雲有了，那麼勢必需要對雲中的應用提供服務，加上Docker自身的許多優勢，自然而然的又涉及到了Big Data的使用場景。

而Docker自身的解決方案Docker Cloud和Docker Data Center的先後推出也側面反應了從開發到運維場景的逐步支援。DDC的出現更是將目標直接瞄準了企業內部容器雲。

難以分清是新技術成就了Docker，還是Docker承載了新技術。至少就目前來看，Docker的發展方向是順應這個時代的。這只是三歲多的Docker，不敢想象它在將來會有多大的能量爆發出來，將這些留給時間去述說。

Docker實現DevOps的優勢

優勢一

開發、測試和生產環境的統一化和標準化。映象作為標準的交付件，可在開發、測試和生產環境上以容器來執行，最終實現三套環境上的應用以及執行所依賴內容的完全一致。

優勢二

解決底層基礎環境的異構問題。基礎環境的多元化造成了從Dev到Ops過程中的阻力，而使用Docker Engine可無視基礎環境的型別。不同的物理裝置，不同的虛擬化型別，不同雲端計算平臺，只要是運行了Docker Engine的環境，最終的應用都會以容器為基礎來提供服務。

優勢三

易於構建、遷移和部署。Dockerfile實現映象構建的標準化和可複用，映象本身的分層機制也提高了映象構建的效率。使用Registry可以將構建好的映象遷移到任意環境，而且環境的部署僅需要將靜態只讀的映象轉換為動態可執行的容器即可。

優勢四

輕量和高效。和需要封裝作業系統的虛擬機器相比，容器僅需要封裝應用和應用需要的依賴檔案，實現輕量的應用執行環境，且擁有比虛擬機器更高的硬體資源利用率。

優勢五

工具鏈的標準化和快速部署。將實現DevOps所需的多種工具或軟體進行Docker化後，可在任意環境實現一條或多條工具鏈的快速部署。

例項分享

架構介紹

該DevOps環境基於開源產品Rancher進行管理，分為三套環境和一套橫跨各環境的私有Registry。基於RancherUI和Docker宿主機，每套環境對不同的角色配置許可權管理，每個角色僅能訪問對應的環境。開發、測試和運維人員可自由選擇Web UI或Docker CLI的方式去管理自己的環境。

DEV ENV

定義為開發環境，包含開發人員客戶端的筆記本和服務端的一臺Docker主機。

**TEST ENV **

定義為測試環境，包含測試人員客戶端筆記本和服務端的一臺Docker主機。

OPS ENV

定義為運維環境，包含運維人員客戶端筆記本和服務端的兩臺Docker主機構建的Swarm叢集。

**Pri-Registry **

私有映象伺服器，整個DevOps流水線中的核心。將映象作為最終的交付件在不同的環境中Ship和Run，以實現從Dev到Ops應用環境的一致性部署。

運作流程

• 開發者通過本地的Git客戶端向服務端的Gogs提交程式碼，Jenkins將程式碼構建成映象放到本地。開發人員將對應的映象啟動容器來預覽的開發結果。如果確認已滿足預期，則將該映象推送到私有的Docker註冊伺服器中進行儲存。
• 測試人員將私有映象倉庫中開發人員新提交的映象執行成容器，並進行手動或者自動的功能性測試，測試通過後映象會被打上一個新的Tag以被其他環境使用。
• 運維人員基於私有映象倉庫中被打過Tag的映象啟動為容器，最終交付給客戶。

目前該環境主要用於Docker Image的構建和釋出，Ops(Prod)環境中跑了一些專案內部使用的應用，但更多的是作為Demo環境提供給客戶訪問而並非真正意義上的生產環境。