摘要：目前我們正采取措施，通過逐步改善現(xiàn)有過程來實(shí)現(xiàn)持續(xù)部署。在這篇文章中，我們將看看如何使用和來改善此設(shè)計(jì)。通過使用，在未來我們可以輕松地將構(gòu)建和部署任務(wù)集成起來，從而得到額外的好處。月日，北京海航萬豪酒店，容器技術(shù)大會(huì)即將舉行。

在這一系列文章的第一篇中，我們分享了只用Docker時(shí)我們開發(fā)的初步的工作流，如何創(chuàng)建一個(gè)基礎(chǔ)的構(gòu)建和部署流水線。容器的部署方式不再是在登陸server的時(shí)候從內(nèi)存中輸入Docker命令。我們已經(jīng)通過Jenkins server實(shí)現(xiàn)了鏡像的自動(dòng)化構(gòu)建。我們使用腳本將Docker命令進(jìn)行封裝，將其存儲(chǔ)到GitHub中并且設(shè)置版本。目前我們正采取措施，通過逐步改善現(xiàn)有過程來實(shí)現(xiàn)持續(xù)部署。然而，仍有一些痛點(diǎn)需要我們?nèi)ソ鉀Q。在這篇文章中，我們將看看如何使用Docker Compose 和 Ansible來改善此設(shè)計(jì)。

在部署鏡像時(shí)，工程師需要登錄到服務(wù)器，并從shell運(yùn)行我們的Docker wrapper腳本。這不是很好的解決方法，因?yàn)樗残枰_發(fā)者進(jìn)行等待。沒有任何一方會(huì)從在這種方式中獲益（作為一個(gè)工程師，當(dāng)你去做某件你很了解并且很容易自動(dòng)化的事情時(shí)，你有多少次被打斷了？）由于每一次部署都是通過操作者電腦中的SSH會(huì)話來執(zhí)行的，因此部署過程是不可見的。

如果你對(duì)我們的部署腳本還有印象，你會(huì)發(fā)現(xiàn)它看起來像下面的代碼段：

實(shí)際上，我們做的是將Docker run命令語句進(jìn)行抽象，由此工程師將不需要知道每個(gè)圖像成功運(yùn)行時(shí)所需要的確切的參數(shù)。雖然這改善了必須全部記住并且手動(dòng)輸入所有Docker參數(shù)的現(xiàn)狀，但同時(shí)也會(huì)帶來新的問題：

每個(gè)容器的邏輯都存儲(chǔ)在同一文件中，這使得對(duì)應(yīng)用程序部署邏輯的更改更難追蹤；

當(dāng)開發(fā)者需要測(cè)試或者修改參數(shù)時(shí)，需要被迫理清腳本中的邏輯，而不是能夠在某一特定的程序中輕松地閱讀和修改參數(shù)。

在我們的工作流中，Docker Compose是一個(gè)更適合使用的工具，它同樣可以將部署參數(shù)進(jìn)行編碼，并且在YAML文件中指定，此文件就是docker-compose.yml。Docker Compose不僅幫助我們解決了上面提到的難點(diǎn)，而且也可以使我們從社區(qū)未來的工作中獲益。下面讓我們理清部署腳本，并且為我們的JAVA程序示例創(chuàng)建一個(gè)Compose文件。首先，我們需要基于原來的部署邏輯創(chuàng)建一個(gè)docker-compose.yml文件：

現(xiàn)在，部署容器只需要在與docker-compose.yml文件相同目錄下輸入以下命令：

docker-compose up

它將根據(jù)compose文件中設(shè)置的參數(shù)啟動(dòng)一個(gè)容器。在compose文件中一個(gè)重要的變量是${VERSION} 。Docker Compose可以從當(dāng)前的shell環(huán)境中插入compose文件里所列出的參數(shù)。我們可以通過簡(jiǎn)單地運(yùn)行以下語句來設(shè)置參數(shù)：

VERSION=1.0.0 docker-compose up

它將從我們的私有鏡像倉(cāng)庫(kù)挑出標(biāo)記1.0.0的鏡像，以此啟動(dòng)java-service-1程序。如果沒有設(shè)置VERSION變量，Docker Compose將產(chǎn)生一條警告信息，并且用空字符串代替變量值，由此，具有最新版本標(biāo)簽的鏡像將會(huì)被挑出。因此，正確地設(shè)置變量是相當(dāng)重要的。

作為開發(fā)過程的一部分，我們希望開發(fā)人員能夠在本地建立服務(wù)并且測(cè)試他們的服務(wù)。然而，由于docker-compose.yml指向私有鏡像倉(cāng)庫(kù)的鏡像，運(yùn)行docker-compose將從最近構(gòu)建的鏡像中開啟服務(wù)而不是從本地資源中開啟。理想情況下，開發(fā)者可以通過運(yùn)行以下代碼使用典型的docker-compose工作流：

Docker Compose能在不修改docker-compose.yml文件的情況下，讓我們做到這一點(diǎn)。我們可以使用多個(gè)文件來覆蓋我們?cè)诒镜販y(cè)試中想要改變的任何參數(shù)。在docker-compose.override.yml中，我們指定一個(gè)key而不是一個(gè)鏡像，并且移除了對(duì)VERSION變量的需求。由于這是一個(gè)覆蓋文件，我們不需要復(fù)制任何額外的設(shè)置，如端口設(shè)置：

使用Docker Compose而非部署腳本之后，我們可以：

在源代碼中存儲(chǔ)每個(gè)compose文件，這與Dockerfile類似；

不再需要復(fù)雜的部署腳本；

允許開發(fā)人員在本地輕松地測(cè)試并修改應(yīng)用程序。

現(xiàn)在我們有了java-service-1程序的compose文件，我們可以將它從我們的部署腳本中刪除，因此文件組織與下面的結(jié)構(gòu)類似：

此時(shí)，我們?nèi)匀粵]有解決鏡像構(gòu)建和部署之間的問題。在docker-compose.yml文件中包含了所有的部署邏輯，但是它如何在環(huán)境中運(yùn)行直至結(jié)束的呢？正好現(xiàn)在我們?cè)谶\(yùn)行與UNIX和TPC socket相關(guān)的Docker守護(hù)進(jìn)程，是時(shí)候討論一些與安全有關(guān)的問題了。

我們的情況是，工程師登錄到服務(wù)器上，手動(dòng)運(yùn)行每個(gè)服務(wù)器所需容器的部署腳本。默認(rèn)情況下，當(dāng)在局部運(yùn)行Docker命令時(shí)，它將使用UNIX socket /var/run/docker.sock連接Docker守護(hù)進(jìn)程；或者讓守護(hù)進(jìn)程監(jiān)聽TCP socket，這允許用戶遠(yuǎn)程連接到每個(gè)Docker守護(hù)進(jìn)程，使得工程師能夠像登錄到主機(jī)一樣運(yùn)行命令。這為連接方式提供了更大的靈活性，但是沒有考慮到一些開銷和安全問題：

通過網(wǎng)絡(luò)連接增加了安全隱患；

增加了對(duì)于基于主機(jī)或者基于網(wǎng)絡(luò)的ACLs需求；

保護(hù)守護(hù)進(jìn)程需要分布式CA和客戶端認(rèn)證。

另一種可能的方法是不使用基于UNIX socket的方式運(yùn)行Docker守護(hù)進(jìn)程，而使用SSH來運(yùn)行命令。已經(jīng)建立的ACLs將保護(hù)SSH端口，并且它只允許通過SSH授權(quán)的特定的用戶才能使用Docker守護(hù)進(jìn)程。雖然這不是最簡(jiǎn)潔的方法，但是它有助于保持較低的運(yùn)行開銷，并且使安全隱患降到最低。這點(diǎn)是非常重要的，尤其是對(duì)于細(xì)粒度的稀疏的任務(wù)隊(duì)列而言。

為了有利于通過SSH運(yùn)行Docker命令，我們可以使用Ansible——一個(gè)流行的編排和配置管理工具。它是無代理的，并且允許通過SSH連接運(yùn)行“劇本”（服務(wù)器任務(wù)集合）。一個(gè)運(yùn)行docker-compose命令的簡(jiǎn)單的劇本如下所示：

如果你對(duì)Ansible沒有過多了解，你也許可以通過上面的劇本大致了解到我們想做什么。它們按順序一步步執(zhí)行，具體如下所示：

Ansible將通過SSH連接到目標(biāo)服務(wù)器（允許通過使用DESTINATION變量來指定主機(jī)）

在每個(gè)服務(wù)器中，Ansible會(huì)通過執(zhí)行shell命令登錄到公司私有的鏡像倉(cāng)庫(kù)

Ansible將位于Jenkins（運(yùn)行ansible劇本的服務(wù)器）中的docker-compose.yml文件復(fù)制到每個(gè)目標(biāo)服務(wù)器中的/tmp/docker-compose.yml下

在每個(gè)目標(biāo)服務(wù)器中運(yùn)行docker-compose命令

通過刪除遠(yuǎn)程的/tmp/docker-compose.yml文件進(jìn)行清理

一個(gè)shell腳本可以被運(yùn)用在同一個(gè)事件中。然而在Ansible中，我們將很容易的使任務(wù)并行化并且得到經(jīng)過良好測(cè)試的模塊，通過使Ansible與新的部署劇本相結(jié)合，我們可以遠(yuǎn)程啟動(dòng)容器，相較于工程師登錄到主機(jī)、人工運(yùn)行命令，這是一個(gè)重要的進(jìn)步。為了在部署過程和狀態(tài)中提供更大的可視性，我們將建立Jenkins任務(wù)來運(yùn)行Ansible代碼。通過使用Jenkins，在未來我們可以輕松地將構(gòu)建和部署任務(wù)集成起來，從而得到額外的好處。

Jenkins任務(wù)需要兩個(gè)參數(shù)：目標(biāo)主機(jī)（傳遞給劇本中的DESTINATION變量）和部署鏡像的版本（在docker-compose.yml文件中插入VERSION變量）。大多數(shù)任務(wù)的構(gòu)建部分是一個(gè)shell構(gòu)建器，它將試圖找到程序中的docker-compose.yml文件，然后通過傳遞變量（用-e）到劇本中，運(yùn)行ansible-playbook命令：

雖然看起來我們似乎只對(duì)工作流做了微小的變化，但是我們正一步一步地向構(gòu)建一個(gè)持續(xù)部署模型邁進(jìn)：

部署是可以被審查的。我們使用日志來記錄輸出什么、何時(shí)輸出、以及哪些主機(jī)是目標(biāo)主機(jī)等信息，這一切都?xì)w功于Jenkins。

程序部署邏輯已經(jīng)從一個(gè)單一的腳本分散到存儲(chǔ)在程序源代碼中的多帶帶的docker-compose.yml文件中，這意味著我們可以輕松地通過git更改程序部署邏輯。在程序源文件或者部署文件發(fā)生變化時(shí)，我們也可以容易地進(jìn)行構(gòu)建和部署。

雖然這些改進(jìn)解決了某些問題，但是它們所帶來的新的問題也成為了焦點(diǎn)：

哪個(gè)容器的哪個(gè)版本會(huì)被部署到何地？

容器在被部署后會(huì)處于哪種狀態(tài)？

我們?nèi)绾未_定哪個(gè)主機(jī)成為程序的目標(biāo)主機(jī)？

在這一系列接下來的文章中，我們將探討怎樣運(yùn)行Rancher以及使用它的原因，尤其是它如何解決上述的問題。與此同時(shí)，我們也討論它在業(yè)務(wù)和開發(fā)團(tuán)隊(duì)中所起到的意想不到的橋梁作用。

9月27日，北京海航萬豪酒店，容器技術(shù)大會(huì)Container Day 2017即將舉行。

CloudStack之父、海航科技技術(shù)總監(jiān)、華為PaaS部門部長(zhǎng)、恒豐銀行科技部總經(jīng)理、阿里云PaaS工程總監(jiān)、民生保險(xiǎn)CIO······均已加入豪華講師套餐！

11家已容器落地企業(yè)，15位真·云計(jì)算大咖，13場(chǎng)純·技術(shù)演講，結(jié)合實(shí)戰(zhàn)場(chǎng)景，聚焦落地經(jīng)驗(yàn)。免費(fèi)參會(huì)+超高規(guī)格，詳細(xì)議程及注冊(cè)鏈接請(qǐng)戳