今天帶來的是一篇 Podman 的介紹文，有關注 Container 發展的讀者想必對於 Podman 這個詞一定很熟，然而有真的實際將 podman 導入日常工作流程的我想屈指可數。
本篇文章開頭針對 Podman 與 docker 的差異進行了簡單介紹，並且分析 Podman 透過
1) 沒有 Daemon, 2)不需要 Root 也可以運行 等特性帶來的好處。

接者針對 MacOS, Windows 等兩種不常見的平台介紹如何運行 Podman, 對於非 Linux 工作環境的讀者如果有想要嚐鮮使用 Podman 的話，非常推薦可以參考這篇文章的方式去使用與安裝

最最最重要的是，本篇文章是繁體中文所撰寫的，請大多多給予這類型的文章一點鼓勵，大家才會更有動力去分享各類技術文章，否則都只能看國外文章了:(

https://hazel.style/2021/01/14/How-to-use-Podman-in-Laptop-environments/

在Apple M1測試 Docker 安裝 開源ERP odoo心得
第一先裝了這個 M1 docker 預覽版
https://docs.docker.com/docker-for-mac/apple-m1/
裝好後照軟體下指令

就先裝好了 Docker Developer Preview for M1
參考 https://hub.docker.com/_/odoo
安裝odoo 14 docker
docker pull odoo --platform linux/amd64
(正常x86不用加 --platform linux/amd64)

docker run -d -e POSTGRES_USER=odoo -e POSTGRES_PASSWORD=odoo -e POSTGRES_DB=postgres --name db postgres:10

docker run -p 8069:8069 --name odoo --link db:db -t odoo
打開本機browser 8069 就可以跑odoo了
說真的 docker團隊還願意讓docker 從 HyperKit 換到macOS Big Sur的API Framework Virtualization.
所以可以跑x86 image 容器.但M1都有不少效能折損了
假設換成raspberry pi開發板,就只能限定用arm image(這樣限制不少)

所以必備一台x86 小電腦應用於docker 是很有用的.
https://osslab.tv/shop/acute_angle_mini_pc/

#kubernetes1.20 #docker-bye

隨著 kubernetes 1.20 相關消息愈來愈多，目前一個引起廣泛討論的就是 docker support 將被標示為棄用，並且於未來版本的中將正式移除。

到底這個未來的改變對於開發以及維運人員來說，到底會有什麼樣的衝擊，這邊就來跟大家分享一下我的看法

# 開發人員
Q1: 我需要重新學習新的工具嗎？ 能不能繼續使用 Docker?
A1: 大部分情況下，你不需要重新學習任何工具，可以繼續使用 Docker 作為本地開發，你產生的 Image 依然可以讓 Kubernetes 去運行。

Q2: Kubernetes 一旦不支援 Docker，那我的 Image 還可以放 Docker Hub 嗎?
A2: 這個沒有問題，因為目前的 Container Registry 都基於 OCI 標準來設計，因此格式相容的情況下， Kubernetes 是可以繼續使用 Docker Hub 上的 image.

Q3: 我的開發環境是 Mac，使用的是 Docker for Desktop 並且用 Docker 內建的 Kubernetes 來開發，請問我會被影響嗎
A3: 這個開發環境比較特別，可以讓 docker build 產生的 image 直接給 kubernetes 使用。一旦 Kubernetes 底下使用別套，也許這條路徑會出問題。 因此這個問題值得關注。

# 維運人員
Q1: 我的公有雲 Kubernetes 服務會被影響嗎？
A1: 三大公有雲目前都有提供除了 Docker 以外的解決方案，可以參閱相關文件來切換。
如果已經使用 containerd/cri-o 這些解決方案的話，基本上什麼都不用做。
但是如果本來使用的是 docker 的話，那就要注意一下你的服務提供者有沒有提供轉移方式。

Q2: 自架 Kubernetes 會被影響嗎
A2: 這取決於你的使用方案，譬如你使用 Rancher 的話，預設是使用 Docker，因此勢必未來一定會有一波轉移問題要處理。
另外如果 Kubernetes 節點是由自己處理的，那要注意需要自行安裝其他的 Container Runtime。單純只有安裝 docker.io 是不夠。

Q3: 維運上會有什麼改變?
A3: 未來若 k8s 不再支持 docker，勢必你將不能於節點上使用 docker 這個指令來觀察相關的運行資訊。這部分可能需要改用 ctr 或是 crictl 等不同的 CLI 工具來觀察。
全新的工具，全新的用法勢必需要學習

Q4: 這樣切換有什麼好處?
A4: 不論是切換到 Containerd 或是 CRI-O ，效能上會提升，與資源消耗會下降，整個容器處理流程也會變得更加精銳

# 結論

1. Kubernetes 不是 Docker 管理平台，是容器管理平台。定義 CRI 標準就是為了支援多種容器技術。
2. Docker 被移除是可以考慮的，未來我認為 CRI-O 都有可能變成預設解決方案，因為其本身的設計就是為了 K8s 而最佳化，同時也與 Kubernetes 版本對齊，
3. 1.20 只是警告，將要退役，並不代表完全移除。但是不久的將來就會正式移除。
4. 如果有時間，就提早進行準備，永遠都不要到最後一刻才決定處理。大量仰賴 Open Source 的情況下，每個專案的開發能量也都很重要，一個不再維護的專案用起來會很令人提心跳膽。