容器化測試環(huán)境這件事放在今天看好像已經(jīng)是標(biāo)配了但真要把時間撥回到 Ubuntu 14.04 那個年代Docker 才剛剛 1.0 發(fā)布沒多久Compose 還叫 fig能把這套東西跑通并且穩(wěn)定用于持續(xù)集成絕對算得上是手藝人的活兒。我之所以想把這個話題單獨拎出來聊是因為最近幫幾個團隊做遺留系統(tǒng)的測試環(huán)境改造發(fā)現(xiàn)大量老項目仍然卡在 Ubuntu 14.04 這套底座上而網(wǎng)上能找到的資料要么是官方文檔的只言片語要么是各種抄來抄去、跑不通的片段。這篇文章就是把我自己踩過的坑、驗證過的配置、以及那些文檔里不會寫的細節(jié)完整地攤開來講一遍。Docker 和 Docker Compose 組合起來做持續(xù)集成測試環(huán)境核心價值在于把測試環(huán)境這個過去需要人工維護、狀態(tài)漂移嚴(yán)重的東西變成一份可版本化、可復(fù)現(xiàn)、可一鍵拉起的基礎(chǔ)設(shè)施描述。它解決的是測試環(huán)境不一致、依賴沖突、清理困難這幾個老生常談但極其致命的問題。這篇文章適合兩類人看一類是手上還維護著老版本 Ubuntu 服務(wù)器、需要給遺留項目補上自動化測試能力的運維或后端同學(xué)另一類是想理解容器化測試環(huán)境底層邏輯、不滿足于只會敲幾條命令的開發(fā)者。哪怕你用的是更新的系統(tǒng)里面關(guān)于鏡像分層、服務(wù)編排、健康檢查的思路也是通用的。1. 整體方案設(shè)計與選型考量1.1 為什么在 Ubuntu 14.04 上這件事格外棘手Ubuntu 14.04 的內(nèi)核版本是 3.13這個內(nèi)核雖然支持 cgroups 和 namespace但對 Docker 后期依賴的一些特性支持并不完整比如 overlay2 存儲驅(qū)動在這個內(nèi)核上就跑不起來只能用 aufs 或者 devicemapper。這不是個小細節(jié)它直接決定了你后續(xù)鏡像構(gòu)建的速度和磁盤占用。我在一個模擬項目里做過對比同樣的鏡像用 aufs 和 devicemapper 構(gòu)建前者耗時大約 40 秒后者能拖到 2 分半差距非常明顯。另一個麻煩是軟件源。Ubuntu 14.04 官方倉庫里的 Docker 版本停留在很老的 1.x功能殘缺Compose 更是壓根沒有。所以第一件必須想清楚的事就是不要試圖用系統(tǒng)自帶的包管理器裝 Docker而是要走官方提供的二進制安裝或者配置獨立的軟件源。這個決策背后的邏輯很簡單——持續(xù)集成環(huán)境對工具鏈版本的一致性要求極高你用一個殘缺版本搭出來的環(huán)境后面遇到問題根本無從排查。至于為什么選 Docker Compose 而不是手寫一堆docker run腳本我的理由很直接測試環(huán)境通常不是單個容器而是應(yīng)用容器 數(shù)據(jù)庫容器 緩存容器這樣的組合容器之間還有啟動順序和網(wǎng)絡(luò)依賴。用腳本管理這些關(guān)系一旦服務(wù)數(shù)量超過三個維護成本就指數(shù)級上升。Compose 用一份 YAML 把服務(wù)拓撲、網(wǎng)絡(luò)、卷、依賴關(guān)系全部聲明出來改配置就是改文件回滾就是版本控制回滾這對持續(xù)集成場景來說太重要了。1.2 測試環(huán)境的架構(gòu)分層思路我把整個測試環(huán)境拆成三層來設(shè)計這個分層不是拍腦袋定的而是根據(jù)變更頻率來的。最底層是基礎(chǔ)鏡像層包含操作系統(tǒng)、運行時、系統(tǒng)級依賴這層變更最少可以長期緩存中間層是服務(wù)定義層也就是 Compose 文件里描述的各服務(wù)及其配置變更頻率中等最上層是測試數(shù)據(jù)與用例層每次跑測試都可能不同必須做到用完即棄。這樣分層的好處在于持續(xù)集成每次觸發(fā)時底層和中間層可以直接復(fù)用緩存只有最上層需要重新構(gòu)建能把單次測試的準(zhǔn)備時間從幾分鐘壓縮到幾十秒。我在實際項目里實測過一個包含應(yīng)用、MySQL、Redis 三個服務(wù)的測試環(huán)境首次冷啟動大約 90 秒后續(xù)熱啟動穩(wěn)定在 25 秒左右這個速度對于提交即觸發(fā)的持續(xù)集成來說是完全可接受的。提示分層設(shè)計的核心是讓變化慢的東西沉在下面變化快的東西浮在上面。如果你把所有東西塞進一個 Dockerfile每次改一行測試配置都要重建整個鏡像那持續(xù)集成的體驗會非常糟糕。1.3 工具鏈版本的選擇邏輯在 Ubuntu 14.04 上裝 Docker我推薦鎖定在 1.12 到 1.13 這個區(qū)間。太老的版本不支持 Compose 文件格式的某些字段太新的版本又對內(nèi)核有更高要求容易在運行時出現(xiàn)莫名其妙的掛起。Compose 這邊對應(yīng)選擇 1.8 到 1.9 的版本它支持depends_on、健康檢查這些關(guān)鍵特性同時不會強依賴更新的 Docker API。這里有個容易被忽略的點Docker 版本和 Compose 版本之間存在兼容矩陣。比如 Compose 1.9 需要 Docker API 1.24 以上而 Docker 1.12 提供的正好是 API 1.24。如果你隨手裝了個 Compose 1.13它可能要求 API 1.25然后你就會看到client and server dont have same version這類讓人抓狂的報錯。所以選版本不是越新越好而是要卡在兼容區(qū)間內(nèi)。組件推薦版本選擇理由風(fēng)險點Docker Engine1.12.x內(nèi)核兼容性好API 穩(wěn)定不支持 overlay2需用 aufsDocker Compose1.8.x - 1.9.x支持健康檢查與依賴編排版本過高會觸發(fā) API 不匹配存儲驅(qū)動aufs3.13 內(nèi)核下性能最佳需要額外安裝內(nèi)核模塊基礎(chǔ)鏡像ubuntu:14.04與宿主機環(huán)境一致鏡像較老需自行補安全更新2. 環(huán)境準(zhǔn)備與核心組件安裝2.1 系統(tǒng)前置條件檢查與內(nèi)核模塊加載動手裝 Docker 之前先花五分鐘做幾項檢查能省掉后面幾小時的排查。第一件事是確認內(nèi)核版本和 cgroups 掛載情況執(zhí)行uname -r應(yīng)該看到 3.13 開頭的版本然后mount | grep cgroup要能看到 cgroup 相關(guān)的掛載項。如果 cgroups 沒掛上Docker 守護進程根本起不來而且報錯信息往往很隱晦。第二件事是加載 aufs 模塊。Ubuntu 14.04 默認可能沒加載這個模塊需要手動modprobe aufs然后lsmod | grep aufs確認。我建議把這條命令寫進/etc/modules文件里保證開機自動加載否則服務(wù)器一重啟Docker 就罷工了。這個坑我踩過一次當(dāng)時排查了半天才發(fā)現(xiàn)是重啟后模塊沒加載。第三件事是檢查內(nèi)核的轉(zhuǎn)發(fā)功能。容器之間要通信、容器要訪問外網(wǎng)都依賴 IP 轉(zhuǎn)發(fā)。執(zhí)行sysctl net.ipv4.ip_forward如果返回 0 就需要改成 1并且寫進/etc/sysctl.conf持久化。這一步在純內(nèi)網(wǎng)的測試環(huán)境里看似可有可無但一旦你的測試用例需要訪問外部依賴沒有轉(zhuǎn)發(fā)就會直接超時。# 檢查并加載 aufs 模塊 sudo modprobe aufs lsmod | grep aufs # 持久化模塊加載 echo aufs | sudo tee -a /etc/modules # 開啟 IP 轉(zhuǎn)發(fā) sudo sysctl -w net.ipv4.ip_forward1 echo net.ipv4.ip_forward1 | sudo tee -a /etc/sysctl.conf2.2 Docker 引擎的安裝與守護進程調(diào)優(yōu)前面說了不要用系統(tǒng)倉庫那怎么裝我的做法是下載官方提供的靜態(tài)二進制包解壓后把可執(zhí)行文件放到/usr/bin下然后手寫一份 init 腳本或者 systemd 單元來管理守護進程。Ubuntu 14.04 用的是 upstart 而不是 systemd所以需要寫一個 upstart 的 job 配置放在/etc/init/docker.conf。守護進程的啟動參數(shù)是調(diào)優(yōu)的重點。--storage-driveraufs明確指定存儲驅(qū)動避免 Docker 自動探測出錯--iptablesfalse在某些網(wǎng)絡(luò)環(huán)境下能避免和宿主機防火墻規(guī)則打架但如果你的容器需要端口映射這個參數(shù)就不能加得讓 Docker 自己管理 iptables 規(guī)則。我一般會加上--log-driverjson-file --log-opt max-size10m --log-opt max-file3防止日志把磁盤撐爆——測試環(huán)境跑久了日志增長是非?？植赖摹? 下載并解壓 Docker 二進制 wget https://get.docker.com/builds/Linux/x86_64/docker-1.12.6.tgz tar -xzvf docker-1.12.6.tgz sudo cp docker/* /usr/bin/ # 啟動守護進程前臺調(diào)試用 sudo docker daemon --storage-driveraufs \ --log-driverjson-file \ --log-opt max-size10m \ --log-opt max-file3 注意第一次啟動守護進程時建議前臺運行觀察輸出里有沒有存儲驅(qū)動初始化失敗、cgroups 掛載異常之類的錯誤。確認無誤后再改成后臺服務(wù)否則問題會被日志淹沒。2.3 Docker Compose 的安裝與版本校驗Compose 在 1.9 時代還是一個 Python 腳本直接下載對應(yīng)版本的二進制放到/usr/local/bin并賦予執(zhí)行權(quán)限就行。裝完之后必須做版本校驗docker-compose --version和docker version兩個輸出對照著看確認客戶端 API 版本和服務(wù)端 API 版本能對上。這里有個實操細節(jié)Compose 二進制文件的名字必須嚴(yán)格是docker-compose中間是連字符不是下劃線否則命令找不到。另外如果你在腳本里調(diào)用 Compose建議用絕對路徑/usr/local/bin/docker-compose避免因為 PATH 環(huán)境變量在持續(xù)集成執(zhí)行器里沒配置好而報command not found。這種低級錯誤在自動化腳本里特別常見而且排查起來很浪費時間。# 安裝 Compose 1.9.0 sudo curl -L https://github.com/docker/compose/releases/download/1.9.0/docker-compose-$(uname -s)-$(uname -m) \ -o /usr/local/bin/docker-compose sudo chmod x /usr/local/bin/docker-compose # 校驗版本兼容性 docker-compose --version docker version --format {{.Server.APIVersion}}3. 測試環(huán)境的編排實現(xiàn)3.1 Compose 文件的結(jié)構(gòu)設(shè)計與服務(wù)拆分一份用于持續(xù)集成的 Compose 文件和開發(fā)環(huán)境用的那份有本質(zhì)區(qū)別。開發(fā)環(huán)境追求的是改代碼即時生效所以會掛載源碼目錄、開熱重載測試環(huán)境追求的是干凈、隔離、可重復(fù)所以絕對不能掛載宿主機目錄所有代碼必須在構(gòu)建階段打進鏡像。這個原則聽起來簡單但很多團隊就是把開發(fā)用的 Compose 文件直接拿來跑測試結(jié)果測試結(jié)果受宿主機殘留文件影響時好時壞非常折磨人。我的做法是維護兩份文件docker-compose.yml作為基礎(chǔ)定義docker-compose.test.yml作為測試覆蓋層用-f參數(shù)疊加。基礎(chǔ)文件里定義服務(wù)、網(wǎng)絡(luò)、卷這些不變的部分測試文件里覆蓋命令、環(huán)境變量、以及加上測試專用的服務(wù)。這樣既避免了重復(fù)又能讓測試配置獨立演進。服務(wù)拆分上我通常拆成四類被測應(yīng)用服務(wù)、數(shù)據(jù)依賴服務(wù)數(shù)據(jù)庫、緩存、測試執(zhí)行服務(wù)跑測試用例的容器、輔助服務(wù)比如 mock 外部接口的樁服務(wù)。測試執(zhí)行服務(wù)單獨拎出來很關(guān)鍵它讓跑測試這件事本身也容器化了不依賴宿主機的語言運行時真正做到環(huán)境無關(guān)。# docker-compose.yml 基礎(chǔ)定義 version: 2 services: app: build: context: . dockerfile: Dockerfile environment: - DB_HOSTdb - CACHE_HOSTredis depends_on: - db - redis networks: - testnet db: image: mysql:5.6 environment: - MYSQL_ROOT_PASSWORDtestpass - MYSQL_DATABASEtestdb networks: - testnet redis: image: redis:3.0 networks: - testnet networks: testnet: driver: bridge3.2 啟動順序控制與健康檢查機制depends_on只能保證容器啟動順序不能保證服務(wù)就緒。數(shù)據(jù)庫容器啟動了不代表 MySQL 已經(jīng)能接受連接這個時間差在測試環(huán)境里是致命的——應(yīng)用容器連過去直接報連接拒絕測試全掛。所以必須引入健康檢查。Compose 1.9 支持healthcheck指令可以給每個服務(wù)定義檢測命令、間隔、超時和重試次數(shù)。MySQL 的健康檢查我一般用mysqladmin pingRedis 用redis-cli ping應(yīng)用服務(wù)則用一個輕量的 HTTP 探針。健康檢查通過后依賴它的服務(wù)才會真正開始工作。不過要注意depends_on在 1.9 版本里還不會自動等待健康狀態(tài)需要配合condition: service_healthy這種寫法這個特性在后續(xù)版本才完善所以在 1.9 上更穩(wěn)妥的做法是在測試執(zhí)行腳本里主動輪詢等待。我寫過一個通用的等待腳本邏輯是循環(huán)執(zhí)行健康檢查命令直到成功或者超時。這個腳本放在測試執(zhí)行容器的入口處比依賴 Compose 的編排能力更可靠。輪詢間隔設(shè) 2 秒超時設(shè) 120 秒這個參數(shù)是根據(jù) MySQL 冷啟動時間定的——在資源緊張的構(gòu)建機上MySQL 首次初始化可能要一分鐘以上。# docker-compose.test.yml 測試覆蓋層 version: 2 services: db: healthcheck: test: [CMD, mysqladmin, ping, -h, localhost] interval: 5s timeout: 3s retries: 10 tester: build: context: ./tests depends_on: - app - db command: sh -c ./wait-for-it.sh db:3306 -- ./run-tests.sh networks: - testnet3.3 網(wǎng)絡(luò)隔離與端口管理策略測試環(huán)境最怕的就是端口沖突。構(gòu)建機上可能同時跑著好幾個項目的測試如果都用默認端口映射到宿主機必然打架。我的策略是測試環(huán)境內(nèi)部完全不映射端口到宿主機所有通信走 Compose 自動創(chuàng)建的內(nèi)部網(wǎng)絡(luò)服務(wù)之間用服務(wù)名做主機名互相訪問。這樣無論跑多少個測試環(huán)境端口都不會沖突。只有在需要從宿主機訪問某個服務(wù)做調(diào)試時才臨時映射端口而且映射到高位隨機端口。這個思路和測試環(huán)境應(yīng)該完全自包含的原則是一致的。內(nèi)部網(wǎng)絡(luò)的 DNS 解析由 Docker 內(nèi)置的 DNS 服務(wù)負責(zé)服務(wù)名直接解析成容器 IP用起來和訪問本地服務(wù)沒區(qū)別。提示如果你的測試用例里硬編碼了localhost:3306這種地址容器化之后必然失敗。正確做法是把數(shù)據(jù)庫地址做成環(huán)境變量注入測試代碼里讀環(huán)境變量。這個改造一次性做完后面所有環(huán)境都能復(fù)用。4. 持續(xù)集成流水線的對接4.1 觸發(fā)、構(gòu)建與清理的完整生命周期持續(xù)集成的核心是每次提交都跑一遍完整測試所以流水線必須覆蓋三個動作拉起環(huán)境、執(zhí)行測試、清理環(huán)境。清理這一步最容易被忽視但恰恰是最重要的——如果每次跑完不清理構(gòu)建機的磁盤很快就會被停止的容器、懸空鏡像、匿名卷塞滿。我見過一臺構(gòu)建機因為沒清理三個月后磁盤爆掉所有流水線全部失敗。清理策略我推薦跑完即刪用docker-compose down -v --rmi local一條命令搞定。-v刪除匿名卷--rmi local刪除本次構(gòu)建產(chǎn)生的本地鏡像。注意不要加--rmi all那會把基礎(chǔ)鏡像也刪掉下次構(gòu)建又要重新拉取得不償失。另外建議在流水線里加一個前置的清理步驟防止上一次異常中斷留下的殘留影響本次運行。#!/bin/bash set -e # 前置清理容忍失敗 docker-compose -f docker-compose.yml -f docker-compose.test.yml down -v --rmi local || true # 構(gòu)建并啟動 docker-compose -f docker-compose.yml -f docker-compose.test.yml build docker-compose -f docker-compose.yml -f docker-compose.test.yml up -d # 執(zhí)行測試并捕獲退出碼 set e docker-compose -f docker-compose.yml -f docker-compose.test.yml run --rm tester TEST_EXIT_CODE$? set -e # 無論成敗都清理 docker-compose -f docker-compose.yml -f docker-compose.test.yml down -v --rmi local exit $TEST_EXIT_CODE這段腳本里有個關(guān)鍵細節(jié)run --rm tester的退出碼必須被捕獲并作為整個腳本的退出碼返回否則持續(xù)集成系統(tǒng)無法判斷測試是否通過。我見過不少流水線腳本忘了這一步結(jié)果測試失敗了流水線還顯示綠色問題被帶到生產(chǎn)環(huán)境才發(fā)現(xiàn)。4.2 構(gòu)建緩存與鏡像分層優(yōu)化持續(xù)集成的速度很大程度上取決于鏡像構(gòu)建能不能命中緩存。Dockerfile 的指令順序直接決定緩存命中率原則是把變化頻率低的指令放前面變化頻率高的放后面。比如先裝系統(tǒng)依賴再裝語言依賴最后才拷貝源碼。如果反過來改一行源碼就會導(dǎo)致依賴重新安裝構(gòu)建時間從幾十秒變成幾分鐘。多階段構(gòu)建在 1.12 時代還不支持所以只能靠精心組織 Dockerfile 來減小鏡像體積。我的做法是把構(gòu)建工具和運行時分離到不同的基礎(chǔ)鏡像構(gòu)建階段產(chǎn)生的中間產(chǎn)物通過COPY --from拷到運行鏡像里——等等這個特性也是后來才有的。在 1.12 上更實際的做法是構(gòu)建完在同一個 Dockerfile 里清理掉構(gòu)建工具或者干脆接受鏡像大一點用.dockerignore把無關(guān)文件排除掉減少構(gòu)建上下文傳輸時間。.dockerignore這個文件很多人不重視但它的作用很實在。構(gòu)建上下文里如果有node_modules、.git、日志文件這些大目錄每次構(gòu)建都要打包傳給守護進程白白浪費時間。我一般會把.git、node_modules、*.log、tmp這些都排除掉構(gòu)建上下文能從幾百兆降到幾兆。4.3 測試結(jié)果收集與失敗診斷測試跑完結(jié)果得能拿出來看。容器里的測試報告、日志、覆蓋率數(shù)據(jù)都要在容器銷毀前拷貝到宿主機。用docker cp或者掛載一個專門的結(jié)果卷都行。我傾向于用卷因為docker cp在容器已經(jīng)退出時容易出問題而卷可以在down之前從容拷貝。失敗診斷的關(guān)鍵是日志。測試失敗時光看測試框架的輸出往往不夠還需要看應(yīng)用容器的日志、數(shù)據(jù)庫容器的日志。所以流水線里要加一步測試失敗時把所有服務(wù)的日志 dump 出來。docker-compose logs --no-color能一次性輸出所有服務(wù)的日志配合--tail限制行數(shù)避免日志太多把流水線輸出刷屏。收集項收集方式用途測試報告結(jié)果卷掛載判斷通過率、生成趨勢圖應(yīng)用日志docker-compose logs定位應(yīng)用層異常依賴服務(wù)日志docker-compose logs排查數(shù)據(jù)庫、緩存問題覆蓋率數(shù)據(jù)結(jié)果卷掛載質(zhì)量趨勢分析5. 常見問題排查與實操避坑5.1 存儲驅(qū)動相關(guān)的典型故障在 Ubuntu 14.04 上跑 Docker存儲驅(qū)動引發(fā)的問題占了故障的一大半。最常見的現(xiàn)象是容器啟動時報 no space left on device但df -h看磁盤明明還有空間。這通常是 devicemapper 的 thin pool 滿了而不是磁盤滿了。解決辦法要么是擴大 thin pool要么是換回 aufs。這也是我前面堅持用 aufs 的原因之一。另一個高頻問題是鏡像層損壞表現(xiàn)為構(gòu)建時隨機報錯、拉取鏡像校驗失敗。aufs 在某些異常斷電后會留下不一致的層數(shù)據(jù)。遇到這種情況docker rmi刪掉相關(guān)鏡像重新拉取通常能解決如果不行就得清理/var/lib/docker/aufs下的殘留目錄。清理前務(wù)必確認沒有正在運行的容器依賴這些層否則會把運行中的環(huán)境搞壞。注意/var/lib/docker目錄千萬不要手動亂刪尤其是devicemapper或aufs子目錄。要清理就用docker system prune這類官方命令手動刪文件很容易把 Docker 的元數(shù)據(jù)搞亂最后只能重裝。5.2 網(wǎng)絡(luò)與 DNS 解析問題容器間通信失敗十有八九是 DNS 解析的問題。Compose 創(chuàng)建的網(wǎng)絡(luò)里服務(wù)名解析依賴 Docker 內(nèi)置 DNS但這個 DNS 在某些老版本上對容器重啟后的 IP 變更處理不及時導(dǎo)致解析到舊 IP。表現(xiàn)就是服務(wù)剛啟動時能連上跑一會兒就連接超時。排查這類問題的第一步是在容器里執(zhí)行nslookup 服務(wù)名或者getent hosts 服務(wù)名看解析結(jié)果對不對。如果解析到錯誤 IP重啟一下相關(guān)容器通常能刷新 DNS 緩存。更徹底的辦法是在應(yīng)用層做重試連接失敗后重新解析。測試環(huán)境里我一般會在數(shù)據(jù)庫客戶端配置里加上連接重試重試間隔 1 秒重試 5 次能覆蓋絕大多數(shù) DNS 抖動。還有一種情況是容器能解析但連不上那就要檢查 iptables 規(guī)則了。如果守護進程啟動時加了--iptablesfalse容器間的轉(zhuǎn)發(fā)規(guī)則需要手動配置很容易漏。我的建議是除非有明確的網(wǎng)絡(luò)隔離需求否則不要關(guān) iptables讓 Docker 自己管理。5.3 資源限制與并發(fā)測試的沖突構(gòu)建機上同時跑多個測試環(huán)境時資源競爭會導(dǎo)致各種詭異問題MySQL 啟動超時、測試隨機失敗、容器被 OOM killer 干掉。這些問題的根源是沒做資源限制。Compose 支持給每個服務(wù)設(shè)置 CPU 和內(nèi)存上限雖然 1.9 版本的資源限制功能還不算完善但基本的mem_limit和cpu_shares是可用的。我的經(jīng)驗值是MySQL 容器給 512MB 內(nèi)存Redis 給 128MB應(yīng)用容器根據(jù)實際占用給 256MB 到 512MB測試執(zhí)行容器給 256MB。這些值不是拍腦袋而是根據(jù)實際運行時的內(nèi)存峰值留了 30% 余量。設(shè)置上限的好處是即使某個測試用例內(nèi)存泄漏也只會影響它自己的容器不會拖垮整臺構(gòu)建機。services: db: image: mysql:5.6 mem_limit: 512m cpu_shares: 512 redis: image: redis:3.0 mem_limit: 128m cpu_shares: 2565.4 常見問題速查表現(xiàn)象可能原因排查命令解決方向容器啟動報 no spacethin pool 滿docker info看 Data Space換 aufs 或擴容服務(wù)間連接超時DNS 解析舊 IPgetent hosts 服務(wù)名重啟容器刷新 DNS測試隨機失敗資源競爭docker stats觀察加資源限制構(gòu)建極慢緩存未命中觀察構(gòu)建輸出調(diào)整 Dockerfile 順序磁盤快速耗盡未清理殘留docker system df加清理步驟守護進程起不來cgroups 未掛載mountgrep cgroup6. 穩(wěn)定性加固與長期維護建議6.1 鏡像版本鎖定與依賴固化測試環(huán)境最忌諱今天能跑明天不能跑?；A(chǔ)鏡像如果用latest標(biāo)簽?zāi)程焐嫌胃铝四愕臏y試可能突然全掛而且根本不知道發(fā)生了什么。所以所有鏡像都必須鎖定到具體版本甚至鎖定到 digest。MySQL 用mysql:5.6.35而不是mysql:5.6更不能用mysql:latest。語言依賴同理。Python 的requirements.txt要鎖版本Node 的package.json要用 lock 文件系統(tǒng)包安裝要指定版本號。這些做法在開發(fā)環(huán)境可能顯得繁瑣但在持續(xù)集成環(huán)境里是穩(wěn)定性的基石。我維護的一個測試環(huán)境所有依賴都鎖死兩年沒動過配置至今跑得好好的。6.2 定期維護與鏡像倉庫清理構(gòu)建機上的鏡像會越積越多即使每次跑完都清理本地鏡像從倉庫拉取的基礎(chǔ)鏡像還是會緩存。建議每周做一次docker system prune -a清理所有未使用的鏡像、容器、網(wǎng)絡(luò)。執(zhí)行前確認沒有正在運行的測試任務(wù)最好放在低峰期。另外如果團隊自建了鏡像倉庫也要定期清理舊版本鏡像。倉庫膨脹不僅占空間還會拖慢拉取速度。我一般保留最近 10 個版本的鏡像更早的自動清理。這個策略要根據(jù)團隊的發(fā)布頻率調(diào)整發(fā)布頻繁的團隊可以保留更多。6.3 監(jiān)控與告警的最小化配置測試環(huán)境本身不需要復(fù)雜的監(jiān)控但有幾個指標(biāo)值得關(guān)注構(gòu)建成功率、單次構(gòu)建耗時、構(gòu)建機磁盤使用率。這三個指標(biāo)能覆蓋 90% 的潛在問題。構(gòu)建成功率下降說明環(huán)境不穩(wěn)定耗時上升說明緩存失效或資源不足磁盤使用率上升說明清理沒做到位。實現(xiàn)方式不需要上重型監(jiān)控系統(tǒng)一個定時腳本采集數(shù)據(jù)寫進日志配合簡單的閾值告警就夠了。我在一個模擬項目里用 shell 腳本加 cron 實現(xiàn)了這套最小監(jiān)控運行了半年提前發(fā)現(xiàn)過兩次磁盤將滿和一次緩存失效效果比想象中好。我在實際維護這類老環(huán)境的過程中最大的體會是容器化測試環(huán)境的價值不在于技術(shù)多先進而在于把環(huán)境這件事變成了代碼。一旦環(huán)境是代碼它就能被審查、被測試、被回滾這才是持續(xù)集成真正需要的確定性。Ubuntu 14.04 這套底座確實老舊但只要把版本鎖定、資源限制、清理策略這幾件事做扎實它依然能穩(wěn)定地支撐起一套可靠的測試流水線。最后分享一個小技巧把 Compose 文件和構(gòu)建腳本放在同一個倉庫里和被測代碼一起做版本控制這樣任何一次環(huán)境變更都有跡可循出問題時git log一下就能定位到是哪次提交改壞了環(huán)境。