摘要：工程師選擇了環(huán)境中的一臺(tái)當(dāng)前沒有在負(fù)載均衡器中被激活的主機(jī)。工程師登陸到這臺(tái)主機(jī)并從注冊(cè)表中獲取新的版本。在生產(chǎn)維護(hù)窗口中，更新負(fù)載均衡器使其指向更新過的主機(jī)。然而將部署代碼化的問題仍然存在。

這篇文章是一系列文章的第一篇，在這一系列文章中，我們想要分享我們?nèi)绾问褂肈ocker、Docker-Compose和Rancher完成容器部署工作流的故事。我們想帶你從頭開始走過pipeline的革命歷程，重點(diǎn)指出我們這一路上遇到的痛點(diǎn)和做出的決定，而不只是單純的回顧。幸好有很多優(yōu)秀的資源可以幫助你使用Docker設(shè)置持續(xù)集成和部署工作流。這篇文章并不屬于這些資源之一。一個(gè)簡(jiǎn)單的部署工作流相對(duì)比較容易設(shè)置。但是我們的經(jīng)驗(yàn)表明，構(gòu)建一個(gè)部署系統(tǒng)的復(fù)雜性主要在于原本容易的部分需要在擁有很多依賴的遺留環(huán)境中完成，以及當(dāng)你的開發(fā)團(tuán)隊(duì)和運(yùn)營(yíng)組織發(fā)生變化以支持新的過程的時(shí)候。希望我們?cè)诮鉀Q構(gòu)建我們的pipeline的困難時(shí)積累下的經(jīng)驗(yàn)會(huì)幫助你解決你在構(gòu)建你的pipeline時(shí)遇到的困難。

在這第一篇文章里，我們將從頭開始，看一看只用Docker時(shí)我們開發(fā)的初步的工作流。在接下來的文章中，我們將進(jìn)一步介紹Docker-compose，最后介紹如何將Rancher應(yīng)用到我們的工作流中。

為了為之后的工作鋪平道路，假設(shè)接下來的事件都發(fā)生在一家SaaS提供商那里，我們?cè)?jīng)在SaaS提供商那里提供過長(zhǎng)時(shí)間服務(wù)。僅為了這篇文章的撰寫，我們姑且稱這家SaaS提供商為Acme Business Company, Inc，即ABC。這項(xiàng)工程開始時(shí)，ABC正處在將大部分基于Java的微服務(wù)棧從裸機(jī)服務(wù)器上的本地部署遷移到運(yùn)行在AWS上的Docker部署的最初階段。這項(xiàng)工程的目標(biāo)很常見：發(fā)布新功能時(shí)更少的前置時(shí)間（lead time）以及更可靠的部署服務(wù)。

為了達(dá)到該目標(biāo)，軟件的部署計(jì)劃大致是這樣的：

這個(gè)過程從代碼的變更、提交、推送到git倉(cāng)庫(kù)開始。當(dāng)代碼推送到git倉(cāng)庫(kù)后，我們的CI系統(tǒng)會(huì)被告知運(yùn)行單元測(cè)試。如果測(cè)試通過，就會(huì)編譯代碼并將結(jié)果作為產(chǎn)出物（artifact）存儲(chǔ)起來。如果上一步成功了，就會(huì)觸發(fā)下一步的工作，利用我們的代碼產(chǎn)出物創(chuàng)建一個(gè)Docker鏡像并將鏡像推送到一個(gè)Docker私有注冊(cè)表（private Docker registry）中。最后，我們將我們的新鏡像部署到一個(gè)環(huán)境中。

要完成這個(gè)過程，如下幾點(diǎn)是必須要有的：

一個(gè)源代碼倉(cāng)庫(kù)。ABC已經(jīng)將他們的代碼存放在GitHub私有倉(cāng)庫(kù)上了。

一個(gè)持續(xù)集成和部署的工具。ABC已經(jīng)在本地安裝了Jenkins。

一個(gè)私有registry。我們部署了一個(gè)Docker registry容器，由Amazon S3支持。

一個(gè)主機(jī)運(yùn)行Docker的環(huán)境。ABC擁有幾個(gè)目標(biāo)環(huán)境，每個(gè)目標(biāo)環(huán)境都包含過渡性（staging）部署和生產(chǎn)部署。

這樣去看的話，這個(gè)過程表面上簡(jiǎn)單，然而實(shí)際過程中會(huì)復(fù)雜一些。像許多其它公司一樣，ABC曾經(jīng)（現(xiàn)在仍然是）將開發(fā)團(tuán)隊(duì)和運(yùn)營(yíng)團(tuán)隊(duì)劃分為不同的組織。當(dāng)代碼準(zhǔn)備好部署時(shí)，會(huì)創(chuàng)建一個(gè)包含應(yīng)用程序和目標(biāo)環(huán)境詳細(xì)信息的任務(wù)單（ticket）。這個(gè)任務(wù)單會(huì)被分配到運(yùn)營(yíng)團(tuán)隊(duì)，并將會(huì)在幾周的部署窗口內(nèi)執(zhí)行。現(xiàn)在，我們已經(jīng)不能清晰地看到一個(gè)持續(xù)部署和分發(fā)的方法了。

最開始，部署任務(wù)單可能看起來是這樣的：

DEPLOY-111:
App: JavaService1, branch "release/1.0.1"
Environment: Production

部署過程是：

部署工程師用了一周時(shí)間在Jenkins上工作，對(duì)相關(guān)的工程執(zhí)行”Build Now“，將分支名作為參數(shù)傳遞。之后彈出了一個(gè)被標(biāo)記的Docker鏡像。這個(gè)鏡像被自動(dòng)的推送到了注冊(cè)表中。工程師選擇了環(huán)境中的一臺(tái)當(dāng)前沒有在負(fù)載均衡器中被激活的Docker主機(jī)。工程師登陸到這臺(tái)主機(jī)并從注冊(cè)表中獲取新的版本。

docker pull registry.abc.net/javaservice1:release-1.0.1

找到現(xiàn)存的容器。

docker ps

終止現(xiàn)存容器運(yùn)行。

docker stop [container_id]

開啟一個(gè)新容器，這個(gè)容器必須擁有所有正確啟動(dòng)容器所需的標(biāo)志。這些標(biāo)志可以從之前運(yùn)行的容器那里，主機(jī)上的shell歷史，或者其它地方的文檔借鑒。

docker run -d -p 8080:8080 … registry.abc.net/javaservice1:release-1.0.1

連接這個(gè)服務(wù)并做一些手工測(cè)試確定服務(wù)正常工作。

curl localhost:8080/api/v1/version

在生產(chǎn)維護(hù)窗口中，更新負(fù)載均衡器使其指向更新過的主機(jī)。

一旦通過驗(yàn)證，這個(gè)更新會(huì)被應(yīng)用到環(huán)境中所有其它主機(jī)上，以防將來需要故障切換（failover）。

不可否認(rèn)的是，這個(gè)部署過程并不怎么讓人印象深刻，但這是通往持續(xù)部署偉大的第一步。這里有好多地方仍可改進(jìn)，但我們先考慮一下這么做的優(yōu)點(diǎn)：

運(yùn)營(yíng)工程師有一套部署的方案，并且每個(gè)應(yīng)用的部署都使用相同的步驟。在Docker運(yùn)行那一步中需要為每個(gè)服務(wù)查找參數(shù)，但是大體步驟總是相同的：Docker pull、Docker stop、Docker run。這個(gè)過程非常簡(jiǎn)單，而且很難忘掉其中一步。

當(dāng)環(huán)境中最少有兩臺(tái)主機(jī)時(shí)，我們便擁有了一個(gè)可管理的藍(lán)綠部署（blue-green deployment）。一個(gè)生產(chǎn)窗口只是簡(jiǎn)單地從負(fù)載均衡器配置轉(zhuǎn)換過來。這個(gè)生產(chǎn)窗口擁有明顯且快速的回滾方法。當(dāng)部署變得更加動(dòng)態(tài)時(shí)，升級(jí)、回滾以及發(fā)現(xiàn)后端服務(wù)器變得愈發(fā)困難，需要更多地協(xié)調(diào)工作。因?yàn)椴渴鹗鞘謩?dòng)的，藍(lán)綠部署代價(jià)是最小的，并且同樣能提供優(yōu)于就地升級(jí)的主要優(yōu)點(diǎn)。

好吧，現(xiàn)在看一看痛點(diǎn)：

重復(fù)輸入相同的命令。或者更準(zhǔn)確地說，重復(fù)地在bash命令行里敲擊輸入。解決這一點(diǎn)很簡(jiǎn)單：使用自動(dòng)化技術(shù)！有很多工具可以幫助你啟動(dòng)Docker容器。對(duì)于運(yùn)營(yíng)工程師，最明顯的解決方案是將重復(fù)的邏輯包裝成bash腳本，這樣只需一條命令就可以執(zhí)行相應(yīng)邏輯。如果你將自己稱作一個(gè)開發(fā)-運(yùn)營(yíng)（devops）工程師，你可能會(huì)去使用Ansible、Puppet、Chef或者SaltStack。編寫腳本或劇本（playbooks）很簡(jiǎn)單，但是這里仍有幾個(gè)問題需要說明：部署邏輯到底放在那里？你怎樣追蹤每個(gè)服務(wù)的不同參數(shù)？這些問題將帶領(lǐng)我們進(jìn)入下一點(diǎn)。

即便一個(gè)運(yùn)營(yíng)工程師擁有超能力，在辦公室工作一整天后的深夜里仍能避免拼寫錯(cuò)誤，并且清晰的思考，他也不會(huì)知道有一個(gè)服務(wù)正在監(jiān)聽一個(gè)不同的端口并且需要改變Docker端口參數(shù)。問題的癥結(jié)在于開發(fā)者確實(shí)了解應(yīng)用運(yùn)行的詳細(xì)信息（但愿如此），但是這些信息需要被傳遞給運(yùn)營(yíng)團(tuán)隊(duì)。很多時(shí)候，運(yùn)營(yíng)邏輯放在另外的代碼倉(cāng)庫(kù)中或這根本沒有代碼倉(cāng)庫(kù)。這種情況下保持應(yīng)用相關(guān)部署邏輯的同步會(huì)變得困難。由于這個(gè)原因，一個(gè)很好的做法是將你的部署邏輯只提交到包含你的Dockerfile的代碼倉(cāng)庫(kù)。如果在一些情況下無法做到這點(diǎn)，有一些方法可以使這么做可行（更多細(xì)節(jié)將在稍后談到）。把細(xì)節(jié)信息提交到某處是重要的。代碼要比部署任務(wù)單好，雖然在一些人的腦海中始終認(rèn)為部署任務(wù)單更好。

可見性。對(duì)一個(gè)容器進(jìn)行一個(gè)故障檢測(cè)須要登陸主機(jī)并且運(yùn)行相應(yīng)命令。在現(xiàn)實(shí)中，這就意味著登陸許多主機(jī)然后運(yùn)行“docker ps”和“docker logs –tail=100”的命令組合。有很多解決方案可以做到集中登陸。如果你有時(shí)間的話，還是相當(dāng)值得設(shè)置成集中登陸的。我們發(fā)現(xiàn)，通常情況下我們?nèi)鄙俚哪芰κ遣榭茨男┤萜鬟\(yùn)行在那些主機(jī)上的。這對(duì)于開發(fā)者而言是個(gè)問題。開發(fā)者想要知道什么版本被部署在怎樣的范圍內(nèi)。對(duì)于運(yùn)營(yíng)人員來說，這也是個(gè)主要問題。他們須要捕獲到要進(jìn)行升級(jí)或故障檢測(cè)的容器。

基于以上的情況，我們開始做出一些改變，解決這些痛點(diǎn)。

第一個(gè)改進(jìn)是寫一個(gè)bash腳本將部署中相同的步驟包裝起來。一個(gè)簡(jiǎn)單的包裝腳本可以是這樣的：

!/bin/bash
APPLICATION=$1
VERSION=$2

docker pull "registry.abc.net/${APPLICATION}:${VERSION}"
docker rm -f $APPLICATION
docker run -d --name "${APPLICATION}" "registry.abc.net/${APPLICATION}:${VERSION}"

這樣做行得通，但僅對(duì)于最簡(jiǎn)單的容器而言，也就是那種用戶不需要連接到的容器。為了能夠?qū)崿F(xiàn)主機(jī)端口映射和卷掛載（volume mounts），我們須要增加應(yīng)用程序特定的邏輯。這里給出一個(gè)使用蠻力實(shí)現(xiàn)的方法：

APPLICATION=$1
VERSION=$2

case "$APPLICATION" in
java-service-1)
 EXTRA_ARGS="-p 8080:8080";;
java-service-2)
 EXTRA_ARGS="-p 8888:8888 --privileged";;
*)
 EXTRA_ARGS="";;
esac

docker pull "registry.abc.net/${APPLICATION}:${VERSION}"
docker stop $APPLICATION
docker run -d --name "${APPLICATION}" $EXTRA_ARGS "registry.abc.net/${APPLICATION}:${VERSION}"

現(xiàn)在這段腳本被安裝在了每一臺(tái)Docker主機(jī)上以幫助部署。運(yùn)營(yíng)工程師會(huì)登陸到主機(jī)并傳遞必要的參數(shù)，之后腳本會(huì)完成剩下的工作。部署時(shí)的工作被簡(jiǎn)化了，工程師的需要做的事情變少了。然而將部署代碼化的問題仍然存在。我們回到過去，把它變成一個(gè)關(guān)于向一個(gè)共同腳本提交改變并且將這些改變分發(fā)到主機(jī)上的問題。通常來說，這樣做很值得。將代碼提交到倉(cāng)庫(kù)會(huì)給諸如代碼審查、測(cè)試、改變歷史以及可重復(fù)性帶來巨大的好處。在關(guān)鍵時(shí)刻，你要考慮的事情越少越好。

理想狀況下，一個(gè)應(yīng)用的相關(guān)部署細(xì)節(jié)和應(yīng)用本身應(yīng)當(dāng)存在于同一個(gè)源代碼倉(cāng)庫(kù)中。有很多原因?qū)е卢F(xiàn)實(shí)情況不是這樣，最突出的原因是開發(fā)人員可能會(huì)反對(duì)將運(yùn)營(yíng)相關(guān)的東西放入他們的代碼倉(cāng)庫(kù)中。尤其對(duì)于一個(gè)用于部署的bash腳本，這種情況更可能發(fā)生，當(dāng)然Dockerfile文件本身也經(jīng)常如此。

這變成了一個(gè)文化問題并且只要有可能的話就值得被解決。盡管為你的部署代碼維持兩個(gè)分開的倉(cāng)庫(kù)確實(shí)是可行的，但是你將不得不耗費(fèi)額外的精力保持兩個(gè)倉(cāng)庫(kù)的同步。本篇文章當(dāng)然會(huì)努力達(dá)到更好的效果，即便實(shí)現(xiàn)起來更困難。在ABC，Dockerfiles最開始在一個(gè)專門的倉(cāng)庫(kù)中，每個(gè)工程都對(duì)應(yīng)一個(gè)文件夾，部署腳本存在于它自己的倉(cāng)庫(kù)中。

Dockerfiles倉(cāng)庫(kù)擁有一個(gè)工作副本，保存在Jenkins主機(jī)上一個(gè)熟知的地址中（就比如是‘/opt/abc/Dockerfiles’）。為了為一個(gè)應(yīng)用創(chuàng)建Docker鏡像，Jenkins會(huì)搜索Dockerfile的路徑，在運(yùn)行”docker build“前將Dockerfile和伴隨的腳本復(fù)制進(jìn)來。由于Dockerfile總是在掌控中，你便可能發(fā)現(xiàn)你是否處在Dockerfile超前（或落后）應(yīng)用配置的狀態(tài)，雖然實(shí)際中大部分時(shí)候都會(huì)處在正常狀態(tài)。這是來自Jenkins構(gòu)建邏輯的一段摘錄：

if [ -f docker/Dockerfile ]; then
 docker_dir=Docker
elif [ -f /opt/abc/dockerfiles/$APPLICATION/Dockerfile ]; then
 docker_dir=/opt/abc/dockerfiles/$APPLICATION
else
 echo "No docker files. Can’t continue!"
 exit 1
if
docker build -t $APPLICATION:$VERSION $docker_dir

隨著時(shí)間的推移，Dockerfiles以及支持腳本會(huì)被遷移到應(yīng)用程序的源碼倉(cāng)庫(kù)中。由于Jenkins最開始已經(jīng)查看了本地的倉(cāng)庫(kù)，pipeline的構(gòu)建不再需要任何變化。在遷移了第一個(gè)服務(wù)后，倉(cāng)庫(kù)的結(jié)構(gòu)大致是這樣的：

我們使用分離的倉(cāng)庫(kù)時(shí)遇到的一個(gè)問題是，如果應(yīng)用源碼或打包邏輯任意一個(gè)發(fā)生改變，Jenkins就會(huì)觸發(fā)應(yīng)用的重建。由于Dockerfiles倉(cāng)庫(kù)包含了許多項(xiàng)目的代碼，當(dāng)改變發(fā)生時(shí)我們不想觸發(fā)所有的倉(cāng)庫(kù)重建。解決方法是：使用在Jenkins Git插件中一個(gè)很隱蔽的選項(xiàng)，叫做Included Regions。當(dāng)配置完成后，Jenkins將一個(gè)變化引起的重建隔離在倉(cāng)庫(kù)的某個(gè)特定子集里面。這允許我們將所有的Dockerfiles放在一個(gè)倉(cāng)庫(kù)里，并且仍然能做到當(dāng)一個(gè)改變發(fā)生時(shí)只會(huì)觸發(fā)特定的構(gòu)建（與當(dāng)改變發(fā)生在倉(cāng)庫(kù)里特定的目錄時(shí)構(gòu)建所有的鏡像相比）。

關(guān)于這個(gè)初步的工作流的另一個(gè)方面是部署工程師必須在部署前強(qiáng)制構(gòu)建一個(gè)應(yīng)用鏡像。這將導(dǎo)致額外的延遲，尤其是構(gòu)建存在問題并且開發(fā)人員需要參與其中的時(shí)候。為了減少這種延遲，并為更加持續(xù)的部署鋪平道路，我們開始為熟知分支中的每一個(gè)提交構(gòu)建Docker鏡像。這要求每一個(gè)鏡像有一個(gè)獨(dú)一無二的版本標(biāo)識(shí)符，而如果我們僅僅依賴官方的應(yīng)用版本字符串往往不能滿足這一點(diǎn)。最終，我們使用官方版本字符串、提交次數(shù)和提交sha碼的組合作為版本標(biāo)識(shí)符。

commit_count=$(git rev-list --count HEAD)
commit_short=$(git rev-parse --short HEAD)
version_string="${version}-${commit_count}-${commit_short}"

這樣得到的版本字符串看起來是這樣的：1.0.1-22-7e56158

在結(jié)束pipeline的Docker file部分的討論之前，還有一些參數(shù)值得提及。如果我們不會(huì)在生產(chǎn)中操作大量的容器，我們很少用到這些參數(shù)。但是，它們被證明有助于我們維護(hù)Docker集群的線上運(yùn)行。

重啟策略（Restart Policy）-一個(gè)重啟策略允許你指定當(dāng)一個(gè)容器退出時(shí)，每個(gè)容器采取什么動(dòng)作。盡管這個(gè)可以被用作應(yīng)用錯(cuò)誤（application panic）時(shí)的恢復(fù)或當(dāng)依賴上線時(shí)保持容器再次嘗試連接，但對(duì)運(yùn)營(yíng)人員來說真正的好處是在Docker守護(hù)進(jìn)程（daemon）或者主機(jī)重啟后的自動(dòng)恢復(fù)。從長(zhǎng)遠(yuǎn)來看，你將希望實(shí)現(xiàn)一個(gè)適當(dāng)?shù)恼{(diào)度程序（scheduler）,它能夠在新主機(jī)上重啟失敗的容器。在那天到來之前，節(jié)省一些工作，設(shè)置一個(gè)重啟策略吧。在現(xiàn)階段的ABC中，我們將這項(xiàng)參數(shù)默認(rèn)為“–restart always”，這將會(huì)使容器始終重啟。簡(jiǎn)單地?fù)碛幸粋€(gè)重啟策略就會(huì)使計(jì)劃的（和非計(jì)劃的）主機(jī)重啟變得輕松得多。

資源約束（Resource Constraints）-使用運(yùn)行時(shí)的資源約束，你可以設(shè)置容器允許消耗的最大內(nèi)存和CPU。它不會(huì)把你從一般的主機(jī)過載（over-subscription）中拯救出來，但是它可以抑制住內(nèi)存泄漏和失控的容器。我們先對(duì)容器應(yīng)用一個(gè)充足的內(nèi)存限制（例如：–memory=”8g”) 。我們知道當(dāng)內(nèi)存增長(zhǎng)時(shí)這樣會(huì)產(chǎn)生問題。盡管擁有一個(gè)硬性限制意味著應(yīng)用最終會(huì)達(dá)到內(nèi)存不足（Out-of-Memory）的狀態(tài)并產(chǎn)生錯(cuò)誤（panic），但是主機(jī)和其它容器會(huì)保持正確運(yùn)行。

結(jié)合重啟策略和資源約束會(huì)給你的集群帶來更好的穩(wěn)定性，與此同時(shí)最小化失敗的影響，縮短恢復(fù)的時(shí)間。這種類型的安全防護(hù)可以讓你和開發(fā)人員一起專注于“起火”的根本原因，而不是忙于應(yīng)付不斷擴(kuò)大的火勢(shì)。

簡(jiǎn)而言之，我們從一個(gè)基礎(chǔ)的構(gòu)建pipeline，即從我們的源碼倉(cāng)庫(kù)中創(chuàng)建被標(biāo)記的Docker鏡像開始。從使用Docker CLI部署容器一路到使用腳本和代碼中定義的參數(shù)部署容器。我們也涉及了如何管理我們的部署代碼，并且強(qiáng)調(diào)了幾個(gè)幫助運(yùn)營(yíng)人員保持服務(wù)上線和運(yùn)行的Docker參數(shù)。

此時(shí)此刻，在我們的構(gòu)建pipeline和部署步驟之間仍然存在空缺。部署工程師會(huì)通過登入一個(gè)服務(wù)器并運(yùn)行部署腳本的方法填補(bǔ)這個(gè)空缺。

盡管較我們剛開始時(shí)有所改進(jìn)，但仍然有進(jìn)一步提高自動(dòng)化水平的空間。所有的部署邏輯都集中在單一的腳本內(nèi)，當(dāng)開發(fā)者需要安裝腳本以及應(yīng)付它的復(fù)雜性時(shí)，會(huì)使本地測(cè)試會(huì)變得困難得多。此時(shí)此刻，我們的部署腳本也包含了通過環(huán)境變量處理任何環(huán)境特定信息的方法。追蹤一個(gè)服務(wù)設(shè)置的環(huán)境變量以及增加新的環(huán)境變量是乏味且容易出錯(cuò)的。

在下一篇文章中，我們將看一看怎樣通過解構(gòu)（deconstructing）共同的包裝腳本解決這些痛點(diǎn)，并使部署邏輯向使用Docker Compose的應(yīng)用更近一步。

您也可以下載免費(fèi)的電子書《Continuous Integration and Deployment with Docker and Rancher》，這本書講解了如何利用容器幫助你完成整個(gè)CI/CD過程。