上兩周剛把一個(gè)前后端分離的項(xiàng)目完整搬到 Docker 上Spring Boot 做后端接口Vue 做管理端頁(yè)面從本地開發(fā)環(huán)境到服務(wù)器一鍵部署整個(gè)過(guò)程折騰了差不多三天。這中間踩了不少坑有的坑網(wǎng)上資料說(shuō)得含糊有的坑是版本更新之后才出現(xiàn)的趁著記憶還熱乎我把整套思路和操作細(xì)節(jié)整理出來(lái)需要的可以直接照著抄。1. 部署前需要理清的設(shè)計(jì)思路1.1 為什么把項(xiàng)目拆成三個(gè)容器而不是直接扔進(jìn)一臺(tái)機(jī)器很多人第一次用 Docker 部署前后端項(xiàng)目容易陷入一個(gè)誤區(qū)把所有東西塞進(jìn)一個(gè)容器里或者干脆只把 Jar 包放進(jìn)去前端文件還是手動(dòng)拷貝到 Nginx 里。這樣做短期能跑但后續(xù)維護(hù)會(huì)發(fā)現(xiàn)很難受——前端改一行代碼要重新登服務(wù)器替換靜態(tài)文件后端升級(jí)版本還要擔(dān)心影響前端環(huán)境。我用的方案是拆成三個(gè)容器后端容器跑 Java 服務(wù)前端容器用 Nginx 承載 Vue 打包后的靜態(tài)文件再加上 MySQL 數(shù)據(jù)庫(kù)容器。三者的關(guān)系是前端通過(guò) HTTP 請(qǐng)求訪問(wèn)后端接口后端連接數(shù)據(jù)庫(kù)讀寫數(shù)據(jù)對(duì)外只暴露前端和數(shù)據(jù)庫(kù)的端口。這樣做的好處有幾個(gè)。第一是環(huán)境隔離Java 的 JDK 版本、Nginx 的配置、MySQL 的數(shù)據(jù)存儲(chǔ)互不干擾不會(huì)出現(xiàn)“升級(jí) Node 導(dǎo)致 Nginx 配置不見了”這種破事。第二是遷移方便整套環(huán)境寫在 docker-compose 文件里換一臺(tái)服務(wù)器只需要裝好 Docker一條命令就能拉起全部服務(wù)。第三是回滾容易鏡像就是存檔版本出問(wèn)題直接把鏡像 tag 切回上一個(gè)驗(yàn)證過(guò)的歷史版本隨時(shí)能用。1.2 項(xiàng)目目錄結(jié)構(gòu)與鏡像規(guī)劃在寫 Dockerfile 之前我先規(guī)劃了目錄結(jié)構(gòu)建議你也先做這一步別急著寫配置。project-root/ ├── backend/ # Spring Boot 項(xiàng)目 │ ├── Dockerfile │ └── target/xxx.jar ├── frontend/ # Vue 項(xiàng)目 │ ├── Dockerfile │ ├── nginx.conf │ ├── dist/ # npm run build 產(chǎn)物 │ └── src/ └── docker-compose.yml后端和前端各自維護(hù)一套 Dockerfile最外層根據(jù)數(shù)據(jù)庫(kù)配置額外添加 MySQL 服務(wù)。需要注意一點(diǎn)Jar 文件是通過(guò) Maven 構(gòu)建出來(lái)的前端 dist 是通過(guò) npm 構(gòu)建出來(lái)的但我在寫鏡像的時(shí)候用了多階段構(gòu)建也就是直接在 Dockerfile 里完成編譯打包不用先在宿主機(jī)上裝一遍 Maven 和 Node。后面的 Dockerfile 部分我會(huì)展開細(xì)說(shuō)。1.3 部署前的自檢清單動(dòng)手寫配置之前先在本地或者測(cè)試環(huán)境確認(rèn)這幾件事Spring Boot 項(xiàng)目是否用了 Maven 或 Gradle 構(gòu)建能在命令行里完整打包生成可執(zhí)行 Jar。Vue 項(xiàng)目執(zhí)行npm run build能正常產(chǎn)出 dist 目錄并且開發(fā)環(huán)境下的 API 請(qǐng)求地址是相對(duì)路徑或者可以通過(guò)環(huán)境變量覆蓋。后端數(shù)據(jù)庫(kù)連接信息沒有硬編碼在代碼里而是通過(guò)環(huán)境變量讀取方便容器啟動(dòng)時(shí)傳入。確認(rèn)服務(wù)器的端口規(guī)劃前端端口、后端端口、數(shù)據(jù)庫(kù)端口不能和已有服務(wù)沖突。前兩項(xiàng)是打包的基礎(chǔ)后兩項(xiàng)是容器化改造的重頭戲。如果你的項(xiàng)目目前是直接寫死數(shù)據(jù)庫(kù)地址的建議先改成配置項(xiàng)容器里再通過(guò) Environment 傳入。2. 后端容器化Spring Boot 的 Dockerfile 編寫2.1 基礎(chǔ)鏡像選擇別只用 openjdk 不帶版本Spring Boot 的 Dockerfile 第一行就是選擇基礎(chǔ)鏡像這一步很容易翻車。很多人習(xí)慣寫FROM openjdk:latest圖省事。但在生產(chǎn)環(huán)境里latest是個(gè)坑——它指向的 JDK 版本可能跟你本地開發(fā)環(huán)境不一致導(dǎo)致編譯出的 class 文件無(wú)法運(yùn)行。我現(xiàn)在用的是結(jié)合了 Maven 和 Java 運(yùn)行時(shí)的多階段方案。第一階段用帶 Maven 的鏡像編譯打包第二階段用精簡(jiǎn)的 JRE 鏡像運(yùn)行。這樣最終鏡像體積小里面也不含編譯工具安全性和啟動(dòng)速度都好得多。一個(gè)實(shí)際例子我的后端項(xiàng)目基于 Java 17 和 Spring Boot 3.xDockerfile 長(zhǎng)這樣# 第一階段編譯打包 FROM maven:3.9.4-eclipse-temurin-17 AS builder WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn clean package -DskipTests # 第二階段運(yùn)行 FROM eclipse-temurin:17-jre WORKDIR /app COPY --frombuilder /app/target/*.jar app.jar EXPOSE 8080 ENV TZAsia/Shanghai ENTRYPOINT [java, -jar, app.jar]2.2 多階段構(gòu)建解決了什么問(wèn)題多階段構(gòu)建最直接的價(jià)值是控制鏡像大小。如果只用單個(gè) Maven 鏡像跑完所有步驟最終鏡像里會(huì)殘留 maven 倉(cāng)庫(kù)、源碼、編譯工具鏈體積輕則幾百 MB重則一個(gè)多 G。而上面的寫法里最終運(yùn)行的鏡像只包含 JRE 和打好的 Jar體積通常在 200 MB 左右。還有一個(gè)隱藏好處是依賴下載緩存。mvn dependency:go-offline會(huì)在構(gòu)建階段先拉取所有依賴存放到鏡像層里。只要 pom.xml 沒變這一層的緩存就不會(huì)失效后續(xù)構(gòu)建幾分鐘內(nèi)就能完成。2.3 構(gòu)建與運(yùn)行細(xì)節(jié)時(shí)區(qū)、參數(shù)、健康檢查Spring Boot 項(xiàng)目打包好之后運(yùn)行階段有幾個(gè)經(jīng)常被忽略的細(xì)節(jié)。時(shí)區(qū)問(wèn)題。如果不設(shè)置環(huán)境變量容器的默認(rèn)時(shí)區(qū)是 UTC和國(guó)內(nèi)的時(shí)間差八個(gè)小時(shí)。數(shù)據(jù)庫(kù)里存的時(shí)間和日志時(shí)間都會(huì)錯(cuò)亂。我在 Dockerfile 里加了ENV TZAsia/Shanghai但更穩(wěn)妥的辦法是在啟動(dòng)時(shí)掛載宿主機(jī)時(shí)區(qū)文件或者直接依賴基礎(chǔ)鏡像的 tzdata 包。上面的寫法在常用基礎(chǔ)鏡像里實(shí)測(cè)沒問(wèn)題如果你的鏡像里沒有 tzdata需要先apt-get install -y tzdata。JVM 參數(shù)。容器環(huán)境下 JVM 的默認(rèn)堆內(nèi)存行為可能會(huì)讓進(jìn)程吃滿宿主機(jī)內(nèi)存。建議在啟動(dòng)命令里顯式限制內(nèi)存ENTRYPOINT [java, -Xms256m, -Xmx512m, -jar, app.jar]如果服務(wù)器內(nèi)存緊張這個(gè)配置能避免容器耗盡宿主機(jī)資源導(dǎo)致 Docker 守護(hù)進(jìn)程被拉死。當(dāng)然具體的堆內(nèi)存大小要根據(jù)你項(xiàng)目的實(shí)際負(fù)載來(lái)調(diào)。還有一個(gè)容易被忽略的點(diǎn)是健康檢查。Spring Boot Actuator 自帶health端點(diǎn)可以在 Dockerfile 里配置 HEALTHCHECKHEALTHCHECK --interval30s --timeout3s --retries3 \ CMD curl -fs http://localhost:8080/actuator/health || exit 1但要注意基礎(chǔ)鏡像里不一定帶 curl有些精簡(jiǎn) JRE 鏡像里沒有。這時(shí)候需要在構(gòu)建階段把 curl 裝進(jìn)去或者直接用 Java 寫一個(gè)簡(jiǎn)單檢查。我一般選擇在基礎(chǔ)鏡像里補(bǔ)裝 curl代價(jià)是體積略增但可排查性和可運(yùn)維性都上來(lái)了。2.4 構(gòu)建鏡像的命令與測(cè)試寫好后端 Dockerfile執(zhí)行構(gòu)建docker build -t backend:1.0.0 ./backend構(gòu)建完成后先不急著編排用單獨(dú)試跑的模式驗(yàn)證容器能不能正常啟動(dòng)docker run -d --name backend-test -p 8080:8080 backend:1.0.0然后檢查容器日志是否出現(xiàn)了 Spring Boot 的啟動(dòng)成功標(biāo)志再訪問(wèn)一下http://localhost:8080/actuator/health確認(rèn)狀態(tài) UP。這一步在開發(fā)機(jī)上驗(yàn)證完后面編排時(shí)心里就踏實(shí)了。3. 前端容器化Vue 項(xiàng)目如何構(gòu)建鏡像3.1 前端構(gòu)建的兩種思路對(duì)比前端和純后端服務(wù)不太一樣Vue 項(xiàng)目本身沒有運(yùn)行時(shí)的服務(wù)進(jìn)程它是一堆靜態(tài)文件通過(guò) Nginx 對(duì)外提供 HTTP 服務(wù)。構(gòu)建思路無(wú)非兩種。一種是先在宿主機(jī)上執(zhí)行npm run build把 dist 目錄拷進(jìn)鏡像里。這種方式適合本機(jī)已經(jīng)裝了 Node但換到其他環(huán)境時(shí)不夠通用。另一種是我推薦的方式用 Node 鏡像在構(gòu)建階段執(zhí)行打包然后只把 dist 產(chǎn)物拷貝到 Nginx 鏡像里。這樣宿主機(jī)完全不需要安裝 Node任何一臺(tái)裝了 Docker 的機(jī)器都能完成構(gòu)建。前端 Dockerfile 如下# 第一階段構(gòu)建 Vue 靜態(tài)資源 FROM node:18-alpine AS builder WORKDIR /app COPY package.json . RUN npm install COPY . . RUN npm run build # 第二階段運(yùn)行 Nginx FROM nginx:1.24-alpine COPY --frombuilder /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 803.2 前端路由 history 模式與 Nginx 配置這地方的坑是我認(rèn)為整個(gè)項(xiàng)目里最容易踩的得單獨(dú)說(shuō)。Vue Router 如果用的是createWebHistory模式頁(yè)面地址長(zhǎng)這樣http://xxx.com/system/user不帶#。這種模式下當(dāng)你直接訪問(wèn)一個(gè)子路由比如刷新頁(yè)面或者直接輸入 URL瀏覽器會(huì)向服務(wù)器請(qǐng)求/system/user這個(gè)路徑但服務(wù)器上根本沒有這個(gè)文件Nginx 會(huì)返回 404。解決方法是給 Nginx 配置try_files讓所有找不到的路徑都回退到index.html由前端路由接管接下來(lái)的路由解析。server { listen 80; server_name localhost; root /usr/share/nginx/html; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://backend:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }這里location /api/是反向代理規(guī)則。前端代碼里請(qǐng)求接口的地址寫成/api/...Nginx 接收到這個(gè)路徑后會(huì)轉(zhuǎn)發(fā)給后端容器。proxy_pass http://backend:8080/api/;里的backend是 docker-compose 里的服務(wù)名容器網(wǎng)絡(luò)內(nèi)可以直接通過(guò)服務(wù)名訪問(wèn)后面編排部分會(huì)解釋為什么這么寫。3.3 運(yùn)行時(shí)環(huán)境變量處理別把打包當(dāng)唯一途徑如果你的前端代碼里有VUE_APP_API_BASE_URL之類的環(huán)境變量并且這個(gè)變量在開發(fā)環(huán)境和測(cè)試環(huán)境指向不同的接口地址那你需要注意npm run build的過(guò)程會(huì)把環(huán)境變量編譯進(jìn) JavaScript 文件里。換句話說(shuō)一旦構(gòu)建完成鏡像里的接口地址就固定了無(wú)法通過(guò)容器運(yùn)行時(shí)的環(huán)境變量覆蓋。這種“構(gòu)建時(shí)注入”的方式在開發(fā)環(huán)境沒問(wèn)題但到了部署階段就很麻煩。比如同一個(gè)鏡像要同時(shí)部署到測(cè)試環(huán)境和生產(chǎn)環(huán)境測(cè)試環(huán)境的接口是http://test-api.xxx.com生產(chǎn)環(huán)境是http://api.xxx.com你就必須分別構(gòu)建兩個(gè)鏡像。我用的方案是運(yùn)行時(shí)動(dòng)態(tài)注入。在 Nginx 鏡像的啟動(dòng)階段執(zhí)行一個(gè)腳本把環(huán)境變量寫到/usr/share/nginx/html/config.js里然后在 HTML 里引入這個(gè)文件前端代碼從window.SITE_CONFIG.apiBaseUrl讀取接口地址。這樣同一個(gè)鏡像通過(guò)傳入不同的環(huán)境變量就能適配不同環(huán)境。具體做法是加一個(gè) entrypoint.sh#!/bin/sh cat /usr/share/nginx/html/config.js EOF window.SITE_CONFIG { apiBaseUrl: ${API_BASE_URL} } EOF nginx -g daemon off;在 Dockerfile 里替換 Nginx 默認(rèn)啟動(dòng)命令COPY entrypoint.sh /entrypoint.sh RUN chmod x /entrypoint.sh ENTRYPOINT [/entrypoint.sh]前端代碼里這樣讀取const apiBaseUrl window.SITE_CONFIG?.apiBaseUrl || /api/;這樣構(gòu)建出的鏡像可以一套打天下每次部署只是改環(huán)境變量不用重新構(gòu)建。對(duì)于需要頻繁發(fā)布測(cè)試版和正式版的情況這個(gè)方案能省不少時(shí)間。4. 使用 docker-compose 一鍵編排整套服務(wù)4.1 docker-compose 文件的基礎(chǔ)結(jié)構(gòu)前端和后端鏡像都構(gòu)建好了接下來(lái)要把數(shù)據(jù)庫(kù)也拉進(jìn)來(lái)一起受 docker-compose 的編排管理。先放一個(gè)實(shí)際能用的 docker-compose.ymlversion: 3.8 services: mysql: image: mysql:8.0 container_name: project-mysql restart: always environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: project_db MYSQL_USER: appuser MYSQL_PASSWORD: app123456 volumes: - ./mysql-data:/var/lib/mysql ports: - 3306:3306 networks: - app-net backend: build: ./backend image: backend:1.0.0 container_name: project-backend restart: always depends_on: - mysql environment: SPRING_PROFILES_ACTIVE: docker DB_HOST: mysql DB_PORT: 3306 DB_NAME: project_db DB_USER: appuser DB_PASSWORD: app123456 ports: - 8080:8080 networks: - app-net frontend: build: ./frontend image: frontend:1.0.0 container_name: project-frontend restart: always depends_on: - backend environment: API_BASE_URL: /api/ ports: - 80:80 networks: - app-net networks: app-net: driver: bridge4.2 服務(wù)名與容器網(wǎng)絡(luò)的關(guān)鍵作用docker-compose 會(huì)給每個(gè)服務(wù)創(chuàng)建一個(gè)可通過(guò)服務(wù)名訪問(wèn)的網(wǎng)絡(luò)別名。比如 backend 容器在 app-net 網(wǎng)絡(luò)里它的主機(jī)名就是backend。所以前端 Nginx 配置里寫proxy_pass http://backend:8080/api/;就能直接訪問(wèn)到后端服務(wù)不需要關(guān)心 IP 地址。這一點(diǎn)在生產(chǎn)環(huán)境特別重要。容器每次啟動(dòng)分配到的 IP 是動(dòng)態(tài)的直接寫死 IP 會(huì)在重啟后失效。通過(guò)服務(wù)名通訊容器怎么重啟、IP 怎么變化都不用修改配置。depends_on控制啟動(dòng)順序。需要注意它只保證先啟動(dòng)數(shù)據(jù)庫(kù)容器不代表數(shù)據(jù)庫(kù)已經(jīng)初始化完成。實(shí)際部署中我遇到過(guò)一個(gè)情況MySQL 還在初始化時(shí)Spring Boot 已經(jīng)啟動(dòng)連接數(shù)據(jù)庫(kù)失敗導(dǎo)致整個(gè)啟動(dòng)流程崩潰。這個(gè)問(wèn)題有兩種處理方式。一是給后端容器加restart: alwaysMySQL 初始化完成后后端會(huì)自動(dòng)重啟連接簡(jiǎn)單粗暴但有效。二是寫一個(gè)等待腳本在容器啟動(dòng)前循環(huán)檢查數(shù)據(jù)庫(kù)端口是否就緒。兩種我都試過(guò)等待腳本更可控但腳本本身的健壯性也要測(cè)試所以我一般先用restart: always等系統(tǒng)平穩(wěn)運(yùn)行后再考慮要不要加腳本。4.3 數(shù)據(jù)庫(kù)數(shù)據(jù)持久化容器能刪數(shù)據(jù)不能丟MySQL 容器有一個(gè)大坑如果容器被刪除而數(shù)據(jù)沒有掛載到宿主機(jī)那么整個(gè)數(shù)據(jù)庫(kù)就沒了。docker-compose 里我用了一個(gè)數(shù)據(jù)卷掛載volumes: - ./mysql-data:/var/lib/mysql這樣 MySQL 的數(shù)據(jù)文件會(huì)存儲(chǔ)到宿主機(jī)項(xiàng)目的mysql-data目錄下。即使執(zhí)行docker-compose down把容器都刪掉下次重新啟動(dòng)docker-compose up -d時(shí)數(shù)據(jù)仍然在。對(duì)于生產(chǎn)環(huán)境這個(gè)掛載目錄最好放到獨(dú)立的數(shù)據(jù)盤或者使用 Docker Volume 卷。4.4 鏡像管理給鏡像打 tag 并推送到倉(cāng)庫(kù)本地構(gòu)建的鏡像只存在于當(dāng)前機(jī)器如果要把項(xiàng)目部署到遠(yuǎn)程服務(wù)器有幾種方式。最簡(jiǎn)單的做法是直接在服務(wù)器上放源碼并執(zhí)行docker-compose up -d --build讓服務(wù)器自己構(gòu)建。這種方式適合測(cè)試環(huán)境但每次發(fā)布都要把源碼傳上去項(xiàng)目大時(shí)很耗時(shí)。更規(guī)范的做法是構(gòu)建完成后把鏡像推送到鏡像倉(cāng)庫(kù)服務(wù)器只負(fù)責(zé)拉取。構(gòu)建時(shí)打好標(biāo)簽docker tag backend:1.0.0 registry.example.com/project/backend:1.0.0 docker push registry.example.com/project/backend:1.0.0在服務(wù)器上執(zhí)行docker pull registry.example.com/project/backend:1.0.0 docker-compose up -d這在多人協(xié)作或需要多臺(tái)服務(wù)器部署時(shí)尤其重要。鏡像倉(cāng)庫(kù)就是存檔每一個(gè)版本都是可回滾的中轉(zhuǎn)點(diǎn)比每次臨時(shí)打 tar 包靠譜得多。4.5 常用編排命令速查這里整理幾個(gè)我每次部署都會(huì)用到的命令# 構(gòu)建鏡像并后臺(tái)啟動(dòng)全部服務(wù) docker-compose up -d --build # 查看服務(wù)狀態(tài) docker-compose ps # 查看某個(gè)服務(wù)的日志 docker-compose logs -f backend # 重新啟動(dòng)某個(gè)服務(wù) docker-compose restart frontend # 停止并移除容器不會(huì)刪數(shù)據(jù)卷 docker-compose down # 徹底停止并移除容器、網(wǎng)絡(luò)和匿名卷 docker-compose down -vdown -v要謹(jǐn)慎使用它會(huì)刪除掛載到容器匿名卷的數(shù)據(jù)。我因?yàn)槭终`執(zhí)行過(guò)一次差點(diǎn)把數(shù)據(jù)庫(kù)測(cè)試數(shù)據(jù)清空好在那只是開發(fā)環(huán)境。生產(chǎn)環(huán)境務(wù)必確保所有數(shù)據(jù)都掛載到了宿主機(jī)路徑或者命名卷否則千萬(wàn)別加-v。5. 踩坑記錄與排查技巧實(shí)錄5.1 鏡像拉取超時(shí)與構(gòu)建慢的問(wèn)題使用默認(rèn)源拉取基礎(chǔ)鏡像時(shí)常會(huì)遇到超時(shí)或速度極慢這個(gè)問(wèn)題在國(guó)內(nèi)環(huán)境尤其明顯。解決辦法是配置鏡像加速地址在 Docker 守護(hù)進(jìn)程的配置文件中加入 registry-mirrors 配置。如果你所在的網(wǎng)絡(luò)環(huán)境無(wú)法直接訪問(wèn)公共倉(cāng)庫(kù)也可以在構(gòu)建階段配置鏡像源。前端 Node 鏡像的npm install速度慢時(shí)可以把 npm 源切到國(guó)內(nèi)鏡像在 Dockerfile 里加一行RUN npm config set registry https://registry.npmmirror.example.comMaven 同理在 settings.xml 或構(gòu)建命令里指定鏡像地址。這一步能有效縮短構(gòu)建時(shí)間尤其是首次構(gòu)建需要拉取大量依賴時(shí)差距非常明顯。5.2 容器里訪問(wèn)不到宿主機(jī)服務(wù)有一種場(chǎng)景是后端需要連接數(shù)據(jù)庫(kù)但數(shù)據(jù)庫(kù)不在容器里而在宿主機(jī)上。這時(shí)候 Spring Boot 配置里如果寫localhost:3306連接的一定是容器自身的 3306 端口肯定連不上宿主機(jī)。解決方法是把數(shù)據(jù)庫(kù)主機(jī)地址寫成宿主機(jī)在 Docker 網(wǎng)絡(luò)里的 IP。Docker 的 bridge 網(wǎng)絡(luò)模式下宿主機(jī)地址通常是172.17.0.1。更推薦的做法是使用host.docker.internal這個(gè)特殊域名它在 Linux 上需要額外參數(shù)支持在 Docker Desktop for Mac/Windows 上是內(nèi)置的。我實(shí)際驗(yàn)證下來(lái)最省心的方案還是把所有依賴服務(wù)都納入 docker-compose 統(tǒng)一管理這樣直接用服務(wù)名即可完成互通不需要關(guān)心 IP 和網(wǎng)絡(luò)模式。5.3 前端刷新頁(yè)面返回 404剛才在 Nginx 配置里提過(guò)這個(gè)問(wèn)題但在實(shí)際部署時(shí)還是會(huì)有人漏掉。如果你已經(jīng)配了try_files $uri $uri/ /index.html;但仍然 404排查幾個(gè)點(diǎn)。第一確認(rèn) Nginx 的root路徑是否正確。如果鏡像里靜態(tài)文件在/usr/share/nginx/html而配置里寫成/var/www/html那所有文件都會(huì) 404。第二確認(rèn)配置生效了。有的基礎(chǔ)鏡像已經(jīng)在/etc/nginx/nginx.conf或/etc/nginx/conf.d/default.conf里有一套默認(rèn)配置你新拷貝的配置可能被覆蓋或沖突。執(zhí)行docker exec進(jìn)入容器查看當(dāng)前生效的配置內(nèi)容逐行確認(rèn)。第三檢查防火墻或安全組規(guī)則。如果是在云服務(wù)器上部署80 端口需要放行否則外部訪問(wèn)不了。5.4 后端容器啟動(dòng)失敗反復(fù)重啟這類問(wèn)題一般集中在依賴資源和資源耗盡兩個(gè)方面。數(shù)據(jù)庫(kù)連接不上的原因可能是數(shù)據(jù)庫(kù)服務(wù)還沒就緒或者連接地址寫錯(cuò)。JVM 內(nèi)存設(shè)置過(guò)大但容器可用內(nèi)存不足則會(huì)導(dǎo)致啟動(dòng)崩潰。使用docker-compose logs查看日志是最直接的排查途徑日志里會(huì)明確顯示啟動(dòng)失敗的原因。有一次我遇到 Spring Boot 不斷重啟循環(huán)日志里沒有特別明顯的報(bào)錯(cuò)最后發(fā)現(xiàn)是 healthcheck 配置的 curl 命令在容器里不存在健康檢查永遠(yuǎn)失敗而觸發(fā)重啟機(jī)制。精簡(jiǎn)的基礎(chǔ)鏡像往往缺少工具排查問(wèn)題前先確認(rèn)基礎(chǔ)鏡像包含哪些命令避免把排查工具本身做成新的故障源。5.5 常用排查命令速查表目標(biāo)命令查看容器狀態(tài)docker ps -a跟蹤日志docker logs -f 容器名進(jìn)入容器docker exec -it 容器名 /bin/sh查看網(wǎng)絡(luò)docker network inspect app-net查看資源占用docker stats查看掛載docker inspect 容器名查看Volumes和Mounts字段清理懸空鏡像docker image prune5.6 鏡像體積優(yōu)化經(jīng)驗(yàn)部署完成后我還會(huì)看一遍鏡像體積。Spring Boot 的多階段構(gòu)建已經(jīng)讓后端鏡像控制在 250 MB 以內(nèi)但 Nginx 鏡像如果配置不當(dāng)也可能變大。最大的體積殺手是把源碼 copy 到運(yùn)行鏡像里。有些人是直接把整個(gè)前端源碼目錄COPY . .到 Nginx 里這樣鏡像里全是 .vue 文件和 node_modules最后體積奔著 1 GB 去了。正確做法是只拷貝dist目錄。其次是一個(gè)隱藏體積殺手如果你用單階段構(gòu)建Jar 文件可能包含一堆冗余依賴。Spring Boot 3.x 自帶 Spring Boot Maven Plugin 的分層工具可以把 Jar 包里的依賴模塊、應(yīng)用模塊拆開分層配合 Docker 構(gòu)建緩存讓依賴層只在 pom 變更時(shí)重新打包。6. 我的自動(dòng)化部署經(jīng)驗(yàn)整套方案穩(wěn)定運(yùn)行之后我加了一點(diǎn)點(diǎn)自動(dòng)化腳本讓發(fā)布流程更順手。先是在項(xiàng)目里寫了一個(gè)簡(jiǎn)單的部署腳本deploy.sh#!/bin/bash set -e echo 構(gòu)建后端鏡像 docker build -t backend:1.0.0 ./backend echo 構(gòu)建前端鏡像 docker build -t frontend:1.0.0 ./frontend echo 啟動(dòng)服務(wù) docker-compose up -d echo 清理懸空鏡像 docker image prune -f在服務(wù)器上執(zhí)行這個(gè)腳本它會(huì)自動(dòng)完成從源碼到服務(wù)啟動(dòng)的全過(guò)程。如果代碼有內(nèi)容更新只需要在服務(wù)器上拉取最新代碼git pull然后重新執(zhí)行腳本前端的 npm 構(gòu)建、后端的 Maven 打包都會(huì)在容器內(nèi)完成宿主機(jī)完全不需要安裝 Java 和 Node 環(huán)境。這種方式對(duì)于中小型項(xiàng)目來(lái)說(shuō)性價(jià)比已經(jīng)很高了。后續(xù)如果團(tuán)隊(duì)規(guī)模變大、發(fā)布頻率變高可以考慮接入更完善的自動(dòng)化流水線但基礎(chǔ)原理都是一樣的仍然是構(gòu)建鏡像、推送倉(cāng)庫(kù)、服務(wù)器拉取啟動(dòng)這三個(gè)環(huán)節(jié)。我這里分享的只是常規(guī)做法不同項(xiàng)目細(xì)節(jié)會(huì)有些出入。比如如果你的前端沒有用 Vue Router 的 history 模式Nginx 的配置就不需要try_files回退如果 Spring Boot 項(xiàng)目還在用 Java 8基礎(chǔ)鏡像的標(biāo)簽要對(duì)應(yīng)改成temurin-8。部署本身不是難點(diǎn)難的是把每個(gè)環(huán)節(jié)的依賴關(guān)系理清楚然后選擇合適的編排方式。按上面這一套流程走下來(lái)前后端項(xiàng)目從一個(gè)無(wú)從下手的“一堆本地進(jìn)程”變成一個(gè)完整的、可遷移的容器集合整個(gè)開發(fā)體驗(yàn)會(huì)順暢很多。