# 第9章 CI/CD 現在，讀者對容器的構建與存儲已經比較熟悉，本章我們簡要地談一下結合Docker鏡像的CI/CD系統的使用。如今很多企業已經采用了DevOps做法，并使用一個類似Jenkins、TravisCI或Teamcity的自動化構建系統來自動構建代碼。當代碼自動構建完畢，在Docker構建流程中將代碼添加到容器里是很簡單的。如果想在生產環境中運行Docker，強烈建議使用一個自動化持續集成和持續部署（CI/CD）構建系統來構建鏡像。Docker構建和推送的簡易性，再與CI/CD系統相結合，可能是迄今為止最強大的DevOps服務部署方式之一。 Docker本質上是一個應用程序交付框架。即便Docker網站的座右銘是：構建、交付與運行。如果能把代碼交付過程中的構建和交付部分自動化，那么很可能可以更快地將產品交付給客戶。開發人員都期望能迅速且頻繁地交付代碼，而企業交付的是產品。Docker允許將整個產品打包在一個容器中，這不僅能迅速且頻繁地交付代碼，也能交付整個產品。在接下來的幾年時間，我們將看到越來越多的產品以容器鏡像的方式進行交付，而不是一個個下載好的msi、jar或zip文件。如果你是一家需要通過SaaS更快地交付代碼給客戶的公司，或正在以容器方式交付產品，你就應該開始使用構建系統來構建Docker鏡像。 如果你已經使用構建系統構建過代碼和產品，下一步是通過構建系統來構建Docker鏡像。展開想象，一個Web容器，它運行著Jetty，并且使用Java代碼的jar文件運行它的應用程序。CI/CD系統將構建代碼、將其打包，然后將最終的jar文件部署在像Artifactory、文件系統、AWS S3這樣的產出位置上，或保存在自己的內部系統中。此時，當構建一個Docker鏡像時，只需要在Dockerfile中使用`ADD code.jar /jetty/bin/code.jar`添加jar文件。在容器運行時，只需要配置Jetty使用`/jetty/bin/code.jar`這個JAR以載入應用程序中。[Rally Soft](https://www.rallydev.com/blog/engineering/deploying-java-apps-docker-and-armada)有一個的具體示例。 CI/CD系統不僅對代碼的構建和打包非常有用，在構建Docker鏡像時表現也非常完美。編譯Docker鏡像只需要Dockerfile（代碼）和一個構建命令。一旦構建完成，用戶只需要將包提交到倉庫中。可以對CI/CD系統進行設置，在每次檢測到GitHub提交時自動完成構建的全部過程。這將讓用戶的開發團隊或基礎設施運維團隊可以在一個自動化部署系統中部署新組件、基礎設施或應用程序。 使用CI/CD系統構建Docker鏡像需要與Docker守護進程進行通信。一個簡單的方法是在用戶的構建代理上安裝Docker，然后就可以構建并交付鏡像。另外一種方法讀者可能聽說過，其術語叫Docker in Docker（[DIND](https://github.com/jpetazzo/dind)）。讀者可以通過閱讀一篇[文章](https://blog.docker.com/2013/09/docker-can-now-run-within-docker/)來了解更多信息。簡單而言，DIND可以通過發送構建命令給另外一個Docker守護進程來完成構建。不論選擇哪種方法，都需要一個自動化方法來構建Docker鏡像并在構建進程中添加代碼。 構建系統一般是按步驟進行的。我們把使用Docker的幾種可能性構建做下分解。 構建Docker鏡像。 （1）從github.com拉取最新的Dockerfile代碼。 （2）運行`docker build -t repo.com/image .`來構建鏡像。 （3）使用`docker push repo.com/image`將鏡像推送到倉庫中。 使用代碼構建Docker鏡像。 （1）從github.com拉取最新的Java代碼。 （2）使用Maven編譯并測試Java代碼，輸出設置為code.jar。 （3）從github.com拉取最新的Dockerfile代碼（Dockerfile具有`ADD code.jar /jetty/bin/code.jar`命令）。 （4）運行`docker build -t repo.com/image .`來構建鏡像。 （5）使用`docker push repo.com/image`將鏡像推送到倉庫中。 使用代碼和集成測試構建Docker鏡像。 （1）從github.com拉取最新的Java代碼。 （2）使用Maven編譯并測試Java代碼，輸出設置為code.jar。 （3）從github.com拉取最新的Dockerfile代碼（Dockerfile具有`ADD code.jar /jetty/bin/code.jar`命令）。 （4）運行`docker build -t repo.com/image .`來構建鏡像。 （5）啟動一個測試專用Docker基礎設施。 （6）運行完整的端到端集成測試。 （7）停止該測試專用Docker基礎設施。 （8）使用`docker push repo.com/image`將鏡像推送到倉庫中。 這些示例并不復雜，不過多數時候也不需要太復雜。構建和交付Docker鏡像非常簡單。最難的部分在于，理解Docker并讓構建系統自動運行Docker命令。實現這一過程的自動化只會提高用戶的工程成果。接下來，我們討論幾個有關使用自動化CI/CD系統構建Docker鏡像的話題。 CI/CD系統已經可以自動化構建鏡像了，并且現在生產環境中也運行著Docker。此時，用戶大概會意識到自己的基礎設施幾乎可以運行所有丟給它的容器。為什么不讓開發人員在編寫新代碼后構建并推送Docker鏡像到生產環境中？或者，只是將其放置在構建系統里，然后自動將容器部署到生產環境中？這是理論上的完美情況，但現實并非如此。尤其是在放任所有開發人員在Docker鏡像中使用任意代碼構建自己的Web服務器容器，然后將鏡像交給運維團隊運行的時候，企業環境很快就會失控。運維團隊會甩手不干、憤而離場。他們很快就會意識到情況不受控制，而且完全不清楚容器內有什么。如果他們堅守崗位，可能會開始問類似這樣的問題：是否運行了Jetty？是否運行了Nginx？是否運行了Apache？Web服務器的版本是否是最新的？是否使用了最新的安全性強化最佳實踐對其進行配置？里面是否有SSH？如何記錄日志？是否使用了標準的日志格式？問題會源源不斷地涌來。讓所有人構建并推送容器是一些團隊會想到的主意，但它經常會迅速地轉變為一個糟糕的做法。我們強烈建議盡早選擇更高的路線并著手制定標準。 以下是我們所認識的團隊在生產環境中使用Docker的一些標準。 如果運維或開發團隊始終從他們的工作站推送鏡像，就會忽略一些信息或最佳實踐。一致性是擴展環境和傳播知識的關鍵。應仔細考慮有關構建、添加、使用及運行Docker容器的標準。在一個提供文檔的中央系統中構建所有的Docker鏡像。基礎設施就像代碼一樣，只是目的是用于構建、編譯和打包鏡像。它也可以啟動有關容器推送的目的地、指定基礎鏡像、代碼驗證等的標準化。 隨著時間推移，你的安全團隊將理解你所做的事情，并希望了解更多。新的安全方法讓安全團隊更多地參與到構建過程中。因此，應賦予安全團隊權限并讓他們審核構建的內容。他們還可以利用工具進行測試，找出容易受攻擊的軟件包、不安全的配置，甚至是一些很糟糕的做法，如在代碼中包含密鑰信息。 你的Docker鏡像是運行Apache、Jetty、Nginx，還是三者都有？是否一個Docker鏡像運行Gwizard，而另一個運行Dropwizard？如果你還沒創建圍繞容器的最佳工程實踐，那就應該不斷地去確認這些問題。在某些時候，你或你的運維團隊會被叫去調試一個遺忘已久的鏡像。讓鏡像內所使用的服務或軟件包具有一致的標準，將為工程實踐的成功奠定基礎。如果你的工程團隊傾向于運行Nginx和Jetty，那就使用這些服務來交付Web服務。如果你的團隊傾向于使用Dropwizard而非Gwizard，那就使用前者的軟件包。你的團隊越早實現鏡像內容標準化，成功的可能性就越大。 如果你遵循了第一個標準（見9.2節）和第二個標準（見9.3節） ，你就會意識到使用一個默認的基礎Docker鏡像是個好主意。假定你的團隊使用Python 2.6作為代碼語言。如果團隊里一個新的開發人員拉取了最新版的Python基礎鏡像，但它是3.0版本，那你注定要遇到問題。樹立一個規范，讓所有鏡像繼承于一個標準基礎鏡像，將大有幫助。有些團隊已經開始讓運維團隊為他們構建基礎鏡像，他們只要繼承即可。例如，運維團隊創建了一個基礎Ubuntu鏡像，對日志做了適當的配置、設置了正確的安全性并安裝了正確的Python 2.6版本。開發團隊所要做的唯一事情就是用`FROM`來使用這個基礎鏡像，然后在構建時用`ADD`將代碼添加到鏡像中，就像這樣： ``` FROM company.com/python_base:2015_02 ADD code.py /code.py CMD [ "python", "./code.py" ] ``` 這大大簡化了鏡像的創建過程，將大量的細節交給擁有并維護這個基礎鏡像的人負責。提供一個標準基礎鏡像將讓運維團隊清楚容器內運行著什么（在多數情況下），它簡化了構建過程，讓開發人員可以專注于代碼，同時，因為它創建了一致性，有助于在用戶的基礎設施上擴展Docker鏡像。 Docker不僅可以讓用戶將應用程序打包成一個鏡像并進行交付，還可豐富基礎設施的方方面面。假定你在生產環境構建中運行集成測試，同時具有一個攜帶靜態數據的靜態環境。很可能你會構建代碼，然后在這個靜態環境中運行集成測試。在使用Docker的世界里，用戶可以把這個靜態環境轉變成一個在測試基礎設施里集成Docker鏡像的動態環境。Docker可以非常快速地啟動與停止，加上制作優質鏡像的簡易性，可根據需要對測試基礎設施進行支撐。在完成一次構建時，用戶可以運行同一個代理或另一臺宿主機系統（調用Docker API）上的集成基礎設施，然后在結束后將其關閉。這甚至可以為公司省下保持靜態基礎設施運行的費用。 到今天為止，在結合Docker的CI/CD測試領域我們還沒看到過多創新，不過已經有一些新項目開始涌現。我們見識過在鏡像中運行Selenium瀏覽器測試，甚至為企業提供完整的端到端測試，但是我們還沒看到任何標準。我們期待在這個領域很快能看到更多成果。如果想了解Docker和Selenium，可以查看名為Docker [Selenium](https://github.com/elgalu/docker-selenium)的GitHub項目。 DevOps完全就是一種“以一個團隊的身份交付代碼和基礎設施”的文化。當你的工程團隊實踐DevOps，并能使用單一系統來配置和部署Docker鏡像到基礎設施上時，你已經開始漸入佳境了。最近在DockerCon 15大會上，我們看到Jenkins全面擁抱了Docker，甚至是微軟Visual Studio團隊也展示了使用Docker鏡像構建和部署應用程序和基礎設施的威力。我們希望看到越來越多的公司開始在他們的CI/CD環境里使用Docker，并樹立更多最佳實踐。 配置管理對Docker來說很重要，第10章將對其進行說明。