Docker 容器與虛擬化技術(shù)這條線上的活我這幾年干得最多的不是“怎么把容器跑起來”而是“怎么讓一群人能安全地看見并管住跑起來的容器”。openEuler 部署 Docker UI 就是典型的后者機器裝好、引擎起來了不代表團隊能用得順手命令行敲得再熟交接給同事、交給值班同學(xué)、交給不常碰服務(wù)器的人效率立刻掉一半。所以這篇我想聊的是完整的落地鏈路——從容器和虛擬化的取舍開始到 openEuler 上的引擎安裝、參數(shù)調(diào)優(yōu)再到 Docker UI 的選型、部署、入口收口和后續(xù)的日常巡檢把我踩過的坑和調(diào)過的參數(shù)都攤開講。先說清楚這東西是什么。Docker UI 是給 Docker 引擎套的一層 Web 管理界面它本身也是一個容器通過掛載宿主機的容器運行時接口來讀取和操作容器、鏡像、網(wǎng)絡(luò)、數(shù)據(jù)卷。它能解決三件事第一把docker ps、docker logs、docker exec這些高頻動作變成點選第二讓多人協(xié)作時有賬號和權(quán)限的概念而不是所有人共用一個 root shell第三把“部署一套服務(wù)”沉淀成模板或編排文件減少口口相傳。適合的讀者范圍其實挺寬剛接手一臺 openEuler 服務(wù)器、想把容器管起來的新手能照著把流程走完已經(jīng)在用 Docker 但界面還停留在命令行的老手可以重點看參數(shù)調(diào)優(yōu)、安全收口和排查那幾節(jié)。1. 動手之前先想清楚為什么是 openEuler 加 Docker UI1.1 容器與虛擬化不是替代關(guān)系是兩把不同型號的刀很多人一上來就問“容器能不能完全取代虛擬機”這個問題本身就問偏了。虛擬化是在硬件之上插一層 Hypervisor給每臺虛擬機切出獨立的內(nèi)核、獨立的設(shè)備視圖隔離邊界在硬件抽象層容器是復(fù)用宿主機內(nèi)核靠 namespace 做視圖隔離、靠 cgroup 做資源限制隔離邊界在操作系統(tǒng)內(nèi)核里。這個差別決定了它們在啟動速度、資源密度、隔離強度上的全部差異也決定了你在 openEuler 上做選型時該怎么擺位置。我給一個自己常用的對照方便你直接對著業(yè)務(wù)場景挑對比維度虛擬機容器隔離層級硬件抽象層獨立內(nèi)核內(nèi)核級共享宿主內(nèi)核啟動耗時十幾秒到一分鐘毫秒到幾秒資源開銷需要預(yù)留固定內(nèi)存與 vCPU按需占用超賣空間大鏡像體積GB 級別幾十 MB 到幾百 MB單機密度十幾到幾十臺幾十到上百個典型用途強隔離、異構(gòu)系統(tǒng)、遺留應(yīng)用微服務(wù)、持續(xù)集成、灰度發(fā)布看這張表你會發(fā)現(xiàn)一個規(guī)律需要“內(nèi)核級隔離”和“跑不同內(nèi)核版本”的場景虛擬機仍然是唯一答案需要“密度”和“交付速度”的場景容器優(yōu)勢壓倒性。我實際的做法是分層——底層用虛擬機切出資源池和故障域池子里跑 openEuler再用 Docker 在池子里切服務(wù)。UI 這一層就落在這個混合結(jié)構(gòu)的上半部分它管的是容器不管虛機所以定位一定要清楚別指望它替你把資源池也管了。提示如果你所在的環(huán)境里已經(jīng)有成熟的虛擬化平臺Docker UI 的定位應(yīng)該是“應(yīng)用側(cè)的可視化入口”不要試圖讓它承擔(dān)基礎(chǔ)設(shè)施層的編排職責(zé)職責(zé)一旦混了權(quán)限模型會變得很難收口。1.2 openEuler 作為宿主發(fā)行版特性帶來的真實影響openEuler 這幾年在服務(wù)器側(cè)的存在感越來越強它默認(rèn)內(nèi)核版本較新cgroup v2 支持完整安全加固策略也相對嚴(yán)格。這些特性對跑容器是好事但也帶來幾個必須在部署前確認(rèn)的點。第一是 cgroup 版本cgroup v1 和 v2 下容器引擎的資源限制行為不完全一樣docker info里能看到 Cgroup Driver 和 Cgroup Version裝完第一件事就該看這個。第二是 SELinux 的默認(rèn)狀態(tài)openEuler 上通常是 enforcing 或 permissive這兩個狀態(tài)對掛載宿主機 socket 文件的影響完全不同后面第三節(jié)我會專門講。第三是軟件源。openEuler 有自己的軟件倉庫體系社區(qū)也維護了一部分容器相關(guān)包但版本更新節(jié)奏和上游不完全同步。我在實際項目里遇到過 EPOL 倉庫里的引擎版本落后于業(yè)務(wù)需要的 API 版本導(dǎo)致某些 compose 特性用不了。這種情況下我一般優(yōu)先選擇“官方靜態(tài)二進制 自建 systemd 單元”的方式繞開發(fā)行版打包差異代價是要自己處理依賴和升級收益是版本完全可控、行為可預(yù)期。還有一個容易被忽略的點openEuler 默認(rèn)可能預(yù)裝了 podman 或 buildah 這類容器工具它們和 Docker 的命令行工具在部分路徑上會打架尤其是/usr/bin/docker這個位置。裝之前先確認(rèn)一下有沒有殘留比裝完再排查省事得多。這個我在第四節(jié)會給出檢查命令。1.3 UI 解決的是“人”的問題別把它當(dāng)技術(shù)方案我想強調(diào)一個觀點Docker UI 不提升任何技術(shù)指標(biāo)。它不會讓你的容器跑得更快不會讓鏡像變小也不會自動幫你做高可用。它解決的是協(xié)作成本——值班同學(xué)半夜要看日志不用再找人要 SSH 權(quán)限新人接手項目能直觀看到有哪些容器、映射了什么端口、掛在哪個卷上交接時不用再寫“這臺機器上跑了什么”的文檔界面本身就是文檔。理解了這一點你在部署時的取舍就會清楚很多。既然是給人用的那么訪問入口、賬號體系、審計記錄就比“功能多不多”更重要既然是內(nèi)部工具就不要把它暴露在公網(wǎng)也不要用默認(rèn)端口和默認(rèn)密碼。我見過太多把管理面板直接映射到 0.0.0.0 上、跑了半年沒人管的例子這類資產(chǎn)一旦被掃到等于把整臺機器的 root 權(quán)限拱手讓人因為 UI 容器掛載了容器運行時接口它天然具備宿主機的等效權(quán)限。這句話不是危言聳聽后面講 socket 掛載時我會展開。2. 部署前的環(huán)境盤點三個必須先確認(rèn)的硬條件2.1 系統(tǒng)版本、內(nèi)核與磁盤的規(guī)劃方法動手前先跑幾條命令把底摸清比裝到一半發(fā)現(xiàn)問題強。系統(tǒng)版本用cat /etc/openEuler-release內(nèi)核用uname -r架構(gòu)用uname -m。openEuler 主流在用的是 22.03 LTS 和 24.03 LTS 兩個系列前者內(nèi)核 5.10后者更新一些兩者都完整支持 Docker 需要的 namespace 和 cgroup 特性不需要額外編譯內(nèi)核模塊。磁盤是重點。Docker 的默認(rèn)數(shù)據(jù)目錄在/var/lib/docker這里會同時存放鏡像層、容器可寫層、數(shù)據(jù)卷和構(gòu)建緩存。我的經(jīng)驗值是只跑幾個輕量服務(wù)給 40GB 起步跑十幾個中等規(guī)模服務(wù)100GB 比較踏實如果涉及數(shù)據(jù)庫容器或者構(gòu)建流水線單獨掛一塊盤給/var/lib/docker是必須的。原因很直接——鏡像層是共享的刪了標(biāo)簽數(shù)據(jù)層未必馬上釋放加上日志默認(rèn)不限制大小一臺跑了三個月的機器被日志撐爆根分區(qū)是極常見的事故。這里給一個可以照著算的公式用來估日志占用上限單容器日志上限等于max-size乘以max-file。假設(shè)你設(shè)置成 50MB 和 3 個文件那么單個容器最多占 150MB機器上跑 50 個容器最壞情況就是 7.5GB。這個數(shù)字必須在磁盤規(guī)劃里預(yù)留出來而不是等它漲到把根分區(qū)吃滿再去清理。我在第六節(jié)會給出對應(yīng)的daemon.json配置。內(nèi)存方面引擎本身加 UI 的常駐開銷并不大Docker 守護進程通常在 100MB 到 200MB 量級Portainer 這類面板容器也差不多在 100MB 上下真正吃內(nèi)存的是業(yè)務(wù)容器。所以規(guī)劃時別把 UI 當(dāng)成負(fù)擔(dān)它幾乎可以忽略不計。不過有一點要注意如果宿主機內(nèi)存比較緊張務(wù)必給容器設(shè)置內(nèi)存上限否則單個容器內(nèi)存泄漏會觸發(fā)宿主機 OOM Killer它挑誰下手是隨機的殺掉引擎進程導(dǎo)致整機容器全掛的情況我遇到過不止一次。2.2 軟件源、依賴與舊組件的清理順序裝 Docker 之前有一輪清理工作順序錯了會很麻煩。第一步查殘留rpm -qa | grep -Ei docker|podman|buildah|containerd|runc把結(jié)果看一眼。如果存在 podman 和 buildah它們和 Docker 共享runc和部分容器運行時組件同時裝可能引發(fā)依賴沖突實踐中最省事的處理是先卸載它們裝完 Docker 需要的話再單獨裝回來。第二步處理倉庫。openEuler 上可以走社區(qū)維護的容器相關(guān)倉庫也可以直接配置上游的軟件源。走上游源時有個坑必須提前說上游倉庫路徑里通常帶$releasever變量而 openEuler 的$releasever值是22.03這種格式拼出來的路徑在上游并不存在dnf makecache會直接報 404。解決辦法是把倉庫文件里的變量寫死成對應(yīng)的主版本號比如按兼容性填8或9或者干脆不用倉庫走靜態(tài)二進制。這個細節(jié)網(wǎng)上很多教程不會提但它確實是新手卡住時間最長的一步。第三步是基礎(chǔ)依賴。靜態(tài)二進制方案需要iptables、iproute、libcgroup、systemd這些openEuler 默認(rèn)基本都齊了只需要確認(rèn)iptables是 nft 還是 legacy 后端。新版 Docker 默認(rèn)走 nft 后端如果系統(tǒng)里只有 legacy 的iptables引擎啟動后創(chuàng)建規(guī)則會失敗表現(xiàn)為容器端口映射不生效但容器本身是運行狀態(tài)。檢查命令是iptables --version如果輸出里沒有nf_tables字樣就需要額外裝iptables-nft包讓兩個后端并存。注意清理和卸載動作一定要在業(yè)務(wù)低峰做并要求有回滾手段。刪除包的同時如果帶走了配置文件重建所需的時間往往比預(yù)想的長。2.3 網(wǎng)絡(luò)、時間與安全基線的三件小事第一件是時間同步。容器里跑的東西一旦涉及證書、令牌、日志時間戳宿主時間漂移就是災(zāi)難。timedatectl status看一眼有沒有同步源chronyc tracking看偏差。我一般要求偏差控制在秒級以內(nèi)因為 TLS 證書校驗對時間很敏感差出幾分鐘就會報證書未生效或已過期而這個報錯在容器里往往被翻譯成“連接失敗”排查方向會被帶偏。第二件是防火墻。openEuler 默認(rèn)可能啟用 firewalld這里有一個非常經(jīng)典的坑Docker 啟動時會自己往 iptables 的nat表和filter表里寫規(guī)則而這些規(guī)則位于 firewalld 管理鏈的下游導(dǎo)致你通過 firewalld 關(guān)掉的端口只要被容器映射了仍然能從外部訪問。也就是說firewall-cmd --remove-port對容器端口是無效的。正確的做法有兩種要么把容器端口綁定到127.0.0.1上只讓本機的 Nginx 轉(zhuǎn)發(fā)要么把限制規(guī)則寫進DOCKER-USER鏈這個鏈?zhǔn)?Docker 專門留給用戶自定義規(guī)則的入口位置在容器規(guī)則之前優(yōu)先級正確。第三件是主機名和 DNS。給機器起一個能看懂的名字比如docker-ui-01后續(xù)在界面里看到節(jié)點名字時不會一臉懵。DNS 方面建議確認(rèn)/etc/resolv.conf里沒有指向127.0.0.53這類只有本機 systemd-resolved 才認(rèn)的地址因為容器默認(rèn)繼承宿主 DNS 配置而127.0.0.53在容器網(wǎng)絡(luò)命名空間里是不可達的結(jié)果就是容器能啟動、能 ping 通 IP但域名解析全部失敗。這個問題在第六節(jié)還會詳細講。3. 引擎安裝的完整實操兩條路線與參數(shù)調(diào)優(yōu)3.1 路線選擇倉庫安裝還是靜態(tài)二進制我把兩條路線的差異攤開方便你按場景選。倉庫安裝的優(yōu)點是省事dnf install一條命令依賴自動處理升級也走dnf upgrade缺點是版本受限于倉庫遇到上游打包滯后時沒轍。靜態(tài)二進制的優(yōu)點是版本完全由你決定解壓即用遷移方便缺點是需要自己寫 systemd 單元升級要手動替換二進制并重啟而且出問題時沒有包管理器的完整性校驗兜底。我的選擇邏輯是如果是個人實驗或者小規(guī)模環(huán)境倉庫安裝足夠如果是團隊共用、需要長期維護、對版本有明確要求走靜態(tài)二進制更省心。下面兩條路線我都會給出關(guān)鍵步驟倉庫那條我會寫清變量替換的坑靜態(tài)那條我會寫全單元文件。3.2 路線一配置軟件源后安裝倉庫配置文件放在/etc/yum.repos.d/下名字隨意后綴必須是.repo。內(nèi)容的關(guān)鍵是baseurl里的版本號不能留變量gpgcheck保持開啟gpgkey指向?qū)?yīng)的密鑰地址。寫完執(zhí)行dnf clean all dnf makecache能正常拉到元數(shù)據(jù)說明配置對了。安裝時我習(xí)慣顯式帶上--allowerasing原因是如果系統(tǒng)里還有舊的運行時組件不加這個參數(shù)會因為文件沖突直接失敗報錯信息里一堆file /usr/bin/xxx conflicts新手看了容易懵。帶上之后 dnf 會自動把沖突的包換掉代價是你得確認(rèn)被換掉的包不是業(yè)務(wù)依賴。裝完之后立刻驗證docker version看客戶端和服務(wù)端是否都返回只出來客戶端說明服務(wù)端沒起docker info看Server Version、Storage Driver、Cgroup Version、Kernel Version四項這四項是后續(xù)所有問題的判斷依據(jù)。還需要處理用戶組。把日常運維賬號加進docker組避免每條命令都sudousermod -aG docker your_user newgrp docker這里必須說一句實話加入docker組等價于拿到 root 權(quán)限因為你可以直接docker run -v /:/host把宿主機根目錄掛進容器再改文件。這不是設(shè)計缺陷是機制使然。所以我的做法是只給確實需要的人開同時把 UI 的權(quán)限體系用起來讓大部分人通過 UI 操作而不是直接上 SSH。3.3 路線二靜態(tài)二進制安裝與 systemd 單元下載對應(yīng)架構(gòu)的壓縮包解壓后把docker/目錄下的可執(zhí)行文件復(fù)制到/usr/bin/然后在/etc/systemd/system/docker.service寫單元文件。核心配置如下[Unit] DescriptionDocker Application Container Engine Afternetwork-online.target firewalld.service Wantsnetwork-online.target [Service] Typenotify ExecStart/usr/bin/dockerd ExecReload/bin/kill -s HUP $MAINPID TimeoutStartSec0 Restartalways RestartSec2 LimitNOFILEinfinity LimitNPROCinfinity Delegateyes KillModeprocess OOMScoreAdjust-500 [Install] WantedBymulti-user.target幾個參數(shù)值得解釋。Typenotify讓 systemd 等引擎真正就緒后才認(rèn)為啟動完成避免服務(wù)狀態(tài)顯示 running 但實際還在初始化。LimitNOFILEinfinity是因為容器密集場景下文件句柄消耗很大默認(rèn)的 1024 遠遠不夠容器數(shù)一多就會出現(xiàn)too many open files。OOMScoreAdjust-500降低引擎被內(nèi)核優(yōu)先殺掉的概率這個在內(nèi)存緊張時能救命。Restartalways配合RestartSec2提供基礎(chǔ)的自動拉起能力但注意它不是萬能的如果引擎是因為配置錯誤反復(fù)崩潰你會看到不斷重啟的循環(huán)要結(jié)合journalctl -u docker -n 100看具體原因。寫完之后systemctl daemon-reload systemctl enable --now docker再跑一次docker info驗證。靜態(tài)二進制方案下 containerd 會由 dockerd 自己拉起不需要額外啟用 containerd 服務(wù)這一點和包管理器方案不同別多此一舉去啟兩個 containerd 搶同一個 socket 目錄會直接報錯。3.4 daemon.json五個真正影響長期運行的參數(shù)配置文件放在/etc/docker/daemon.json改完必須重啟引擎systemctl reload docker只對部分參數(shù)生效圖省事用 reload 結(jié)果參數(shù)沒生效、排查半天的情況我見過。下面這份是我在多數(shù)環(huán)境里會用的基線{ data-root: /data/docker, log-driver: json-file, log-opts: { max-size: 50m, max-file: 3 }, live-restore: true, default-address-pools: [ { base: 172.30.0.0/16, size: 24 } ], exec-opts: [native.cgroupdriversystemd] }>docker volume create portainer_data docker run -d \ --name portainer \ --restartalways \ -p 127.0.0.1:9443:9443 \ -p 127.0.0.1:8000:8000 \ -v /var/run/docker.sock:/var/run/docker.sock \ -v portainer_data:/data \ portainer/portainer-ce:lts-p前面的127.0.0.1是我強烈建議加的。不加的話端口監(jiān)聽在0.0.0.0等于把管理面板直接暴露出去后面再加 Nginx 也擋不住——別人可以直接打容器端口。加上綁定之后外部只能通過本機的轉(zhuǎn)發(fā)層訪問攻擊面立刻收窄了一大截。8000端口是邊緣計算代理用的單機環(huán)境其實用不上我保留它是因為某些版本的界面會用到這個端口做節(jié)點注冊去掉也能跑屬于可選項。9443是默認(rèn)的 HTTPS 端口新版 UI 默認(rèn)只走 HTTPS早期版本還提供過一個 HTTP 端口現(xiàn)在需要顯式打開才有我傾向于不開 HTTP直接走 HTTPS 更省心。-v /var/run/docker.sock:/var/run/docker.sock這一行是整個部署里最需要理解的。它把宿主機上的容器運行時接口以 Unix socket 文件的形式掛進容器UI 通過這個文件發(fā) HTTP 請求來操作引擎。這意味著容器里的進程實際擁有和宿主機 root 同等的容器管理權(quán)限。所以這個掛載不能給任意鏡像用只能給自己審查過的 UI 鏡像用而且一旦 UI 本身被攻破宿主機也就失守了。如果你對這點比較介意有一個中間方案在前面加一層 socket 白名單網(wǎng)關(guān)只放行讀操作和有限的寫操作UI 連網(wǎng)關(guān)不連原始 socket。這個方案會增加一個容器和一份配置但能把“UI 被攻破等于宿主機失守”降級成“只能做允許的動作”。規(guī)模不大時可以先不做但要清楚這個風(fēng)險存在。portainer/portainer-ce:lts這個標(biāo)簽我建議在生產(chǎn)上換成具體版本號比如明確寫死到某個小版本。浮動標(biāo)簽在升級時可能帶來非預(yù)期變更管理面組件尤其不該這樣因為界面結(jié)構(gòu)變化會影響值班同學(xué)的操作習(xí)慣。4.3 首次初始化與安全收口容器起來之后先看日志確認(rèn)沒有報錯docker logs portainer里如果出現(xiàn)權(quán)限相關(guān)的錯誤基本都是 socket 掛載或 SELinux 的問題第六節(jié)有排查表。然后瀏覽器訪問https://服務(wù)器IP:9443此時是自簽證書瀏覽器會告警點繼續(xù)即可反正后面會用 Nginx 接管。第一件事是設(shè)置管理員密碼第二件事是選環(huán)境類型單機選 Docker 就行。初始化完成后有幾個收口動作建議立刻做把默認(rèn)的admin用戶名改掉開啟雙因素認(rèn)證如果環(huán)境支持給團隊成員建普通賬號而不是共用管理員把“允許外部加載應(yīng)用模板”這類用不到的功能關(guān)掉。管理面的原則是能關(guān)就關(guān)留下的每一個入口都會成為后續(xù)審計的負(fù)擔(dān)。還有一個細節(jié)初始化有個時間窗口如果容器起來后超過幾分鐘沒人訪問某些版本會要求重啟容器才能繼續(xù)初始化。這不是故障是安全設(shè)計。我遇到過同事以為部署失敗反復(fù)重建容器其實是沒在窗口內(nèi)完成初始化白折騰。4.4 用編排文件管理 UI 自身UI 自己也是容器用編排文件管它升級和遷移會舒服很多services: portainer: image: portainer/portainer-ce:2.20.3 container_name: portainer restart: always ports: - 127.0.0.1:9443:9443 volumes: - /var/run/docker.sock:/var/run/docker.sock - portainer_data:/data volumes: portainer_data: external: true注意數(shù)據(jù)卷聲明成external因為你已經(jīng)用命令建過了編排文件如果自己再建一個同名卷會沖突。把文件放在/opt/stacks/portainer/這類固定路徑下和業(yè)務(wù)編排文件分開避免哪天誤刪業(yè)務(wù)目錄把管理面一起帶走。升級時改鏡像版本號docker compose up -d就完成替換回滾就把版本號改回去比記命令靠譜。5. 訪問入口收口Nginx 前置與證書配置5.1 為什么建議再套一層UI 自帶的 HTTPS 用的是容器內(nèi)置的自簽證書每次重建容器證書都可能變?yōu)g覽器告警會反復(fù)出現(xiàn)值班同學(xué)點“繼續(xù)訪問”點多了就麻木了這恰恰是安全習(xí)慣被磨掉的過程。套一層 Nginx 的好處有三個證書統(tǒng)一管理換證書不用動容器可以加訪問控制比如只允許內(nèi)網(wǎng)段訪問、加基礎(chǔ)認(rèn)證做二次校驗可以做統(tǒng)一入口多個管理面板掛在不同路徑下對外只暴露一個域名和端口。這一層的定位就是轉(zhuǎn)發(fā)不做緩存不做改寫配置越簡單越好因為它是所有管理流量的必經(jīng)之路多一條規(guī)則就多一個故障點。5.2 配置示例與證書生成先出證書內(nèi)網(wǎng)用自簽就夠了關(guān)鍵是把它固定下來mkdir -p /etc/nginx/certs openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \ -keyout /etc/nginx/certs/docker.key \ -out /etc/nginx/certs/docker.crt \ -subj /CNdocker-ui.internal有效期給到 3650 天內(nèi)網(wǎng)自簽沒必要頻繁換但要在日歷上記一筆到期提醒我吃過證書過期導(dǎo)致整個面板打不開、排查半天以為是服務(wù)掛了的虧。如果內(nèi)網(wǎng)有統(tǒng)一的證書簽發(fā)設(shè)施優(yōu)先用統(tǒng)一簽發(fā)省掉信任導(dǎo)入的麻煩。Nginx 配置的關(guān)鍵點在于后端是 HTTPS需要關(guān)掉后端證書校驗同時要把長連接的升級頭帶上否則界面里某些實時刷新的功能會失效server { listen 443 ssl; server_name docker-ui.internal; ssl_certificate /etc/nginx/certs/docker.crt; ssl_certificate_key /etc/nginx/certs/docker.key; client_max_body_size 0; location / { proxy_pass https://127.0.0.1:9443; proxy_ssl_verify off; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 3600s; } }client_max_body_size 0是必須的因為通過界面上傳鏡像或?qū)刖幣盼募r請求體可能很大默認(rèn)的 1MB 限制會直接返回 413而界面上只會顯示一個含糊的失敗提示。proxy_read_timeout拉長到一小時是因為查看日志流這類長連接會被默認(rèn) 60 秒掐斷表現(xiàn)為日志看一會兒就不動了容易誤判成服務(wù)卡死。proxy_ssl_verify off只在這個內(nèi)網(wǎng)回環(huán)場景下可以接受因為后端就在本機不存在被中間人截獲的路徑。配完nginx -t驗證語法再systemctl reload nginx。驗證方式是訪問域名看證書是不是 Nginx 那張同時確認(rèn)界面能正常加載、日志能持續(xù)刷新。6. 踩過的坑排查思路與速查表6.1 鏡像拉不下來先分層排除再動手這個問題我被問得最多排查順序錯了會浪費大量時間。正確的順序是從外到內(nèi)先在宿主機上curl -I目標(biāo)倉庫地址確認(rèn)網(wǎng)絡(luò)可達和證書鏈正常再docker pull一個極小的公共鏡像做對照排除是單個鏡像的問題還是全局問題再看journalctl -u docker -n 200里的具體錯誤碼。常見的三種錯誤對應(yīng)三種原因。報 TLS 握手超時多半是宿主時間偏差或者中間有設(shè)備做了證書攔截報no such host或者解析超時是 DNS 問題容器內(nèi)繼承的resolv.conf指向了本機回環(huán)地址的解析服務(wù)在容器命名空間里根本連不上解決辦法是在daemon.json里顯式指定dns字段或者把宿主機的解析配置改成容器可訪問的地址報i/o timeout但curl正常很可能是 MTU 不匹配鏈路上存在隧道或者 overlay 封裝時默認(rèn) 1500 的 MTU 會讓大包被丟棄小包正常大包卡住表現(xiàn)就是拉取進度條走到一半停住。MTU 的處理方法是在daemon.json里加mtu: 1450然后重啟引擎并重建網(wǎng)絡(luò)。這個值不是固定的1400 到 1450 之間試判斷標(biāo)準(zhǔn)是ping -M do -s 1472這類不分片探測能不能通。我給的這個排查法雖然土但比翻日志快。6.2 端口不通與權(quán)限拒絕兩類完全不同的原因容器跑了但端口訪問不了第一步看docker port 容器名確認(rèn)映射關(guān)系第二步在宿主機curl 127.0.0.1:端口繞開防火墻測試第三步從另一臺機器測。這三步能把問題定位到“映射錯”“本機防火墻”“鏈路防火墻”三個層面之一。如果本機通、外部不通八成是前面說的 firewalld 與 Docker 規(guī)則順序問題。驗證方法很直接iptables -t nat -L -n看有沒有對應(yīng)的 DNAT 規(guī)則有規(guī)則但外部不通就去DOCKER-USER鏈里找有沒有被攔截。解決辦法是把放行規(guī)則插到DOCKER-USER鏈?zhǔn)譱ptables -I DOCKER-USER -s 內(nèi)網(wǎng)段 -j ACCEPT再補一條默認(rèn)拒絕。注意這些規(guī)則重啟會丟要寫進開機腳本或者用iptables-save持久化。另一類問題是 SELinux 拒絕。表現(xiàn)是容器啟動失敗日志里有permission deniedausearch -m avc -ts recent能看到具體的拒絕記錄。UI 掛載 socket 時最容易碰到處理辦法有兩種給掛載加:z標(biāo)簽讓 SELinux 重打上下文或者針對容器相關(guān)布爾值做定向放行。我不建議直接把 SELinux 設(shè)成 disabled那等于放棄了最后一道防線而且改回來很麻煩。定向放行雖然要多花十分鐘但長期看是值得的。6.3 磁盤告急與數(shù)據(jù)目錄遷移根分區(qū)被吃滿的現(xiàn)場通常是這樣的df -h顯示 100%du -sh /var/lib/docker/*一看overlay2占了絕大部分再進去看是某個容器的日志文件幾個 G。這時候別急著刪目錄先按前面說的給daemon.json加日志上限并重啟引擎新日志會按新策略滾動老的大文件再單獨清理。直接rm正在被進程打開的文件空間不會立刻釋放因為文件句柄還在lsof | grep deleted能看到這類懸空文件。數(shù)據(jù)目錄遷移要按順序來停業(yè)務(wù)容器、停引擎、用rsync -aHAX同步、確認(rèn)新目錄權(quán)限、改daemon.json、啟引擎、驗證docker info里的 Root Dir 已指向新路徑、再啟業(yè)務(wù)容器。中間任何一步跳過都可能出現(xiàn)“容器還在但數(shù)據(jù)沒了”的情況。我一般會在遷移前把docker ps -a和docker volume ls的輸出存一份遷移后逐項核對雖然土但有效。6.4 UI 打不開或報 500 的速查路徑這類問題的排查我整理成了一張表按命中率排序現(xiàn)象最可能原因驗證方式處理頁面 500日志報連接 socket 失敗socket 掛載路徑錯或權(quán)限不足ls -l /var/run/docker.sock確認(rèn)掛載路徑檢查 SELinux 上下文頁面能開但容器列表為空UI 連的是別的引擎或環(huán)境配錯看 UI 里的環(huán)境配置重新指向本機 socket上傳編排文件報 413轉(zhuǎn)發(fā)層請求體限制看 Nginx 錯誤日志調(diào)整client_max_body_size日志界面幾秒后停止刷新轉(zhuǎn)發(fā)層讀超時觀察停止的固定間隔調(diào)大proxy_read_timeout界面操作全部超時引擎無響應(yīng)或磁盤滿docker info是否卡住先救引擎再查 UI證書告警反復(fù)出現(xiàn)用了容器內(nèi)置自簽證書看證書簽發(fā)者用 Nginx 統(tǒng)一證書6.5 三條來自現(xiàn)場的經(jīng)驗第一條出問題先看引擎再看 UI。UI 只是殼它所有的能力都來自引擎接口引擎不健康的時候 UI 的表現(xiàn)五花八門容易把人引向錯誤方向。養(yǎng)成先跑docker info的習(xí)慣能省掉一半排查時間。第二條任何變更前先留證據(jù)。docker ps -a、docker images、docker volume ls、daemon.json備份四樣?xùn)|西存一份出問題時對照著看比憑記憶靠譜得多。第三條別在生產(chǎn)上試新版本 UI。管理面的界面變更會影響操作習(xí)慣而操作習(xí)慣在應(yīng)急時就是肌肉記憶。要升級先在測試環(huán)境用一周確認(rèn)常用路徑?jīng)]變再推。7. 長期可用備份、升級與日常巡檢7.1 備份策略備份的是配置不是數(shù)據(jù)管理面的備份重點在于數(shù)據(jù)卷和編排文件不在鏡像。數(shù)據(jù)卷里存的是用戶、環(huán)境、模板、設(shè)置這些信息丟了就得重建一套重新配權(quán)限很煩。備份方式很直接停容器用臨時容器把卷打包成 tar 落到宿主機再傳到備份目錄最后啟容器。整個過程對業(yè)務(wù)容器沒有影響因為停的只是管理面。編排文件和證書目錄要一起備份因為它們和卷里的配置是配套的。我習(xí)慣把這三樣?xùn)|西卷歸檔、編排文件、證書放在同一個帶日期的目錄下恢復(fù)時整體解壓不會漏。備份頻率看團隊規(guī)模賬號體系變化不頻繁的話一周一次加上變更前手動一次就夠。7.2 升級與回滾的具體動作升級前先看新版本的變更說明里有沒有涉及認(rèn)證方式、數(shù)據(jù)結(jié)構(gòu)的調(diào)整有的話必須先備份再動。動作順序是改編排文件里的鏡像版本、docker compose pull、docker compose up -d、看日志確認(rèn)遷移完成、登錄驗證核心功能。如果驗證不通過把版本號改回舊值再up -d因為數(shù)據(jù)卷通常做了向后兼容遷移回滾到舊版本多數(shù)情況下能正常讀取但有極小概率舊版本讀不了新結(jié)構(gòu)所以備份是回滾的前提。引擎本身的升級我建議和 UI 升級錯開至少一周。兩個組件同時變更出問題時無法判斷是誰引起的排查成本翻倍。7.3 巡檢清單每周花十分鐘我給自己定的巡檢項很樸素docker system df看鏡像和卷的占用趨勢漲得太快說明有東西在堆積df -h看磁盤水位超過 80% 就提前處理docker ps --filter healthunhealthy看有沒有不健康的容器journalctl -u docker --since 7 days ago | grep -i error看引擎有沒有反復(fù)報錯最后登錄 UI 掃一眼確認(rèn)賬號沒有多余的、模板沒有被亂改。這套動作十分鐘能做完但能擋住絕大多數(shù)“突然全線崩”的場景因為所有大故障在發(fā)生前都會有小征兆只是沒人看。我在實際使用中最大的體會是容器這套東西的上手門檻很低但長期可用性完全取決于這些瑣碎的日常動作裝的時候花的心思只是開頭后面每周十分鐘才是真正決定它能不能撐住的部分。最后分享一個小技巧給 UI 加一個只讀賬號專門給不常操作但需要看狀態(tài)的同事用然后把這個賬號的登錄方式寫進值班手冊第一頁。既省了開權(quán)限的溝通成本也把誤操作的可能性壓到了最低。