Docker+rancher如何構(gòu)建環(huán)境容器化

166次閱讀

共計 5765 個字符，預(yù)計需要花費 15 分鐘才能閱讀完成。

這篇文章給大家分享的是有關(guān) Docker+rancher 如何構(gòu)建環(huán)境容器化的內(nèi)容。丸趣 TV 小編覺得挺實用的，因此分享給大家做個參考，一起跟隨丸趣 TV 小編過來看看吧。

介紹

隨著 Docker 項目及其相關(guān)生態(tài)系統(tǒng)逐漸成熟，容器已經(jīng)開始被更多企業(yè)用在了更大規(guī)模的項目中。因此，我們需要一套連貫的工作流程和流水線來簡化大規(guī)模項目的部署。在本指南中，我們將從代碼開發(fā)、持續(xù)集成、持續(xù)部署以及零停機更新幾個方面進行介紹。在大型組織中，這已是相當標準的工作流；但在本系列文章中，我們會更著重于探討在容器時代，如何在基于 Docker 的環(huán)境中復(fù)制這些工作流。另外，我們還將詳細介紹如何利用 Docker 和 Rancher 自動化處理這些工作流。在本指南中，我們提供了每個步驟的詳細示例，幫助你實現(xiàn)自己的 CI 系統(tǒng)。

我們希望你通過該指南，能夠提取到其中的一些想法，利用諸如 Docker 和 Rancher 這類工具來創(chuàng)建屬于你們企業(yè)的持續(xù)集成和持續(xù)部署流水線，并根據(jù)自己的實際情況和需求在這 CI/CD 流水線中也加入自定義的流程。

在我們開始之前，還有一些需要注意的事項：因為 Docker 和 Rancher 的版本更迭都非常快，可能會出現(xiàn)一些在不同版本的平臺上 API 和實現(xiàn)不一致的情況。作為參考，我們在指南中的工作環(huán)境是：Golang 1.8，Docker 1.13.1+，Jenkins Version 2.32.2，docker-compose 1.11.1+ 以及 Rancher 1.4.1+。

第一部分：持續(xù)集成

那么踏出第一步，我們先從流水線的入口開始，即構(gòu)建源代碼。在任何項目開始時，構(gòu)建 / 編譯并不會是什么麻煩的問題，因為大多數(shù)語言和工具都有定義良好且記錄詳細的編譯源代碼過程。但是隨著項目和團隊在規(guī)模上的擴大以及依賴關(guān)系的增加，在確保代碼質(zhì)量的同時，如何為所有開發(fā)人員提供一致且穩(wěn)定的構(gòu)建，會逐漸成為一個更大的挑戰(zhàn)。在本節(jié)中，我們將會介紹一些常見的挑戰(zhàn)、最佳實踐以及如何通過 Docker 來實現(xiàn)持續(xù)集成。

擴展構(gòu)建系統(tǒng)的挑戰(zhàn)

在分享最佳實踐之前，讓我們看看在維護構(gòu)建系統(tǒng)中常出現(xiàn)的一些挑戰(zhàn)。

首先，在擴展項目時你會面臨的第一個問題就是 Dependency Management（依賴管理）。開發(fā)人員會從庫中拉取代碼并和源代碼進行集成，如此一來，跟蹤代碼所使用的每個庫的版本，確保項目所有部分都使用相同的版本，測試庫版本的升級并把通過測試的更新 push 到你全部的項目中，這些過程都變得非常重要。

其次，管理環(huán)境依賴是一個和依賴管理相關(guān)但又有一些不同的問題。它包括 IDE 和 IDE 配置、工具版本（如 Maven 版本、Python 版本）和工具配置（如靜態(tài)分析規(guī)則文件、代碼格式化模版）。因為項目的不同部分可能相互間有需求沖突，環(huán)境依賴管理會變得非常棘手。和代碼層面的依賴沖突不同，想要解決這些沖突往往是非常困難甚至是不可能的。比如，在最近的一個項目中，我們使用 fabric 進行自動化部署，使用 s3cmd 將工件上傳到 Amazon S3。不幸的是，fabric 的最新版本需要 Python 2.7，而 s3cmd 需要使用 Python 2.6。修復(fù)程序需要我們切換到 s3cmd 的測試版本或者使用舊版的 fabric。

最后，對每個大型項目來說，它們主要面臨的是構(gòu)建時間問題。隨著項目范圍和復(fù)雜度增加，越來越多的語言添加了進來。同時，項目團隊還需要為各種相互依賴的組件進行測試。例如，如果你有一個共享數(shù)據(jù)庫，那么改變相同數(shù)據(jù)的測試是不能夠同時執(zhí)行的。此外，我們需要在測試執(zhí)行之前設(shè)置預(yù)期狀態(tài)，并能在完成后自行清理。如此一來，所有這一切可能需要幾分鐘到幾個小時的時間進行構(gòu)建，充分測試意味著會大大減慢開發(fā)速度，但如果跳過測試又有可能出現(xiàn)嚴重的問題。

解決方案和最佳實踐

為了解決所有這些問題，就需要我們有一個支持下列需求的構(gòu)建系統(tǒng)：

可重復(fù)性

我們必須能夠在不同的開發(fā)機器和自動構(gòu)建服務(wù)器上生成 / 創(chuàng)建出有同樣依賴關(guān)系的、相似（或相同）的構(gòu)建環(huán)境。

集中管理

我們必須能夠控制所有開發(fā)人員的構(gòu)建環(huán)境，并從中央代碼倉庫或服務(wù)器構(gòu)建服務(wù)器。這包括了設(shè)置構(gòu)建環(huán)境以及更新延時。

隔離

項目的各個子組件必須獨立構(gòu)建，而不是使用明確定義的共享依賴項。

并行化

我們必須能夠為子組件提供并行化構(gòu)建。

為了滿足可重復(fù)性要求，我們必須使用集中式依賴管理。大多數(shù)現(xiàn)代語言和開發(fā)框架都支持自動依賴管理。Maven 廣泛用于 Java 和其他幾種語言，Python 使用 pip，Ruby 使用 Bundler。所有這些工具都有一個非常相似的樣式，你可以 commit 索引文件（pom,xml, requirements.txt 或者 gemfile）到你的源碼控制中。然后運行該工具，把依賴下載到構(gòu)建機器上。我們可以在測試過它們后，集中管理索引文件，接著通過更新源碼控制中的索引來進行更改。但是，管理環(huán)境依賴的問題依然存在，比如我們必須安裝正確版本的 Maven、Python 和 Ruby。我們還需要確保這些工具由開發(fā)人員運行。Maven 能夠自動檢查依賴項更新，但對于 pip 和 Bundler，我們必須將構(gòu)建命令包裝在觸發(fā)依賴項更新運行的腳本中。

對于設(shè)置依賴關(guān)系管理工具和腳本，大多數(shù)小型團隊只使用文檔，并把任務(wù)交給了開發(fā)人員。然而這種方法在大型團隊中并不完全適用，特別是當依賴關(guān)系會隨時間發(fā)生變化時。更復(fù)雜的是，根據(jù)構(gòu)建機器的平臺和操作系統(tǒng)不同，這些工具的安裝命令都會發(fā)生變化。你可以使用編排工具（比如 Puppet 或 Chef）來管理依賴項的安裝以及設(shè)置配置文件。Puppet 和 Cher 都允許在源代碼控制中使用中央服務(wù)器或共享配置，來支持集中管理。這樣一來，你就可以提前對配置更改進行測試，然后交給開發(fā)人員。但是，這些工具有一些缺點：首先，安裝和配置 Puppet 或 Chef 會變得過于重要，而且它們的完整版本都不是免費的。另外，每一種工具都有自己的語言來定義任務(wù)，這就為 IT 團隊和開發(fā)人員增加了另一項管理成本。還有一點是，編排工具不提供隔離，因此工具版本的沖突依舊是一個問題，而且執(zhí)行并行化測試的問題也依然沒有解決。

為了確保組件隔離并且縮短構(gòu)建時間，我們可以使用自動虛擬化系統(tǒng)，比如 Vagrant。Vagrant 可以創(chuàng)建并運行虛擬機，這些虛擬機能夠隔離各種組件的構(gòu)建，而且能支持并行構(gòu)建。當準備好集中管理時，Vagrant 配置文件可以提交到源碼控制中，并且交給開發(fā)人員。另外。可以對虛擬機進行測試，將其部署到 Atlas，供所有開發(fā)人員下載。這樣還是會有缺點，你需要進一步的配置來設(shè)置 Vagrant，而且在這個問題中，虛擬機是非常重要的解決方案。每個虛擬機運行一個完整的操作系統(tǒng)和網(wǎng)絡(luò)堆棧，包含測試運行或者編譯器。內(nèi)存和磁盤資源需要提前分配給每一臺虛擬機。

盡管存在一些警告和缺陷，但是使用依賴管理（Maven、pip、Bundler）、編排（Puppet、Chef）和虛擬化（Vagrant），我們可以構(gòu)建一個穩(wěn)定的、可測試的、集中管理的構(gòu)建系統(tǒng)。并非所有的項目都需要有完整的工具堆棧；不過，任何長期運行的大型項目都需要這種層面的自動化。

利用 Docker 創(chuàng)建容器化的構(gòu)建系統(tǒng)

Docker 出現(xiàn)之后，我們可以無需再花費過多時間和資源來支持上文我們提到的這些工具，Docker 及其工具生態(tài)系統(tǒng)就可以幫助我們滿足上述的需求。在本節(jié)中，我們將通過下面的步驟為應(yīng)用程序創(chuàng)建容器化構(gòu)建環(huán)境。

  將你的構(gòu)建環(huán)境容器化

  用 Docker 將你的應(yīng)用程序打包起來

  使用 Docker Compose 創(chuàng)建構(gòu)建環(huán)境

我們使用一個叫做 go-messenger 的實例應(yīng)用程序來說明如何在構(gòu)建流水線中使用 Docker，后面章節(jié)也會用到它。你可以從 Github 中獲取這個應(yīng)用程序：

https://github.com/usmanismail/go-messenger/tree/golang-1.8。

系統(tǒng)的主要數(shù)據(jù)流如下所示。該應(yīng)用程序有兩個組件：一個是用 Golang 便攜的 RESTful 認證服務(wù)器，另一個是會話管理器，它接受來自客戶端的長時運行 TCP 連接并在客戶端之間路由消息。回到本文的目標，我們將重點介紹 RESTful 認證服務(wù)（go-auth）。這個子系統(tǒng)包含了一組無狀態(tài)網(wǎng)絡(luò)服務(wù)器以及一個數(shù)據(jù)庫集群，用于存儲用戶信息。

將你的構(gòu)建環(huán)境容器化

建立構(gòu)建系統(tǒng)的第一步，是創(chuàng)建一個容器鏡像，其中包含了構(gòu)建項目所需的全部工具。我們鏡像的 Docker 文件如下圖所示。因為我們的應(yīng)用程序是用 Go 語言編寫的，所以使用的是官方的 golang 鏡像，并且安裝了 govendor 依賴管理工具。需要注意的是，如果你在自己的項目中使用的是 Java 語言，那么可以用 Java 基礎(chǔ)鏡像創(chuàng)建一個類似的“構(gòu)建容器”，并安裝 Maven 替代 govendor。

然后我們添加了一個編譯腳本，將構(gòu)建和測試我們代碼的所有步驟集中到了一塊。下面所示的腳本使用了 govendor restore 下載依賴項，通過 go fmt 命令標準化格式，用 go test 命令執(zhí)行測試，接著使用了 go build 來編譯項目。

為確保可重復(fù)性，我們可以使用 Docker 容器以及一切需要的工具，將組件構(gòu)建成一個單一的、版本化的容器鏡像。該鏡像可從 Dockerhub 上下載，也可以使用 Dockerfile 構(gòu)建（docker build -t go-builder:1.8）。到這為止，所有的開發(fā)人員（以及構(gòu)建環(huán)境的機器）都可以通過下面的命令，來使用容器構(gòu)建任何的 go 項目：

上面的命令中我們運行了 usman/go-builder 鏡像的 1.8 版本，并使用 - v 將我們的源代碼安裝到了容器中，使用 - e 指定了 SOURCE_PATH 環(huán)境變量。如果想要在我們的示例項目中測試 go-builder，你可以使用下面的命令運行全部步驟，并在 go-auth 項目的根目錄中創(chuàng)建一個名為 go-auth 的可執(zhí)行文件。

將所有源從構(gòu)建工具中隔離開來后，產(chǎn)生的一個有趣的副產(chǎn)物是，我們可以輕松地更換構(gòu)建工具和配置。例如，在上面的命令中，我們使用了 golang 1.8。把 go builder：1.8 改成 go builder：1.5，你就可以測試使用 golang 1.5 時對項目的影響。為了集中管理所有開發(fā)人員使用的鏡像，我們可以將構(gòu)建容器（builder container）的最新測試版本部署到一個固定版本（即最新版本），并確保所有開發(fā)人員都使用了 go-builder：latest 構(gòu)建源代碼。同樣地，如果我們項目中不同部分使用了不同版本的構(gòu)建工具，我們可以使用不同的容器來構(gòu)建他們，而無需擔心在單個構(gòu)建環(huán)境中管理多個語言版本的問題。例如，我們可以使用支持各種 python 版本的官方 python 鏡像來減輕早期的 python 問題。

用 Docker 打包你的應(yīng)用程序

如果你想將可執(zhí)行文件打包到自己的容器中，那么需要先添加一個 dockerfile 文件，包含下面顯示的內(nèi)容，接著運行“docker build -t go-auth”。在 dockerfile 中，我們將最后一步的二進制輸出添加到一個新容器中，并將 9000 端口公開給應(yīng)用程序以便接受傳入的連接。我們還指定了運行二進制文件的入口點，該入口點使用了給定的參數(shù)。由于 Go 的二進制文件是自包含（self-contained）的，因此我們使用了原版的 Ubuntu 鏡像。不過如果你的項目需要運行時（run time）依賴項，那么也可以將它們打包到容器中。例如，如果你準備生成一個 war 文件，你可以使用 tomcat 容器。

使用 Docker Compose 創(chuàng)建構(gòu)建環(huán)境

現(xiàn)在我們可以在集中管理的容器中重復(fù)構(gòu)建項目了，該容器隔離了各種組件，我們還可以擴展構(gòu)建管道來運行集成測試。這也充分展示了 Docker 在使用并行化時加速構(gòu)建的能力。而測試不能并行化的一個主要原因是共享數(shù)據(jù)存儲。對于集成測試來說尤為如此，因為我們通常不會去模擬外部數(shù)據(jù)庫。我們的示例項目也有類似的問題，因為我們使用了 MySQL 數(shù)據(jù)庫來存儲用戶。我們想編寫一個測試，確保我們可以注冊新用戶。而第二次為同一用戶進行注冊時，我們期望會發(fā)生沖突錯誤。這讓我們不得不對測試進行序列化，這樣我們在測試完成后就可以清除注冊用戶，然后再開始新的測試。

要想設(shè)置隔離的、并行的構(gòu)建，我們可以按如下的方式定義一個 Docker Compose 模板（docker-compose.yml）。我們定義了一個數(shù)據(jù)庫服務(wù)，它使用 MySQL 官方鏡像以及需要的環(huán)境變量。然后我們使用自己創(chuàng)建的容器，創(chuàng)建一個 GoAuth 服務(wù)來打包應(yīng)用程序，并將其與數(shù)據(jù)庫容器連接起來。需要注意的是，這里我們使用了 GO_AUTH_VERSION 變量替換。如果在環(huán)境中指定了該變量，那么 compose 將使用它作為 go-auth 鏡像的標記，否則會使用默認值 latest 作為標記。

有了這個 docker-compose 模板，我們可以通過執(zhí)行 docker-compose up 來運行應(yīng)用程序環(huán)境。然后運行下面的 curl 命令來模擬我們的集成測試。第一次應(yīng)該會返回 200 OK，而第二次應(yīng)該返回 409 Conflict。如果你是在 Linux 上運行，則 service_ip 參數(shù)應(yīng)該是 localhost，而如果你使用的是 OSX，那么參數(shù)應(yīng)該是 Docker 虛擬機的 IP。想要查找 service_ip 你可以運行：

最后，在運行完測試之后，我們可以運行 docker-compose rm 來清理整個應(yīng)用程序環(huán)境。

如果想要運行多個獨立版本的應(yīng)用程序，我們需要更新 docker-compose 模板來，將服務(wù) database1 和 goauth2 以相同的配置添加到其對應(yīng)項中。唯一的變化是在 Goauth2 中，我們需要將 9000：9000 端口條目改變?yōu)?9001:9000。這樣應(yīng)用程序公開的端口就不會發(fā)生沖突。完整的模板在這里。現(xiàn)在運行 docker-compose 時，可以并行運行兩個集成測試。像這樣的東西可以有效地用于為一個具有多個獨立子組件的項目加速構(gòu)建，例如，多模塊的 Maven 項目。