在本系列文章的第一部分，我們搭建了基本的構建和部署流水線（pipeline）。容器不再是靠登陸服務器，然後輸入記憶中的Docker命令來部署。鏡像的構建也已經由Jenkins服務器實現了自動化。我們將Docker命令寫成Bash腳本，保存在Git中，實現了版本追蹤。應該說，我們對原有流程做了很大的改進。但是，仍然有一些痛點我們需要關注，在本文中，我們將看一下如何使用Docker Compose和Ansible來優化持續部署工作。
閱讀前文請點擊：有容雲:實戰總結之利用Docker、Docker Compose &Rancher構建持續部署
爲了部署一個容器鏡像，運維工程師需要登錄到服務器中，在shell 中執行含有Docker命令的腳本。這太土了，同時還需要運維等待命令執行完畢。這種模式對整個團隊沒有任何益處。（作爲一個工程師，有多少次你需要盯着本來可以自動化完成的任務？）另外，大多數情況下，運維人員從筆記本上發起的SSH會話中執行命令，部署過程也沒有實現可視化記錄和日誌保留。
如果你還記得，我們的部署腳本應該是如下的樣子：
我們已經做到了從Docker run命令中抽象了一層，工程師不需要知道每個鏡像成功運行所需要的具體參數。這是一個顯著的改進，但我們也意識到在如下部分存在的一些問題。
存在問題
1.每一個容器的邏輯存放在同一個文件中，對應用部署邏輯的變更更難去跟蹤；
- 開發人員測試和修改參數時，只能在腳本中理清邏輯，而不能爲某個特定的應用很容易地讀取和修改參數。
在我們工作流中， Docker Compose是一款更合適的工具，它允許我們對部署參數進行代碼化，這些參數可以在YAML文件裏指定，該文件稱之爲docker－compose.yml。
Docker Compose不僅僅可以幫助我們解決上面提到的痛點，也可以使得我們從社區的未來工作中受益。接下來讓我們開始理清部署邏輯，爲我們的Jave示例程序創建一個Compose文件。做爲開始，我們需要基於我們原先的部署腳本創建一個docker-compose.yml文件：
現在部署一個容器只需要在包含docker-compose.yml文件的路徑下執行如下命令：
該命令會按照在Compose文件中指定的參數啓動一個容器。該例子中需要解決如何輸入${VERSION}的問題。Docker Compose能夠從當前shell環境中接受在Compose文件中指定的變量。爲設置該變量，我們可以很簡單地運行如下命令：
該命令將會從我們的私有鏡像庫里拉取標記爲1.0.0的鏡像，啓動java-service-1應用。如果VERSION變量沒有設置，Docker Compose將會輸出告警信息，並將之替換爲空字符串，從而將拉取latest鏡像。因此，正確設置VERSION變量非常重要。
作爲部署流程的一部分，我們想讓開發人員能夠在本地構建和測試他們開發的服務。但是，因爲docker-compose.yml文件指向是私有鏡像庫的鏡像，所以執行docker-compose up命令將不會使用本地資源，而是使用事先做好的鏡像。 比較理想的情況是，開發人員可以用如下命令來使用標準的docker-compose 工作流程：
Docker Compose提供了一個方式讓我們做到這一點，而不用修改生產環境中的docker-compose.yml文件。我們可以使用多個Compose文件，在本地機上測試時，可以利用docker-compose.override.yml來替換我們希望改動的任意參數。在該文件中，我們指定Build鍵值而不是鏡像名稱，同時移除VERSION變量。因爲它是一個覆蓋文件，我們不需要複製任何例如端口等額外的設置：
通過將我們之前的部署腳本轉化爲Docker Compose文件，現在我們能夠得到不少收穫。
收穫
1.將compose文件和源代碼存在一個代碼庫裏，和Dockerfile一樣；
- 再不需要編寫複雜的部署腳本；
- 允許開發者很容易地在本地測試和修改應用。
現在我們爲java-service-1應用創建了Compose文件，我們可以從我們的部署腳本里去掉它，我們的存儲庫裏大概會存放如下內容：
到目前爲止，我們依舊沒有完全將鏡像創建和部署之間的差距拉平。我們有docker-compse.yml文件，包含了所有的部署邏輯，但是到底在我們的環境裏如何執行它呢？讓我們稍微偏離一下主題，談一下運行Docker daemon時關於UNIX和TCP socket的一些安全顧慮。
在我們這個項目中，工程師登錄到每臺服務器中來執行部署腳本，啓動相應的容器。缺省情況下，當在本地執行Docker命令時，它會使用Unix socket /var/run/docker.sock 來連接到Docker daemon。 除了這樣做，我們可以讓daemon監聽TCP socket。這樣使得客戶端可以遠程連接每個Docker daemon，然後就好像已經登錄該節點一樣運行命令。這種方法使得我們擁有了一些靈活性，但是也帶來了一些安全問題。
安全問題
- 允許從網絡上遠程連接帶來的安全問題；
- 增加了一些需求，來設置基於節點或基於網絡的ACL；
- 保護daemon需要分發CA和客戶端證書。
另外一個方式是在SSH之上來執行我們的命令。我們已經有了ACL來保護SSH端口，只有指定的授權用戶才能通過SSH 訪問Docker daemon。 這也許不是一個最好的方法，但它能夠減少我們的運維負擔，將安全風險降到最低。 這確實爲我們帶來很多好處，尤其是工作負擔已經很大的團隊。
爲了協助在SSH之上運行Docker命令，我們可以使用Ansible，一個廣受歡迎的編排和配置管理工具。 Ansible不需要在服務器上安裝代理，允許在SSH之上運行PlayBook（服務器端任務的集合）。一個簡單的PlayBook可以執行我們的docker-compose命令，其格式大概如下所示：
不需要對Ansible懂太多，你都能夠對如上的PlayBook到底要做什麼有一個大概瞭解。每一行要執行的動作和步驟可以描述如下：
- Ansible連接目標服務器（使用變量DESTINATION定義服務器）；
- 在每臺服務器上，Ansible執行一個shell命令，登錄到公司的私有代碼倉庫；
- Ansible從Jenkins服務器上（也就是執行Ansible PlayBook的服務器）上拷貝docker-compose.yml文件到目標服務器的本地/tmp/docker-compose.yml；
- 在目標服務器上執行docker-compose命令；
- 移除臨時文件/tmp/docker-compose.yml。
當然，可以寫一個shell腳本做同樣的事情。不同的是，利用Ansible，我們可以得到一個並行執行、完美測試的腳本模塊。通過Ansible和PlayBook文件，我們能夠遠程啓動容器，相對於手動登錄遠程節點、執行命令來說前進了一大步。爲了近一步加強該流程的可視化，我們將配置Jenkins作業來執行Ansible代碼。使用Jenkins，我們也得到了額外的收益，能夠在未來將我們的構建和部署緊密聯繫在一起。
Jenkins作業將需要兩個參數：目標服務器（傳遞給PlayBook的DESTINATION變量）以及需要部署的鏡像版本（傳遞給docker-compose.yml文件中的VERSION 變量）。該作業的構建部分是一個shell構建腳本，它將試圖爲該應用找到docker-compose.yml文件，然後運行ansible-playbook命令，傳遞變量給PlayBook：
儘管看上去好像我們只是在工作流中做了一點小的改變，但整個持續部署模式卻有了很好的進步。
進步
- 部署現在可以被審計。 日誌中記錄了什麼被執行，何時被執行，在哪些節點上執行，這些歸功於Jenkins作業；
- 部署邏輯更嚴密。應用部署邏輯從單一腳本分解爲多個單獨的Docker docker-compose.yml文件，這些文件和應用代碼存放在一起。這意味着我們可以通過Git來跟蹤應用部署邏輯的變化。另外，我們也可以通過應用源代碼的修改或者部署文件的修改，來觸發構建和部署。
當然，儘管這些改進解決了一些問題，同時也帶來了一些新的問題：
• 哪些容器被部署了？部署在哪臺主機？部署了哪幾個版本？
• 部署完成以後，容器是什麼狀態？
• 我們如何確定哪些節點應該是某個應用的 DESTINATION?
在下一篇文章中，將探討我們爲什麼引入以及如何使用Rancher，特別是該平臺如何幫助我們解決如上問題。我們也將探討該平臺如何助力運維和開發一體化。
同時，你也可以下載有容雲團隊編譯的白皮書： 《基於Docker的構建流程 (第一部分) - 持續集成及測試》，該文檔詳細闡述了在CI/CD流程中容器帶來的價值。
目前可以通過以下鏈接訪問本系列4篇文章：
Part 1: CI/CD 和 Docker入門
Part 2: 使用Docker Compose
Part 3: Rancher助力容器編排
Part 4: 服務發現
原文地址：Lessons learned building a continuous deployment pipeline with Docker, Docker-Compose and Rancher (Part 2)
溫馨提示
對Docker容器技術或容器生產實施感興趣的朋友歡迎加羣454565480討論。我們彙集了Docker容器技術落地實施團隊精英及業內技術派高人，在線爲您分享Docker技術乾貨。我們的宗旨是爲了大家擁有更專業的平臺交流Docker實戰技術，我們將定期邀請嘉賓做各類話題分享及回顧，共同實踐研究Docker容器生態圈。