[[272170]]

近日，網友 zwischenzugs 發(fā)文稱，他把自己已經使用了六年的家庭服務器中的 Docker 都刪除了，并使用了其它開源軟件來替代 Docker。

為什么 zwischenzugs 會選擇把所有家庭服務器里的 Docker 都一齊刪除（apt purge -y docker-ce）呢？因為他總是會遇到一個反復出現(xiàn)且令人頭痛的問題：“Docker 守護程序在多個核心上占用 100% CPU 資源，并導致主機無法正常使用。”

zwischenzugs 認為出現(xiàn)這種情況，最可能的原因是腳本失控導致啟動了太多容器，但是他也一直沒能找出更深層次的原因，因為如果想搞清楚原因，必須先刪除所有容器，然后重啟守護程序。由于已經刪除了 Docker，這時再去探究根源似乎也沒什么必要了。

當然，刪除了 Docker，并不意味著zwischenzugs 對 Docker 有所抱怨，只是他突然又想到了之前聽過的一個爭論：“Docker 干嘛要配一個守護程序？”

zwischenzugs 原本由 Docker 負責的工作現(xiàn)在基本都由紅帽發(fā)布的三款工具接管了，分別是 Podman、Skopeo 與 Buildah。它們都不需要守護程序，也不需要訪問 root 權限組。

Podman 能夠替代大部分子命令（run, push, pull 等等）。由于不需要守護程序，而且會利用用戶命名空間模擬容器中的 root，所以 Podman 不需要接入具有 root 權限的 socket——這就解決了 Docker 長期以來一直面臨的老大難問題。

https://podman.io/

Buildah 負責構建 OCI 鏡像。令人困惑的是，podman build 也能夠用于構建 Docker 鏡像，但其速度太慢而且默認使用 vfs 存儲驅動的設置會占用大量磁盤空間。相比之下，buildah bud（「利用 Dockerfile 構建」）對我來說速度更快，而且能夠自動覆蓋存儲驅動。

用戶命名空間允許無 root 構建的功能對我來說同樣非常重要?，F(xiàn)在，至少在 Ubuntu 上，我們已經能夠利用 /etc/subuid 與 /etc/subgid 以開箱即用的方式享受這一便利。

https://buildah.io/

Skopeo 工具允許我們對 Docker 與 OCI 鏡像執(zhí)行 psuh、pull 以及 copy 等操作。

http://github.com/containers/skopeo

與半年前相比，如今在 Ubuntu 上安裝這些工具已經變得非常簡便。不過，runc 好像還是需要獨立安裝，其實 runc 也可以預先設置好。

安裝好之后，我們就來一起看看具體的替換步驟吧。首先，要在 cron 當中替換掉所有 Docker 實例，并通過 Podman 替換所有 CI 任務。這項工作非常輕松，Ansible 腳本就能輕松搞定，剩下的一點問題在 GitHub 庫里搜索一下也可快速解決。

在完成上述操作后，可以利用 sysdig 查看是否還有指向 docker 的引用調用：sysdig | grep -w docker，需要注意的是，這項操作比較占用資源，可能會大大降低系統(tǒng)運行速度。

在確定不存在任何 docker 調用之后，可以運行以下命令：apt remove -y docker-ce。

為了保證之后還能找到某些需要使用的配置，zwischenzugs 并沒有徹底刪除所有用例。當在一切開始穩(wěn)定運行之后，最后一步就是進行“大掃除”：刪除 /etc/apt/* 當中所有指向 Docker apt repo 的剩余源；使用 delgroup docker 從系統(tǒng)當中刪除 docker 組；刪除  etc/docker / *、 /etc/default/docker 以及 /var/lib/docker 當中的所有剩余文件。

也許有人會好奇 Docker Compose 是如何處理的？zwischenzugs 表示：“我其實一直沒用它，所以也就沒什么問題。如果使用了的朋友可以嘗試 podman-compose 項目，只不過該項目目前還不太成熟。”

完成這番替換之后，有哪些不同呢？zwischenzugs 表示：“除了告別守護程序和告別 sudo 訪問要求之外，我并沒覺得有什么其它區(qū)別。對用戶來說，builds 都存放在本地（~/.local/containers 當中）而非全局（/var/lib/docker 當中）。這也與此次使用的工具的設計原理保持一致，即面向用戶而非面向守護程序。不過由于我的家庭服務器中只有一個 Docker 用戶，所以也談不上有多大區(qū)別。”

另一個重大差異在于，與 Docker 相比，podman pull 會并行下載所有層。如果一次性 pull 太多鏡像可能會引發(fā)問題，但是 zwischenzugs 表示，就他自己的用例而言，目前一切運轉良好。

這篇博文發(fā)布之后，在 Hacker News 上引發(fā)了網友的廣泛討論，有網友表示：“放棄 Docker 似乎正在成為新的潮流，最近看到了好幾篇這樣的文章，我仔細查看了每篇文章，得出了一個結論，那就是如果你有比較多的時間，且愿意接受比較多的限制，那么 Docker 是有很多替代品的。”

因為前文中，zwischenzugs 提到了出現(xiàn)異常情況可能的原因是腳本失控導致啟動了太多容器，所以也有網友建議可以修復錯誤腳本，不需大動干戈切換容器平臺來解決。

不過，也有網友對 Docker 本身提出了疑問，Docker 到底能帶來什么樣實質性的好處：用戶真的能夠從容器中獲得好的抽象，從而為部署挑戰(zhàn)提供了更好的解決方案? 例如，無需考慮應用程序中的 http 客戶機被配置為與哪個主機通信，可以通過操作網絡配置在容器級別神奇地重新定向它。如果構建的應用程序使用服務發(fā)現(xiàn)結構，那么同時使用 Docker 是否會獲得額外的好處呢? 人們經常在本地運行生產 Docker 映像來調試生產應用程序問題嗎? 是否存在這樣的解決方案，將調試器附加到遠程 QA 測試人員 chrome 實例上，然后自動將調試器附加到處理與該瀏覽器相關的請求的生產容器集上?

您如何看待網友的這次 Docker 刪除操作？刪除 Docker 是否正在成為新的流行？Docker 到底能帶來什么樣實質性的好處？歡迎在下方留言評論。