用開源軟件打造企業級 DevOps 工做流（一）：概述

前言

做爲程序員或開發運維人員，可能不多有沒在開發、部署、交付過程當中遇到過問題的。特別是在企業環境、多人協同工做、模塊紛繁複雜的狀況下，要用簡單粗暴的方式（例如手動上傳代碼，或是線上更改代碼）每每會形成很嚴重的問題。所以對於企業級環境中開發部署來講，有一套嚴格完備的工做流機制會減小不少失誤和所以而致使的延期，增長交付應用的健壯性，從而提高交付效率。

如今有個很流行的名詞叫 DevOps，意爲開發（Development）與運維（Operations）的組合簡寫，從字面上的意思解釋，就是讓開發團隊（Dev）和運維團隊（Ops）相互溝通、融合、協做，旨在促進開發和技術運營與質量保障之間的整合。甚至有些職位就設置爲 DevOps 工程師，要求工程師既作開發，又作運維，這對人自己、技術以及流程要求都較高。

本文將簡單介紹 DevOps，以及 DevOps 工做流程包含的一些基礎架構元素。而本系列文章將從應用開源框架的角度，介紹如何實用開源軟件構建一個健壯、實用的企業級 DevOps 工做流。本系列文章主要集中在 DevOps 三大要素（下面咱們會簡單介紹）中的技術這一塊講解。

本文或本系列文章適合對軟件開發及運維有必定基礎，並想要實踐 DevOps 工做流到工做中的技術人員。

DevOps概述

DevOps 的概念由一個名叫 Patrick Debois 的 IT 諮詢師發明。他在負責測試工做的時候發現，他既須要跟隨開發團隊的敏捷節奏，還須要以傳統方式維護這些系統，並領會到這兩種工做環境的巨大差別。他看到2009年的 Velocity 大會上的一篇轟動世界的演講，該演講提出了以業務敏捷爲中心、構造適應快速發佈軟件的工具（Tools）和文化（Culture）。Patrick 由此萌發了舉辦"社區版" Velocity 大會的想法，取名爲 DevOpsDays，並號召了全球各地的人來參加。DevOps 這個概念由此誕生。

人們對 DevOps 這個概念的認識不盡相同：有認爲 DevOps 是一種技術或平臺的，這種認識過於片面，忽視了人和流程的做用；另外一種認爲 DevOps 是一種流程，這種認識雖然比較合理，也相對片面；還有一種認爲 DevOps 是Dev和Ops的組合的一種職位，這完善了 DevOps 的定義。下圖是 DevOps 的三大元素，能夠看到 DevOps 是平臺（技術）、流程、人的融合出來的結果，少了同樣都會很片面。

本文或系列文章主要關注的是平臺或技術這一塊，講解如何用開源軟件打造企業級 DevOps 工做流。但要注意的是，DevOps 只考慮技術是不夠的，還須要考慮流程和人的因素。若是一個技術人員只知道如何配置 Jenkins 自動發佈應用，而不知道將該流程推廣到整個公司，不能造成一個文化的話，這樣的 DevOps 是失敗的。DevOps 要求有合適的工具，更須要全公司參與，打形成一個工做流程和文化。

下圖是 DevOps 涉及到的技術。

能夠看到，DevOps 涉及的技術至關繁多，包括玲琅滿目的技術類別。咱們不用掌握全部的技術，對不一樣的場景，咱們用合適的工具就足夠。本系列文章將講解一些基礎功能，包括版本控制（VCS）、持續集成（CI）、容器化（Container）、編排（Orchestration）以及網絡（Networking），以及如何用開源軟件實現上述功能。

版本控制（VCS）

版本控制系統（Version Control System）是 DevOps 中重要的環節。這相能夠看做是代碼的數據庫，誰修改了什麼、誰刪除了什麼，均可以經過這個系統來管理。在中大型項目中，不用版本控制系統極可能會致使嚴重的問題。

下面是一個典型的場景。

1. 線上服務被發現有 bug，須要當即修復；
2. 維護人員發現是由於一個變量名稱寫錯致使的；
3. 這名維護人員採用了最快速的線上修改代碼的方式，將這個問題暫時解決了，你們彷佛相安無事；
4. 一個月之後，這個問題又出現了，因爲代碼量和項目複雜度的增長，這個問題隱藏得很深，久久得不到解決，或者好不容易把這個問題解決了，其餘問題又出現了。

其實，若是一開始全部開發人員都用了版本控制系統 Git 或者 SVN 的話，而且要求全部代碼更改都必須進入版本控制，就有很難出現上述這個問題了。

在後續文章中，咱們將講解如何用開源軟件 GitLab 來實現版本控制。

持續集成（CI）

持續集成（Continuous Integration）也是很是重要的部分，由於這個將構建應用並打包上線的工做自動化了，減小了不少人工上線的成本。

能夠想象，沒有持續集成，咱們的部署流程會是什麼樣子：

1. 開發人員開發好一個應用，編寫好部署文檔；
2. 運維人員獲取源碼，並按照部署文檔來部署應用；
3. 中途運維人員發現，部署文檔中缺乏了一個安裝依賴的步驟，須要去找開發人員要這個步驟；
4. 開發人員測試了半天，將正確的部署文檔發給運維人員；
5. 反反覆覆折騰，終於部署好了，但時間也浪費了好幾天。

這是個典型的沒有持續集成的例子。若是採用 Jenkins 將發佈作成自動化的，就不須要部署文檔了，開發人員能夠直接看到部署是否成功，能夠當即調試和配置。

在後續文章中，咱們將講解如何用開源軟件 Jenkins 來實現持續集成和自動部署。

容器化（Container）

想象這樣一個開發場景，爲了保證環境隔離，咱們創建了開發、測試、生產三個環境，每一個環境儘可能保證一致，例如操做系統都爲 Linux，數據庫版本一致，編譯器版本一致，等等。但惋惜的是，咱們不可能徹底作到環境一致，特別是開發者本身的環境，與測試（Test）和生產環境（Production），不可能徹底一致。大多數開發者仍是用的 Windows 操做系統或 Mac OS 系統，但實際測試環境和生產環境大多數狀況是 Linux 的，不少 Windows 或 MacOS 上能夠的，到了服務器上就不能運行了或者有 bug。這都是環境不一致致使的。

早期有解決方案是讓每一個開發者裝一個虛擬機（VM），在上面安裝虛擬的 Linux 環境，讓開發好的應用在上面調試，經過後再測試部署到測試或者生產環境上。自動化的軟件也涌現出來，有著名的 Vagrant，能夠經過編寫配置文件一鍵生成虛擬環境。可是，安裝虛擬機開銷比較大，須要預分配內存和磁盤空間，這對於資源並不充裕的服務器來講不是個最優的解決方案。

2013年，Docker 開源項目橫空出世，實現了容器化功能。它與虛擬機有本質區別，不要求預分配資源。Docker 的使用很是簡單，其中的 容器（Container）概念相似於編程語言中的實例（Instance），鏡像（Image）相似於類（Class），很易於管理，橫向擴展很是簡單。實質上，Docker 的配置跟編寫一個應用差很少，用 Dockerfile 可讓構建一個五臟俱全的應用程序變得很是容易。若是把版本控制系統比喻爲收藏設計圖紙的圖書館，持續集成比喻成工廠流水線，那麼容器則可看做是一個個功能樣式統一的產品。Docker 正在（或者已經）成爲編程部署應用的首選。

在後續文章中，咱們將講解如何利用大紅大紫的 Docker 來構建容器化部署。

編排（Orchestration）

隨着服務器資源變得愈來愈廉價，分佈式應用獲得普及，像微服務這樣的架構在現在正在逐漸成爲主流。而伴隨而來的痛點是如何有效的讓這些分佈式應用或者集羣被更好的管理起來。編排（Orchestration）技術正是這樣的管理集羣的有效方法，保證分佈式應用能獲得很好的擴展。對於一些簡單的應用來講，單機或許已經足夠，但對於某些大型應用，例如搜索引擎爬蟲、高併發服務器、大數據應用，對資源要求較高，須要大規模的分佈式集羣，而爲了管理這些集羣，編排技術必不可少。

Kubernetes 是 Google 開源的容器編排引擎，後續文章將講解如何利用 Kubernetes 實現集羣的管理。

網絡（Networking）

網絡是很是重要的技術。咱們能夠沒有 DevOps 這樣的流程和技術，但 99% 以上的多是少不了網絡技術的。而網絡技術也種類繁多，涉及通訊、傳輸、配置等等，這裏咱們只會講解其中一個類別，也就是反向代理。爲何會講反向代理呢？我相信絕大多數人在開發 Web 應用的時候會碰到配置路由的狀況，而反向代理正是解決網絡路由問題的技術。另外，反向代理還能夠實現負載均衡（Load Balance），合理利用分佈式應用的計算、網絡帶寬等資源。若是沒有反向代理，你會發現不少內部端口會暴露在外，既不安全，也不美觀。

在後續文章中，咱們將講解如何使用 Nginx 實現反向代理，並會介紹如何將其整合到 DevOps 工做流中。

總結

本文介紹了 DevOps 的基本概念，以及簡單介紹了一些 DevOps 工做流中的技術，包括版本控制、持續集成、容器、編排、網絡，另外咱們還介紹了即將在後續系列文章裏講解的開源軟件。可是 DevOps 的技術 RoadMap 絕對不只僅侷限於此，從前面小節中的圖就能夠看出來，要懂得全部技術絕對是 CTO 級別的大師級人物。而咱們也應該瞭解 DevOps 也不只限於技術和平臺，而應該將其與流程跟人結合起來，纔可能很好地實踐 DevOps。

本文只是個開始，後面咱們將更加細緻的講解各項技術以及實現用到的開源軟件，而且如何將他們應用到企業級 DevOps 工做流中來。請關注後續的文章，有更精彩的內容。

若是您以爲本文章對您有幫助，或有任何疑問或建議，請掃描下方二維碼或者加做者微信 tikazyq1 並註明"DevOps"，做者將答疑解惑。