新特性初探：Docker for Mac喜迎Kuberntes支持能力
很高興內置支持Docker Swarm和Kubernetes的Mac版Docker[1]發布了，本文將會回顧一下此工具簡史，然後看看新功能的第一印象。
為什麼對開發者很重要？
Docker CE（簡稱Docker）是一款易用簡便的容器工具，是給用戶帶來自主和硬體無關性體驗的軟體。Mac版Docker並不是從一開始就支持Kubernetes，我們看看它的簡史：
Docker發端於DotCloud公司，一開始並不支持Windows和Mac，只能運行在Linux上。
Docker簡史
虛機
最開始，如果Mac或者Linux用戶想使用容器技術，就需要在Linux主機中安裝如VirtualBox或者VMWare Workstation/Player之類的虛擬機工具，並設置共享目錄。為了使用統一CLI工具，用戶不得不採用Hashicorp公司的Vagrant[2]。
使用場景：這種方式都是過時的技術，並不建議採用。
Docker Machine
Docker Machine是進化的第二步，採用boot2docker鏡像在本地或者遠程環境部署虛機，並提供可寫磁碟空間，也是朝易用性邁出的一大步。一旦基於SSL認證的VM生成，Docker客戶端就可以通過TCP/IP工具訪問它，可以同時支持多個Docker版本構成的集群。
優點：
同一主機支持多個容器後端
只支持Linux
使用boot2docker鏡像
模塊化支持各家雲提供商插件
缺點：
命令行方式操作
不支持Windows和Mac
使用場景：使用Windows 7或者Windows 10 Home，需要在本地運行一套集群，或者需要在雲端運維一套集群。
Docker for Mac/Windows
Docker Machine需要太多手工操作（通過docker-machine env），為了採用TLS，有時還需要重建。Docker for Mac/Windows（簡稱DfM）本著造福廣大使用者的初衷，內建UI和菜單支持，推出了功能有限的beta版本，剛開始主要是Twitter使用它。
優點：
安裝簡便
自動配置命令行
圖形化界面配置
一鍵啟停作業
缺點：
共享卷時性能很差
高耗能降低電池使用時間
支持Windows 10 pro或者enterprise
使用場景：可用，但是需要本地安裝Docker Swarm或者Kubernetes。
Minikube
Minikube跟docker-machine非常類似，也依靠boot2docker，初衷是創建內含可用於開發的Docker主機的單節點Kubernetes集群。
Mac上的minikube輸出案例如下：
優點：
本地環境易於訪問
Kubernetes可用
缺點：
Kubernetes在空閑時耗費大量電力
感覺還是跟docker-machine很類似
內置Docker版本嚴重滯後
有些功能尚不支持，例如RBAC（role-based authentication control）
需要使用minikube start/stop
使用場景：需要本地Kubernetes場景但是不必關注Docker版本。
第一印象
以下是我更新DfM後，使用它得到的第一印象。
開始
需要Docker 17.12或者更高版本以獲得Kubernetes支持，然後就是通過UI界面花幾分鐘下載新版本。
上下文和命名空間
如果以前安裝了minikube，需要轉換到DfM上下文，否則kubectl會掛起。
如果發現有太多輸出內容，Kubernetes社區有一個叫kubectx[3]的工具可以改善輸出狀況。
Docker Swarm和Kubernetes之間一個不同是命名空間的支持。默認地，Kubernetes生態容器運行在稱為system的隱藏命名空間，可以通過以下命令查看kubectl get all --all-namespaces：
輸出有很多默認運行的服務，和Docker Swarm一樣，區別是對用戶隱藏，運行在幾個固定二進位代碼中，而不是分散運行的服務。
以下命令可以查看Kubernetes版本：
看起來是1.8.2版本，儘管不是最新版本但也包含了所有重要功能。
整合Docker
Docker希望Kubernetes更加易用，因此整合了Docker stacks和Kubernetes原生部署服務。
Kubernetes是很容易擴展的，Docker使用Custom Resource Definitions （CRDs）引入了對「棧（stack）」概念的支持。可以驗證如下：
看看對compose文件的效果：
CRD驗證：
創建了幾個Pods：
Prometheus有一個bug，可以用這個命令debug：$kubectl logs pod/prom-76b4f584f7-qckc9。
如果仍然使用docker-compose開發和生產，現在可以直接轉向Kubernetes了。
內置工作流
我們期望內置工作流能夠實現：
kubectl apply 支持YAML
helm
RBAC激活
下面部署OpenFaaS-Serverless功能（採用Docker和Kubernetes實現起來很簡單）。
如果碰到命名空間錯誤，可以在faas-netes目錄下執行kubectl apply -f ./namespaces.yml ，然後再嘗試一遍。
OpenFaaS會在localhost:31112啟動圖形界面，並啟用了RBAC和兩個命名空間（openfaas / openfaas-fn），輸出如下：
服務也創建完畢。驗證如下：
然後打開UI，部署一個應用功能：
http://localhost:31112
然後選擇Figlet - figlet是Linux下二進位文件可以產生ASCII 文本logos。
查看產生的Function/Pod：
相對於Docker Swarm，Kubernetes使用更多對象形成服務。
激活服務查看結果:
作業運行很順暢，而且簡單易用。對於社區維護和內置OpenFaaS整合很有幫助。
之前提過需要helm（一個類似OpenFaaS的分散式軟體管理器），在Docker Swarm中沒有類似的概念。
寫這篇博客之前，我在Twitter上看有消息說helm也已經被支持了。
總結
其實不僅是簡單的DfM整合了「棧」，應該說在現有工具外層實現了簡單化，提高了速度，更加易用。相信Docker Swarm用戶都會使用這種整合，而且遷移到Kubernetes。
Docker Swarm 已死？作為Docker Captains用戶組成員，我並沒有更多內部消息，但是因為Docker Swarm仍然有很多用戶，因此仍然會被支持。例如：最原始可以運行在容器內的Swarm仍然被Docker"s UCP product[4]支持。
如果讀了developer reactions on Hacker News[5]，可以看到Swarm仍然有很多粉絲，如果Kubernetes想吸引他們，那麼on-prem安裝維護過程需要提高。
因此我的第一印象總結如下：很多新功能令人振奮，尤其是對DfM的更新以及內部新元素使得它看起來更像一個LinuxKit了。
TAG:Docker |