Docker最全教程——從理論到實戰（七）

時間 2019-11-07

原文原文鏈接

在本系列教程中，筆者但願將必要的知識點圍繞理論、流程（工做流程）、方法、實踐來進行講解，而不是單純的爲講解知識點而進行講解。也就是說，筆者但願可以讓你們將理論、知識、思想和指導應用到工做的實際場景和實踐之中，而不是拿着字典寫文章，抱着寶典寫代碼。至於不少具體的語法、技術細節，除了經常使用的知識點，筆者更但願你們閱讀官方文檔——畢竟看官網比看書靠譜多了，官網會一直更新和改進，而書和教程自出版或發佈以後，基本上就「死「了。html

本系列教程預計所有完成還須要2到3個月的時間。在這個過程當中，您能夠和咱們一塊兒討論、交流和分享這一塊的技術。咱們也但願獲得你們的支持，請多多點贊，大家的支持是咱們前進的最大動力！git

Docker和持續集成（CI）

什麼是持續集成？

咱們先得了解持續集成的相關概念，才能更好地指導開發和使用Docker來改進咱們的工做流。和其餘教程不同，筆者更喜歡將必要的知識點圍繞理論、流程（工做流程）、方法、實踐來進行講解，而不是單純的爲講解知識點而進行講解。也就是說，筆者但願爲你們打通任督二脈，可以將理論、知識、思想和指導應用到工做的實際場景和實踐之中，而不是拿着字典寫文章，抱着寶典寫代碼。至於不少具體的語法、技術細節，除了經常使用的知識點，筆者更但願你們閱讀官方文檔——畢竟看官網比看書靠譜多了，官網會一直更新和改進，而書和教程自出版或發佈以後，基本上就「死「了。後端

好了，咱們回到正題。持續集成是一種軟件開發實踐，即團隊開發成員常常集成他們的工做，一般每一個成員天天至少集成一次，也就意味着天天可能會發生屢次集成。每次集成都經過自動化的構建（包括編譯，發佈，自動化測試）來驗證，從而儘早地發現集成錯誤。服務器

徒弟一臉崇拜道：「師父，爲何我作出來的飛劍，一念咒語不是碎了就是爆了呢？」。架構

師父摸了摸鬍子道：「徒兒莫急，冰凍三尺非一日之寒！爲師我刻了3年的陣法，練習了3年的咒語，而後又花了3年一塊兒練習，才讓第一把飛劍飛上了太空。我看你天資聰慧，頂多20年就夠了」。運維

2年後，徒弟邊刻陣法邊唸咒，忽然飛劍的劍身嗖的一下不見了，只餘劍柄。工具

師父：「徒兒，你的飛劍怎麼飛了一截出去了！」post

徒弟握着劍柄行禮道：「師父勿怪，這段時間我對飛劍的製做過程進行了改良，一邊刻陣法一邊唸咒，如今我對陣法和咒語的掌控都達到了70%，因此只有前半截飛出去了！「測試

注意：集成軟件的過程不是新問題，若是項目開發的規模比較小，好比一我的的項目，若是它對外部系統的依賴很小，那麼軟件集成不是問題，可是隨着軟件項目複雜度的增長（即便增長一我的），就會對集成和確保軟件組件可以在一塊兒工做提出了更多的要求-要早集成，常集成。早集成，頻繁的集成幫助項目在早期發現項目風險和質量問題，若是到後期才發現這些問題，解決問題代價很大，頗有可能致使項目延期或者項目失敗。url

核心價值

要素

1.統一的代碼庫

2.自動構建

3.自動測試

4.每一個人天天都要向代碼庫主幹提交代碼

5.每次代碼遞交後都會在持續集成服務器上觸發一次構建

6.保證快速構建

7.模擬生產環境的自動測試

8.每一個人均可以很容易的獲取最新可執行的應用程序

9.每一個人都清楚正在發生的情況

10.自動化的部署

原則

1. 全部的開發人員須要在本地機器上作本地構建，而後再提交的版本控制庫中，從而確保他們的變動不會致使持續集成失敗。

2. 開發人員天天至少向版本控制庫中提交一次代碼。

3. 開發人員天天至少須要從版本控制庫中更新一次代碼到本地機器。

4. 須要有專門的集成服務器來執行集成構建,天天要執行屢次構建。

5. 每次構建都要100%經過。

6. 每次構建均可以生成可發佈的產品。

7. 修復失敗的構建是優先級最高的事情。

8. 測試是將來，將來是測試

持續集成咱們就先說到這裏，建議你們也能夠了解下敏捷開發，畢竟持續集成是敏捷開發的基石，可是敏捷開發是一個大命題，這裏咱們順帶提一下，而後咱們仍是先繼續本篇教程：

師父：「徒兒，你真的在短短3年就讓飛劍飛起來了？」。

徒弟：「弟子愚鈍，在刻劍的過程當中倍覺無聊，又不喜歡哼歌，因而索性邊練咒邊刻劍。後面徒兒發現，若是刻錯了或者唸錯了，飛劍就會提早直接爆炸，雖然每次炸的內褲都沒了，可是可以儘早發現錯誤。因此徒弟才能一日千里」。

師父摸了摸鬍鬚道：「然來如此！不過，這就是你大庭廣衆之下裸奔的藉口！！？」

Docker和持續集成（CI）

相比其餘技術，Docker在持續集成（CI）這塊有着先天的優點。在一般的狀況下，咱們要實現持續集成每每會遇到如下問題：

l 複雜的依賴關係

不一樣的項目環境，不一樣的語言，不一樣的程序包依賴，甚至是操做系統的依賴等等，都會影響到咱們持續集成的自動化腳本的執行。並且依賴包之間的兼容性，版本的兼容性，間接依賴或者多重依賴等問題等等，對於開發和運維來講，都是一個噩夢。就如如下對話：

徒弟：「師父，我按照您教的方式唸咒，爲何飛劍飛起來了以後就收不回來了？」。

師父直接一巴掌，說：「兔崽子，上次就和你說了，咒語如今最低的兼容級別是——普通話二級乙等！誰教你說長沙話的！」

l 不一致的環境

在一般的環境中，咱們須要準備好開發、測試和生產環境，每每開發環境隨便開發人員折騰，有時候操做系統或者依賴軟件的版本的區別、組件的不一樣、配置不同，都足夠讓開發環境正常運行的程序在測試環境上跑不起來，形成測試人員和開發人員的故意傷害事件，致使「行兇人員」後悔終生，感悟到「衝動就是魔鬼」的箴言。咱們仍是以對話來闡述這個問題：

徒弟拿出普通話二級乙等證書道：「師父，我苦學普通話，終於達到普通話二級乙等。而後按照您教的方式唸咒了，以後爲何飛劍飛起來了以後仍是無法收回來？」。

師父又是一巴掌，說：「兔崽子，你沒看到下雨了麼？」

徒弟弱弱的問：「這個和下雨有關係麼？是否是雨天法術受雨滴乾擾，咒語的效果受到影響呢？」

師父指着外面道：「瞎了？你丫的不趕忙把被子收回來烘乾，你的飛劍就甭想要了！」

l 應用架構的複雜性和配置的多樣性

如今的系統架構愈來愈複雜，甚至由多種開發語言組成，並且包含先後端等多方面內容。這些可能會致使其部署方式的不一樣以及配置的複雜性。而且一個系統維護到後面，每每有不少歷史遺留問題，好比那各類配置文件和配置方式，各類補丁，各類腳本等等。這些因素會致使自動化流程會很是麻煩和艱難。咱們繼續來一段對話：

徒弟：「師父，被子收好了，可是飛劍越飛越遠了，是否是能夠教我收回個人飛劍啦！」。

師父張開一隻眼：「小崽子，普通話念完後，用長沙話再念一遍收劍咒！前幾天，爲師對收劍咒又進行了改造。」

徒弟用長沙話念完，飛劍仍是再天空中亂竄，並無降下來的意思。徒弟趕忙問道：「師父，爲啥仍是不行呢？」

師父彈了彈手指，遠處一根若隱若現的細線展示出來，師父指着那根線說：「看到那邊那根線沒？還不趕忙去追！」

相比這些問題，Docker實現持續集成（CI）就方便多了。

首先，Docker可讓咱們很是容易和方便地以「容器化」的方式去部署應用。它就像集裝箱同樣，打包了全部依賴，再在其餘服務器上部署很容易，不至於換服務器後發現各類配置文件散落一地，這樣就解決了編譯時依賴和運行時依賴的問題。