最近在 CentOS 8 上敲下dnf install docker-ce之后屏幕上彈出一串以problem with installed package podman-1.6.4-10.module_el8.2.03055e198a41.x86_64開(kāi)頭的報(bào)錯(cuò)先別急著懷疑軟件源配錯(cuò)了。這個(gè)問(wèn)題我前前后后遇到過(guò)好幾次它跟倉(cāng)庫(kù)地址沒(méi)關(guān)系真正原因是 CentOS 8 系統(tǒng)自帶的 podman 與 docker-ce 在同一個(gè)“坑位”上撞了車。這篇文章把報(bào)錯(cuò)原理、處理思路、手把手安裝步驟和后續(xù)容易踩的坑都過(guò)一遍給準(zhǔn)備在 CentOS 8 上轉(zhuǎn)向 Docker 的同學(xué)一份可以直接照著操作的參考。1. 報(bào)錯(cuò)現(xiàn)場(chǎng)podman 到底和 docker 搶了什么1.1 一條典型的安裝報(bào)錯(cuò)長(zhǎng)什么樣假設(shè)你已經(jīng)配置好了 Docker 官方軟件源執(zhí)行dnf install -y docker-ce docker-ce-cli containerd.io正常情況下 DNF 會(huì)直接解析依賴并安裝但 CentOS 8 默認(rèn)預(yù)裝了 Podman 容器工具鏈于是很可能出現(xiàn)下面這種輸出Error: Problem: problem with installed package podman-1.6.4-10.module_el8.2.03055e198a41.x86_64 - package podman-1.6.4-10.module_el8.2.03055e198a41.x86_64 conflicts with docker-ce provided by docker-ce-3:19.03.13-3.el7.x86_64 - docker-ce-3:19.03.13-3.el7.x86_64 conflicts with podman provided by podman-1.6.4-10.module_el8.2.03055e198a41.x86_64 - problem with installed package buildah-1.11.6-10.module_el8.2.03055e198a41.x86_64 - package buildah-1.11.6-10.module_el8.2.03055e198a41.x86_64 conflicts with docker-ce provided by docker-ce-3:19.03.13-3.el7.x86_64注意報(bào)錯(cuò)里的關(guān)鍵詞是conflicts with也就是軟件包沖突。DNF 不是想說(shuō)你的 podman 壞了而是說(shuō)當(dāng)前系統(tǒng)里已經(jīng)裝好的 podman 包與你要安裝的 docker-ce 包之間存在 RPM 層面的沖突關(guān)系兩邊都有同一個(gè)“勢(shì)力范圍”包管理器不允許它們同時(shí)存在。標(biāo)題中出現(xiàn)的1.6.4-10.module_el8.2.03055e198a41也不是隨意生成的版本號(hào)。module_el8.2.0說(shuō)明這個(gè) podman 來(lái)自 CentOS 8.2 的 AppStream 模塊倉(cāng)庫(kù)由container-tools模塊構(gòu)建。x86_64是架構(gòu)。這個(gè)版本號(hào)本身就暴露了它的來(lái)源后面排查模塊時(shí)用得上。1.2 沖突根源CentOS 8 的默認(rèn)容器棧要理解這個(gè)沖突得先知道 CentOS 8 和之前的 CentOS 7 在容器生態(tài)上的態(tài)度變了。CentOS 7 時(shí)代Docker 是默認(rèn)的容器方案系統(tǒng)里幾乎沒(méi)有 Podman 的影子。到了 CentOS 8 / RHEL 8Red Hat 主推的是 Podman、Buildah、Skopeo 這一套“無(wú)守護(hù)進(jìn)程”容器工具鏈系統(tǒng)安裝時(shí)甚至默認(rèn)就把 podman 和相關(guān)組件裝上。這套工具鏈由 AppStream 倉(cāng)庫(kù)里的container-tools模塊統(tǒng)一管理。我們可以在安裝前用下面命令查看dnf module list container-tools正常情況下會(huì)看到類似輸出Name Stream Profiles Summary container-tools rhel8 common Most container tools container-tools 2.0 common Most container tools也就是說(shuō)podman、buildah 這些包是以模塊形式分發(fā)的。正因?yàn)槿绱四銜?huì)在錯(cuò)誤信息里看到module_el8.2.0這種帶著模塊標(biāo)識(shí)的版本號(hào)。那它到底和 Docker 沖突在哪簡(jiǎn)單說(shuō)兩者都想控制同一個(gè)命令入口。Podman 為了兼容習(xí)慣使用 Docker 命令的用戶提供了/usr/bin/docker的模擬入口而 Docker CE 安裝后也要提供/usr/bin/docker。命令名重疊管理方式又不一致RPM 包維護(hù)者為了防止裝完系統(tǒng)一團(tuán)亂直接在包的Conflicts字段里聲明了互斥關(guān)系。于是 DNF 檢查依賴時(shí)發(fā)現(xiàn)已經(jīng)有 podman 占著位置再裝 docker-ce 就違反了沖突規(guī)則只能停下。1.3 為什么 DNF 不自動(dòng)把 podman 卸掉很多新手第一反應(yīng)是既然沖突你 DNF 為什么不自動(dòng)卸載舊包這個(gè)想法很危險(xiǎn)。包管理器的核心原則是盡量不破壞用戶已有的系統(tǒng)狀態(tài)。當(dāng)前系統(tǒng)里已經(jīng)安裝了 podman也許有用戶正用它在跑容器也許有其他軟件依賴 podman比如 CentOS 8 的 Web 管理面板組件cockpit-podman。如果 DNF 默認(rèn)就自動(dòng)刪除現(xiàn)有包很容易把用戶的運(yùn)行環(huán)境搞壞。所以 DNF 的策略是發(fā)現(xiàn)沖突后先報(bào)錯(cuò)把沖突的包列出來(lái)等用戶明確表態(tài)。你可以手動(dòng)卸載也可以用--allowerasing參數(shù)讓它“自行其是”。我見(jiàn)過(guò)不少人在這一步直接上--allowerasing后面把系統(tǒng)里某些依賴 Podman 的功能也順帶走弄得手忙腳亂。正確的做法是搞清楚誰(shuí)依賴 podman再?zèng)Q定刪除范圍。2. 動(dòng)手前倉(cāng)庫(kù)、模塊、備份一個(gè)都別漏2.1 先確認(rèn)系統(tǒng)版本和已裝組件在清理之前我強(qiáng)烈建議先摸清系統(tǒng)現(xiàn)狀。第一步看版本cat /etc/os-release確認(rèn)系統(tǒng)確實(shí)是 CentOS 8且知道是 8.幾。不同小版本的模塊流名稱可能不同報(bào)錯(cuò)信息里的el8.2.0說(shuō)明當(dāng)前環(huán)境大概率是 8.2。不過(guò)即便小版本不同處理思路完全一致。接著看當(dāng)前已經(jīng)裝了多少相關(guān)包rpm -qa | grep -E podman|buildah|skopeo|runc|containernetworking這條命令能列出 podman、buildah、skopeo、runc 等一系列容器組件的版本。在我的經(jīng)驗(yàn)里光刪一個(gè) podman 往往不夠因?yàn)?buildah 也會(huì)和 docker-ce 沖突報(bào)錯(cuò)里已經(jīng)寫(xiě)了。所以觀察完整列表避免刪一次再報(bào)一次。再看倉(cāng)庫(kù)狀態(tài)dnf repolist如果之前折騰過(guò)各種軟件源先看一眼有哪些倉(cāng)庫(kù)是啟用的。尤其是epel、extras、AppStream、BaseOS。Docker 官方源的包名有些會(huì)和 EPEL 里的包重名或沖突提前知道有助于判斷后續(xù)依賴問(wèn)題。2.2 添加 Docker 官方軟件源如果你還沒(méi)加 Docker 官方源先補(bǔ)上。還是那套經(jīng)典命令dnf install -y yum-utils yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repoyum-utils提供yum-config-manager工具后面可以用它管理倉(cāng)庫(kù)。添加完成后建議先dnf makecache刷新一下元數(shù)據(jù)避免裝出“找不到包”的靈異問(wèn)題。添加完倉(cāng)庫(kù)順手檢查一下 repo 文件的開(kāi)關(guān)狀態(tài)cat /etc/yum.repos.d/docker-ce.repo這個(gè)文件里會(huì)有docker-ce-stable、docker-ce-test、docker-ce-nightly三個(gè)源默認(rèn) stable 是啟用的。除非你在做測(cè)試否則不建議啟用 nightly 和 test否則裝上非穩(wěn)定版可能給自己添亂。2.3 清理前務(wù)必備份容器數(shù)據(jù)這一步很多人忽略但真出了事才后悔。比如你當(dāng)前正是在用 podman 跑業(yè)務(wù)容器或者本地編過(guò)鏡像一旦刪除 podman 相關(guān)包默認(rèn)存儲(chǔ)目錄/var/lib/containers下的鏡像、容器數(shù)據(jù)可能直接不可用。因此在移除前先把該導(dǎo)出的東西導(dǎo)出podman ps -a podman images podman save -o my-images.tar 鏡像名 podman commit 容器名 backup-image:latest如果 podman 里的容器已經(jīng)不需要了那可以跳過(guò)備份。但如果里面有幾個(gè)跑了很久的數(shù)據(jù)庫(kù)容器我建議老老實(shí)實(shí)把數(shù)據(jù)目錄也備份一份tar czf containers-backup.tar.gz /var/lib/containers ~/.config/containers /etc/containers別嫌這一步多余。之前我在處理類似問(wèn)題時(shí)遇到過(guò)一位同事沒(méi)備份就直接dnf remove podman結(jié)果里面一個(gè)本地測(cè)試環(huán)境的數(shù)據(jù)全沒(méi)了連回滾的余地都沒(méi)有。容器工具替換是小操作數(shù)據(jù)安全是大事情。3. 三招解決 podman 沖突親測(cè)可用3.1 方案A手動(dòng)移除沖突包最直觀既然 DNF 說(shuō)已安裝包和 docker-ce 沖突那直接刪掉這些沖突包是最符合直覺(jué)的做法。執(zhí)行dnf remove -y podman buildah這里只刪除 podman 和 buildah 是否夠?qū)嶋H上報(bào)錯(cuò)里還可能出現(xiàn)skopeo、runc、containernetworking-plugins等包沖突。為了減少來(lái)回折騰我習(xí)慣把這一套默認(rèn)容器工具鏈一起移除dnf remove -y podman buildah skopeo runc containernetworking-plugins執(zhí)行過(guò)程中 DNF 會(huì)提示有哪些包會(huì)被連帶刪除比如cockpit-podman。這時(shí)候要仔細(xì)看一眼如果系統(tǒng)里有需要保留的組件就要考慮是不是只用 Docker 這個(gè)決定值得重新評(píng)估。當(dāng)前環(huán)境如果沒(méi)有其他軟件依賴 podman移除后就可以直接安裝dnf install -y docker-ce docker-ce-cli containerd.io這個(gè)方案的優(yōu)點(diǎn)是邏輯簡(jiǎn)單每一步都可以確認(rèn)。缺點(diǎn)是如果只刪了 podman 而忘了 buildah第二次安裝可能還會(huì)報(bào)類似的problem with installed package buildah...所以建議一次把相關(guān)工具鏈清干凈。3.2 方案B禁用 container-tools 模塊更穩(wěn)妥如果只是想刪一次包那方案A足夠。但如果你希望以后系統(tǒng)更新時(shí)不會(huì)被莫名拉回 podman 相關(guān)組件或者你想從“模塊層面”把整條容器工具鏈暫時(shí)關(guān)掉可以配合禁用模塊一起操作。先看模塊狀態(tài)dnf module list container-tools然后執(zhí)行禁用dnf module disable container-tools這里要注意一個(gè)細(xì)節(jié)module disable只是讓 DNF 不再把這個(gè)模塊作為可用軟件包來(lái)源并不會(huì)自動(dòng)刪除已經(jīng)安裝的 podman 和 buildah。所以真正安裝前仍然要手動(dòng)卸載已裝的包dnf remove -y podman buildah skopeo runc containernetworking-plugins為什么建議把禁用模塊和刪除包一起做因?yàn)槿绻阒粍h包但不禁用模塊下一次執(zhí)行dnf update時(shí)只要 AppStream 模塊仍處于啟用狀態(tài)系統(tǒng)有可能因?yàn)槟承┙M件的依賴把 podman 重新拉回來(lái)于是沖突再次出現(xiàn)。先禁用模塊等于提前把“再安裝”的路徑堵死。在正式的服務(wù)器環(huán)境中我更推薦這個(gè)組合拳。它多執(zhí)行一條命令但后續(xù)維護(hù)更省心不容易莫名其妙復(fù)發(fā)。3.3 方案C用 --allowerasing 臨時(shí)繞過(guò)但不建議如果只是臨時(shí)測(cè)試機(jī)、或者你不在乎系統(tǒng)里原本裝了啥可以用一條命令強(qiáng)行讓 DNF 決定刪除沖突包dnf install -y docker-ce docker-ce-cli containerd.io --allowerasing--allowerasing的含義是“允許刪除已安裝包以解決依賴問(wèn)題”。DNF 會(huì)自行分析哪些現(xiàn)有包需要被移除然后繼續(xù)安裝。好處是快一條命令結(jié)束壞處是 DNF 可能刪掉一些你并沒(méi)有想到會(huì)被牽連的包。舉個(gè)例子如果系統(tǒng)里裝了cockpit-podman而這個(gè)包又依賴 podman那么--allowerasing可能直接把 cockpit 的容器管理模塊一起刪掉。你在 Web 管理界面里可能會(huì)發(fā)現(xiàn)相關(guān)功能不見(jiàn)了排查半天才發(fā)現(xiàn)是安裝 Docker 時(shí)被連帶清理的。所以在生產(chǎn)環(huán)境或多人共用環(huán)境里我不太建議直接--allowerasing。它適合個(gè)人開(kāi)發(fā)機(jī)、無(wú)狀態(tài)臨時(shí)環(huán)境但不適合作為標(biāo)準(zhǔn)操作流程寫(xiě)進(jìn)文檔。3.4 三種方案怎么選一張表說(shuō)清楚方案核心操作優(yōu)點(diǎn)風(fēng)險(xiǎn)推薦場(chǎng)景A 手動(dòng)移除dnf remove podman buildah ...每一步可控邏輯清晰需要自己識(shí)別所有沖突包普通服務(wù)器、個(gè)人開(kāi)發(fā)機(jī)B 禁用模塊移除dnf module disable container-tools再移除防止后續(xù)更新時(shí) podman 回來(lái)最穩(wěn)定多一條模塊命令生產(chǎn)環(huán)境、長(zhǎng)期維護(hù)系統(tǒng)C--allowerasingdnf install ... --allowerasing一條命令搞定速度快可能誤刪依賴組件臨時(shí)環(huán)境、測(cè)試機(jī)我的建議是只要你愿意花一分鐘多敲一條命令就用方案B。它帶來(lái)的“防復(fù)發(fā)”效果是另外兩個(gè)方案替代不了的。4. 裝完只是開(kāi)始驗(yàn)證、啟動(dòng)、命令切換4.1 從清理到安裝的一條龍命令把上面方案整理成一套可以在新環(huán)境上直接復(fù)制的流程推薦組合是方案B加 Docker 官方源安裝# 1. 安裝 yum-utils 工具 dnf install -y yum-utils # 2. 添加 Docker 官方倉(cāng)庫(kù) yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo # 3. 刷新倉(cāng)庫(kù)緩存 dnf makecache # 4. 禁用默認(rèn)容器模塊避免后續(xù) podman 被拉回 dnf module disable -y container-tools # 5. 刪除默認(rèn)容器工具鏈 dnf remove -y podman buildah skopeo runc containernetworking-plugins # 6. 安裝 docker-ce dnf install -y docker-ce docker-ce-cli containerd.io執(zhí)行第 5 步時(shí)如果提示會(huì)刪除一些額外包請(qǐng)逐條看一眼確認(rèn)沒(méi)有關(guān)鍵服務(wù)依賴。第 6 步安裝完成后DNF 會(huì)自動(dòng)處理好 docker-ce 本身的依賴正常情況下不會(huì)再出現(xiàn)開(kāi)頭的 podman 沖突報(bào)錯(cuò)。整體跑下來(lái)的體驗(yàn)是最關(guān)鍵的操作其實(shí)不是安裝 docker-ce而是前面把 podman 那條線收拾干凈。只要模塊禁用和包刪除都做對(duì)了后面基本一路綠燈。4.2 啟動(dòng) Docker 并完成基礎(chǔ)驗(yàn)證安裝完成不代表 Docker 已經(jīng)能用。CentOS 8 里 Docker 服務(wù)默認(rèn)不會(huì)自動(dòng)啟動(dòng)需要手動(dòng)啟用并設(shè)置開(kāi)機(jī)自啟systemctl enable --now docker查看服務(wù)狀態(tài)systemctl status docker --no-pager如果狀態(tài)是active (running)說(shuō)明服務(wù)正常。接下來(lái)最經(jīng)典的驗(yàn)證方式docker version正常會(huì)分別顯示 Client 和 Server 的版本信息。注意如果只看到 Client 部分而 Server 部分報(bào)錯(cuò)說(shuō)明服務(wù)端可能沒(méi)起來(lái)繼續(xù)查systemctl status docker或查看日志journalctl -u docker --no-pager -n 50再進(jìn)一步驗(yàn)證能真的拉取并運(yùn)行鏡像可以跑docker run --rm hello-world如果看到類似 “Hello from Docker!” 的輸出說(shuō)明整個(gè)容器鏈路已經(jīng)打通。這一步建議一定跑一次它能一次性驗(yàn)證 Docker 守護(hù)進(jìn)程、鏡像倉(cāng)庫(kù)連通性、容器運(yùn)行時(shí)是否正常。4.3 一個(gè)容易忽略的坑docker 命令被 podman 兼容層占用在 CentOS 8 里有個(gè)特殊現(xiàn)象系統(tǒng)有時(shí)候可以通過(guò)podman-docker這個(gè)包提供/usr/bin/docker的兼容入口目的是讓習(xí)慣了 Docker 命令的人無(wú)縫切換到 podman。如果你在安裝 docker-ce 前系統(tǒng)里本來(lái)就有這個(gè)兼容層那么即便 docker-ce 安裝成功docker命令的指向也可能仍然落在 podman 的兼容腳本上。安裝完成后可以檢查一下which docker ls -l /usr/bin/docker如果/usr/bin/docker是一個(gè)指向/etc/alternatives/docker的符號(hào)鏈接說(shuō)明系統(tǒng)使用了 alternatives 機(jī)制來(lái)管理 docker 命令指向。這時(shí)可以執(zhí)行update-alternatives --config docker在列出的候選項(xiàng)里選擇對(duì)應(yīng) docker-ce 的那個(gè)。例如可能是/usr/bin/docker-ce或類似路徑。選完后docker version才能真正顯示出 Docker 的版本信息而不是 podman 的模擬輸出版本。如果之前沒(méi)用過(guò) podman-docker也沒(méi)有 alternatives 符號(hào)鏈接那么安裝 docker-ce 后/usr/bin/docker就來(lái)自 docker-ce 包本身無(wú)需處理。但做一次which docker的確認(rèn)不虧幾秒鐘的事。5. 后續(xù)常遇到的問(wèn)題快速排查清單5.1 安裝階段containerd.io 與 runc 的糾纏除了 podman 沖突CentOS 8 上安裝 docker-ce 時(shí)還有一類高頻報(bào)錯(cuò)看起來(lái)和containerd.io、runc相關(guān)。典型的錯(cuò)誤信息是Error: Problem: package containerd.io-1.x.x-x.el8.x86_64 requires runc 1.x, but none of the providers can be installed這類問(wèn)題的本質(zhì)是系統(tǒng)自帶的runc版本和 containerd.io 要求的版本對(duì)不上。處理思路是先把系統(tǒng)里已有的 runc 升級(jí)或移除dnf update runc如果升級(jí)后仍然無(wú)法滿足版本要求那就手動(dòng)刪除帶版本沖突的 runc再重新安裝 containerd.io。當(dāng)然更簡(jiǎn)單的兜底手段是在安裝 containerd.io 時(shí)加上--allowerasing。但和前面說(shuō)的一樣這個(gè)參數(shù)有副作用使用前先確認(rèn)系統(tǒng)里沒(méi)有其他服務(wù)依賴舊版 runc。在我實(shí)際處理中CentOS 8 的標(biāo)準(zhǔn)倉(cāng)庫(kù)里runc版本通常能滿足 Docker 官方 containerd.io 的需求遇到這個(gè)報(bào)錯(cuò)更多是因?yàn)橹盎煊昧似渌谌皆磳?dǎo)致包版本變得混亂。因此第一步永遠(yuǎn)是檢查倉(cāng)庫(kù)狀態(tài)看看有沒(méi)有奇怪的源在起作用。5.2 倉(cāng)庫(kù)緩存與源配置導(dǎo)致的奇怪問(wèn)題有段時(shí)間我在一臺(tái) CentOS 8 機(jī)器上執(zhí)行安裝報(bào)錯(cuò)信息和 podman 完全不相關(guān)只是提示某些依賴找不到。排查到最后發(fā)現(xiàn)是倉(cāng)庫(kù)元數(shù)據(jù)太老系統(tǒng)里實(shí)際上已經(jīng)有新版本包但 DNF 的緩存里沒(méi)有索引。遇到這種“迷之無(wú)法滿足依賴”的情況執(zhí)行dnf clean all dnf makecache然后重新安裝。大多數(shù)情況下刷新倉(cāng)庫(kù)緩存就能解決。另外如果 Docker 官方倉(cāng)庫(kù)所在網(wǎng)絡(luò)不穩(wěn)定DNF 可能因?yàn)橄螺d失敗而報(bào)各種奇怪的錯(cuò)。這時(shí)可以配置該倉(cāng)庫(kù)在不可用時(shí)跳過(guò)yum-config-manager --save --setoptdocker-ce-stable.skip_if_unavailabletrue這個(gè)配置的意思是倉(cāng)庫(kù)暫時(shí)不可用時(shí)不阻塞其他安裝事務(wù)而不是永遠(yuǎn)忽略。用起來(lái)比較靈活。這里特別提醒一句不要輕易用--skip-broken跳過(guò)依賴錯(cuò)誤。它會(huì)把真正的問(wèn)題掩蓋住導(dǎo)致系統(tǒng)里留下殘缺依賴后面再更新其他軟件時(shí)可能爆炸。寧可多花幾分鐘把沖突根源找出來(lái)也不要長(zhǎng)期帶著隱患跑。5.3 容器啟動(dòng)后的網(wǎng)絡(luò)與 SELinux 問(wèn)題docker-ce 安裝并啟動(dòng)成功很多人會(huì)在docker run階段遇到新問(wèn)題。最常見(jiàn)的是端口映射不通、容器訪問(wèn)外網(wǎng)受阻。CentOS 8 默認(rèn)開(kāi)啟了 firewalld。如果容器端口要從外部訪問(wèn)需要顯式放行firewall-cmd --add-port8080/tcp --permanent firewall-cmd --reload如果不想使用防火墻直接停掉 firewalld 也能快速驗(yàn)證但服務(wù)器正式環(huán)境不建議裸奔。另一個(gè)高頻坑是 SELinux。CentOS 8 默認(rèn) SELinux 為 enforcing 狀態(tài)Docker 掛載宿主機(jī)目錄時(shí)可能因?yàn)榘踩呗员痪芙^表現(xiàn)為容器啟動(dòng)后目錄為空或直接報(bào)權(quán)限錯(cuò)誤。快速驗(yàn)證的方法setenforce 0臨時(shí)切到 permissive 模式如果容器立刻正常說(shuō)明就是 SELinux 策略問(wèn)題。但長(zhǎng)期方案不是關(guān)閉 SELinux而是給掛載目錄加上正確的標(biāo)簽或者在 Docker daemon 配置里調(diào)整 SELinux 支持方式。只要記住“一句話驗(yàn)證認(rèn)真配置收尾”的原則就能少花很多時(shí)間。5.4 問(wèn)題速查表癥狀可能原因快速處理安裝提示problem with installed package podman...系統(tǒng)預(yù)裝容器工具與 docker-ce 沖突刪除 podman/buildah禁用 container-tools 模塊提示containerd.io requires runc ...runc 版本過(guò)低或來(lái)源混亂dnf update runc必要時(shí)移除后重裝安裝時(shí)找不到某些依賴包倉(cāng)庫(kù)元數(shù)據(jù)過(guò)舊或源不可用dnf clean all dnf makecache配 skip_if_unavailabledocker命令顯示 podman 版本信息alternatives 鏈接仍指向 podmanupdate-alternatives --config docker切換服務(wù)啟動(dòng)但docker docker run無(wú)法連接Docker 服務(wù)未運(yùn)行或日志報(bào)錯(cuò)檢查systemctl status docker與journalctl容器端口外部無(wú)法訪問(wèn)firewalld 未放行firewall-cmd --add-port.../tcp --permanent掛載目錄權(quán)限異常SELinux 策略阻止臨時(shí)setenforce 0驗(yàn)證再配置標(biāo)簽這張表基本覆蓋了從安裝到運(yùn)行的常見(jiàn)問(wèn)題。把這幾類問(wèn)題提前了解一遍再遇到報(bào)錯(cuò)就不會(huì)手忙腳亂。6. 幾次折騰之后說(shuō)點(diǎn)個(gè)人體會(huì)從第一次看到problem with installed package podman開(kāi)始到最后完全搞清楚整套邏輯我最大的體會(huì)是這種報(bào)錯(cuò)與其說(shuō)是“安裝失敗”不如說(shuō)是系統(tǒng)在強(qiáng)制你重新思考容器運(yùn)行時(shí)選型。CentOS 8 的默認(rèn)方向本來(lái)就是 podmanDocker 是一個(gè)“逆向走回去”的選擇。如果你只是圖 docker-compose 生態(tài)順手那清理并替換沒(méi)有問(wèn)題如果生產(chǎn)環(huán)境已經(jīng)有大量依賴 podman 的自動(dòng)化腳本和系統(tǒng)組件反而應(yīng)該停下來(lái)確認(rèn)一下是否真要換。最后分享一個(gè)小技巧不管用哪套方案處理完安裝成功后先做一次系統(tǒng)級(jí)別的快照或備份。以我這幾年操作經(jīng)驗(yàn)來(lái)看容器運(yùn)行時(shí)替換這件事安裝階段的報(bào)錯(cuò)只是第一關(guān)真正讓人頭疼的往往是安裝成功之后出現(xiàn)的網(wǎng)絡(luò)、SELinux、倉(cāng)庫(kù)混源問(wèn)題。但只要你理解沖突背后的原理后續(xù)遇到類似問(wèn)題基本上都能舉一反三。