Docker遇到的一些問題和感想

Docker 是“不可變”架構。

　　當你希望改變一個服務的時候（比如更新版本、修改配置、開放端口），不允許直接登錄到服務器上改變某個文件，而是應該把這個服務整個刪掉，然后替換成新的版本。你不能改變它，只能替換它，這就是 Docker 的優點。

　　在服務規模大的時候，這種維護方式能夠保持每個服務版本、配置的一致性。Docker 禁止對容器內部做任何修改，所以只要查看鏡像版本和調度參數，就能判斷服務的一致性。系統運行在軟件定義的基礎架構上，這樣就可以使用版本管理工具（比如 Git）管理基礎架構的變化，像管理軟件版本一樣管理整個環境。這是他的優勢。

Docker “還不夠好”。

1. 不少同事或者朋友，吐槽了Docker的很多麻煩事兒，簡單說就是拋棄了傳統的操作系統環境，很多原來的東西都要用新的容器工具鏈。Docker的隔離性也沒有虛擬機級別的好。這些都是客觀存在的。Docker是一套新的承載環境，相對於傳統的虛擬機需要非常多的新的工具鏈，但遠沒有成熟。帶來的好處，在傳統的模式下也不是沒有方案。所以Docker仍然缺少決定性的優勢。並不能說服大家大規模的遷移和適應。
2. 目前docker 鏡像，沒有統一標准，體現在一下幾個方面。在使用過程中會遇到過各種本班的 OS。包括 alpine, debian, ubuntu, centos, oraclelinux, redhat 等等。即使是鏡像采用 CentOS 母版，很多鏡像制作者會給操作系統減肥。經過優化后，已經不是官方版本，在使用過程中你會遇到各種麻煩。例如調試的時候需要 curl,wget,telnet,nslookup 等工具在鏡像中沒有。甚至 ps, top, free, find, netstat, ifconfig 命令都沒有。很多容器都不帶 iptables 所以，即使帶有iptables 在容器中修改規則也很麻煩。

3. 傳統OS 以 CentOS為例，有嚴格的安裝規范，例如：

   /etc/example  配置文件
   /bin/sbin 二進制文件
   /var/lib/example 數據文件
   /var/log/example 日志文件
   /var/run/example PID 文件
   
   /etc/sysconfig/example 啟動參數文件
   /etc/system.d/example  啟動腳本

   或者被安裝在：

   /usr/local/etc 配置文件
   /usr/local/bin 可執行文件
   /usr/local/share 文檔

   最后一種是獨立安裝在：/usr/local/example 下。容器鏡像那可是五花八門，沒有統一標准，如果不看 Dockerfile 根本不知道作者將文件安裝到了哪里。常常存儲目錄被放置在根目錄。例如 /data

4. 在我的執業生涯中是遇到過 Linux 系統有BUG的，如果你采用的鏡像有BUG，你想過怎么去debug 嗎？
5. 在Linux是一般是采用守護進程方式啟動。啟動后進入后台，啟動采用 systemd 。
   1. 容器中啟動通常是直接運行，這樣的運行方式，相當於你在linux的Shell 終端直接運行一樣，是在前台運行，隨時 CTRL + C 或者關閉終端窗口，程序就會退出。容器采用這種方式啟動，就是為了讓 docker 管理容器，docker 能夠感知到容器的當前狀態，如果程序退出，docker 將會重新啟動這個容器。　　
   2. 守護進程方式需要記錄 pid 即父進程ID，用於后面管理該進程，例如可以實現 HUP 信號處理。也就是 reload 操作，不用退出當前程序實現配置文件刷新。處理 HUP 信號，無需關閉 Socker 端口，也不會關閉線程或進程，
   3. 用戶體驗更好。容器是直接運行（前台運行），所以沒有 PID 也不能實現 reload 操作。 配置文件更新需要重新啟動容器，容器啟動瞬間TCP Socker 端口關閉，此時用戶會 timeout。甚至該服務可能會引起集群系統的雪崩效應。
   4. 很多鏡像制作者更趨向使用環境變量傳遞啟動參數。當然你也可以在容器中使用 systemd ，這樣做容器不能直接感知到容器的運行狀態，systemctl stop example 后，容器仍然正常。需要做存活和健康檢查。通過健康狀態判斷容器的工作情況。如果處於非健康狀態，將該節點從負載均衡節點池中將它踢出去。
   5. Linux 啟動一個應用遠遠比docker 啟動一個容器速度要快。因為物理機或者虛擬機的Linux操作系統已經啟動，虛擬機也分配了資源，運行可執行文件基本上是瞬間啟動。而 docker 啟動容器，要分配資源（分配內存和CPU資源，新建文件系統），相當於創建一個虛擬機的過程，最后載入約200MB左右的鏡像，並將鏡像運行起來，所以啟動所需時間較長，有時不可控，尤其是Java應用更為突出。
6. 存儲面臨的問題。傳統 Linux 直接操作本地硬盤，IO性能最大化。私有雲還好辦公有雲處處受限。自建的 Docker 或 Kubrnetes 可以使用宿主主機資源，公有雲只能使用網絡文件系統和分布式系統。這也是我的架構中 KVM，Docker，Kubernetes，物理機混合使用的原因，根據業務場景的需要來選擇哪種方案。
   1. 物理機上部署 docker 可以分配宿主主機的所有資源，適合做有狀態的服務的存儲持久化的需求。
   2. 私有雲Kubernetes 適合做 CPU密集型運算服務，雖然通過local 卷和 hostPath 可以綁定，但是管理起來不如 Docker 更方便。
   3. NFS 基本是做實驗用的，不能用在生產環境。我職業生涯遇到過很多奇葩，例如 NFS 卡頓，NFS 用一段時間后訪問不了，或者可以訪問，文件內容是舊的等等。無論是NFS是更先進的分布式文件系統，如果不是 10G以太網，基本都不能用在生產環境。多年前我用4電口1G網卡做端口聚合勉強可以用於生產環境，不過當年的互聯網生態跟當今不同，那時還是以圖文為主，確切的說是文字為主，配圖還很少。
7. 內部域名DNS。由於在集群環境中容器名稱是隨機，IP地址是不固定的，甚至端口也是動態的。為了定位到容器的節點，通常集群中帶有DNS功能，為每個節點分配一個域名，在其他容器中使用域名即可訪問到需要的容器。
   1. 看似沒有問題，我的職業生涯中就遇到過DNS的問題，bind,dnsmseq 我都用過，都出現過事故。解析卡頓，ping  www.domain.com  后遲遲解析不出IP。最長一次用了幾分鍾才解析到IP地址。
   2. 所以后面就非常謹慎，配置文件中我們仍然使用域名，因為修改配置文件可能需要 reload 應用，或者重新部署等等。域名寫入配置，方便IP地址變更。例如 db.host=www.domain.com   同時我們會在 /etc/hosts 中增加 xxx.xxx.xxx.xxx    www.domain.com。這樣主要使用 /etc/hosts 做解析，一旦漏掉 /etc/hosts 配置 DNS 還能工作。
   3. 故障分析。DNS 使用 UDP 協議 53 端口，UDP 在網絡中傳輸不會返回狀態，有無數種可能導致 DNS 解析失敗。例如內部的交換機繁忙，背板帶寬不夠（用戶存儲轉發數據包，你可以理解就是交換機的內存），路由的問題等等……
8. 容器中的網絡環境。
   1. 相比傳統網絡，容器中的網絡環境是十分復雜的。傳統網絡中一個數據包僅僅經過路由器，交換機，達到服務器，最多在服務前在增加一些防火牆，負載均衡等設備。
   2. 容器網絡部分實現方式SDN（軟件定義網絡）相比物理機（路由器、交換機、無服務）實現相對復雜。容器里面使用了IP轉發，端口轉發，軟路由，lvs，7層負載均衡等等技術…… 調試起來非常復雜。docker 的 iptables 規則很頭痛。
   3. 例如一個TCP/IP 請求，需要經過多層虛擬網絡設備（docker0,bridge0,tun0……）層層轉發，再經過4層和7層的各種應用拆包，封包，最終到達容器內部。有興趣你可以測試一下對比硬件設備，容器的網絡延遲和吞吐量。
9. 容器的管理。
   1. 傳統服務可以通過鍵盤和顯示器本地管理，OpenSSH 遠程管理，通過配置還能使用串口。容器的管理讓你抓狂 docker exec 和 kubectl exec 進入后與傳統Linux差異非常大，這是鏡像制作者造成的。
   2. 有些鏡像沒有初始化 shell 只有一個 $ 符號，沒有彩色顯示，可能不支持 UTF-8，中文亂碼，可能不是標准 ANSI/XTerm 終端，鍵盤定義五花八門，可能不是美式104鍵盤，國家和時區並不是東八區，HOME 目錄也是不是 /root······
   3. 想查看端口情況，發現 netstat 和 ss 命令沒有。想查看IP地址，發現 ifconfig, ip 命令沒有。想測試IP地址是否暢通，發現 ping, traceroute 沒有。想測試URL，發現 curl , wget 沒有。
   4. 有些鏡像 dnf,yum,apk,apt 可以使用，有些鏡像把包管理也給閹割了，你想安裝上述工具都安裝不了。然后就自己用 Dockerfile 編譯，整出200MB的鏡像，卧槽這么大。
10. 容器的安全。
    1. 很多容器的鏡像中是不包含 iptables 的，所以無法做顆粒度很細的容器內部網絡安全設置。即使你制作的鏡像帶有iptables ，多數容器的策略，IP地址和端口是隨機變化的。綁定IP地址又帶了容器的復雜性。一旦攻入一個容器，進入容器后，容器與容器間基本是暢通無阻。
    2. 在容器中藏一個后門比物理機更容易，如上文所說很多容器中沒有調試相關命令，限制了你排查后門的難度。所以Dockerfile 制作鏡像，最好使用官方鏡像衍生出你的鏡像。
11. 容器與CI/CD
    1. 在DevOps場景中，使用 docker 或 kubernetes 做 CI/CD 是很扯淡的。當 git 產生提交后，gitlab/jenkins 啟動容器，下載代碼，編譯，打包，測試，產生構建物，編譯 Dockerfile ，上傳 docker 鏡像到 registry，最后部署到容器執行。卧槽！！！速度能急死你。
    2. 於是乎，我們做了 Cache。 不用每次都 pull 鏡像，緩存 Maven 的 .m2 庫，不再清理代碼（mvn clean）提速不少，測試環境湊合用吧。 注意不mvn clean 有時會編譯出錯。至於生產環境，我就不說了，有多少人真用CD部署生產環境。

使用物理機，虛擬機，學習成本，試錯成本，部署成本遠遠低於容器技術。Google 官方也曾經說過，未來 kubernetes 重點可能會轉向虛擬機。不過Docker的理念和思想還是值得學習的。任何技術都會有平替，只是各種成本的妥協，在你想好怎么處理一些問題的時候，謹慎引入Docker等各類新技術到你的生產環境中。還有一些Docker+微服務遇到的坑和想法，等有空了再更新。