docker如何創建持續部署流水線

本篇內容主要講解“docker如何創建持續部署流水線”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“docker如何創建持續部署流水線”吧!

創建持續部署流水線

我們已經創建好了測試環境，在前文中我們也構建好了CI流水線，由它來創建應用、將應用打包進容器、進行集成測試。現在我們將來到本系列文章的最終章，拓展CI流水線來創建一個持續部署流水線。

發布Docker鏡像

我們首先將打包的鏡像發布到Docker存儲庫中。方便起見，我們使用了一個公共DockerHub倉庫，不過，對于實際的開發項目，我們還是建議將Docker鏡像push到私有庫中。下面我們在Jenkins中創建一個新的Free Style Project任務，點擊New Item按鈕，把任務命名為push-go-auth-image。完成了這些步驟后，你會進入到Jenkins任務配置頁面，在這里你可以定義push你的go-auth鏡像到Dockerhub所需要的步驟。

因為這是我們對前一章中構建的流水線的后續，因此該作業會有和go-auth-integration-test作業類似的配置。你需要首先設置的是parameterized build并且添加GO_AUTH_VERSION變量。

要push鏡像，我們選擇Add build step下拉菜單，然后選擇Execute shell選項。在結果文本框中添加下面的命令。在這些命令中，我們將登陸到DockerHub，并且push我們之前構建好的鏡像。這里我們準備將其push到usman/go-auth倉庫中，而你則需要把它推送到自己的DockerHub庫中。

上一章提到，我們使用的是git-flow分支模型，其所有的功能分支都合并到“開發”分支中。為了能夠不斷地將發生的變更部署到集成環境中，我們需要一個簡單的機制來生成基于開發分支的最新鏡像。在打包過程中，我們使用GO_AUTH_VERSION來標記docker容器（例如，docker build -t usman/go-auth:${GO_AUTH_VERSION} ....）。在默認情況下，這個版本將會成為開發分支，但是本章后面我們將為我們的應用程序創建新發布，使用CI/CD流水線來構建、打包、測試，并把它們部署到我們的集成環境中。要注意的是，在這個方案中，我們總會覆蓋我們開發分支的鏡像（usman/go-auth:develop） ，這限制了我們引用歷史構建以及執行回滾。你可以對流水線做一個簡單的更改，把Jenkins構建編號添加到自身的版本名稱上，比如usman/go-auth:develop-14。

你需要指定你的DockerHub用戶名、密碼和電子郵件地址。你可以在每次運行時用參數構建的方式指定它們，也可以使用Jenkins Mask Passwords Plugin在主要的Jenkins配置中安全地定義它們，并將它們添加到構建中。要確保Build Environment中為你的作業啟用了“Mask passwords（并且啟用全局密碼）”。

現在我們需要確保這個作業是在集成測試作業之后才觸發的。要做到這一點，我們需要更新集成測試作業，以便使用當前的構建參數觸發參數化構建。這意味著在每次成功運行集成測試作業后，我們會把測試好的鏡像push到DockerHub上。

最后，我們需要在鏡像成功push到DockerHub之后觸發部署作業。就像我們為其他作業所做的一樣，我們可以通過添加構建后操作來實現這一點。

部署到集成環境

我們將使用Rancher Compose CLI來停止運行的環境，從DockerHub獲取最新的鏡像，并重新啟動環境（提醒一下，Updates API還在發展，可能會發生變化。未來幾周或者幾個月內肯定會增加新的功能，因此請隨時查看文檔是否有更新項）。在我們創建Jenkins作業來實現持續部署之前，我們先手動完成這些步驟。

我們可以使用最簡單的方法——停止所有服務（auth服務、負載均衡器以及mysql），提取最新的鏡像并啟動所有服務。然而，對于我們來說，我們只想更新應用程序，而并不想停止長時間運行的環境，這樣就不太理想了。要更新我們的應用程序，我們首先要停止auth-service。你可以在Rancher Compose使用stop命令完成操作。

這會停止運行goauth服務的所有容器，你可以在Rancher UI中打開堆棧來驗證該服務的狀態是否設置為Inactive（不活躍）。接下來，我們要讓Rancher拉取我們想要部署的鏡像版本。現在，我們已經可以動態指定想要運行的版本，而無需每次都要更新模板了。如果你需要多次push相同的鏡像版本，請添加pull開關，確保我們使用的是鏡像版本的最新副本。

我們還可以通過下面的命令使用升級功能，零停機地實現環境的滾動更新。下一節中我們將進一步討論滾動更新。在升級完成后，你可以使--rollbach命令或--confirm-upgrade來確認更改或者回滾到預覽狀態。

現在我們已經知道該如何運行我們的更新，我們在流水線中創建一個Jenkins作業來執行此操作。和之前一樣，創建一個新的freestyle項目，命名為deploy-integration。與其他的作業一樣，它也是一個參數化構建，用GO_AUTH_VERSION作為字符串參數。接下來，我們要從上游的build-go-auth作業中復制工件。

最后，我們需要向Execute Sheell構建步驟中添加Rancher Compose up命令，這是我們在之前指定好的。需要注意，你還需要提前在Jenkins上設置Rancher CLI，讓它可以用于你在系統路徑上的構建。執行shell步驟的內容和下面的代碼片段相似。如果你有多個Rancher Compose節點，負載均衡器容器可能會在不同的主機上啟動，你的Route 53記錄集合就可能需要更新。

有了我們兩個新的Jenkins作業，我們從上一章就開始構建的流水線現在看起來就像下圖所示。每次對我們示例應用程序的check-in都會被編譯，確保其沒有出現語法錯誤并且能夠通過自動化測試。然后，將這些變更打包，通過集成測試，最后再部署到手動測試中。下面的五個步驟為構建流水線提供了一個良好的基線模板，并且有助于將代碼從開發階段轉移到測試和部署階段上。擁有一個連續的部署流水線確保了代碼不僅可以進過自動化系統的測試，而且還能快速提供給測試人員使用。除此之外它還能夠作為生產部署自動化的模型，測試操作工具和代碼，持續部署應用程序。

發布和部署一個新的版本

在我們將代碼部署到持續的可測試環境中后，我們就會讓QA團隊測試對這些變更進行一段時間的測試。在他們確定代碼已經就緒后，我們可以創建一個發布，隨后將它部署到生產環境中。用git-flow發布的方式類似于特征分支（我們在前一章討論過的工作方式），我們使用gitflow release start [Release Name]命令（如下所示）進行發布。這將創建一個新的名稱來發布分支。在這個分支中，我們將執行一些內部的操作，比如增加版本號，做最后的修改。

完成這些后，我們運行releasefinish命令將發布分支合并到主分支中。這樣，主分支總能反映出最新發布的代碼。另外，每個發布都會加上標簽，對每個發布的內容都能夠有歷史記錄。如果我們不需要再進行其他的更改，我們就可以確定最終的發布了。

最后一步就是把發布push到遠端倉庫中

git push origin master git push --tags //pushes the v1 tag to remote repository

如果你使用的是Github來托管git庫，現在應該會發現有一個新的版本了。我們還可以將與發布名稱相匹配的版本鏡像push到DockerHub，這也是一個不錯的選擇。我們先運行第一項作業來觸發我們的CD流水線。可能你還記得，我們為CI流水線設置了GitParameter插件，以便能夠從git中獲取與過濾器相匹配的所有標記。不過，這是對于默認的開發分支而言，當我們手動觸發流水線時，我們可以從git標簽中進行選擇。例如，在下面我們為應用程序提供了兩個版本。我們選擇其中一個，啟動集成和部署流水線。

然后，經過以下步驟，我們的應用程序1.1版本將會被部署到長時間運行的集成環境中，只需要點擊幾下就能實現。

1. 從git中獲取所選的發布

2. 構建應用程序，運行單元測試

3. 創建一個帶有標簽v1.1的新鏡像（比如usman/go-auth:v1.1）

4. 運行集成測試

5. Push鏡像（usman/go-auth:v1.1）到DockerHub

6. 將該版本部署到我們的集成環境

部署策略

管理長時間運行的環境時會遇到很多挑戰，其中之一就是盡可能在發布期間的停機時間要降至最短，最好為零。為了讓這個過程可預測并且安全，需要做相當多的工作。自動化和質量保證確實可以大大提高發布的可預測性和安全性。不過即使是這樣，失敗也會發生，而且對任何優秀的運維團隊來說，他們的目標都是在最小化影響的同時快速恢復。在本節中，我們將介紹一些部署長時間運行環境的策略以及它們的優缺點。

就地更新

第一個策略稱為就地更新（In-placeupdates），顧名思義，它的思想就是復用應用程序環境，并且就地更新應用程序。這有時也稱作是滾動部署。我們將使用我們目前討論的示例應用程序（go-auth）。此外，我們假定你有用Rancher運行的服務。如果要就地更新，你可以使用下面的升級命令：

在用戶看不到的地方，Rancher agent會在每個運行auth服務容器的主機上獲取新的鏡像（--pull會重新下載，盡管鏡像已經存在）。之后代理會停止舊的容器，批量啟動新的容器。你可以使用--batch-size標志來控制批處理的大小。此外，你還可以指定批更新之間的暫停時間間隔（--interval），使用足夠大的時間間隔來驗證新容器的行為是否按照預期運行，并且總體而言，服務是健康的。在默認情況下，舊的容器終止后，新的容器會在它們的位置上啟動。或者你可以在rancher-compose.yml中設置start_first標志，告訴Rancher在啟動新容器之前先停止舊容器。

如果對當前的更新不滿意想要回滾，可以使用回滾標志來完成回滾。或者你想要繼續進行更新，只需告訴rancher指定confirm-update標志完成更新即可。你也可以在原始的up命令中指定confirm-update標志一步完成這些操作。你還可以在RancherUI執行更新，從服務菜單（下圖所示）中選擇“upgrade”。

就地更新非常簡單，不需要額外的資源來管理多個堆棧。然而，這種生產方式是存在缺點的。首先，對回滾更新進行細粒度控制大多很困難，就是說在故障發生的情況下它們往往是難以估計的。例如，處理部分故障和滾動更新會變得非常混亂。你需要知道在哪些節點上部署了更改，哪些沒能部署，還有哪些仍在運行之前的版本。其次，你還需要保證所有的更新不僅是向后兼容，還能向前兼容，因為舊版本和新版本都是需要在相同的環境中同時運行的。最后，根據使用的情況，就地更新可能不實用。比如，如果老的客戶端需要繼續使用舊環境，而新的客戶端需要向前滾。在這種情況下，使用我們今天要列出的方法分離客戶端會更加容易。

藍綠部署

就地更新的一個問題是缺少可預測性。為了克服這一問題，另一個部署策略是針對應用程序使用兩個并行堆棧：一個處于活躍狀態，另一個處于待機狀態。要運行新版本，部署應用程序的最新版本到待機堆棧。當驗證到新版本需要工作，將會從活動堆棧切換流量到備用堆棧上。這時，先前活躍的堆棧稱為備用堆棧，反之亦然。該策略允許驗證已經部署的代碼、快速回滾（切換備用和重新激活），并還可以在需要時擴展兩個堆棧的并發操作。這種策略通常被稱為藍綠部署。用我們的示例應用程序完成這樣的部署，可以簡單地在Rancher中創建兩個堆棧：go-auth-blue和go-auth-green。此外，我們假設數據庫不是這些堆棧的一部分，而是獨立管理的。每個堆棧都會運行goauth和auth-lb服務。如果假設go-auth-green堆棧式活躍的，要執行更新，我們要做的就是將最新版本部署到藍色堆棧中，執行驗證并將流量切換到它這。

流量切換

有兩個方法可用于執行流量切換，更改DNS記錄來指向新堆棧，或者使用代理或負載均衡器，將流量路由到活動堆棧。下面我們會詳細介紹這兩個方法。

記錄更新

一個簡單的方法是更新DNS記錄指向活動堆棧。這種方法的一個優點是，我們可以使用加權DNS記錄將流量慢慢轉換到新版本中。這也是執行canary releases的簡單方法，對安全地在實時環境中進行更新或者做A/B測試非常有用。例如，我們可以將實驗性的功能更部署到自己的功能堆棧（或活動堆棧），然后更新DNS，僅將一小部分流量轉發到新版本。如果新更新出現問題，我們可以逆轉DNS記錄回滾回來。此外，他比將所有流量從一個堆棧切換到另一個堆棧要安全得多，因為這樣會覆蓋掉新的堆棧。雖然簡單，如果你希望所有流量能一次切換到新版本，DNS記錄更新就把u 事最簡潔的方法。根據DNS客戶端不同，這些更改可能需要很長時間才能傳播，從而導致和舊版本之間的大量通信，而不是直接了斷切換。

使用反向代理

使用代理或負載均衡器，只需要將其更新成指向新堆棧就可以一次切換整個流量。這種方法在各種場景下都非常有用，例如非向后兼容的更新。要使用Rancher完成這一操作，我們首先要創建一個僅包含負載均衡器的堆棧。

接著，我們為負載均衡器指定一個端口，配置SSL并從下拉菜單中選擇活動堆棧的負載均衡器作為target service來完成創建。本質上來說，我們將負載放到了負載均衡器上，它會在之后將流量路由到實際的服務節點。借助外部負載均衡器，你不需要更新每個版本的DNS記錄。相反，你可以簡單地更新外部負載均衡器指向已更新的堆棧。

到此，相信大家對“docker如何創建持續部署流水線”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！