前后端分离,如何在前端项目中动态插入后端API基地址?(in docker)
开门见山,本文分享前后端分离,容器化前端项目时动态插入后端API基地址,这是一个很赞的实践,解决了前端项目容器化过程中受制后端调用的尴尬。
尴尬从何而来
常见的web前后端分离:前后端分开部署,前端项目由nginx承载打包文件,反向代理请求。
应用的某些部分必须是可配置的,比如API调用基地址
,
前端打包的时候需要统一插入该地址形成完整chunk files。
# ------------------------------------------------------ # generate chunk file # ------------------------------------------------------ FROM node:10-alpine as builder # install and cache app dependencies COPY package.json package-lock.json ./ RUN npm install && mkdir /react-frontend && mv ./node_modules ./react-frontend WORKDIR /react-frontend COPY . . RUN npm run build # ------------------------------------------------------ # Production Build # ------------------------------------------------------ FROM nginx:latest COPY nginx.conf /etc/nginx/nginx.conf COPY --from=builder /react-frontend/build /usr/share/nginx/html EXPOSE 80 CMD ["nginx", "-g", "daemon off;"]
在Docker中打包前端,或许会尝试用镜像构建参数Arg/Env
来传递后端API调用基地址,但这样是很不理想的:
打包时参数被统一插入,打包结果chunk files作为最终镜像的一部分,导致最终的前端镜像会与后端API地址强关联。
或许你会针对不用的后端环境(canary、staging、production)构建不同的前端镜像,但这是一次又一次的工作量,并不是最佳实践。
下面分享一个容器执行阶段动态插入后端API基地址的实践
前端以容器形式独立部署,动态插入后端API基地址(in Docker)
我希望将API基地址延迟到生成容器
阶段(与构建镜像的过程解耦), 这样我就可以使用一个镜像,针对不同的环境传参形成不同的前端容器。
在前端配置中写入后端APi基地址API_BASE_URL
占位符,
// FILE: set-env.ts ... export const environment = { production: ${isProd}, apiBaseUrl: 'API_BASE_URL', version: 'v${require('../package.json').version}' }; ...
按照既定流程前端打包;
Dockerfile CMD指令指示容器如何运行:
- 用真实值替换前端chunk files中原插入的
API_BASE_URL
占位符 - 使用nginx承载替换后的chunk files
# FILE: Dockerfile ... EXPOSE 80 COPY --from=builder /react-frontend/replace_api_url.sh / CMD ["sh", "replace_api_url.sh"]
下面是replace_api_url.sh的内容:
#!/usr/bin/env sh find '/usr/share/nginx/html' -name '*.js' -exec sed -i -e 's,API_BASE_URL,'"$API_BASE_URL"',g' {} \; nginx -g "daemon off;"
为什么要加nginx -g "daemon off";
因为要让容器能持续运行, 必须要有前台进程,常规的nginx是后台守护进程,我们在 CMD 执行的以上 ["sh", "replace_api_url.sh"], 实际已经开始在执行进程,脚本执行完,进程退出, 容器也会退出;
这里要将nginx转为 前台进程。
sed -i 's/bj.name.vip.before.com/bj.name.last.com' /app/config.toml
将文件中原字符串 修改为 后者字符串
sed -i 's/bj.name.vip.before.com/bj.name.last.com' /app/config.toml
表示全文替换
我们在使用常规的nginx时, 为啥不需要这样写 : docker run -it -d nginx
呢?
因为 nginx官方dockerfile 内部已经指明使用前台进程。 https://github.com/nginxinc/docker-nginx/blob/master/Dockerfile-alpine.template
正常构建镜像之后;现在生成容器时,可通过环境变量传参替换原前端chunk files的API_BASE_URL字符串
docker build -t front . docker run -p 80:80 -e API_BASE_URL=http://somebackend.com/api front
总结输出
这是一个巧妙的设计,让我们在前端独立容器化部署时,能解耦后端API基地址,避免了一次又一次的构建镜像工作量。
Dockerfile CMD指令包装的容器启动脚本:让我们在nginx承载前端打包文件之前,做一次字符串替换,成功将后端API基地址“延迟”到容器运行阶段。
本文来自博客园,作者:{有态度的马甲},转载请注明原文链接:https://www.cnblogs.com/JulianHuang/p/13032240.html
欢迎关注我的原创技术、职场公众号, 加好友谈天说地,一起进化
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· DeepSeek 开源周回顾「GitHub 热点速览」
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布:重大改进与新特性概览!
· AI与.NET技术实操系列(二):开始使用ML.NET
· 单线程的Redis速度为什么快?