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