Docker 是一個 Client-Server 架構的應用，人家是有官稱的：Docker Engine。Docker 隻是大家對 Docker Engine 的昵稱，當然 Docker 還有其他的意思，比如一家公司的名稱。簡單起見，本文中的 Docker 等同于 Docker Engine。
提到 Docker 我們必須要知道它包含了三部分内容：
Docker daemon
一套與 Docker daemon 互動的 REST API
一個指令行用戶端
下圖很清晰的展示了它們之間的關系：
Docker Machine 則是一個安裝和管理 Docker 的工具。它有自己的指令行工具：docker-machine。
既然 Docker 用戶端要和 Docker daemon 通過 REST API 通信，那就讓我們看看它們可以采用的方法有哪些：
Unix socket
Systemd socket activation
Tcp
我們可以簡單的把 1 和 2 了解成一種方式，就是同一台主機上的程序間通信。至于 3 則很好了解：通過 tcp 協定進行跨網絡的通信。
既然 1 和 2 用于同一台機器上的程序間通信，那麼我們可以猜想：安裝在同一主機上的 Docker 用戶端和 Docker daemon 就是通過這種方式來通信的。事實也正是如此，我們可以檢視安裝 Docker 時預設添加的 Docker daemon 啟動配置，打開檔案 /etc/systemd/system/multi-user.target.wants/docker.service：
圖中的 -H 用來指定 Docker Daemon 監聽的 socket，此處指定的類型為 system socket activation。使用類型 1 和 2 進行通信需要程序具有 root 權限。這也是 Docker 安裝過程中會自動建立一個具有 root 權限的使用者和使用者組的主要原因。新建立的使用者和使用者組名稱為 docker，建議大家把需要操作 Docker 的使用者都加入到這個組中，否則當你執行指令時就會碰到下圖顯示的問題：
我們還可以同時指定多個 -H 參數讓 Docker daemon 同時監聽不同的 socket 類型。比如要添加對 TCP 端口 2376 的監聽就可以使用下面的指令行參數：
運作上面的指令，然後檢視本機監聽的端口：
此時我們就可以從遠端主機上的 Docker 用戶端通路這部主機的 2376 端口了。
Docker 用戶端預設的配置是通路本機的 Docker daemon，當你指定了 DOCKER_HOST 變量後，Docker 用戶端會通路這個變量中指定的 Docker daemon。讓我們回顧一下 docker-machine env 指令：
原來我們在前文中執行的 $ eval $(docker-machine env krdevdb) 指令就是在設定 DOCKER_HOST 環境變量。
我們的 Docker daemon 監聽了 tcp 端口，糟糕的是此時我們沒有做任何的保護措施。是以任何 Docker 用戶端都可以通過 tcp 端口與我們的 Docker daemon 互動，這顯然是無法接受的。解決方案是同時啟用 Docker daemon 和 Docker 用戶端的 TLS 證書認證機制。這樣 Docker daemon 和 Docker 用戶端之間的通信會被加密，并且隻有安裝了特定證書的用戶端才能夠與對應的 Docker daemon 互動。
至此本文的鋪墊部分終于結束了，接下來我們将讨論 Docker Machine 相關的内容。
根據 Docker Machine 驅動的不同，create 指令執行的操作也不太一樣，但其中有兩步是我們在這裡比較關心的：
docker-machine 會在您指定的主機上執行下面的操作：
安裝 Docker，并進行配置。
生成證書保護 Docker 服務的安全。
Docker 的安裝過程并沒有什麼秘密，這裡不再贅述。我們重點關注 Docker daemon 的配置。仔細觀察我們會發現，通過 docker-machine 安裝的 Docker 在 /etc/systemd/system 目錄下多出了一個 Docker 相關的目錄：docker.service.d。這個目錄中隻有一個檔案 10-machine.conf：
好吧，-H tcp://0.0.0.0:2376 出現在這裡并沒有讓我們太吃驚。在我們做了巨多的鋪墊之後，你應該覺得這是理所當然才是。--tls 開頭的幾個參數主要和證書相關，我們會在後面的安全設定中詳細的介紹它們。讓人多少有些疑惑的地方是上圖中的 /usr/bin/docker。目前最新版本的 Docker Machine 還在使用舊的方式設定 Docker daemon，希望在接下來的版本中會有所更新。
這個配置檔案至關重要，因為它會覆寫 Docker 預設安裝時的配置檔案，進而以 Docker Machine 指定的方式啟動 Docker daemon。至此我們有了一個可以被遠端通路的 Docker daemon。
我們在 Docker daemon 的配置檔案中看到四個以 --tls 開頭的參數，分别是 --tlsverify、--tlscacert、--tlscert和 –tlskey。其中的 --tlsverify 告訴 Docker daemon 需要通過 TLS 來驗證遠端用戶端。其它三個參數分别指定了一個 pem 格式檔案的路徑，按照它們指定的檔案路徑去檢視一下：
對比一下手動安裝的 Docker，會發現 /etc/docker 目錄下并沒有這三個檔案。毫無疑問它們是 Docker Machine 生成的，主要是為了啟用 Docker daemon 的 TLS 驗證功能。關于 TLS，筆者在《區域網路内部署 Docker Registry》一文中略有涉及，當時是手動配置的證書，感興趣的朋友可以參考一下。
現在讓我們回到安裝了 Docker Machine 的主機上。
檢視 /home/nick/.docker/machines/krdevdb 目錄，發現了一些同名的檔案(ca.pem、server-key.pem 和 server.pem)，和主機 drdevdb 上的檔案對比一下，發現它們是一樣的！
讓我們再來觀察一下這幅圖：
除了我們關注過的 DOCKER_HOST，還有另外三個環境變量。其中的 DOCKER_TLS_VERIFY 告訴 Docker 用戶端需要啟用 TLS 驗證。DOCKER_CERT_PATH 則指定了 TLS 驗證所依賴檔案的目錄，這個目錄正是我們前面檢視的 /home/nick/.docker/machines/krdevdb 目錄。
行文至此，困擾我們的安全問題終于得到了解釋：Docker Machine 在執行 create 指令的過程中，生成了一系列保證安全性的秘鑰和數字證書(*.pem)檔案。這些檔案在本地和遠端 Docker 主機上各存一份，本地的用于配置 Docker 用戶端，遠端主機上的用于配置 Docker daemon，讓兩邊都設定 TLS 驗證的标記，依此實作安全的通信。
本文轉自xmgdc51CTO部落格，原文連結：http://blog.51cto.com/12953214/1941214 ，如需轉載請自行聯系原作者