AI 时代前端还要学 Docker & K8s 吗？我用一次真实部署经历说清楚

青晚舟2026-03-20 18:34

AI时代前端也能搞定部署！从CI/CD到Docker+K8s部署全流程实操（附真实项目经历）

最近跟不少前端朋友聊天，大家都有个共同的困惑：AI都能写代码、改Bug、甚至生成配置了，我们除了写页面，还能靠什么提升竞争力？

以前我也觉得，部署、运维都是后端或运维的活儿，前端只要把页面写漂亮、交互做流畅就够了。直到最近做项目，遇到了频繁上线出错、环境不一致的坑，才下定决心自己动手，从0到1配置CI/CD、编写Dockerfile、打包镜像，最后通过K8s部署成功。

全程踩了不少坑，但也真正明白：前端懂一点部署，不仅能解决工作中的实际麻烦，还能让自己的竞争力上一个台阶。今天就把我这段真实项目经历分享出来，手把手教大家前端如何搞定完整部署链路，新手也能跟着学、跟着做。

一、项目背景：为什么前端要自己搞部署？

这次做的是一个基于MonoRepo架构的Vue3+TS项目，团队不大，没有专门的运维，之前的部署流程全靠手动：

  1. 本地npm run build:console打包产物；2. 手动把dist文件夹上传到服务器；3. 后端帮忙配置nginx，重启服务。

看似简单，但问题越来越多：每次上线都要等后端有空，效率极低；本地打包正常，上传到服务器就报错（环境依赖不一致）；偶尔手抖传错文件，还得重新上传，特别麻烦。

加上项目迭代越来越快，几乎每天都要测试、上线，手动部署已经拖慢了进度。思来想去，与其一直依赖别人，不如自己搞定一套自动化部署流程------这就是我接触Docker、K8s和CI/CD的初衷。

先跟大家说句实话：不用怕，前端搞部署，不用精通运维知识，只要掌握核心流程和常用操作，就能轻松上手，AI还能帮我们省不少事。

二、第一步：编写Dockerfile，把前端项目"打包"成镜像

Docker的核心作用，就是把项目和它依赖的环境一起打包成一个"镜像"，不管是本地、测试服务器还是线上服务器，只要有Docker，就能一键运行，从根源上解决"我本地好好的，一上线就崩"的问题。

结合我这个Vue3项目，给大家分享一下我写的Dockerfile，以及编写时踩过的坑，新手可以直接参考套用。

2.1 编写Dockerfile（附详细注释）

在项目根目录下新建一个名为Dockerfile的文件（无后缀），内容如下，每一行都加了注释，大家一看就懂：

ini 复制代码 
# 第一步：选择基础镜像，这里用的是我们之前已经提前做好的一个node镜像里面已经安装好了node并发布到了Docker上
# as builder 的意思是为这个镜像启一个别名
FROM registry.cn-hangzhou.aliyuncs.com/xxx/frontend-project.aliyuncs.com/library/node:22.14.0.ossutil as builder

# 第二步：在 Docker 容器内部，创建并进入 `/code` 这个目录。 
# 后面所有命令（COPY、RUN、CMD）都会**默认在这个目录下执行**
WORKDIR /code 

# 把你本机项目根目录的所有文件，复制到容器里的 /code 目录。
COPY . /code  

# 第三步：设置git的代理并进行打包 安装pnpm 并进行打包

RUN npm config set registry https://registry.npmmirror.com && \
    npm install pnpm@10 -g && \
    pnpm i && \
    pnpm run build:console

# 第四步：创建一个基于nginx的容器
FROM registry.cn-hangzhou.aliyuncs.com/xxx/frontend-project.aliyuncs.com/library/nginx:1.27.4

    
# 注意：这里的builder就是第一个容器的别名 两个阶段的文件系统在 build 期间 Docker 都持有，所以可以互相取文件。第一阶段构建完之后不会立刻销毁，等第二阶段用完 COPY --from 之后才丢弃。这样做的好处是最终镜像里只有 nginx + 静态文件，没有 Node.js、源码、node_modules 这些东西，镜像体积会小很多。
COPY --from=builder /code/apps/dft-console-front/dist /usr/share/nginx/html




# 第五步：修改nginx镜像中的配置 因为现在的nginx的配置是默认的配置 如果你要设置代理，配置证书，负载均衡、动静分离等需要重写对应的配置 这里举例说明配置nginx的代理

RUN echo 'server {\n\
    listen       80;\n\
    listen  [::]:80;\n\
    server_name  localhost;\n\
\n\
    #access_log  /var/log/nginx/host.access.log  main;\n\
\n\
    # 代理后端接口\n\
    location /draftingee-structure {\n\
        proxy_pass http://xxx.xxx.xxx.xx:xxxx;\n\
        proxy_set_header Host $host;\n\
        proxy_set_header X-Real-IP $remote_addr;\n\
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n\
    }\n\
\n\
\n\
    # 前端静态资源（支持 history 模式路由）\n\
    location / {\n\
        root   /usr/share/nginx/html;\n\
        index  index.html index.htm;\n\
        try_files $uri $uri/ /index.html;\n\
    }\n\
\n\
    error_page   500 502 503 504  /50x.html;\n\
    location = /50x.html {\n\
        root   /usr/share/nginx/html;\n\
    }\n\
}' > /etc/nginx/conf.d/default.conf



# 暴露80端口（nginx默认端口）
EXPOSE 80

# 启动nginx服务
CMD ["nginx", "-g", "daemon off;"]

2.2 本地测试Docker镜像（关键一步，避免后续踩坑）

编写完Dockerfile和nginx.conf后，先在本地测试一下镜像能不能正常运行，避免上传到仓库后才发现问题。

步骤很简单，打开终端，进入项目根目录，执行以下命令（新手记这3条就够了）：

  1. 本地打包项目：npm run build:console（确保dist文件夹正常生成）；

  2. 构建Docker镜像：docker build -t frontend-project:v1.0 . （frontend-project是镜像名，v1.0是版本号，可自定义）；

  3. 运行镜像：docker run -d -p 8080:80 frontend-project:v1.0 （把容器的80端口映射到本地8080端口）；

运行成功后，打开浏览器访问http://localhost:8080，如果能正常看到项目页面，说明Dockerfile和nginx配置没问题！

这里需要注意的一个点是 如果你的Dockerfile里面配置的是公司自己私有的仓库地址 那么需要鉴权 比如我们是阿里云的私有仓库 那么就需要登录到阿里云上 找到下面这个图片的地方 根据提示先在自己的本地登录一下授权后在进行拉取

三、第二步：配置CI/CD，实现代码提交自动构建镜像

搞定了Docker镜像，接下来就是配置CI/CD------简单说，就是我们提交代码到Git仓库后，系统会自动帮我们打包项目、构建Docker镜像，然后推送到镜像仓库，不用再手动执行命令，彻底解放双手。

我用的是GitLab CI/CD（如果你们用GitHub，流程类似，用GitHub Actions即可），结合自己的项目，给大家分享具体配置步骤。

3.1 准备工作：注册镜像仓库

我们需要一个镜像仓库，用来存放构建好的Docker镜像（类似代码仓库存放代码），常用的有阿里云容器镜像服务、Docker Hub、GitLab自带的镜像仓库。

我用的是阿里云容器镜像服务，步骤很简单：注册阿里云账号，创建一个命名空间，再创建一个镜像仓库（比如命名为frontend-project），记录下仓库地址（比如registry.cn-hangzhou.aliyuncs.com/xxx/frontend-project），后续会用到。

3.2 配置GitLab CI/CD（核心步骤）

在项目根目录下新建.gitlab-ci.yml文件，这是CI/CD的配置文件，里面定义了代码提交后，系统要执行的一系列操作。

以下是我的配置文件，同样带详细注释，新手可以直接修改使用：

yaml 复制代码 
# 定义CI/CD流水线的阶段（顺序执行）
stages:
  - build # 第一步：构建Docker镜像

# 第一步：构建Docker镜像
docker_build:
  stage: docker_build
  image: docker:20.10.17 # 使用docker镜像，用于构建镜像
  services:
    - docker:20.10.17-dind # 启动docker服务
  dependencies:
    - build # 依赖build阶段的dist文件夹
  script:
    # 登录阿里云镜像仓库（用户名、密码在GitLab仓库设置中配置为环境变量，避免明文泄露）
    - docker login --username=$DOCKER_USERNAME --password=$DOCKER_PASSWORD registry.cn-hangzhou.aliyuncs.com
    # 构建镜像，镜像名要和镜像仓库地址一致，版本号用当前提交的commit哈希，避免重复
    - docker build -t registry.cn-hangzhou.aliyuncs.com/xxx/frontend-project:${CI_COMMIT_SHORT_SHA} .
  only:
    - master

# 第三步：推送镜像到镜像仓库
docker_push:
  stage: docker_push
  image: docker:20.10.17
  services:
    - docker:20.10.17-dind
  dependencies:
    - docker_build
  script:
    # 推送镜像到仓库
    - docker push registry.cn-hangzhou.aliyuncs.com/xxx/frontend-project:${CI_COMMIT_SHORT_SHA}
    # 可选：推送一个latest版本，方便后续部署时拉取最新镜像
    - docker tag registry.cn-hangzhou.aliyuncs.com/xxx/frontend-project:${CI_COMMIT_SHORT_SHA} registry.cn-hangzhou.aliyuncs.com/xxx/frontend-project:latest
    - docker push registry.cn-hangzhou.aliyuncs.com/xxx/frontend-project:latest
  only:
    - master

3.3 关键注意点（避坑必看）

  1. 环境变量配置：Docker仓库的用户名（DOCKER_USERNAME）和密码（DOCKER_PASSWORD），不要明文写在配置文件里，要在GitLab仓库的"设置→CI/CD→环境变量"中添加，这样更安全；

  2. 镜像版本号：我用的是Git提交的commit哈希（${CI_COMMIT_SHORT_SHA}），这样每个提交对应一个唯一的镜像版本，方便回滚；

  3. 测试CI/CD：配置完成后，提交一次代码到master分支，然后在GitLab的"CI/CD→流水线"中查看进度，如果所有阶段都显示"成功"，说明CI/CD配置没问题，镜像已经成功推送到仓库了！

四、第三步：通过K8s拉取镜像，完成最终部署

搞定了Docker镜像和CI/CD，最后一步就是通过K8s拉取镜像，完成项目部署。很多前端朋友一听到K8s就觉得复杂，其实对前端来说，我们不用掌握K8s的全部功能，只要会编写简单的配置文件，能拉取镜像、启动服务就够了。

前提：你的服务器已经部署好了K8s集群（如果是测试，也可以搭建k3s配置文件跟k8s一样没有什么区别 k3s安装地址 ）。

4.1 编写K8s部署配置文件（deployment.yaml）

在项目根目录下新建deployment.yaml文件，用于定义K8s如何拉取镜像、启动容器，内容如下（带注释）：

yaml 复制代码 
apiVersion: apps/v1
kind: Deployment # 资源类型：Deployment，用于管理Pod的创建和更新
metadata:
  name: dft-console-front-712  # Deployment名称，可自定义
  namespace: zhip # 命名空间，默认用default即可 （一般情况每个人都有单独的分支 默认的分支为default ）
spec:
  replicas: 1 # 启动1个Pod（容器实例），可根据需求增加
  selector:
    matchLabels:
      app: dft-console-front-712 # 匹配Pod的标签，和下面的template.metadata.labels一致
  template:
    metadata:
      labels:
        app: dft-console-front-712
    spec:
      containers:
        - name: dft-console-front-712 # 容器名称，可自定义
          image: fm-container-registry.cn-beijing.cr.aliyuncs.com/draftingee/console-front:v3.0.90292359 # 镜像地址，和我们推送到仓库的一致
          ports:
            - containerPort: 80 # 容器内部端口，和Dockerfile中暴露的80端口一致
      imagePullSecrets:
        - name: registry-secret
# 由于我这是纯前端的容器就不需要磁盘映射了 更新的话直接替换镜像即可

4.2 编写K8s服务配置文件（service.yaml）

光有Deployment还不够，我们需要通过Service暴露服务，让外部能访问到K8s集群中的容器，新建service.yaml文件：

yaml 复制代码 
apiVersion: v1
kind: Service # 资源类型：Service
metadata:
  name: frontend-project-service # Service名称，可自定义
  namespace: default
spec:
  type: NodePort # 暴露服务的方式，NodePort适合测试，生产环境可用LoadBalancer
  selector:
    app: frontend-project # 匹配Deployment中的Pod标签
  ports:
  - port: 80 # Service端口
    targetPort: 80 # 映射到容器的80端口
    nodePort: 30080 # 外部访问端口（范围30000-32767，可自定义）

4.3 执行K8s命令，完成部署

将deployment.yaml和service.yaml两个文件上传到K8s集群的服务器（或本地Minikube环境），然后执行以下命令，一步步完成部署：

  1. 部署Deployment：kubectl apply -f deployment.yaml；

  2. 部署Service：kubectl apply -f service.yaml；

  3. 查看Deployment状态：kubectl get deployments，看到READY为1/1，说明部署成功；

  4. 查看Pod状态：kubectl get pods，看到STATUS为Running，说明容器正常运行；

  5. 查看Service状态：kubectl get services，看到frontend-project-service的EXTERNAL-IP为，NodePort为30080；

最后，打开浏览器，访问http://服务器IP:30080，就能看到我们部署好的前端项目了！

4.4 部署过程中踩过的坑

  1. 镜像拉取失败：一开始忘记给K8s配置阿里云镜像仓库的凭证，导致拉取镜像时提示权限不足。解决方法：在K8s中创建secret，存储Docker仓库的用户名和密码，然后在deployment.yaml中引用secret；

    • 更新srcret命令 kubectl create secret docker-registry registry-secret --docker-server=Docker地址 --docker-username=用户名 --docker-password=密码

  2. 端口冲突：一开始把nodePort设为80，导致和服务器上的nginx端口冲突，改成30080后正常

  3. 如何在k8s更新镜像

五、总结：前端搞部署，收获的不只是技能

从配置CI/CD、编写Dockerfile，到打包镜像、K8s部署成功，整个过程我用了3天时间，踩了不少坑，但当最后在浏览器中看到部署好的项目时，那种成就感真的难以形容。

很多前端朋友会问：AI都能生成Dockerfile、YAML配置了，我们还有必要自己学吗？

我的答案是：有必要，但不用精通。AI能帮我们写配置、拼命令，但它替代不了我们对整个部署链路的理解，替代不了我们排查问题的能力。就像这次部署，AI能生成配置文件，但当出现镜像拉取失败、端口冲突时，还是需要我们自己去分析问题、解决问题。

对前端来说，Docker和K8s不是必学的"硬技能"，但却是能让你脱颖而出的"加分项"：

  1. 不用再依赖后端/运维部署，自己就能掌控项目上线，效率大幅提升；

  2. 理解了从开发到上线的完整链路，考虑问题会更全面，写代码时也会更注重环境兼容性；

  3. 在团队中，能独立搞定部署，会让你更有话语权，也能为自己的职业发展拓宽道路。

最后想跟大家说：不用害怕接触自己不熟悉的领域，前端的边界从来不是写页面，而是不断学习、不断突破。AI时代，我们要做的不是被工具替代，而是学会利用工具，提升自己的核心竞争力。

如果你也想尝试前端部署，不妨从编写第一个Dockerfile开始，一步步来，你会发现，原来部署也没那么难～

相关推荐
星浩AI2 小时前
现在最需要被 PUA 的，其实是 AI
人工智能·后端·github
墨鱼笔记2 小时前
不使用微前端：如何实现主应用和子模块动态管理与通信实现
前端
兆子龙2 小时前
前端工程师转型 AI Agent 工程师：后端能力补全指南
前端·javascript
长安11082 小时前
web后端----HTTP协议与浏览器F12
前端·网络协议·http
前端大波2 小时前
Web Vitals 与前端性能监控实战
前端·javascript
AlienZHOU3 小时前
从零开始，跟着写一个产品级 Coding Agent
前端
RichardZhiLi3 小时前
大前端全栈实践课程：章节二（前端工程化建设）
前端
毕设源码-赖学姐3 小时前
【开题答辩全过程】以 基于VUE的环保网站设计为例，包含答辩的问题和答案
前端·javascript·vue.js
热门推荐
01GitHub 镜像站点02Qwen3.5 开源全解析：从 0.8B 到 397B，代际升级 + 全场景选型指南03OpenClaw 使用和管理 MCP 完全指南04Labelme从安装到标注：零基础完整指南05AI 编程三剑客：Spec-Kit、OpenSpec、Superpowers 深度对比与实战指南06UV安装并设置国内源07小黑课堂计算机二级WPSoffice题库软件下载安装教程（2026年3月最新版）08OpenClaw Control UI安全上下文访问配置09Claude Code + GLM4.7 避坑指南：解决 Unable to connect to Anthropic services10让 Trae IDE 智能体 “读懂”文档 Excel+PDF+DOCX ：mcp-documents-reader 工具使用指南