Compose是定義和運行多容器Docker應用程序的工具。 使用Compose，您可以使用YAML文件來配置應用程序的服務。 然後，使用單個命令，您可以創建並啟動配置中的所有服務。

Compose適用於所有環境：生產，開發，測試以及CI工作流程。使用Compose基本上是一個三步過程：

1. 使用Dockerfile定義應用程序的環境，以便在任何地方進行復制。
2. 在docker-compose.yml中定義組成應用程序的服務，以便它們可以在隔離的環境中一起運行。
3. 運行docker-compose並撰寫開始並運行你的整個應用程序。

可以參考docker-compose官方說明詳細了解：https://docs.docker.com/compose/overview/

還沒有完全理解的朋友，用通俗的語言來說：

docker-compose 是用來做docker 的多容器控制，docker-compose 是一個用來把 docker 自動化的東西，有了 docker-compose 你可以把所有繁復的 docker 操作全都一條命令，自動化的完成。來看看下面這張圖你也許又能更好的理解了：

從上圖可以看到，這位compose哥們非常開心的把N多個容器抓在一起，根據自己的心情來編排部署。

談談容器編排與部署

?Docker有很多優勢，但對於運維或開發者來說，Docker最大的有點在於它提供了一種全新的發布機制。這種發布機制，指的是我們使用Docker鏡像作為統一的軟件制品載體，使用Docker容器提供獨立的軟件運行上下文環境，使用Docker Hub提供鏡像統一協作，最重要的是該機制使用Dockerfile定義容器內部行為和容器關鍵屬性來支撐軟件運行。

?Dockerfile作為整個機制的核心。這是一個非常了不起的創新，因為在Dockerfile中，不但能夠定義使用者在容器中需要進行的操作，而且能夠定義容器中運行軟件需要的配置，於是軟件開發和運維終於能夠在一個配置文件上達成統一。運維人員使用同一個Dockerfile能在不同的場合下“重現”與開發者環境中一模一樣的運行單元（Docker容器）出來。

為什麽要使用Compose

?先來想一下我們平時是怎麽樣使用docker的？把它進行拆分一下：

1、docker search 鏡像，是不是先查找一個鏡像；
2、docker run -itd 鏡像名稱 ，然後在運行這個鏡像；
3、然後如果你要在運行第二個鏡像、第三個鏡像.....等等鏡像，你是不是又要docker search、docker run運行。

?上面“ docker run it 鏡像名稱 ”這只是最小的動作， 如果你要映射硬盤，設置nat網絡或者映射端品，等等…你就要做更多的 docker 操作， 這顯然是非常沒有效率的，況且如果你要大規模部署，是不是覺得就很麻煩了。

?但是我們寫在 docker-compose.file 裏面就很好了。你只需要寫好後只運行一句：
?docker-compose up -d

?一切都是那麽的簡單！！！

了解下編排和部署

編排，即orchestration，它根據被部署的對象之間的耦合關系，以及被部署對象環境的依賴，制定部署流程中各個動作的執行順序，部署過程所需要的依賴文件的存儲位置和獲取方式，以及如何驗證部署成功。這些信息都會在編排工具中以指定的格式（比如配置文件或者特定的代碼）來要求運維人員定義並保存起來，從而保證這個流程能夠隨時在全新的環境中可靠有序地重現出來。

部署，即deployment，它是指按照編排所指定的內容和流程 ，在目標機器上執行編排指定環境初始化，存放指定的依賴和文件，運行指定的部署動作，最終按照編排中的規則來確認聯署成功。

這麽來解釋吧，編排是一個指揮家，他的大腦裏存儲了整個樂曲的演奏流程，對於每一個小節每一段音樂的演奏方式、開始、結束他都了然於胸；部署就是整個樂隊，他們嚴格按照指揮家的意圖用樂器來完成樂譜的執行，在需要時開始演奏，又在適當的時機停止演奏。最終，兩者通過協作就能把每一位演奏者獨立的演奏通過組合、重疊、銜接來形成高品位的交響樂。

而在Compose的世界裏，編排和部署的組合結果，就是一朵“容器雲”。

一探究竟~~ Compose原理

docker-compose的調用過程扁平的像一張紙，僅用一張簡單的模塊圖就足夠解釋明白，如下圖所示：

?首先，用戶執行的docker-compose up指令調用了命令行中的啟動方法。功能很簡單明了，一個docker-compose.yml定義了一個docker-compose的project，docker-compose操作提供的命令行參數則作為這個project的啟動參數交由project模塊去處理。

?其次，如果當前宿主機已經存在與該應用對應的容器，docker-compose將進行行為邏輯判斷。如果用戶指定可以重新啟動已有服務，docker-compose就會執行service模塊的容器重啟方法，否則就將直接啟動已有容器。這兩種操作的區別在於前者會停止舊的容器，創建啟動新的容器，並把舊容器移除掉。在這個過程中創建容器的各項定義參數都是從docker-compose up 指令和docker-compose.yml中傳入的。

?接下來，啟動容器的方法也很簡潔，這個方法中完成了一個Docker容器啟動所需的主要參數的封裝，並在container模塊執行啟動。該方法所支持的參數我想大多數朋友過是有所了解的。

?最後，container模塊會調用docker-py客戶端執行向Docker daemon發起創建容器的POST請求，再往後就是Docker處理的範疇了，相信看過我這篇文章 Docker：架構拆解請添加鏈接描述 的朋友就明白了。

總結思考

  大家想想，僅僅使用Compose，就可以構建自己的容器雲嗎？答案顯然是否定的。docker-compose解決的問題局限在“編排”二字，甚至連“部署”範疇都涉足甚少，而在一個能夠服務於大眾的雲平臺中，編排與部署也僅僅是其中的一個組成部分而已。來一起分析一下它的局限制會有哪些：

1. docker-compse是面向單宿主機部署的，這是一種部署能力的欠缺。在更多的場合下，管理員需要面對大量物理服務器（或者虛擬機），這時如果要實現基於docker-compose的容器自動化編排與部署，管理員就得借助成熟的自動化運維工具（ansible、puppet、chef、saltstack）來負責管理多個目標主機，將docker-compose所需的所有資源（配置文件、用戶代碼）交給目標主機，然後在目標主機上執行docker-compose指令。
2. 同樣網絡和存儲也比較棘手，Docker不能提供跨宿主機的網絡，完全面向Docker daemon的docker-compose當然也不支持。這意味著管理員必須部署一套類似於Open vSwich的獨立網絡工具，而且管理員還需要完成集成工作。當好不容易把容器編排都安排妥當之後，又會發現容器還處在內網環境中，於是負載均衡、服務發現等一堆問題就面臨而來了，這些問題很快能消耗掉工程師所有的耐心。

那麽，是否有一種能夠提供完善的面向服務器集群的Docker編排和部署方案呢？Docker官方給出的答案是Compose同Machine和Swarm聯動，其實還有大家近期經常聽到了kubernetes（k8s）。後期筆者會更新出這些內容和大家一起來討論。

docker：編排與部署小神器>>Compose概念篇