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

時間 2020-04-23

原文原文鏈接

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

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

使用Azure DevOps來完成CI

Azure DevOps，之前叫VSTS，如今被微軟更名部正式改名爲Azure DevOps，說明微軟云爲先之心仍然蠢蠢欲動。不過和VSTS同樣，微軟都提供了免費的使用額度，對於小團隊和我的開發者來講，徹底是足夠了。docker

什麼是DevOps？

DevOps（Development和Operations的組合詞）是一組過程、方法與系統的統稱，用於促進開發（應用程序/軟件工程）、技術運營和質量保障（QA）部門之間的溝通、協做與整合。它是一種重視「軟件開發人員（Dev）」和「IT運維技術人員（Ops）」之間溝通合做的文化、運動或慣例。透過自動化「軟件交付」和「架構變動」的流程，來使得構建、測試、發佈軟件可以更加地快捷、頻繁和可靠。它的出現是因爲軟件行業日益清晰地認識到：爲了按時交付軟件產品和服務，開發和運營工做必須緊密合做。安全

DevOps的引入能對產品交付、測試、功能開發和維護（包括──曾經罕見但現在已家常便飯的──「熱補丁」）起到意義深遠的影響。在缺少DevOps能力的組織中，開發與運營之間存在着信息「鴻溝」──例如運營人員要求更好的可靠性和安全性，開發人員則但願基礎設施響應更快，而業務用戶的需求則是更快地將更多的特性發布給最終用戶使用。這種信息鴻溝就是最常出問題的地方。網絡

DevOps常常被描述爲「開發團隊與運營團隊之間更具協做性、更高效的關係」。因爲團隊間協做關係的改善，整個組織的效率所以獲得提高，伴隨頻繁變化而來的生產環境的風險也能獲得下降。架構

總之，經過DevOps，各專業團隊之間的協調和協做獲得改善，縮短了將更改提交到系統與將更改投入到生產之間的時間。它還可確保此過程符合安全性和可靠性標準。結果：產品質量改善、交付速度加快、客戶滿意度提高。框架

DevOps對應用程序發佈的影響

在不少企業中，應用程序發佈是一項涉及多個團隊、壓力很大、風險很高的活動。然而在具有DevOps能力的組織中，應用程序發佈的風險很低，緣由以下：運維

減小變動範圍

與傳統的瀑布式開發模型相比，採用敏捷或迭代式開發意味着更頻繁的發佈、每次發佈包含的變化更少。因爲部署常常進行，所以每次部署不會對生產系統形成巨大影響，應用程序會以平滑的速率逐漸生長。工具

增強發佈協調

靠強有力的發佈協調人來彌合開發與運營之間的技能鴻溝和溝通鴻溝；採用電子數據表、電話會議、即時消息、企業門戶（wiki、sharepoint）等協做工具來確保全部相關人員理解變動的內容並全力合做。單元測試

自動化

強大的部署自動化手段確保部署任務的可重複性、減小部署出錯的可能性。

與傳統開發方法那種大規模的、不頻繁的發佈（一般以「季度」或「年」爲單位）相比，敏捷方法大大提高了發佈頻率（一般以「天」或「周」爲單位）。減小變動範圍與傳統的瀑布式開發模型相比，採用敏捷或迭代式開發意味着更頻繁的發佈、每次發佈包含的變化更少。因爲部署常常進行，所以每次部署不會對生產系統形成巨大影響，應用程序會以平滑的速率逐漸生長。增強發佈協調靠強有力的發佈協調人來彌合開發與運營之間的技能鴻溝和溝通鴻溝；採用電子數據表、電話會議、即時消息、企業門戶（wiki、sharepoint）等協做工具來確保全部相關人員理解變動的內容並全力合做。強大的自動化部署手段可以確保部署任務的可重複性、減小部署出錯的可能性。

適用於容器的 CI/CD 流程

使用容器，可輕鬆地持續生成和部署應用程序。

Azure DevOps 能夠經過設置持續版本以生成容器映像和業務流程，讓咱們能更快、更可靠地進行部署。如下是一個適用於容器和Azure的CI/CD 流程：

步驟說明：

使用Azure DevOps來配置一個簡單的CI流程

Azure DevOps服務涵蓋了整個開發生命週期，可幫助開發人員更快地高質量地交付軟件，其提供了Azure Pipelines、Azure Boards、Azure Artifacts、Azure Repos和Azure Test Plans。關於Azure DevOps咱們就介紹到這裏，畢竟是免費介紹。

如今，咱們須要側重介紹的是Pipelines，也就是代碼流水線。看，多形象，因此之前自誇爲碼農是錯誤的，咱們應該是碼工，廣大流水線工人的一環，無產階級之一，共產主義接班人。很差意思，又偏題了，咱們繼續：

首先，咱們須要定義一個流水線，爲了便於演示，我這裏就定義一些針對Docker的簡單步驟，你們能夠按需添加步驟，好比單元測試步驟等等。

如圖所示，步驟很簡單，首先設置代碼源，這裏咱們直接對接Magicodes.Admin框架的git庫地址。Git庫地址你們能夠在這裏找到：https://gitee.com/xl_wenqiang/Magicodes.Admin.Core。

由於代碼是託管再碼雲，因此咱們選擇如上圖所示的最後一種方式，而且選擇對應的分支。

接下來，咱們須要添加job和task。job添加一個默認的便可，無需設置什麼條件和參數。接下來咱們添加task，實際上就是步驟。

第一步，構建鏡像。

咱們須要添加一個docker task:

而後設置command命令爲build，也就是構建：

構建配置咱們能夠根據本身的需求來設置，好比根據分支設置鏡像版本等等。

第二步，登陸騰訊雲鏡像倉庫而且推送。

這一步，就有點門檻了，原生的docker命令並很差使，由於task之間的上下文是斷開的，也就是login了你也無法push。這時候，仍是命令行靠譜，簡單粗暴。因此咱們須要添加一個Command line task：

而後編寫命令腳本：

簡單粗暴的兩個步驟就搞定了，你們能夠根據本身的持續集成流程來定製，畢竟微軟在開發者服務這塊淫蕩多年，仍是至關給力的。咱們能夠初步看看支持的task：

很是之多，足夠咱們隨便玩了。並且玩壞了還不用賠錢。

接下來，跑起來：

點開還能看到詳細的過程：

激不激動，簡單不簡單？就這麼幾下就搞定了。產品很強大，就是拉取代碼有點慢，看起來是託管在國外。順手一查，額，美國：

所以，咱們不是很推薦使用Azure DevOps來完成CI，網絡的延遲足夠拖垮咱們焦慮的神經。可是若是咱們的代碼託管在Github，那麼使用Azure DevOps是不錯的選擇。在接下來的教程中，咱們會講解如何打造本身的Github開源庫的CI流程——不只徹底自動化，並且還支持在readme頁面添加各類動態圖標。