引言 

在使用 Docker Compose 部署前后端分離項目時，前端容器需要根據(jù)不同的環(huán)境（開發(fā)、測試、生產(chǎn)）動態(tài)請求后端服務(wù)的地址。常見的需求矛盾在于：

• 開發(fā)環(huán)境：前端可能需要直接訪問宿主機的后端服務(wù)（如 localhost:8080）。
• 生產(chǎn)環(huán)境：前端需要訪問 Docker 內(nèi)部網(wǎng)絡(luò)中的后端服務(wù)（如 backend:8080）。

本文將對比三種主流實現(xiàn)方案，分析其優(yōu)缺點及適用場景。

方案一：構(gòu)建時注入 URL（硬編碼方式） 

核心思想：在構(gòu)建鏡像時，通過 Dockerfile 的 ARG 參數(shù)將后端地址固化到鏡像中。

實現(xiàn)步驟

• 修改 Dockerfile

FROM node:20 AS build
ARG API_BASE_URL              # 聲明構(gòu)建參數(shù)
ENV VUE_APP_API_BASE=$API_BASE_URL  # 傳遞到 Vue 環(huán)境變量
COPY . .
RUN npm run build
 
FROM nginx
COPY --from=build /app/dist /usr/share/nginx/html

• 配置 docker-compose.yml

services:
  frontend:
    build:
      context: .
      args:
        API_BASE_URL: "http://backend:8080"  # 直接寫死地址

• 前端代碼使用

// 直接讀取環(huán)境變量
axios.get(`${process.env.VUE_APP_API_BASE}/api/data`);

優(yōu)點

• 簡單直接：一次構(gòu)建，永久生效，無需額外配置。
• 安全性高：配置內(nèi)置于鏡像，外部無法篡改。

缺點

• 靈活性差：每次修改地址需重新構(gòu)建鏡像。
• 環(huán)境隔離弱：無法用同一個鏡像適應(yīng)不同環(huán)境。

適用場景

• 后端地址固定不變（如純內(nèi)網(wǎng)環(huán)境）。
• 對鏡像版本控制有嚴格要求。

方案二：運行時動態(tài)配置 URL（環(huán)境變量或腳本生成） 

核心思想：構(gòu)建通用的前端鏡像，在容器啟動時通過環(huán)境變量或動態(tài)腳本生成配置文件。

實現(xiàn)步驟

1. 修改 Dockerfile

FROM nginx:alpine
COPY entrypoint.sh /entrypoint.sh    # 入口腳本
COPY nginx.conf /etc/nginx/conf.d/default.conf
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]       # 啟動時執(zhí)行腳本

• 入口腳本 (entrypoint.sh)

#!/bin/sh
# 動態(tài)生成配置文件
echo "window.APP_CONFIG = { API_BASE_URL: '${API_BASE_URL}' };" > /usr/share/nginx/html/config.js
exec nginx -g "daemon off;"

• 配置 docker-compose.yml

services:
  frontend:
    image: my-frontend-image  # 使用預(yù)構(gòu)建的通用鏡像
    environment:
      API_BASE_URL: "http://backend:8080"  # 運行時注入

• 前端代碼動態(tài)加載配置

// 初始化時加載配置
fetch('/config.js')
  .then(res => res.text())
  .then(script => {
    new Function(script)();  // 執(zhí)行 JS 代碼注入全局變量
    axios.defaults.baseURL = window.APP_CONFIG.API_BASE_URL;
  });

優(yōu)點

• 高度靈活：同一鏡像適配不同環(huán)境，僅需修改環(huán)境變量。
• 快速迭代：無需重新構(gòu)建鏡像即可調(diào)整配置。

缺點

• 復(fù)雜度高：需處理 Nginx 配置和動態(tài)腳本。
• 安全性注意：需防范配置信息泄露風(fēng)險。

適用場景

• 多環(huán)境部署（開發(fā)、測試、生產(chǎn)）。
• 需要頻繁修改后端地址的場景。

方案三：掛載外部配置文件（文件替換方式）

核心思想：將配置文件存儲在宿主機，通過 Docker 卷掛載到容器中，實現(xiàn)動態(tài)配置。

實現(xiàn)步驟

1. 創(chuàng)建外部配置文件

// 宿主機文件：./config/prod.js
window.APP_CONFIG = {
  API_BASE_URL: "http://backend:8080"
};

• 配置 docker-compose.yml

services:
  frontend:
    image: my-frontend-image
    volumes:
      - ./config/prod.js:/usr/share/nginx/html/config.js  # 掛載配置文件

• 前端代碼直接引用

// 直接訪問全局變量
axios.defaults.baseURL = window.APP_CONFIG.API_BASE_URL;

• Nginx 配置（需允許訪問配置文件）

server {
    location /config.js {
        add_header Cache-Control "no-cache";  # 禁用緩存
    }
}

優(yōu)點

• 直觀透明：配置文件可見且易維護。
• 靈活修改：直接編輯宿主機文件即可生效，無需重啟容器。

缺點

• 依賴宿主機文件：需確保文件路徑正確，且權(quán)限可控。
• 環(huán)境耦合：配置需與宿主機目錄綁定，遷移時需同步文件。

適用場景

• 配置項較多且需頻繁調(diào)整。
• 需要直接編輯配置文件的場景（如運維人員手動干預(yù)）。

方案對比總結(jié)

實戰(zhàn)建議

• 開發(fā)環(huán)境：推薦方案：運行時動態(tài)配置（API_BASE_URL=http://host.docker.internal:8080）。 理由：快速調(diào)整，無需重建鏡像。
• 生產(chǎn)環(huán)境：
  • 固定地址：構(gòu)建時注入（安全性優(yōu)先）。
  • 靈活需求：運行時動態(tài)配置 + CI/CD 環(huán)境變量注入。
• 復(fù)雜配置場景：推薦方案：掛載外部配置文件（如需要配置 API 密鑰、多服務(wù)地址等）。
• 混合方案：yaml

# docker-compose.yml
services:
  frontend:
    build:
      args:
        API_BASE_URL: "default_url"  # 默認值
    environment:
      API_BASE_URL: "overridden_url"  # 運行時覆蓋
    volumes:
      - ./config:/usr/share/nginx/html/config  # 掛載目錄

優(yōu)勢：默認值 + 動態(tài)覆蓋 + 文件掛載，三重保險。

結(jié)語 三種方案各有千秋：

• 構(gòu)建時注入適合“一次構(gòu)建，處處運行”的穩(wěn)定場景。
• 運行時動態(tài)配置是現(xiàn)代云原生應(yīng)用的標(biāo)配，平衡了靈活性與安全性。
• 掛載外部配置文件則在需要透明化管理或復(fù)雜配置時展現(xiàn)優(yōu)勢。

實際項目中，可根據(jù)團隊技術(shù)棧、運維習(xí)慣及安全要求靈活選擇，甚至組合使用！

以上就是在Docker中動態(tài)配置前端請求地址的三種方式的詳細內(nèi)容，更多關(guān)于Docker動態(tài)配置前端請求地址的資料請關(guān)注腳本之家其它相關(guān)文章！