最近完成了一套Docker與DevSecOps的動手實驗，想把完整過程寫下來——包括那些搞砸的部分，因為真正的學(xué)習(xí)往往發(fā)生在報錯之后。

最終成果包括：從拉取公共鏡像到構(gòu)建自定義應(yīng)用，再到集成安全掃描和自動化部署的完整流水線。本文按實際步驟復(fù)盤，穿插三個具體問題及解決方法。如果你打算復(fù)現(xiàn)，應(yīng)該能省些時間。

開始前需要準(zhǔn)備：Docker Desktop或本地Docker環(huán)境、Docker Hub賬號、GitHub賬號。還需要一個Docker Hub個人訪問令牌（不是密碼），在hub.docker.com的賬戶設(shè)置-安全-新建訪問令牌生成，賦予讀寫權(quán)限，立即復(fù)制保存——它只顯示一次。

第一階段：作為消費者

先不構(gòu)建任何東西，而是拉取公共鏡像、運行并觀察。執(zhí)行docker pull nginx:alpine獲取輕量級Nginx鏡像，用docker run -d -p 8080:80 --name my-nginx nginx:alpine以分離模式運行，將容器80端口映射到主機8080端口。docker ps查看運行狀態(tài)，docker logs my-nginx查看日志，最后用docker rm -f my-nginx清理。

瀏覽器打開localhost:8080能看到Nginx歡迎頁。這個過程的本質(zhì)是：從Docker Hub下載預(yù)構(gòu)建的文件系統(tǒng)（鏡像），Docker據(jù)此啟動隔離進程（容器）。-p 8080:80讓容器內(nèi)端口可被外部訪問，這是后續(xù)所有操作的基礎(chǔ)。

第二階段：成為構(gòu)建者

現(xiàn)在構(gòu)建Python Flask應(yīng)用。項目結(jié)構(gòu)包含app.py、templates/index.html、requirements.txt、Dockerfile和.dockerignore。app.py是極簡Flask應(yīng)用，有首頁和/health健康檢查端點，APP_NODE變量從環(huán)境讀取——這實現(xiàn)了配置與代碼分離，運行時注入標(biāo)識符無需重建鏡像。

templates/index.html提供前端界面，requirements.txt列出flask依賴。Dockerfile采用多階段構(gòu)建：先用python:3.9-slim作為基礎(chǔ)鏡像，設(shè)置工作目錄，復(fù)制依賴文件并安裝，再復(fù)制應(yīng)用代碼，暴露5000端口，最后定義啟動命令。.dockerignore排除__pycache__等文件減小鏡像體積。

構(gòu)建命令docker build -t yourusername/flask-app:v1 . 會逐層執(zhí)行Dockerfile指令，生成帶標(biāo)簽的本地鏡像。推送前需docker login，然后docker push yourusername/flask-app:v1上傳到Docker Hub，他人即可拉取使用。

第三階段：安全掃描

鏡像上傳后需要安全檢查。Docker Hub本身提供基礎(chǔ)掃描，但實驗要求集成Trivy——一個開源漏洞掃描器。安裝后執(zhí)行trivy image yourusername/flask-app:v1，它會比對漏洞數(shù)據(jù)庫，輸出按嚴(yán)重程度分級的結(jié)果。

我遇到的第一個坑：Trivy初次運行下載數(shù)據(jù)庫極慢，且超時失敗。解決方式是配置鏡像源加速，或先執(zhí)行trivy image --download-db-only單獨下載數(shù)據(jù)庫。第二個坑：掃描報告里大量"誤報"，比如某些CVE在Alpine Linux實際已修復(fù)但數(shù)據(jù)庫未更新。需要結(jié)合docker scout或人工判斷，不能全信掃描結(jié)果。

第四階段：自動化流水線

用GitHub Actions實現(xiàn)推送代碼即構(gòu)建部署。工作流文件放在.github/workflows/docker.yml，觸發(fā)條件設(shè)為push到main分支。步驟包括：檢出代碼、登錄Docker Hub、構(gòu)建并推送鏡像、運行Trivy掃描、掃描失敗時阻止部署。

第三個坑來了：GitHub Actions的默認(rèn)Ubuntu運行器沒有Docker Buildx，多平臺構(gòu)建報錯。需在步驟中顯式設(shè)置docker/setup-buildx-action@v2。另一個隱蔽問題是secrets.DOCKER_TOKEN在fork的PR中不可用，導(dǎo)致外部貢獻(xiàn)者構(gòu)建失敗——這是安全設(shè)計，但文檔很少提及。

最終工作流跑通后，每次git push自動完成構(gòu)建-掃描-推送全流程。失敗時GitHub會發(fā)郵件，掃描報告作為構(gòu)建產(chǎn)物可下載審計。

復(fù)盤

這套流水線最耗時的不是寫配置，而是調(diào)通憑證和權(quán)限。Docker Hub令牌、GitHub Secrets、Trivy數(shù)據(jù)庫，三個外部依賴各卡了一次。文檔往往假設(shè)讀者已熟悉這些生態(tài)，但新手連錯誤信息都搜不到對應(yīng)方案。建議遇到報錯先檢查版本——Trivy 0.48和0.50的數(shù)據(jù)庫格式不兼容，這是隱性坑點。