七.容器的管理
傳統服務可以通過鍵盤和顯示器本地管理，OpenSSH 遠端管理，通過配置還能使用序列槽。
容器的管理讓你抓狂 docker exec 和 kubectl exec 進入後與傳統Linux差異非常大，這是鏡像制作者造成了。
- 有些鏡像沒有初始化 shell 隻有一個 $ 符号
- 沒有彩色顯示
- 可能不支援 UTF-8，中文亂碼
- 可能不是标準 ANSI/XTerm 終端
- 鍵盤定義五花八門，可能不是美式104鍵盤
- 國家和時區并不是東八區，上海
- HOME 目錄也是不是 /root
- 想檢視端口情況，發現 netstat 和 ss 指令沒有。
- 想檢視IP位址，發現 ifconfig, ip 指令沒有。
- 想測試IP位址是否暢通，發現 ping, traceroute 沒有。
- 想測試URL，發現 curl , wget 沒有。
- 有些鏡像 dnf,yum,apk,apt 可以使用，有些鏡像把包管理也給閹割了，你想安裝上述工具都安裝不了。
卧槽！！！ 一萬匹草泥馬
然後就自己用 Dockerfile 編譯，整出200MB的鏡像，卧槽這麼大。
八.容器與安全
很多容器的鏡像中是不包含 iptables 的，是以無法做顆粒度很細的容器内部網絡安全設定。即使你制作的鏡像帶有iptables ，多數容器的側咯，IP位址和端口是随機變化的。
綁定IP位址又帶了容器的複雜性。
一旦攻入一個容器，進入容器後，容器與容器間基本是暢通無阻。
在容器中藏一個後門比實體機更容易，如上文所說很多容器中沒有調試相關指令，限制了你排查後門的難度。是以Dockerfile 制作鏡像，最好使用官方鏡像衍生出你的鏡像。
九.容器與監控
談到監控，跳不開 prometheus（普羅米修斯），它并不能覆寫到所有監控。
我曾經寫過一篇文章《監控的藝術》網上可以搜到。
容器與CI/CD
在DevOps場景中，使用 docker 或 kubernetes 做 CI/CD 是很扯淡的。
當 git 産生送出後，gitlab/jenkins 啟動容器，下載下傳代碼，編譯，打包，測試，産生建構物，編譯 Dockerfile ，上傳 docker 鏡像到 registry，最後部署到容器執行。
卧槽！！！速度能急死你。
于是乎，我們做了 Cache。 不用每次都 pull 鏡像，緩存 Maven 的 .m2 庫，不再清理代碼（mvn clean）提速不少，測試環境湊合用吧。 注意不mvn clean 有時會編譯出錯
至于生産環境，我就不說了，有多少人真用CD部署生産環境。