資安廠商Sysdig釋出年度容器使用報告，分析了將近200萬個容器，並且整合來自CNCF、Docker Hub以及GitHub等公開資料。

Sysdig提到，比起前一次調查，在建構過程就掃描容器映像檔的用戶增加，表示企業逐漸建立提早測試的觀念，而在Runtime的使用上，Docker占比大幅下降，而Containerd以及CRI-O成長率均達到200％

https://www.ithome.com.tw/news/142242

本篇文章的標題很聳動，看起來是要人完全放棄 Docker，實際上則是詳細的跟大家介紹 Docker 生態系中各種潛在的替換工具，這個生態系主要可以分成 Container Engines, Building Images, Container Runtime 以及 Image Inspection and Distribution.

文章內容偏長，但是偏向系統與概念的去介紹，也是非常推薦吃飯時的良好讀物。
這篇就簡單重點整理一下，詳細的還是請點選全文去觀看

1. Container Engines
作者列出了幾個競爭對手，譬如 podman, lxd, cri-o 以及 rkt. 不過介紹都是以 podman 為主，其特色有(1)daemonless, (2) non-root container, (3) 支援 pod 的概念
此外 podman 的指令完全相容於 docker，因此也可以透過 aliase docker=podman 的方式去運行。

2. Building Images
這邊提到了 Buildah, Kaniko 以及 buildkit.
Buildah 是由 RedHat 所推廣的開源專案，天生整合到 podman 裡面，而 Kaniko 則是 Google 所推出的解決方案，主要應用場景是於 Kubernetes 內建置 contianer image。最後 buildkit 則是 moby 目前開發的下一代 docker build 解決方案，期望能夠提供更多的功能及來提升建置的效率

3. Contianer Runtime
這邊的選擇性列出兩個，最常使用的 runc 以及 RedHat 開源的 crun，兩者都遵循 OCI 標準，因此上述的 Container Engine 都必須要可以輕鬆的於兩者之間切換。

當然除了這些之外，還有不同的 Contaienr Runtime，譬如 gVisor, Kata Container 等安全性更高的解決方案。

4. Image Inspection and Distribution
這邊則是提到了 Skopeo，一樣是由 RedHat 所推廣的開源專案，Skopeo 甚至支援同步不同節點的 Container Registry 而不需要將其內容可複製到本地端，使用上有滿多有趣的功能。

此外還有一個叫做 Dive 的工具也非常棒，能夠幫你檢視 Docker Image 每一層的內容，譬如使用的空間大小等，讓你有機會好好的認識你的 imagea。

5. Others:

當然這篇文章內就沒有花太多篇幅介紹 CRI-O 以及 ContainerD 的關係與概念，如果你對於 CRI/CRI-O/ContainerD 有興趣的話，也可以參考我之前的線上 meetup 錄影: https://www.youtube.com/watch?v=5JhQOjSSnzQ&t=2s

原文: https://towardsdatascience.com/its-time-to-say-goodbye-to-docker-5cfec8eff833

昨天受邀參加 CNTUG 社群所舉行的一場線上分享會，來跟大家探討一下最近 Kubernetes 1.20 的議題，也就是 dockershim 的退休倒數計畫

為了能夠更加充分地去理解這次的改動，我們必須要對 Docker, Kubernetes, CRI 以及 OCI 這四個關鍵字有所瞭解，當你對這些東西的彼此關係都熟悉與清楚後，你就會發現這次的改動其實沒太大影響，對於開發者來說幾乎是毫無感覺。而系統維運者甚至服務提供者則是會因為底層軟體的變動而會有一些轉移的過程需要去思索該怎麼做。

昨天與會人數將近125人，討論非常踴躍，等會議錄影處理完畢後會再釋出，到時候大家可以再次回味。

這邊用比較簡單的敘述去幫大家稍微釐清一下標題四個元件的差異。

以下概念我們主要探討的是 2020 當下的架構，過往舊版的架構不列入考慮之中，有心力與興趣的可以再去挖掘這些架構演進

1. Docker 是 Contianer 的解決方案之一，除了 Docker 外也有別的方案可以提供 Container 的應用與環境，因此要注意，不要再說 Container 就是 Docker。 這句話於現在是一個完全錯誤的說法
2. 有一個叫做 OCI (Open Container Initiative) 的概念，旨於標準化 Container 環境，該標準定義了兩大項，分別是 Runtime 以及 Image.
Runtime 定義了該如何運行一個 Container，而 Image 則定義了 Image 的格式
4. Docker 解決方案產生出的 image 是完全遵循 OCI Image 格式，而 Docker 運行的 Container 也是遵循 OCI Runtime。
精準的說 Docker 指令會把內容送給 Dockerd，而 dockerd 會再把運行的指令送給 containerd，而 containerd 最後會叫起一個基於 OCI Runtime 標準實作的解決方案 Runc，最後產生出運行的 Container。
4. 根據上述架構，Docker 產生出的 image 以及運行的 container 其實最後都跟 OCI 標準脫不了勾
5. Kubernetes 一開始就表明我是 Container 管理平台，不是 Docker 管理平台，希望能夠支援不同的 Container 解決方案。 Docker 只是其中之一罷了
6. Kubernetes 希望透過 CRI (Container Runtime Interface) 來銜接各式各樣的容器解決方案
7. Docker 出世的時間早於 Kubernetes，因此 Kubernetes 無法使用 CRI 來直接銜接 Docker
8. 因此 Kubernetes 設計與實作了一個名為 dockershim 的中間層，該層透過 CRI 與 Kubernetes 溝通，同時往下與 docker 溝通來創建最後的 container.
9. 一旦 dockershim 被移除後， kubernetes 還是繼續使用 CRI 的介面與 Container 解決方案溝通，只是 docker 這邊就找不到一個很好的角色來串接彼此的對話。
10. 其他的解決方案，譬如 containerd, CRI-O，其底層的實作也都相容於 OCI 標準。這意味你透過 docker build 產生的 image 是可以於上述兩個解決方案去運行的。
因為大家都是基於 OCI 標準

所以這次的影響對於開發者來說毫無感覺，繼續使用 docker 還是可以讓你的服務交給 Kubernetes 處理，只要底層使用的解決方案也是相容 OCI 標準。

相關影片: https://www.youtube.com/watch?v=nc3mBN3LzvM&feature=youtu.be
相關投影片: https://www2.slideshare.net/hongweiqiu/the-relationship-between-docker-kubernetes-and-cri