docker基礎之容器編排

1. 容器編排

   如果使用前面的知識來部署一個網站，我們需要先啟動數據庫容器，然后再啟動應用容器，最后可能還要啟動反代理容器， 這樣才算完整地部署一個Web應用。這需妥使用三條命令才能部署，操作起來很麻煩，而且不能把三個容器統一起來管理，就連三條命令都要自己動手保存起來，那么有沒有什么工具可以統一管理多個互相關聯的容器呢？

   工具有不少，如docker compose，Docker Compose原本是Docker社區的一個基於Python語言編寫的容器編排工具，后來被Docker項目組合並。

   簡單來說，Docker Compose是一個用來組裝、管理多容器應用的工具，它可以根據配直文件自動構建、管理、編排一組容器，極大地方便了用戶對多容器應用的操作。

2. 安裝Docker Compose

   Docker Compos巳使用Python語言編寫，因此從一開始它就是全平台支持的， 而且release文件一個二進制執行文件，因此可以很輕松地安裝到各個平台中。

    

3. 二進制安裝

    

   下載docker-compose

   curl -L https://get.daocloud.io/docker/compose/releases/download/1.29.1/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose

   授權

   chmod +x /usr/local/bin/docker-compose

   查看版本

   docker-compose version

   

   此外還有pip安裝方式不再細說。

4. Docker Compose命令

   學習Docker Compose 當然不能忽視最基本的啟動參數。 Docker Compose 命令是 docker­compose。

   Docker Compose默認解析當前目錄的docker-compose.yml文件，DockerCompose的命令有些類似DockerClient的子命令，使用docker-compose -h即可查看

5. 指定配置文件

   下面先看Commands中常用的參數。

   這個參數是 -f，它是用來指定DockerCompose配置文件的。該參數可以使用多次，例如：

   docker-compose -f docker-compose.yml -f docker-compose admin.yml

   如果兩份配置文件有同名的服務，Docker Compose只會解析執行后面的配置文件。例如在docker-compose.yml中有一個服務叫作webapp:

   在docker-compose admin.yml也有一個叫作webapp的服務：

   Docker Compose會執行后面的webapp配置，-f選項是可選的，如果不使用該選項，默認會解析當前目錄下的docker-compose.yml文件。

6. 指定項目名稱

   Docker Compose啟動容器時會默認地把當前的目錄名稱設置為容器名稱的 前綴，例如在web文件夾下啟動容器，配置文件中有兩個服務分別是app和db， 啟動的容器名稱默認是 web_db_1和web_app_l，如果想要指定容器項目名稱（就是web這個前綴），可以使用-p參數：

   docker-compose -p myapp up

   想要完全指定名稱可以在配置文件指定。

7. Compose環境變量

   在Docker Compose中有一個環境配置文件 .env，這是一個隱藏文件，文件中可以設定一些Docker Compose的環境變量。

   

   COMPOSE_PROJECT_NAME：這個變量用來定義使用Compose啟動容器時的名稱，作用與-p參數相同。

   COMPOSE_FILE：指定默認的配置文件名稱，默認是docker-compose.yml，作用類似於-f參數。

   DOCKER_HOST:指定Docker client連接Docker daemon的地址，默認是unix:///v ar/run/docker.sock。

   如果是遠程操作，可以使用上面的 -tls*選項，要確保指令傳輸過程加密，因為 有時候啟動命令中會有明文密碼。

   小技巧：操作Docker或者Compose時如何避免在Shell環境的歷史記錄中暴露密碼呢？可以通過間接輸出密碼的方式，例如以docker run -e PASSWORD＝$（cat pass.txt）這樣的方式輸入命令，同理，Compose可以在配置文件中使用這一 Shell語句的特性，或者像下面這樣：

   解析執行的時候會.env的變量置換到yml文件中

   

8. build：構建服務鏡像

   Docker Compose提供了與DockerClient類似的構建命令，與DockerBuild不同， docker­compose.yml不只是個啟動配置，有時還包括構建定義，例如：

   

   在上面的docker-compose.yml中執行docker-compose build命令時會自動創建mysql與ui兩個鏡像，默認構建的鏡像名稱是myapp_myapp和myapp_ui上面在設置Dockerfile路徑的同時還可以指定Dockerfile的上下文路徑，這是Dockerclient做不到的。

   在docker-compose.yml里面定義構建鏡像時要注意一定要把Dockerfile寫好，因為Docker Compose實際上是通過docker-compose.yml讀取信息解析后發給Docker Client執行的。在docker-compose.yml中可以使用相對路徑。

   在docker-compose.yml中通常包含了多個容器構建，啟動配置，默認情況下使用docker-compose build時構建docker-compose.yml里面的所有鏡像。

   但是有時候我們只是想構建其中一個容器的鏡像，這時可以指定構建容器的名稱， 例如：

   docker-compose build ui

   這個命令適用於重構部分鏡像使用，避免重構所有的鏡像。

   

   選項：

   --build arg key=val 設置服務的生成時間變量。

   --compress 使用gzip壓縮構建上下文。

   --force-rm 強制rm始終移除中間容器。

   -m、 --memory MEM 內存設置生成容器的內存限制。

   --no-cache 生成映像時不使用緩存。

   --no-rm 成功生成后不刪除中間容器

   --parallel 構建並行映像。

   --progress string 設置進度輸出的類型（自動、普通、tty）。

   --pull 始終嘗試提取較新版本的圖像。

   -q， --quiet 不要把任何東西打印到STDOUT上

   --force-rm和--no-cache都是屬於在構建過程中自動清理緩存的選項， 我們知道，構建過程實際上是后台運行一個容器在執行Dockerfile的命令，這其中會產生中間容器，使用—force-rm選項會在構建結束時刪除這些容器，而如果構建失敗的話，則Docker會在本地保留上一個臨時容器，該容器保存了直至失敗那條命令前面的構建內容，也就是我們說的構建緩存，使用--no-cache會在構建過程中自動刪除構建緩存，所以上面這兩個選項都不推薦使用。

   此外還有一個選項就是-pull選項，默認情況下Docker Compose會在啟動容器的時候查看本地是否有該鏡像，如果有就直接使用本地已存在的鏡像，使用一pull之后即使本地有該鏡像，也會執行該pull命令拉取鏡像，這樣可以確保每次啟動的容器都是基於最新的鏡像啟動的。

    

9. bundle：生成DAB包

   從docker-compose.yml文件中生成一個分布式應用程序包（DAB），這個概念涉及分布式應用，在這不進行細說，簡單地說就是生成了一個.dab文件，然后使用docker deploy部署。

   此命令在20版本已經丟棄

10. config：檢查配置語法

    這個命令用來檢查docker-compsoe.yml文件是否有語法問題，如果有問題會返回錯誤的原因：

    

    以下是各個參數解釋：

    將圖像標記固定到摘要。

    不要插入環境變量。

    只驗證配置，不打印任何東西

    打印配置文件名稱，每行一個。

    打印服務名稱，每行一個。

    打印卷名，每行一個。

    打印服務配置哈希，每行一個。為指定服務的列表設置"service1，service2"

    或者使用通配符顯示所有服務。

11. create：創建服務容器

    這個命令與Docker Create類似，使用docker-compose create會創建所有服務需要的容器，但是不會運行。

    

    這個命令將丟棄，改為up命令了。

     

12. down：清理項目

    這個命令與后面的up命令相對應，down可以停止容器並刪除包括容器、 網絡、數據卷等內容。也就是說，只要是up命令創建的東西，使用down都可以刪除。此外，如果網絡、數據卷等資源正在被其他服務使用，down會跳過這些組件。例如：

    

    與docker rm命令類似，docker-compose down也可以通過-v和--rmi來指定刪除的內容。

     

    默認情況下，down命令只會刪除定義的服務運行的容器，以及網絡。通過指定-v參數會刪除數據卷，指定--rmi可以刪除與服務相關的鏡像，此外，使用-remove-orphans還可以刪除與服務相關、但是沒有在配置文件中重定義的容器。

13. events：查看事件

    這個命令實際上就是對docker events的整合，通過這個命令可以看到與配置文件定義的服務的相關事件：

    

    使用--json選項可以格式化輸出，更容易閱讀

     

14. exec：進入服務容器

    這個命令和docker exec類似，可以進入容器執行命令，不同的是docker compose exec后面是服務名稱而不是容器名稱。

    

     

     

15. kill：殺死服務容器

    使用kill命令，默認會殺死項目下所有服務的容器，如果指定服務名稱可以殺死指定服務下的容器。不可以殺死指定容器名稱：

    

     

16. logs：查看服務容器日志

    這個命令用於查看項目日志， 默認這些日志包含了全部容器的日志， 輸出時會用不同的顏色標示，指定服務名稱可以查看指定服務的日志：

    

17. pause：暫停服務容器

    暫停項目服務可以使用這個命令，默認會停止全部的服務容器的進程，類似於使用docker pause的效果，如果你需要停止指定的服務，可以在后面指明服務名稱。

    

18. port：查看服務容器端口狀態

    在Docker Compose中port命令不如Docker Client中的port命令那么靈活，在Docker Compose中使用port命令，你不僅需要指定服務名稱，還需要指定服務容器暴露的端口才可以查看該端口在宿主機中的映射。

    

19. ps/images:查看容器與鏡像

    該命令的用途與docker ps類似，使用docker-compose ps可以查看正在運行的服務容器。

    

    

20. pull:拉取項目鏡像

    使用docker-compose pull可以拉取多個鏡像，因為在一份docker-compose.yml文件中通常有多個服務， 每個服務都要有一個鏡像作為鏡像基礎。

    在DockerCompose所有的子命令中都可以使用-f這個參數，因此在pull操作時也可以指定多個配置文件，如果服務名相同，后來者會覆蓋前者，pull操作只會在拉取后出現服務所需要的鏡像：

    

     

21. push：推送項目鏡像

    在一些項目中，鏡像並不是基於現成的Docker鏡像運行的，而是在第－次啟動的時候自動創建的。因此在項目中有新構建的鏡像時，可以使用push將項目的服務鏡像推送到倉庫中：

    

     

22. restart：重啟服務容器

    在DockerCompose中可以像DockerClient一樣操作容器， 所以當然也包括重啟服務容器，restart 默認會重啟項目下的全部服務容器。

    如果用戶指定服務名稱，可以重啟指定的服務容器。

    

23. rm：刪除項目容器

    使用rm命令當然可以刪除服務容器，Docker Compose的rm實際上就是對配置文件解析后向Docker Client發送rm的API請求，因此Client的參數在Compose這里也大都適用，例如-v是刪除服務容器的數據卷。

    

    -f是強制刪除服務容器，與Docker client不同的是，Compose不允許強制刪除正在運行的容器，因此必須是停止或者殺死容器之后才能執行刪除容器的操作。 使用docker-compose rm操作時默認會提示是否真的刪除容器：

    而使用-f參數之后會直接刪除而不會詢問。

24. run:執行一次性命令

    與Docker client不同的是，Compose並沒有給run命令太多的可選參數。 Compose的run命令與 Docker client的run命令不一樣。 使用docker-compose run命令只能對一個服務的容器運行一個一次性的命令。例如，啟動一個容器的 bash的命令：

    docker-compose run app bash

    使用run命令運行容器時，創建的容器不屬於項目中的服務，而是作為一個獨立的容器，例如下面項目有兩個服務，app和db,app依賴db 服務，現在需要使用app的配置來臨時執行一條一次性的命令，這時候就需要用run命令來運行一個app容器了：

    docker-compose run -d app ./script.sh

    使用run命令執行時創建的容器不屬於項目服務的一部分，容器名字表明這是一個使用run命令啟動的一次性容器。執行刪除時也不像上面的rm命令一樣必須要停止容器才可以刪除，而是直接刪除的：

     

    如果同時啟動多個一次性容器，則會生成多個run標志的容器：

     

    但是使用ps命令查看服務時，是看不到這些容器信息的：

     

    使用rm -f命令時會直接刪除所有一次性容器：

     

    這個命令會使用配置文件里面定義的配置來啟動容器。這意昧着啟動容器具有相同的數據卷、鏈接映射和配置，不過有兩點不同。

     

    1. run會覆蓋配置文件中的運行命令，例如容器默認CMD是bash，使用docker-compose run app python之后Python會覆蓋bash命令。

        

    2. run命令不會解析執行配置文件中的端口映射定義，這可以有效地防止端口占用等問題，如果你需要在run命令中執行端口映射，請加上—service-ports參數，或者手動指定端口映射，和Docker Client一樣使用-p參數

    

    上面提到一個—no-deps參數，這是一個取消容器關聯的參數，例如有一個項目， 項目內有兩個服務，其中一個是應用容器（app），另一個是數據庫（db），應用容器依賴數據庫容器，如果使用 docker-compose run app bash來運行一個 次性命令，會默認啟動數據庫容器，如果不需要這種關聯就需要添加--no-deps參數。

    到底什么時候需要使用run命令呢？一個簡單的例子就是備份數據庫，我們知道如果將服務寫到配置文件中就會解析執行，因此備份數據庫的配置文件通常要獨立開來，這個時候就有兩個配置文件了，如下面的例子：

     

    在docker-compose.yml中定義了web和db兩個服務：

    

    然后在docker-compose.backup. yml中定義一個備份服務，內容如下：

    

    再然后使用run命令來運行這次備份任務，這是一個一次性命令，使用-f加入兩個配置文件才可以完成備份任務，這樣就把備份配置與運行配置分開來了。

    

25. scale：設置服務容器數量

    這個命令已經放棄，未來會刪除，作為替代，這個命令變成了up命令的一個參數，通常web服務為了保證高可用和負載均衡，會在后端啟動多個服務，以確保應用不會因為其中后端服務崩潰而無法訪問。

    

26. start：啟動服務容器

    

27. stop：停止服務容器

    

28. top：查看進程狀態

    查看容器內部運行的進程

    docker-compose top SERVICE命令表示后面接的是服務名稱而不是容器名稱，服務名稱可以是多個，如果不寫則默認輸出全部的服務信息。

    top命令是非交互式的，PID表示進程在宿主機中的ID編號，PPID是父級進程D編號，C表示在容器內部的PID。通常，C的值為l的那個進程是容器的核心進程。

29. unpause:取消暫停

    用pause的時候，會鎖定容器進程，這時候需要使用unpause來取消暫停才可以繼續操作容器。

    

    同樣默認是針對項目全部的服務，可以指定服務名稱來操作。無論是pause還是unpause都需要容器處於運行狀態才能操作，話得說回來，不運行的容器也用不着暫停。

30. up：啟動項目

    最后，up命令可以說是壓軸出場的命令，這個命令與down相對應，使用up命令的時候會從配置文件讀取解析各項定義，然后發給 Docker Client執行，up可以創建包括服務容器、數據卷、網絡等一系列組件。

    

    Compose的up命令包括構建、創建（重新創建）、啟動和連接服務容器。直接使用docker-composeup命令可以聚合全部的容器信息，每個容器輸出的內容會用不同的顏色區分，當按快捷鍵 Ctrl+C時，會停止所有容器的輸出。

    如果想讓項目在后台運行就需要添加-d參數，這樣服務就會在后台運行，通過docker-compose ps可以查看容器運行狀態，logs可以看到所有容器的日志。

    下面以一個例子來說明

    首先去https://github.com/vegasbrianc/docker-compose-demo下載項目

    這里需要上外網，拉取鏡像的時候可能需要設置以下本機dns地址，8.8.8.8

    

    我們啟動5個whoami服務

    

    

     

    我們刪除一個whoami容器看看

    

    發現第一個whoami容器消失了，但還是有4個whoami提供服務。所以仍然可以正常提供服務。

     

     

     

     

     

     

     

     

     

     

     

31. Compose配置文件

    Docker Compose是使用YML文件來定義多個容器關系的，因此掌握docker-compose.yml文件的寫法才能更好地書寫配置文件，以方便管理多容器應用。

    Docker Compose實際上是把YML文件解析成原生的 Docker命令然后執行的，它通過定義解析容器依賴關系來按順序啟動容器。

32. 配置文件基礎

    Compose配置文件是一個YML格式的文件它定義了包括服務（容器）、網絡、數據卷在內的一系列項目組件。Compose配置文件的默認路徑是./docker-compose.yml。

    使用配置文件定義的服務在啟動時就像使用Docker Client的docker run一樣，同樣的配置文件重定義的網絡、數據卷也相當於在Docker Client中使用docker network create和docker volume create一樣。實際上，Compose並不會真正地操作容器，它管理容器的辦法就是解析配置文件的定義，然后發送給Docker Client。

    Compose配置文件中定義的每個服務部必須通過image標簽指定鏡像或build標簽來執行構建（上下文中存在Dockerfile）。其實配置文件的寫法與Docker Client中的命令有異曲同工之妙。就像在docker run中一樣，使用Compose

    時，Dockerfile中的命令依然有效，不必在docker-compose.yml文件中重新設定。

    例如，在Dockerfile中定義的變量可以在docker-compose.yml文件中使用，就像Shell腳本的寫法樣，形如$｛EXTERNAL_PORT｝即可。

    Compose配置文件有多個版本,建議按照最新配置文件寫法。

     

     

33. 基礎配置

    下面看一份簡單的docker-compose.yml文件：

    

    可以看到一份標准配置文件應該包含version、services、 networks三大部分，其中最關鍵的就是services和networks兩個部分，下面先來看services的書寫規則。

     

    1. image

    

    在services標簽下的第二級標簽是web，這個名字是用戶自己定義的，它就是服務名稱。

    image則是指定服務的鏡像名稱或鏡像ID。如果鏡像在本地不存在，Compose將會嘗試拉取這個鏡像。

    例如下面這些格式都是可以的 ：

    image:redis

    image:ubuntu:16.04

    1. build

    服務除了可以基於指定的鏡像，還可以基於一份Dockerfile，在使用up啟動之時執行構建任務，這個構建標簽就是build，它可以指定Dockerfile 所在文件夾的路徑。Compose將會利用它自動構建這個鏡像，然后使用這個鏡像啟動服務容器。

    build: /path/to/build/dir

    也可以是相對路徑，只要上下文確定就可以讀取Dockerfile

    build：./dir

    設定上下文根目錄，然后以該目錄為准指定Dockerfile。

    

    注意：build是一個目錄，如果你要指定Dockerfile文件，需要在 build標簽的子級標簽中使用dockerfile標簽指定，如上面的例子。

    如果你同時指定image和build兩個標簽，那么Compose會構建鏡像並且把鏡像命名為image 后面的那個名字。

    build: ./dir

    image： webapp：tag

    既然可以在 docker-compose.yml中定義構建任務，那么一定少不了arg 這個標簽，還記得 Dockerfile中的ARG 命令吧，它可以在構建過程中指定環境變量，但是在構建成功后取消，在 docker-compose.yml文件中也支持這樣的寫法：

     

    

    下面這種寫法也可以，更適合閱讀

    

    與ENV不同的是，ARG是允許空值的。例如：

    

    這樣，構建過程可以向它們賦值 。

    在v3.2中，添加了一個新的標簽CACHE FROM，通過指定構建緩存，類似於docker build

    --cache-from命令

    

    在v3.3版本中，補充了LABELS標簽，與Dockerfile中的LABEL命令相同。

    

    同時，把以前獨立的capabilities標簽（cap_add與cap_drop）移入build中，需要注意的是這個配置會在Swarm中失效，因為集群調度的權限由Swarm控制。

    

    注意：YAML的布爾值（true, false, yes,no, on, off）必須要用引號引起來（單引號、雙引號均可），否則會當成字符串解析的。

    1. command

     

    使用command可以覆蓋容器啟動后默認執行的命令。

    command: bundle exec thin -p 3000

    也可以寫成類似Dockerfile中的格式

    command： [bundle, exec, thin, -p, 3000]

     

    1. configs

    這個命令其實就是docker config，通過設置config文件，在集群部署時可以方便地調度配置文件，這是Swarm的亮點之一，與之匹配使用的通常還有docker secret等命令，Docker通過抽象配置、密鑰等文件，把煩瑣的文件復制工作變成了可管理的集群資源。

     

    

    配置中的config 可以是任何形式的配置文件，在上面的配置文件中，我們設置了兩個配置文件，其中my_config指定了一個值就是.／my_config.txt，另一個my_ other_ config則使用了external 的標簽，這表示它引用的是外部的配置文件，這個外部配置文件必須事先通過docker config create的方式創建，否則這個docker-compose.yaml是無法啟動的。

    source:Docker中存在的配置的名稱

    target：容器內部的目標路徑

    uid/gid:指定配置文件存放時的用戶歸屬

    mode：指定配置文件的權限

    1. cgroup_parent

    為容器指定一個可選的父cgroup:

    cgroup_parent: m-executor-abcd

    少數情況用到，並且對swarm集群無效

     

    6．container_name

    前面說過Compose 的容器名稱格式是：

    <項目名稱><服務名稱><序號>

    雖然可以自定義項目名稱、服務名稱，但是如果你想完全控制容器的命名，可以使用這個標簽指定：

    container_name: app

    這樣，容器的名字就指定為app了。需要注意的是，在容器編排過程中並不建議使用指定的容器名，因為在伸縮服務規模時，命名是由Docker控制的，如果人為設定名稱有可能導致命名沖突或者命名不規范而造成管理困難。

    當然如果啟動服務沒有彈性伸縮的打算，自定義容器名稱顯然更容易管理。

     

    7.deploy

    這個命令僅在使用docker stack部署到群集時生效，也就是說，docker-compose up和docker-compose run等命令無效。

    

    子選項解釋如下：

    MODE與REPLICAS

    deploy部署的容器有兩種情況，一種是global，另一種是replicated，這兩種模式是沖突的，只能二選一：

    

    或者

    

    因為replicated是默認的。所以可以不寫mode子選項。

     

    UPDATE_CONFIG

    配置服務應如何更新。該子選項常用於配置滾動更新。

    parallelism：每次更新的容器數量

    delay：更新一組容器時等待的時間

    failure_action: 如果更新失敗，后續操作是continue或pause（默認為pause）。

    monitor_failure_ratio:允許更新過程中更新失敗的最大容器數量。

     

    

     

    RESOURCES

    配置資源約束，主要是指硬件資源，把以前單獨的選項放到deploy中有助於在Swarm集群中調整容器硬件資源的利用。主要包括：cpu shares, cpu quota, cpuset, mem limit, memswap_limit，mem_swappiness等。

    

    都是單個值，所以一目了然，用法與docker run參數一致。設置limits可以有效地避免因為內存不足導致節點失聯的情況。

     

    RESTART_POLICY

    在重啟策略中可以配置在容器退出時如何重新啟動容器。

    condition：可選值有none、on-failure與any（默認為 any）。

    delay：在每次嘗試重新啟動時要等待多長時間，指定一個時間值（默認值為0）。

    max attempts：嘗試重新啟動一個容器最多可以多少次（默認為永不放棄）。

    window：設置容器重新啟動之后，等待多長時間才能確定容器啟動成功，時間單位是秒（默認為立即判定）。

    

    總結一下，Deploy不支持的選項有：buil d、cgroup_parent、container_name、 devices、dns、dns_search、 tmpfs、extemal_links、links、network_mode、sec urity_opt、stop_signal、sysctls、 usems_mode。說白了，就是集群不支持的Deploy都不支持。

     

    8．devices

    設備映射列表，使用與—device一致

    devices：

• "/dev/tty/USB0:/dev/ttyUSB0"

 

9.depends_on

在使用Compose 時，最大的好處就是減少使用煩瑣的啟動命令，但是一般項目容器啟動的順序是有要求的，如果直接從上到下地啟動容器，必然會因為容器依賴問題而啟動失敗。

例如在沒有啟動數據庫容器的時候啟動了應用容器，這時候應用容器會因為找不到數據庫而退出，為了避免這種情況，我們需要加入一個標簽，就是depends_on，這個標簽解決了容器的依賴和啟動先后的問題

例如下面容器會先啟動redis和db兩個服務，最后才啟動web服務：

需要注意的是，默認情況下使用docker-compose up web這樣的方式啟動web服務時，也會啟動redis和db兩個服務，因為在配置文件中定義了依賴關系。

 

10.dns

dns和--dns參數有一樣的用途，格式如下

dns: 8.8.8.8

也可以是一個列表

此外dns search的配置也類似，自定義DNS搜索域，可以是單個值或列表：

 

11.tmpfs

將臨時目錄掛載到容器內部中，具有類似於run的參數一樣的效果

 

12.entrypoint

在Dockedile中有一個ENTRYPOINT命令，用於指定接入點，在前面己對比過它與CMD的區別。

在docker-compose.yml中可以定義接入點，覆蓋Dockerfile中的定義：

entrypoint: /code/entrypoint.sh

格式和Docker類似，不過，還可以寫成這樣：

 

13.env_file

還記得前面提到的.env文件吧，這個文件可以設置Compose的變量。而在docker-compose.yml中可以定義一個專門存放變量的文件。

如果通過docker-compose -f FILE指定配置文件，則在env_file中路徑會使用配置文件路徑。

如果有變量名稱與environment命令沖突，則以后者為准。格式如下：

env_file: . env

或者根據docker- compose.yml 設置多個：

需要注意的是，這里所說的環境變量是對宿主機的Compose而言的，如果在配置文件中有build操作，這些變量並不會進入構建過程中，如果要在構建中使用變量，還是首選前面講的arg標簽。

 

 

14.environment

environment與上面的env_file標簽完全不同，反而和arg有幾分類似，這個標簽的作用是設置鏡像變量，它可以將變量保存到鏡像里面，也就是說，啟動的容器也會包含這些變量設置，這是與arg最大的不同。

 

一般arg標簽的變量僅用在構建過程中；而environment和Dockerfile中的ENV命令一樣，會把變量一直保存在鏡像和容器中，類似於docker run -e的效果：

 

15.expose

這個標簽與Dockerfile中的EXPOSE命令一樣，用於指定暴露的端口，但只是作為一種參考，實際上docker-compose.yml 的端口映射還得用ports這樣的標簽：

16.external_links

在使用Docker過程中，會有許多單獨使用docker run啟動的容器，為了使Compose能夠連接這些不在docker-compose.yml中定義的容器，我們需要一個特殊的標簽，就是external_links，它可以讓Compose項目里面的容器連接到那些項目配置外部的容器（前提是外部容器中必須至少有一個容器是連接到與項目內服務同一個網絡里面的）。

格式如下：

 

17.extra_hosts

添加主機名的標簽，就是往:／etc/hosts文件中添加一些記錄，與Docker client的--add-host類似：

 

啟動之后，查看容器內部的hosts

 

18.healthcheack

healthchecks前面已經介紹過了一個用於檢查容器運行狀態的命令，與在Compose選項中用法一樣。

interval指定間隔時間，test就是一條命令或者某種可以返回心跳信息的工具，三種寫法都是可以的：

如果鏡像構建時設置了健康檢查，你可以關閉：

19.labels

向容器添加元數據，和Dockerfile的LABEL命令是一個意思，格式如下：

20.links

還記得上面的depends_on吧，那個標簽是解決啟動順序的問題，這個標簽是解決容器連接的問題，與Docker client的link有一樣的效果，會連接到其他服務的容器中。

格式如下

使用別名將會自動地在服務容器中的/etc/hosts里創建。例如

相應的環境變量也將會被創建。

 

21.logging

這個標簽用於配置日志服務。格式如下：

默認的driver是json-file。只有json-file和journald可以通過docker-compose logs顯示日志，其他方式有其他的日志查看方式，但目前Compose不支持。對於可選值可以使用 options指定。

官方文檔為：https://docs.docker.com/engine/admin/logging/overview／

 

22.network_mode

網絡模式，與Docker client的—net參數類似，只是相對多了一個service:[service name］的格式。

 

 

23.networks

加入網絡，這是一個頂級的選項，與服務、版本等選項同級。

上面是一個典型的網絡配置例子，其中設置了兩個網絡，一個是新的new網絡，另一個是舊的legacy網絡，這種場景常見於服務升級時應用來不及調整或者前后端分離的場合。不同的服務可以位於不同的網絡中。同時使用aliases選項，可以把同一個服務映射到不同的網絡中，而且連接名稱不一樣。這里的aliases與--link的用法類似。

 

24.PID

pid: "host"

將 PID 模式設置為主機 PID 模式，跟主機系統共享進程命名空間。容器使用這個標簽將能夠訪問和操縱其他容器和宿主機的名稱空間。

 

25.ports

映射端口的標簽。

使用HOST:CONTAINER格式或者只是指定容器的端口，宿主機會隨機映射端口。

注意：當使用HOST:CONTAINER格式來映射端口時，如果你使用的容器端口小於60你可能會得到錯誤的結果，因為YAML將會解析xx:yy這種數字格式為60進制。所以建議采用字符串格式。

26.secret

為每個服務配置獨立的secrets，支持兩種不同的語法變體，用法與config一致。

配置與config是同一個模板，所以詳情可參看上面的config章節。

 

 

27.security_opt

為每個容器覆蓋默認的標簽。簡單來說，就是管理全部服務的標簽，比如設置全部服務的user標簽值為USER。

 

28.stop_signal

設置另一個信號來停止容器。在默認情況下是使用SIGTERM停止容器。設置另一個信號可以使用stop signal標簽。

stop_signal: SIGUSR1

 

29.volumes

掛載一個目錄或者一個已存在的數據卷容器，可以直接使用［HOST:CONTAINER］這樣的格式，或者使用［HOST:CONTAINER:ro］這樣的格式，后者對於容器來說， 數據卷是只讀的，這樣可以有效地保護宿主機的文件系統。

Compose的數據卷指定路徑可以是相對路徑，使用．或者．．來指定相對目錄。數據卷的格式可以是如下的多種形式：

 

30.volumes_from

從其他容器或者服務掛載數據卷，可選的參數是：ro或者：rw，前者表示容器只讀，后者表示容器對數據卷是可讀可寫的。默認情況下是可讀可寫的。

 

31.extends

這個標簽可以擴展另一個服務，擴展內容可以來自當前文件，也可以來自其他文件，在相同服務的情況下，后來者會有選擇地覆蓋原有配置。

用戶可以在任何地方使用這個標簽，只要標簽內容包含file和service兩個值就可以了。file的值可以是相對或者絕對路徑，如果不指fille的值，那么Compose會讀取當前YML文件的信息。

 

32.其它

還有下列這些標簽：cpu_shares,cpu_quota, cpuset, domainname, hostname, ipc, mac_address, mem_limit, memswap_limit, privileged, read_only, restart, shm_size, stdin_open，tty, user, working dir, credential_ spec。

上面這些都是一個單值的標簽，類似於使用docker run的效果。

 

1. 網絡配置

   compose可以指定自定義網絡，而不是使用默認的應用網絡，這允許用戶創建更復雜的拓撲結構和指定自定義網絡的驅動程序和選項。

   以下面配置文件為例，proxy服務位於項目的前端網絡，app屬於中間件， 位於前端Proxy和后端db之間，所以app需要與前后端兩個網絡中的容器通信：

   

   

   除了配置默認網絡之外，還可以使用已經存在的網絡，與前面的networks 標簽類似，可以在service同級標簽中設置networks覆蓋全部服務容器。例如：

   

2. 配置拓展

   前面的基礎配置中介紹過一個標簽extends，網絡拓展中介紹了external標簽，這兩個都屬於Compose配置文件中的一個拓展部分。

   Compsoe配置擴展有兩種方法，第一種方法是使用-f參數添加多個配置文件，在前面經介紹過了，第二種方法是使用extends標簽，在Compose配置文件中可以使用該標簽來擴展指定的服務。

   關於第一種-f參數，其實Compose默認情況下不僅會讀取docker-compose.yml這個文件，還會讀取一個叫作docker-compose.override.yml的文件（如果存在的話），后者表示默認覆蓋前者的配置，兩者的名稱在.env文件中可以定義。

   舉個例子：

   下面是docker-compose.yml的內容，在文件中定義了兩個服務（默認不填寫，version 會按照Compsoe版本自動補充），分別是web和db:

   

   

   然后，在同目錄下的docker-compose.override.yml文件中定義了兩個服務名稱相同的服務，但是服務內的定義並不相同,此時docker-compose.override.yml的配置會選擇性地覆蓋上面配置的定義。

   

   所謂選擇性覆蓋配置是指有沖突時以后面的配置為准， 無沖突時兩者合並。例如上面兩份配置文件選擇性覆蓋合並以后，實際內容是：

   

   

   如果使用了-f參數指定多份配置文件，Compose將不會讀取docker-compose.override.yml文件。

   而第二個方法就是使用extends標簽，這個標簽原則上可以放在配置文件的任何地方，但是我們一般把它放到服務定義子級中，例如：

   

   啟動時Compose會從common-services.yml文件中讀取拓展定義

   

   這時候啟動只需要指定docker-compose.yml即可，不必使用-f再指定common-services.yml文件。在同一個配置文件中還可以對同項目的服務做擴展，例如：

   

   在上面的配置中，important_web基於web服務擴展，重新設置了cpu_shares的值，而web服務擴展自common-services.yml的webapp。

   最后是關於配置覆蓋的注意要點，前面提到過配置是選擇覆蓋的，例如command標簽，Compose會把鏡像Dockerfile中的定義與默認配置對比，如果不同則用默認配置的值覆蓋Dockerfile的值，如果有擴展配置文件，那么以擴展配置文件的值為准，例如：

   

   這是單值標簽的情況，包含此種情況的標簽還有image、mem-limit等。但在多值標簽中又有不同，以expose標簽為例：

   

   除了expose，還有一些標簽也是這樣的，例如ports、expose、external_links、dns、dns_search、tmpfs等。

   除了合並定義的情況還有產生定義沖突的情況，例如environment標簽：

   

   

   可以看到：在合並的基礎上，Compose會把沖突的值處理，以后來定義的值為准。