Docker 1.13 – 新增功能大揭祕

前言

Docker 1.13 立刻就要發佈了。從 7 月 29 日發佈 1.12 發佈以來，已通過去 4 個多月了，對於活躍的 Docker 社區來講，已經好久了，讓咱們看看都 1.13 都新增了什麼內容吧。

1.13 有一千二百多個 issue/pull request，四千多個 commits，是歷史上最高的。這並非一個簡單的小版本變化，裏面有大量的更新。

要想測試 1.13.0 的新功能，能夠起一個新的機器，而後在裏面運行：curl -fsSL https://test.docker.com/ | sh，這樣會安裝最新的測試版本。

• Top 10 新增功能

一、正式支持服務棧 docker stack

二、正式支持插件：docker plugin

三、添加在 Swarm 集羣環境下對密碼、密鑰管理的 secret 管理服務：docker secret

四、增長 docker system 命令

五、能夠直接使用 docker-compose.yml 進行服務部署

六、添加 docker service 滾動升級出故障後回滾的功能

七、增長強制再發布選項 docker service update –force

八、容許 docker service create 映射宿主端口，而不是邊界負載均衡網絡端口

九、容許 docker run 連入指定的 swarm mode 的 overlay 網絡

十、解決中國 GFW 牆掉 docker-engine apt/yum 源的問題

Docker 鏡像構建 

• 從已有鏡像取得緩存

咱們都知道使用 Dockerfile 構建鏡像的時候，會充分利用分層存儲的特性進行緩存，以前構建過的層，若是沒有變化，那麼會直接使用緩存的內容，避免沒有意義的重複構建。不過使用緩存的前提條件是曾經在本地構建過這個鏡像。這在 CI 進行集羣構建時是一個比較麻煩的問題，由於構建任務可能會被分配到不一樣的機器上，而該機器沒有構建過該鏡像，所以緩存老是用不上，所以大量的時間浪費在了重複構建已經構建過的層上了。

在 1.13 中，爲 docker build 增長了一個新的參數 –cache-from，利用鏡像中的 History 來判斷該層是否和以前的鏡像一致，從而避免重複構建。

好比咱們先下載獲取做爲緩存的鏡像：

$ docker pull mongo:3.2

3.2: Pulling from library/mongo

386a066cd84a: Pull complete

524267bc200a: Pull complete

476d61c7c43a: Pull complete

0750d0e28b90: Pull complete

4bedd83d0855: Pull complete

b3b5d21a0eda: Pull complete

7354b6c26240: Pull complete

db792d386b51: Pull complete

a867bd77950c: Pull complete

Digest: sha256:532a19da83ee0e4e2a2ec6bc4212fc4af26357c040675d5c2629a4e4c4563cef

Status: Downloaded newer image for mongo:3.2

而後咱們使用更新後的 Dockerfile 構建鏡像時，若是加上 –cache-from mongo:3.2 後，會發現若是是已經在 mongo:3.2 中存在並無修改的層，就會用 mongo:3.2 中的該層作緩存。

$ docker build –cache-from mongo:3.2 -t mongo:3.2.1 .

Sending build context to Docker daemon 4.608 kB

Step 1/18 : FROM debian:jessie

—> 73e72bf822ca

Step 2/18 : RUN groupadd -r mongodb && useradd -r -g mongodb mongodb

—> Using cache

—> 0f6297900a5e

Step 3/18 : RUN apt-get update && apt-get install -y –no-install-recommends numactl && rm -rf /var/lib/apt/lists/*

—> Using cache

—> a465f2e906fc

Step 4/18 : ENV GOSU_VERSION 1.7

—> Using cache

—> d448ddca2126

…

• 壓扁(squash)鏡像（實驗階段）

對於老是把 Dockerfile 當作 bash 文件來用的人，會發現很快因爲太多的 RUN 致使鏡像有特別多的層，鏡像超級臃腫，並且甚至會碰到超出最大層數限制的問題。這些人每每不從自身找問題，反而去尋找旁門左道，好比導出鏡像作一些特殊處理，合併爲一層，而後再導入等等，這種作法是很錯誤的，除了致使構建緩存失敗外，還致使 docker history 丟失，致使鏡像變爲黑箱鏡像。其實正確的作法是遵循 Dockerfile 最佳實踐，應該把多個命令合併爲一個 RUN，每個 RUN 要精心設計，確保安裝構建最後進行清理。這樣才能夠下降鏡像體積，以及最大化的利用構建緩存。

在 Docker 1.13 中，爲了應對這羣用戶，實驗性的提供了一個 –squash 參數給 docker build，其功能就是如上所說，將 Dockerfile 中全部的操做，壓縮爲一層。不過，與旁門左道不一樣，它保留了 docker history。

好比以下的 Dockerfile：

FROM busybox

RUN echo hello > /hello

RUN echo world >> /hello

RUN touch remove_me /remove_me

ENV HELLO world

RUN rm /remove_me

若是咱們正常的構建的話，好比 docker build -t my-not-squash .，其 history 是這樣子的：

而若是咱們用 –squash 構建：

docker build -t mysquash –squash .

其 history 則是這樣子：

咱們能夠注意到，全部層的層ID都 <missing> 了，而且多了一層 merge。

要注意，這並非解決懶惰的辦法，撰寫 Dockerfile 的時候，依舊須要遵循最佳實踐，不要試圖用這種辦法去壓縮鏡像。

安裝 

• 解決 GFW 影響 Docker 安裝問題

官方的 apt/yum 源使用的是 AWS 的服務，而且爲了確保安全使用了 HTTPS，所以偉大的牆很樂於干擾你們使用。沒辦法的狀況下，各個雲服務商紛紛創建本身官方源鏡像，阿里雲、DaoCloud、Azura 等等，而且本身作了個修訂版的 https://get.docker.com 的腳原本進行安裝。

如今這個發生改變了，官方的 https://get.docker.com 將支持 –mirror 參數，你能夠用這個參數指定國內鏡像源，目前支持微軟的 Azure 雲，（或阿里雲？）。使用方法以下，將原來官網安裝命令：

curl -sSL https://get.docker.com/ | sh

替換爲：

curl -sSL https://get.docker.com/ | sh -s — –mirror AzureChinaCloud

若是是阿里雲的話，將 AzureChinaCloud 替換爲 Aliyun。

此時，https://get.docker.com/ 還沒有更新，因此暫時沒法使用，在 1.13 正式發佈後，便可使用。

• 增長更多的系統支持

在此次發佈中，增長了 Ubuntu 16.10 的安裝包，並且對 Ubuntu 系統增長了 PPC64LE 和 s390x 構架的安裝包。此外，還正式支持了 VMWare Photon OS 系統的 RPM 安裝包，以及在 https://get.docker.com 的支持。而且支持了 Fedora 25。同時也因爲一些系統生命週期的結束，而被移除支持，好比 Ubuntu 15.十、Fedora 22 都不在支持了。

網絡 

• 容許 docker run 連入指定的 swarm mode 的網絡

在 Docker 1.12 發佈新的 Swarm Mode 以後，不少人都問過這樣的問題，怎麼才能讓 docker run 連入服務的 overlay 網絡中去？答案是不能夠，由於 swarm 的 overaly 是爲了 swarm service 準備的，相對更健壯，而直接使用 docker run，會破壞了這裏面的安全模型。

可是因爲你們需求不少，因而提供了一種折衷的辦法。1.13 容許創建網絡的時候，設定該網絡爲 attachable，容許以後的 docker run 的容器鏈接到該網絡上。

咱們建立一個不容許以後 attach 的網絡：

$ docker network create -d overlay mynet1

xmgoco2vfrtp0ggc5r0p5z4mg

而後再建立一個容許 attach 的網絡，這裏會使用 1.13 新加入的 –attachable 參數：

$ docker network create -d overlay –attachable mynet2

yvcyhoc6ni0436jux9azc4cjt

而後咱們啓動一個 web 服務，連入這兩個網絡：

$ docker service create \

–name web \

–network mynet1 \

–network mynet2 \

nginx

vv91wd7166y80lbl833rugl2z

如今咱們用 docker run 啓動一個容器連入第一個網絡：

$ docker run -it –rm –network mynet1 busybox

docker: Error response from daemon: Could not attach to network mynet1: rpc error: code = 7 desc = network mynet1 not manually attachable.

因爲 mynet1 不容許手動 attach 因此這裏報錯了。

在 1.12 的狀況下，會報告該網絡沒法給 docker run 使用：

docker: Error response from daemon: swarm-scoped network (mynet1) is not compatible with `docker create` or `docker run`. This network can only be used by a docker service.

See ‘docker run –help’.

不過，–attachable 其實是將網絡的安全模型打開了一個缺口，所以這不是默認設置，並且並不推薦使用。用戶在使用這個選項創建網絡的時候，必定要知道本身在作什麼。

• 容許 docker service create 映射宿主端口，而不是邊界負載均衡網絡端口

首先，docker service create 中的 –publish 將改成 –port（縮寫仍是 -p 不變）。之因此這麼作，是由於對映射開放端口有了更進一步的發展，原來的 –publish 1234:1234 的格式已沒法知足需求。

在 1.12 中，docker service create 容許使用參數 –publish 80:80 這類形式映射邊界(ingress)網絡的端口，這樣的映射會享受邊界負載均衡，以及 routing mesh。

從 1.13 開始，增長另外一種映射模式，被稱爲 host 模式，也就是說，用這種模式映射的端口，只會映射於容器所運行的主機上。這就和一代 Swarm 中同樣了。雖然失去了邊界負載均衡，可是肯定了映射點，有的時候更方便管理。

如今新的 –port 的參數形式和 –mount 差很少。參數值爲 , 逗號分隔的鍵值對，鍵值間以 = 等號分隔。目前支持 4 項內容：

• protocol： 支持 tcp 或者 udp
• mode： 支持 ingress 或者 host
• target： 容器的端口號
• published： 映射到宿主的端口號

好比，與 -p 8080:80 等效的 –port 選項爲：

–port protocol=tcp,mode=ingress,published=8080,target=80

固然咱們能夠繼續使用 -p 8080:80，可是新的選項格式增長了更多的可能。好比，使用 1.13 開始加入的 host 映射模式：

ubuntu@d1:~$ docker service create –name web \

–port mode=host,published=80,target=80 \

nginx

運行成功後，查看一下服務容器運行的節點：

咱們能夠看到，集羣有3個節點，而服務就一個副本，跑到了 d3 上。若是這是之前的使用邊界負載均衡的網絡 ingress 的話，那麼咱們訪問任意節點的 80 端口都會看到頁面。

可是，host 模式不一樣，它只映射容器所在宿主的端口。所以，若是咱們 curl d1 的話，應該什麼看不到網頁，而 curl d3 的話就會看到頁面：

root@d1:~$ curl localhost

curl: (7) Failed to connect to localhost port 80: Connection refused

root@d3:~$ curl localhost

<!DOCTYPE html>

<html>

<head>

<title>Welcome to nginx!</title>

…

• iptables 的轉發規則將默認拒絕

從默認容許改成默認拒絕，從而避免容器外露的問題。

• 在 docker network inspect 裏顯示連入節點

Show peer nodes in docker network inspect for swarm overlay networks #28078

• 容許 service VIP 能夠被 ping

在 1.12 的二代 Swarm 排障過程當中，常見的一個問題就是跨節點的服務 VIP 不能夠 ping，因此不少時候不少時候搞不懂是 overlay 網絡不通呢？仍是服務沒起來？仍是服務發現有問題？這個問題在 1.13 解決了，VIP 能夠隨便 ping，跨宿主也不要緊。

插件

• 插件功能正式啓用

在 1.12 引入了插件概念後，做爲試驗特性獲得了不少關注。包括服務端的 Docker Store 開始準備上線，以及第三方的插件的開發。如今 1.13 插件做爲正式功能提供了。

$ docker plugin

Usage: docker plugin COMMAND

Manage plugins

Options:

–help   Print usage

Commands:

create      Create a plugin from a rootfs and config

disable     Disable a plugin

enable      Enable a plugin

inspect     Display detailed information on one or more plugins

install     Install a plugin

ls          List plugins

push        Push a plugin to a registry

rm          Remove one or more plugins

set         Change settings for a plugin

Run ‘docker plugin COMMAND –help’ for more information on a command.

相比於 1.12 的試驗版本而言，增長了 docker plugin create 命令，指定 rootfs 和 config.json 便可建立插件。