DevOps 介紹
DevOps（Deveplopment 和 Operations 的簡稱），中譯爲開發運維一體化，可定義爲是一種過程、方法、文化、運動或實踐，主要是爲了經過一條高度自動化的流水線來增強開發和其餘 IT 職能部門之間的溝通和協做，加速軟件和服務的交付。html
在一個較成熟的軟件和服務交付的團隊裏，就技術層面來講主要分爲三個組成部分：開發、測試和運維。DevOps的做用就是將這三個部分緊密的鏈接起來，提供一條從軟件開發到質量保障到技術運營的自動化流水線，增強不一樣角色之間的溝通和協做，基於用戶需求實現軟件和服務的快速交付。git
「開發的這羣傻叉新給的發佈包又把系統 CPU 搞到100%了，應用又夯住了，都是些什麼水平的人啊……」安全
「運維的這幫傻鳥技術太差，維護的是些什麼稀爛的系統，在我這跑得好好的，上他們那應用就掛……」服務器
「這是開發的鍋……」微信
「這是運維的盤……」架構
描述得略顯浮誇……但這種踢皮球的事情在 IT 公司裏面真的是隨處可見。無謂對錯，也無鍋可背，都是由開發和運維的基因所決定，可是最終的受害者倒是用戶。恰恰比較有意思的就是，開發和運維人員所作的這些也都是爲了用戶，開發人員必須根據用戶的需求對應用的功能進行不停的變動，運維人員也必須根據用戶的需求提供穩定和持續的服務。各司其職的同時也在二者之間造成了一面無形的牆，阻礙了開發和運維之間的溝通和協做，而DevOps的出現就是爲了擊碎這堵無形之牆。運維
DevOps落地的思考
技術層面
不是一個工具，但它須要被工具來實現，好在現今已經有了不少商業版和開源版的軟件來造成一個有效的工具鏈來做爲 DevOps 技術層面的支撐。可是光有工具還不夠，再好的工具沒人會用也沒意義，因此須要有熟悉這個工具鏈的 IT 人員來提供技術支持，利用工具實現 DevOps 的高度自動化。分佈式
流程層面
DevOps 是一條從開發到運維的流水線，想要流水線可以高效的自動運行，必需要設定一系列的流程和規範來進行管控。IT 的管理者須要有基於軟件或服務交付的全局觀，可以清晰的認識到交付週期中不一樣角色的痛點在哪裏，進而定製出合適的協做流程。工具
組織層面
DevOps 並非簡單的將開發部門和運維部門合併，而是增強開發部門和運維部門之間的協做和溝通。這須要管理者們對企業的 IT 部門有着足夠的重視而且願意去推進 DevOps 這種開發和運維間高效協做的模式，而且開發和運維的人員之間也須要有開放、接納和協做的意識。post
DevOps 是一個虛無縹緲的玩意兒，它並不能被工具或軟件來簡單的定義或量化。但工具或軟件倒是實現 DevOps 的一個重要組成部分，而 Docker 就是實現 DevOps 最合適的工具之一。
Docker介紹
Docker 是一個分佈式應用構建、遷移和運行的開放平臺，它容許開發或運維人員將應用和運行應用所依賴的文件打包到一個標準化的單元（容器）中運行。
容器是一個很是早期的技術，Unix 的 Chroot 功能能夠說是容器的雛形，然後到你們所熟知的基於 Namespace 和 Cgroups 技術的 LXC（Linux Container），最後到如今如日中天的 Docker。站在前人的肩膀之上，Docker 最妙的地方就是將容器的使用簡單化和標準化，再配合一波開源、互聯網、雲計算、大數據的浪潮，可謂是時代的寵兒。
不少人都喜歡拿容器和虛擬機對比，其實容器和虛機都是屬於虛擬化技術的一種實現。兩種架構在底層上相同，須要物理硬件和操做系統的支持。不一樣的是虛擬機場景中，Hypervisor（如 KVM）做爲操做系統到虛擬機的中間層，而容器場景中 Docker Engine（以 Docker 爲例）做爲操做系統到容器的中間層。虛機封裝操做系統和應用，而容器則直接封裝應用，這也是爲何容器要比虛機輕量的緣由。
上圖中將虛擬機和容器的特性進行了對比，能夠看出容器相對於虛擬機比較有優點的地方就是輕量、靈活、資源利用率高。缺點主要就是隔離性不如虛擬機，也就是一直被無限放大的容器的安全性問題。但恰恰就是由於容器沒有徹底被隔離到一個密封的小黑屋裏面，因此才能帶來比虛擬機更好的資源利用率。
我的認爲容器在短時間以內還取代不了虛機，在將來很長一段時間內會是容器和虛機並存的狀況。而到最終誰替代誰，取決的不是技術自己，而是用戶體驗時代的需求。
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 的原生環境，加上比較火的 Kubernetes、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 化後，可在任意環境實現一條或多條工具鏈的快速部署。