基本概念
默認情況下，Compose會為我們的應用創(chuàng)建一個網(wǎng)絡，服務的每個容器都會加入該網(wǎng)絡中。這樣，容器就可被該網(wǎng)絡中的其他容器訪問，不僅如此，該容器還能以服務名稱作為hostname被其他容器訪問。
默認情況下，應用程序的網(wǎng)絡名稱基于Compose的工程名稱，而項目名稱基于docker-compose.yml所在目錄的名稱。如需修改工程名稱，可使用--project-name標識或COMPOSE_PORJECT_NAME環(huán)境變量。
舉個例子，假如一個應用程序在名為myapp的目錄中，并且docker-compose.yml如下所示：version: '2'
services:
web:
build: .
ports:
- "8000:8000"
db:
image: postgres
當我們運行docker-compose up時，將會執(zhí)行以下幾步：
- 創(chuàng)建一個名為myapp_default的網(wǎng)絡；
- 使用web服務的配置創(chuàng)建容器，它以“web”這個名稱加入網(wǎng)絡myapp_default；
- 使用db服務的配置創(chuàng)建容器，它以“db”這個名稱加入網(wǎng)絡myapp_default。
容器間可使用服務名稱（web或db）作為hostname相互訪問。例如，web這個服務可使用postgres://db:5432 訪問db容器。
更新容器
當服務的配置發(fā)生更改時，可使用docker-compose up命令更新配置。
此時，Compose會刪除舊容器并創(chuàng)建新容器。新容器會以不同的IP地址加入網(wǎng)絡，名稱保持不變。任何指向舊容器的連接都會被關閉，容器會重新找到新容器并連接上去。links前文講過，默認情況下，服務之間可使用服務名稱相互訪問。
links
允許我們定義一個別名，從而使用該別名訪問其他服務。舉個例子：version: '2'
services:
web:
build: .
links:
- "db:database"
db:
image: postgres
這樣web服務就可使用db或database作為hostname訪問db服務了。
指定自定義網(wǎng)絡
一些場景下，默認的網(wǎng)絡配置滿足不了我們的需求，此時我們可使用networks命令自定義網(wǎng)絡。networks命令允許我們創(chuàng)建更加復雜的網(wǎng)絡拓撲并指定自定義網(wǎng)絡驅動和選項。不僅如此，我們還可使用networks將服務連接到不是由Compose管理的、外部創(chuàng)建的網(wǎng)絡。
如下，我們在其中定義了兩個自定義網(wǎng)絡。version: '2'
services:
proxy:
build: ./proxy
networks:
- front
app:
build: ./app
networks:
- front
- back
db:
image: postgres
networks:
- back
networks:
front:
# Use a custom driver
driver: custom-driver-1
back:
# Use a custom driver which takes special options
driver: custom-driver-2
driver_opts:
foo: "1"
bar: "2"
其中，proxy服務與db服務隔離，兩者分別使用自己的網(wǎng)絡；app服務可與兩者通信。
由本例不難發(fā)現(xiàn)，使用networks命令，即可方便實現(xiàn)服務間的網(wǎng)絡隔離與連接。
配置默認網(wǎng)絡
除自定義網(wǎng)絡外，我們也可為默認網(wǎng)絡自定義配置。version: '2'
services:
web:
build: .
ports:
- "8000:8000"
db:
image: postgres
networks:
default:
# Use a custom driver
driver: custom-driver-1
這樣，就可為該應用指定自定義的網(wǎng)絡驅動。
使用已存在的網(wǎng)絡
一些場景下，我們并不需要創(chuàng)建新的網(wǎng)絡，而只需加入已存在的網(wǎng)絡，此時可使用external選項。示例：
networks:
default:
external:
name: my-pre-existing-network
Docker Compose 鏈接外部容器的幾種方式
在Docker中，容器之間的鏈接是一種很常見的操作：它提供了訪問其中的某個容器的網(wǎng)絡服務而不需要將所需的端口暴露給Docker Host主機的功能。Docker Compose中對該特性的支持同樣是很方便的。然而，如果需要鏈接的容器沒有定義在同一個docker-compose.yml中的時候，這個時候就稍微麻煩復雜了點。
在不使用Docker Compose的時候，將兩個容器鏈接起來使用—link參數(shù)，相對來說比較簡單，以nginx鏡像為例子：
docker run --rm --name test1 -d nginx #開啟一個實例test1
docker run --rm --name test2 --link test1 -d nginx #開啟一個實例test2并與test1建立鏈接
這樣，test2與test1便建立了鏈接，就可以在test2中使用訪問test1中的服務了。如果使用Docker Compose，那么這個事情就更簡單了，還是以上面的nginx鏡像為例子，編輯docker-compose.yml文件為：
version: "3"
services:
test2:
image: nginx
depends_on:
- test1
links:
- test1
test1:
image: nginx
最終效果與使用普通的Docker命令docker run xxxx建立的鏈接并無區(qū)別。這只是一種最為理想的情況。
如果容器沒有定義在同一個docker-compose.yml文件中，應該如何鏈接它們呢？
又如果定義在docker-compose.yml文件中的容器需要與docker run xxx啟動的容器鏈接，需要如何處理？
針對這兩種典型的情況，下面給出我個人測試可行的辦法：
方式一：讓需要鏈接的容器同屬一個外部網(wǎng)絡
我們還是使用nginx鏡像來模擬這樣的一個情景：假設我們需要將兩個使用Docker Compose管理的nignx容器（test1和test2）鏈接起來，使得test2能夠訪問test1中提供的服務，這里我們以能ping通為準。
首先，我們定義容器test1的docker-compose.yml文件內(nèi)容為：
version: "3"
services:
test2:
image: nginx
container_name: test1
networks:
- default
- app_net
networks:
app_net:
external: true
容器test2內(nèi)容與test1基本一樣，只是多了一個external_links,需要特別說明的是：最近發(fā)布的Docker版本已經(jīng)不需要使用external_links來鏈接容器，容器的DNS服務可以正確的作出判斷，因此如果你你需要兼容較老版本的Docker的話，那么容器test2的docker-compose.yml文件內(nèi)容為：
version: "3"
services:
test2:
image: nginx
networks:
- default
- app_net
external_links:
- test1
container_name: test2
networks:
app_net:
external: true
否則的話，test2的docker-compose.yml和test1的定義完全一致，不需要額外多指定一個external_links。相關的問題請參見stackoverflow上的相關問題：docker-compose + external container
正如你看到的那樣，這里兩個容器的定義里都使用了同一個外部網(wǎng)絡app_net,因此，我們需要在啟動這兩個容器之前通過以下命令再創(chuàng)建外部網(wǎng)絡：
docker network create app_net
之后，通過docker-compose up -d命令啟動這兩個容器，然后執(zhí)行docker exec -it test2 ping test1,你將會看到如下的輸出：
docker exec -it test2 ping test1
PING test1 (172.18.0.2): 56 data bytes
64 bytes from 172.18.0.2: icmp_seq=0 ttl=64 time=0.091 ms
64 bytes from 172.18.0.2: icmp_seq=1 ttl=64 time=0.146 ms
64 bytes from 172.18.0.2: icmp_seq=2 ttl=64 time=0.150 ms
64 bytes from 172.18.0.2: icmp_seq=3 ttl=64 time=0.145 ms
64 bytes from 172.18.0.2: icmp_seq=4 ttl=64 time=0.126 ms
64 bytes from 172.18.0.2: icmp_seq=5 ttl=64 time=0.147 ms
證明這兩個容器是成功鏈接了，反過來在test1中pingtest2也是能夠正常ping通的。
如果我們通過docker run --rm --name test3 -d nginx這種方式來先啟動了一個容器(test3)并且沒有指定它所屬的外部網(wǎng)絡，而需要將其與test1或者test2鏈接的話，這個時候手動鏈接外部網(wǎng)絡即可：
docker network connect app_net test3
這樣，三個容器都可以相互訪問了。
方式二：更改需要鏈接的容器的網(wǎng)絡模式
通過更改你想要相互鏈接的容器的網(wǎng)絡模式為bridge,并指定需要鏈接的外部容器（external_links)即可。與同屬外部網(wǎng)絡的容器可以相互訪問的鏈接方式一不同，這種方式的訪問是單向的。還是以nginx容器鏡像為例子，如果容器實例nginx1需要訪問容器實例nginx2，那么nginx2的doker-compose.yml定義為：
version: "3"
services:
nginx2:
image: nginx
container_name: nginx2
network_mode: bridge
與其對應的，nginx1的docker-compose.yml定義為：
version: "3"
services:
nginx1:
image: nginx
external_links:
- nginx2
container_name: nginx1
network_mode: bridge
需要特別說明的是，這里的external_links是不能省略的，而且nginx1的啟動必須要在nginx2之后，否則可能會報找不到容器nginx2的錯誤。接著我們使用ping來測試下連通性：
$ docker exec -it nginx1 ping nginx2 # nginx1 to nginx2
PING nginx2 (172.17.0.4): 56 data bytes
64 bytes from 172.17.0.4: icmp_seq=0 ttl=64 time=0.141 ms
64 bytes from 172.17.0.4: icmp_seq=1 ttl=64 time=0.139 ms
64 bytes from 172.17.0.4: icmp_seq=2 ttl=64 time=0.145 ms
$ docker exec -it nginx2 ping nginx1 #nginx2 to nginx1
ping: unknown host
以上也能充分證明這種方式是屬于單向聯(lián)通的。
在實際應用中根據(jù)自己的需要靈活的選擇這兩種鏈接方式，如果想偷懶的話，大可選擇第二種。不過我更推薦第一種，不難看出無論是聯(lián)通性還是靈活性，較為更改網(wǎng)絡模式的第二種都更為友好。
附docker-compose.yml文件詳解Compose和Docker兼容性：
Compose 文件格式有3個版本,分別為1, 2.x 和 3.x
目前主流的為 3.x 其支持 docker 1.13.0 及其以上的版本
常用參數(shù)：
version # 指定 compose 文件的版本
services # 定義所有的 service 信息, services 下面的第一級別的 key 既是一個 service 的名稱
build # 指定包含構建上下文的路徑, 或作為一個對象，該對象具有 context 和指定的 dockerfile 文件以及 args 參數(shù)值
context # context: 指定 Dockerfile 文件所在的路徑
dockerfile # dockerfile: 指定 context 指定的目錄下面的 Dockerfile 的名稱(默認為 Dockerfile)
args # args: Dockerfile 在 build 過程中需要的參數(shù) (等同于 docker container build --build-arg 的作用)
cache_from # v3.2中新增的參數(shù), 指定緩存的鏡像列表 (等同于 docker container build --cache_from 的作用)
labels # v3.3中新增的參數(shù), 設置鏡像的元數(shù)據(jù) (等同于 docker container build --labels 的作用)
shm_size # v3.5中新增的參數(shù), 設置容器 /dev/shm 分區(qū)的大小 (等同于 docker container build --shm-size 的作用)
command # 覆蓋容器啟動后默認執(zhí)行的命令, 支持 shell 格式和 [] 格式
configs # 不知道怎么用
cgroup_parent # 不知道怎么用
container_name # 指定容器的名稱 (等同于 docker run --name 的作用)
credential_spec # 不知道怎么用
deploy # v3 版本以上, 指定與部署和運行服務相關的配置, deploy 部分是 docker stack 使用的, docker stack 依賴 docker swarm
endpoint_mode # v3.3 版本中新增的功能, 指定服務暴露的方式
vip # Docker 為該服務分配了一個虛擬 IP(VIP), 作為客戶端的訪問服務的地址
dnsrr # DNS輪詢, Docker 為該服務設置 DNS 條目, 使得服務名稱的 DNS 查詢返回一個 IP 地址列表, 客戶端直接訪問其中的一個地址
labels # 指定服務的標簽，這些標簽僅在服務上設置
mode # 指定 deploy 的模式
global # 每個集群節(jié)點都只有一個容器
replicated # 用戶可以指定集群中容器的數(shù)量(默認)
placement # 不知道怎么用
replicas # deploy 的 mode 為 replicated 時, 指定容器副本的數(shù)量
resources # 資源限制
limits # 設置容器的資源限制
cpus: "0.5" # 設置該容器最多只能使用 50% 的 CPU
memory: 50M # 設置該容器最多只能使用 50M 的內(nèi)存空間
reservations # 設置為容器預留的系統(tǒng)資源(隨時可用)
cpus: "0.2" # 為該容器保留 20% 的 CPU
memory: 20M # 為該容器保留 20M 的內(nèi)存空間
restart_policy # 定義容器重啟策略, 用于代替 restart 參數(shù)
condition # 定義容器重啟策略(接受三個參數(shù))
none # 不嘗試重啟
on-failure # 只有當容器內(nèi)部應用程序出現(xiàn)問題才會重啟
any # 無論如何都會嘗試重啟(默認)
delay # 嘗試重啟的間隔時間(默認為 0s)
max_attempts # 嘗試重啟次數(shù)(默認一直嘗試重啟)
window # 檢查重啟是否成功之前的等待時間(即如果容器啟動了, 隔多少秒之后去檢測容器是否正常, 默認 0s)
update_config # 用于配置滾動更新配置
parallelism # 一次性更新的容器數(shù)量
delay # 更新一組容器之間的間隔時間
failure_action # 定義更新失敗的策略
continue # 繼續(xù)更新
rollback # 回滾更新
pause # 暫停更新(默認)
monitor # 每次更新后的持續(xù)時間以監(jiān)視更新是否失敗(單位: ns|us|ms|s|m|h) (默認為0)
max_failure_ratio # 回滾期間容忍的失敗率(默認值為0)
order # v3.4 版本中新增的參數(shù), 回滾期間的操作順序
stop-first #舊任務在啟動新任務之前停止(默認)
start-first #首先啟動新任務, 并且正在運行的任務暫時重疊
rollback_config # v3.7 版本中新增的參數(shù), 用于定義在 update_config 更新失敗的回滾策略
parallelism # 一次回滾的容器數(shù), 如果設置為0, 則所有容器同時回滾
delay # 每個組回滾之間的時間間隔(默認為0)
failure_action # 定義回滾失敗的策略
continue # 繼續(xù)回滾
pause # 暫停回滾
monitor # 每次回滾任務后的持續(xù)時間以監(jiān)視失敗(單位: ns|us|ms|s|m|h) (默認為0)
max_failure_ratio # 回滾期間容忍的失敗率(默認值0)
order # 回滾期間的操作順序
stop-first # 舊任務在啟動新任務之前停止(默認)
start-first # 首先啟動新任務, 并且正在運行的任務暫時重疊
注意：
支持 docker-compose up 和 docker-compose run 但不支持 docker stack deploy 的子選項
security_opt container_name devices tmpfs stop_signal links cgroup_parent
network_mode external_links restart build userns_mode sysctls
devices # 指定設備映射列表 (等同于 docker run --device 的作用)
depends_on # 定義容器啟動順序 (此選項解決了容器之間的依賴關系， 此選項在 v3 版本中 使用 swarm 部署時將忽略該選項)
示例：
docker-compose up 以依賴順序啟動服務，下面例子中 redis 和 db 服務在 web 啟動前啟動
默認情況下使用 docker-compose up web 這樣的方式啟動 web 服務時，也會啟動 redis 和 db 兩個服務，因為在配置文件中定義了依賴關系
version: '3'
services:
web:
build: .
depends_on:
- db
- redis
redis:
image: redis
db:
image: postgres
dns # 設置 DNS 地址(等同于 docker run --dns 的作用)
dns_search # 設置 DNS 搜索域(等同于 docker run --dns-search 的作用)
tmpfs # v2 版本以上, 掛載目錄到容器中, 作為容器的臨時文件系統(tǒng)(等同于 docker run --tmpfs 的作用, 在使用 swarm 部署時將忽略該選項)
entrypoint # 覆蓋容器的默認 entrypoint 指令 (等同于 docker run --entrypoint 的作用)
env_file # 從指定文件中讀取變量設置為容器中的環(huán)境變量, 可以是單個值或者一個文件列表, 如果多個文件中的變量重名則后面的變量覆蓋前面的變量, environment 的值覆蓋 env_file 的值
文件格式：
RACK_ENV=development
environment # 設置環(huán)境變量， environment 的值可以覆蓋 env_file 的值 (等同于 docker run --env 的作用)
expose # 暴露端口, 但是不能和宿主機建立映射關系, 類似于 Dockerfile 的 EXPOSE 指令
external_links # 連接不在 docker-compose.yml 中定義的容器或者不在 compose 管理的容器(docker run 啟動的容器, 在 v3 版本中使用 swarm 部署時將忽略該選項)
extra_hosts # 添加 host 記錄到容器中的 /etc/hosts 中 (等同于 docker run --add-host 的作用)
healthcheck # v2.1 以上版本, 定義容器健康狀態(tài)檢查, 類似于 Dockerfile 的 HEALTHCHECK 指令
test # 檢查容器檢查狀態(tài)的命令, 該選項必須是一個字符串或者列表, 第一項必須是 NONE, CMD 或 CMD-SHELL, 如果其是一個字符串則相當于 CMD-SHELL 加該字符串
NONE # 禁用容器的健康狀態(tài)檢測
CMD # test: ["CMD", "curl", "-f", "http://localhost"]
CMD-SHELL # test: ["CMD-SHELL", "curl -f http://localhost || exit 1"] 或者 test: curl -f https://localhost || exit 1
interval: 1m30s # 每次檢查之間的間隔時間
timeout: 10s # 運行命令的超時時間
retries: 3 # 重試次數(shù)
start_period: 40s # v3.4 以上新增的選項, 定義容器啟動時間間隔
disable: true # true 或 false, 表示是否禁用健康狀態(tài)檢測和 test: NONE 相同
image # 指定 docker 鏡像, 可以是遠程倉庫鏡像、本地鏡像
init # v3.7 中新增的參數(shù), true 或 false 表示是否在容器中運行一個 init, 它接收信號并傳遞給進程
isolation # 隔離容器技術, 在 Linux 中僅支持 default 值
labels # 使用 Docker 標簽將元數(shù)據(jù)添加到容器, 與 Dockerfile 中的 LABELS 類似
links # 鏈接到其它服務中的容器, 該選項是 docker 歷史遺留的選項, 目前已被用戶自定義網(wǎng)絡名稱空間取代, 最終有可能被廢棄 (在使用 swarm 部署時將忽略該選項)
logging # 設置容器日志服務
driver # 指定日志記錄驅動程序, 默認 json-file (等同于 docker run --log-driver 的作用)
options # 指定日志的相關參數(shù) (等同于 docker run --log-opt 的作用)
max-size # 設置單個日志文件的大小, 當?shù)竭_這個值后會進行日志滾動操作
max-file # 日志文件保留的數(shù)量
network_mode # 指定網(wǎng)絡模式 (等同于 docker run --net 的作用, 在使用 swarm 部署時將忽略該選項)
networks # 將容器加入指定網(wǎng)絡 (等同于 docker network connect 的作用), networks 可以位于 compose 文件頂級鍵和 services 鍵的二級鍵
aliases # 同一網(wǎng)絡上的容器可以使用服務名稱或別名連接到其中一個服務的容器
ipv4_address # IP V4 格式
ipv6_address # IP V6 格式
示例:
version: '3.7'
services:
test:
image: nginx:1.14-alpine
container_name: mynginx
command: ifconfig
networks:
app_net: # 調(diào)用下面 networks 定義的 app_net 網(wǎng)絡
ipv4_address: 172.16.238.10
networks:
app_net:
driver: bridge
ipam:
driver: default
config:
- subnet: 172.16.238.0/24
pid: 'host' # 共享宿主機的 進程空間(PID)
ports # 建立宿主機和容器之間的端口映射關系, ports 支持兩種語法格式
SHORT 語法格式示例:
- "3000" # 暴露容器的 3000 端口, 宿主機的端口由 docker 隨機映射一個沒有被占用的端口
- "3000-3005" # 暴露容器的 3000 到 3005 端口, 宿主機的端口由 docker 隨機映射沒有被占用的端口
- "8000:8000" # 容器的 8000 端口和宿主機的 8000 端口建立映射關系
- "9090-9091:8080-8081"
- "127.0.0.1:8001:8001" # 指定映射宿主機的指定地址的
- "127.0.0.1:5000-5010:5000-5010"
- "6060:6060/udp" # 指定協(xié)議
LONG 語法格式示例:(v3.2 新增的語法格式)
ports:
- target: 80 # 容器端口
published: 8080 # 宿主機端口
protocol: tcp # 協(xié)議類型
mode: host # host 在每個節(jié)點上發(fā)布主機端口, ingress 對于群模式端口進行負載均衡
secrets # 不知道怎么用
security_opt # 為每個容器覆蓋默認的標簽 (在使用 swarm 部署時將忽略該選項)
stop_grace_period # 指定在發(fā)送了 SIGTERM 信號之后, 容器等待多少秒之后退出(默認 10s)
stop_signal # 指定停止容器發(fā)送的信號 (默認為 SIGTERM 相當于 kill PID; SIGKILL 相當于 kill -9 PID; 在使用 swarm 部署時將忽略該選項)
sysctls # 設置容器中的內(nèi)核參數(shù) (在使用 swarm 部署時將忽略該選項)
ulimits # 設置容器的 limit
userns_mode # 如果Docker守護程序配置了用戶名稱空間, 則禁用此服務的用戶名稱空間 (在使用 swarm 部署時將忽略該選項)
volumes # 定義容器和宿主機的卷映射關系, 其和 networks 一樣可以位于 services 鍵的二級鍵和 compose 頂級鍵, 如果需要跨服務間使用則在頂級鍵定義, 在 services 中引用
SHORT 語法格式示例:
volumes:
- /var/lib/mysql # 映射容器內(nèi)的 /var/lib/mysql 到宿主機的一個隨機目錄中
- /opt/data:/var/lib/mysql # 映射容器內(nèi)的 /var/lib/mysql 到宿主機的 /opt/data
- ./cache:/tmp/cache # 映射容器內(nèi)的 /var/lib/mysql 到宿主機 compose 文件所在的位置
- ~/configs:/etc/configs/:ro # 映射容器宿主機的目錄到容器中去, 權限只讀
- datavolume:/var/lib/mysql # datavolume 為 volumes 頂級鍵定義的目錄, 在此處直接調(diào)用
LONG 語法格式示例:(v3.2 新增的語法格式)
version: "3.2"
services:
web:
image: nginx:alpine
ports:
- "80:80"
volumes:
- type: volume # mount 的類型, 必須是 bind、volume 或 tmpfs
source: mydata # 宿主機目錄
target: /data # 容器目錄
volume: # 配置額外的選項, 其 key 必須和 type 的值相同
nocopy: true # volume 額外的選項, 在創(chuàng)建卷時禁用從容器復制數(shù)據(jù)
- type: bind # volume 模式只指定容器路徑即可, 宿主機路徑隨機生成; bind 需要指定容器和數(shù)據(jù)機的映射路徑
source: ./static
target: /opt/app/static
read_only: true # 設置文件系統(tǒng)為只讀文件系統(tǒng)
volumes:
mydata: # 定義在 volume, 可在所有服務中調(diào)用
restart # 定義容器重啟策略(在使用 swarm 部署時將忽略該選項, 在 swarm 使用 restart_policy 代替 restart)
no # 禁止自動重啟容器(默認)
always # 無論如何容器都會重啟
on-failure # 當出現(xiàn) on-failure 報錯時, 容器重新啟動
其他選項：
domainname, hostname, ipc, mac_address, privileged, read_only, shm_size, stdin_open, tty, user, working_dir
上面這些選項都只接受單個值和 docker run 的對應參數(shù)類似
對于值為時間的可接受的值：
2.5s
10s
1m30s
2h32m
5h34m56s
時間單位: us, ms, s, m， h
對于值為大小的可接受的值：
2b
1024kb
2048k
300m
1gb
單位: b, k, m, g 或者 kb, mb, gb
networks # 定義 networks 信息
driver # 指定網(wǎng)絡模式, 大多數(shù)情況下, 它 bridge 于單個主機和 overlay Swarm 上
bridge # Docker 默認使用 bridge 連接單個主機上的網(wǎng)絡
overlay # overlay 驅動程序創(chuàng)建一個跨多個節(jié)點命名的網(wǎng)絡
host # 共享主機網(wǎng)絡名稱空間(等同于 docker run --net=host)
none # 等同于 docker run --net=none
driver_opts # v3.2以上版本, 傳遞給驅動程序的參數(shù), 這些參數(shù)取決于驅動程序
attachable # driver 為 overlay 時使用, 如果設置為 true 則除了服務之外，獨立容器也可以附加到該網(wǎng)絡; 如果獨立容器連接到該網(wǎng)絡，則它可以與其他 Docker 守護進程連接到的該網(wǎng)絡的服務和獨立容器進行通信
ipam # 自定義 IPAM 配置. 這是一個具有多個屬性的對象, 每個屬性都是可選的
driver # IPAM 驅動程序, bridge 或者 default
config # 配置項
subnet # CIDR格式的子網(wǎng)，表示該網(wǎng)絡的網(wǎng)段
external # 外部網(wǎng)絡, 如果設置為 true 則 docker-compose up 不會嘗試創(chuàng)建它, 如果它不存在則引發(fā)錯誤
name # v3.5 以上版本, 為此網(wǎng)絡設置名稱
文件格式示例：
version: "3"
services:
redis:
image: redis:alpine
ports:
- "6379"
networks:
- frontend
deploy:
replicas: 2
update_config:
parallelism: 2
delay: 10s
restart_policy:
condition: on-failure
db:
image: postgres:9.4
volumes:
- db-data:/var/lib/postgresql/data
networks:
- backend
deploy:
placement:
constraints: [node.role == manager]
以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。
