什么是Docker?
Docker 容器化技术是当今最重要的基础设施之一，或者说它已经成为服务程序 的标准化运行环境。
先不谈它相比传统的虚拟化技术有多少优势，站在软件工程角度，笔者认为，Docker 有两个重要的意义：
一）「提供一致性的运行环境。让我们的程序在一致性的环境中运行：不管是开发环境、测试环境、还是生产环境；不管是开发时、构建时、还是运行时」。
比如开发时可以使用 Docker Dev Environments, 可以配合 VsCode Remote 开发，从而实现跳槽时或者换设备，可以快速 Setup 自己的开发环境。有兴趣的可以看看掘友写的 Docker化一个前端基础开发环境：简洁高效的选择
构建时，现在 CI/CD 平台都是基于 Docker 来提供多样化的构建环境需求。
运行时，‘巨轮’ K8S 已经是云时代的重要基础设施。
「二）标准化的服务程序封装技术。」
在没有容器之前，使用不同编程语言或框架编写的程序，部署和运行的方式千差万别。比如 Java 会生成 jar 包或者war 包，运行环境需要预装指定版本的 JDK…
而现在，容器镜像成为了标准的服务程序封装技术。镜像中包含了程序以及程序对运行环境的依赖。
不管前后端应用都可以使用镜像的形式进行分发和流通。这应该就是 Docker Logo，那条鲸鱼驮着货运箱的解释吧：就像我们平时下载、传递 Zip 文件一样， 镜像是云时代’通用货币’，可以在研发的不同环节、区域中流通。
这种标准化的打包格式、轻量化的运行时，不仅给开发者和运维带来便利， 也催生了强大的容器管理工具比如 K8S, 「K8S 现在已经是容器和集群管理的标准。」
「那 Docker 之于前端意义是啥？」
Docker 对前端的意义也很重大。实际上，Docker 的世界里，并不区分什么前端、后端，没有人说只适合后端、不适合前端 … 在运维的眼里更是如此
为了照顾那些不太懂 Docker 的开发者，本文会循序渐进、由浅入深地讲解。如果你需要 Docker 入门教程，推荐你看看 Docker —— 从入门到实践
主要分成三个部分：
- 标准化的 CI/CD。讲讲怎么基于 Docker 来构建前端应用，这里提出了一个重要的观点：就是基于 Dockerfile 来实现 ‘跨 CI/CD’ 的任务执行，我们可以在 Dockerfile 中执行各种任务，包括环境初始化、单元测试、构建等等
- 标准化部署和运行。怎么部署基于 Docker 的前端应用，包括静态资源、NodeJS 程序、微前端。
- 一些高级的话题。讲讲容器化后的前端应用怎么实现 ’「一份基准代码，多份部署」‘、灰度发布、蓝绿发布等高级发布需求。
标准化CI/CD
市面上有很多 CI/CD 产品，比如 GitLab、Github Action、Jenkins、Zadig… 它们的构建配置、脚本语法差异都挺大，基本上是不能共用的。
比如我们公司前不久引入了 Zadig，原本基于 Jenkinks 的构建配置几乎需要重新适配。
**有没有跨‘平台’的方式？**于是，我开始探索将前端 CI/CD 的流程完全集成到 Docker 镜像构建中去。
从简单的单元测试开始
我们先从简单的任务开始。先来写一个简单的单元测试：
FROM node:20-slim
# pnpm 安装
RUN corepack enable
# 拷贝源代码
COPY . /app
WORKDIR /app
#安装依赖
RUN pnpm install
# 执行测试
RUN pnpm test
corepack? NodeJS 的包管理碎片化越来越验证了，以前我们区分 npm、yarn、pnpm, 现在还要继续分裂版本，pnpm v7、pnpm v8…
NodeJS 官方推出的 Corepack 应该可以救你一命
别忘了 .dockerignore
node_modules
.git
.gitignore
*.md
dist
为什么不能遗漏 .dockerignore 呢？
构建运行：
$ docker build . –progress=plain
#1 [internal] load build definition from Dockerfile.for_test
#1 transferring dockerfile: 40B done
#1 DONE 0.0s
#2 [internal] load .dockerignore
#2 transferring context: 34B done
#2 DONE 0.0s
#3 [internal] load metadata for docker.io/library/node:20-slim
#3 DONE 1.5s
#4 [1/6] FROM docker.io/library/node:20-slim@sha256:6eea4330e89a0c6a8106d0bee575d3d9978b51aac16ffe7f6825e78727815631
#4 CACHED
#5 [internal] load build context
#5 transferring context: 227B done
#5 DONE 0.0s
#6 [2/6] RUN corepack enable
#6 DONE 0.2s
#7 [3/6] COPY . /app
#7 DONE 0.0s
#8 [4/6] WORKDIR /app
#8 DONE 0.0s
#9 [5/6] RUN pnpm install
#9 4.878 Lockfile is up to date, resolution step is skipped
#9 4.880 Progress: resolved 1, reused 0, downloaded 0, added 0
#9 4.881 Packages: +1
#9 4.881 +
#9 6.603 Progress: resolved 1, reused 0, downloaded 1, added 0
#9 6.643 Packages are hard linked from the content-addressable store to the virtual store.
#9 6.643 Content-addressable store is at: /root/.local/share/pnpm/store/v3
#9 6.643 Virtual store is at: node_modules/.pnpm
#9 6.659
#9 6.659 dependencies:
#9 6.659 + lodash 4.17.21
#9 6.659
#9 6.661 Done in 2s
#9 7.608 Progress: resolved 1, reused 0, downloaded 1, added 1, done
#9 DONE 7.7s
#10 [6/6] RUN pnpm test
#10 0.497 测试通过
#10 DONE 0.5s
#11 exporting to image
#11 exporting layers
#11 exporting layers 0.2s done
#11 writing image sha256:9d61ce0fd5d96685aa62fb268db37b3dea4cfa1699df73d8d6a7de259c914a8d done
#11 DONE 0.2s
二次运行的结果：
#1 [internal] load build definition from Dockerfile.for_test
#1 transferring dockerfile: 40B done
#1 DONE 0.0s
#2 [internal] load .dockerignore
#2 transferring context: 34B done
#2 DONE 0.0s
#3 [internal] load metadata for docker.io/library/node:20-slim
#3 DONE 3.2s
#4 [1/6] FROM docker.io/library/node:20-slim@sha256:6eea4330e89a0c6a8106d0bee575d3d9978b51aac16ffe7f6825e78727815631
#4 DONE 0.0s
#5 [internal] load build context
#5 transferring context: 227B done
#5 DONE 0.0s
#6 [2/6] RUN corepack enable
#6 CACHED <- 缓存了
#7 [4/6] WORKDIR /app
#7 CACHED
#8 [3/6] COPY . /app
#8 CACHED
#9 [5/6] RUN pnpm install
#9 CACHED
#10 [6/6] RUN pnpm test
#10 CACHED <- 缓存了
…
Docker 镜像是多层存储的， 每一层是在前一层的基础上进行的修改。换句话说， Dockerfile 文件中的每条指令(Instruction)都是在构建新的一层。
Docker 使用了缓存来加速镜像构建，所以上面执行结果可以看出只要上一层和当前层的输入没有变动，那么执行结果就会被缓存下来。
现在你可以随便更动 src/* 或者 package.json , 再执行构建，会发现，从 COPY 指令那里重新开始执行了：
# …
#3 [internal] load metadata for docker.io/library/node:20-slim
#3 DONE 1.3s
#4 [1/6] FROM docker.io/library/node:20-slim@sha256:75404fc5825f24222276501c09944a5bee8ed04517dede5a9934f1654ca84caf
#4 DONE 0.0s
#5 [internal] load build context
#5 transferring context: 525B done
#5 DONE 0.0s
#6 [2/6] RUN corepack enable
#6 CACHED
# 变更点
#7 [3/6] COPY . /app
#7 DONE 0.0s
#8 [4/6] WORKDIR /app
#8 DONE 0.0s
#9 [5/6] RUN pnpm install
#….
也就是，又从 0 开始进行 pnpm install …
缓存处理
前端构建会深度依赖缓存来加速，比如 node_modules、Webpack 的模块缓存、vite 的 prebundle、Typescript 的 tsBuildInfoFile …
上面从零开始 pnpm install 显然是无法接受的。每次都是从头开始，构建的过程会变得很慢。有什么解决办法呢?
「解决办法 1）利用 Docker 分层缓存」
pnpm 依赖的安装，其实只需要 package.json、pnpm-lock.yaml 等文件就够了，那我们是不是可以把 COPY 拆分从两步？采用动静分离策略，分离 package.json 和源代码的变更。毕竟 package.json 的变更频率要低得多：
FROM node:20-slim
RUN corepack enable
WORKDIR /app
# 拷贝依赖声明
COPY package.json pnpm-lock.yaml /app/
RUN pnpm install
# 拷贝源代码
COPY . /app
RUN pnpm test
「解决办法 2） RUN 挂载缓存」
方案1 还是有很多缺陷，比如 package.json 只要变动一个字节，都会导致 pnpm 重新安装。能不能在运行 build 的时候挂载缓存目录进去？把 node_modules 或者 pnpm store 缓存下来？
Docker build 确实支持挂载(BuildKit, 需要 Docker 18.09+)。以下是缓存 pnpm 的示例(来自官方文档)：
FROM node:20-slim
RUN corepack enable
WORKDIR /app
# 拷贝依赖声明
ENV PNPM_HOME=”/pnpm”
ENV PATH=”$PNPM_HOME:$PATH”
COPY package.json pnpm-lock.yaml /app/
# 挂载缓存
RUN –mount=type=cache,id=pnpm,target=/pnpm/store pnpm install
# 拷贝源代码
COPY . /app
RUN pnpm test
你也可以通过设置 DOCKER_BUILDKIT=1 环境变量来启用 BuildKit
RUN —mount 参数可以指定要挂载的目录，对应的缓存会存储在宿主机器中。这样就解决了 Docker 构建过程的外部缓存问题。
同理其他的缓存，比如 vite、Webpack，也是通过 —mount 挂载。一个 RUN 支持指定多个 —mount
因为采用挂载形式，这种跨设备会导致 pnpm 回退到拷贝模式(pnpm store → node_modules)，而不是链接模式，所以安装性能会有所损耗。
如果是 npm 通常需要缓存 ~/.npm 目录
多阶段构建
假设我们要在原有单元测试的基础上，加入编译任务。并且要求两个命令支持「独立执行」，比如在代码 commit 到远程仓库时只执行单元测试，发布时才执行单元测试 + 编译。
第一种解决办法就是创建两个 Dockerfile， 这个方案的缺点就是指令重复(比如 pnpm 安装依赖)。另一个缺点就是如果任务之间有依赖或文件交互，那么整合起来也会比较麻烦。
更好的办法就是多阶段构建（Multi-Stage）。Docker 允许将多个构建步骤整合在一个 Dockerfile 文件中，这个构建步骤之间可以存在依赖关系，也可以进行文件传递，还可以更好地利用缓存。
# 阶段 1，安装依赖
FROM node:20-slim as base
RUN corepack enable
WORKDIR /app
ENV PNPM_HOME=”/pnpm”
ENV PATH=”$PNPM_HOME:$PATH”
# 拷贝依赖声明
COPY package.json pnpm-lock.yaml /app/
RUN –mount=type=cache,id=pnpm,target=/pnpm/store pnpm install
# 阶段 2，单元测试
FROM base as test
# 拷贝源代码
COPY . /app
RUN pnpm test
# 阶段 3，构建
FROM test as build
RUN pnpm build
通过 FROM * as NAME 的形式创建一个阶段。FROM 可以指定依赖的其他步骤。
现在我们运行:
$ docker build .
默认会执行最后一个阶段。即 build。
如果我们只想跑 test，可以通过 —target 参数指定:
$ docker build –target=test .
我们再来看一个典型的复杂例子，Nextjs 程序构建：
FROM node:19-alpine AS base
# 0. 构建依赖, 为什么要分开一步构建依赖呢，这是为了利用 Docker 的构建缓存
FROM base AS deps
RUN apk add –no-cache libc6-compat
WORKDIR /app
COPY package.json .npmrc pnpm-lock.yaml* ./
RUN npm i -g pnpm@7 && pnpm install
# 1. 第一步构建编译
FROM base AS builder
WORKDIR /app
# COPY 依赖
COPY –from=deps /app/node_modules /app/node_modules
# COPY 源代码
COPY . .
# COPY .env.production.sample .env.production
RUN env && ls -a && npm run build
# 2. 第二步，运行
FROM base AS runner
ENV NODE_ENV production
# Uncomment the following line in case you want to disable telemetry during runtime.
# ENV NEXT_TELEMETRY_DISABLED 1
RUN addgroup –system –gid 1001 nodejs
RUN adduser –system –uid 1001 nextjs
WORKDIR /app
COPY –from=builder –chown=nextjs:nodejs app/public /app/public
COPY –from=builder –chown=nextjs:nodejs app/.next/standalone /app
COPY –from=builder –chown=nextjs:nodejs app/.next/static /app/.next/static
USER nextjs
EXPOSE 3000
ENV PORT 3000
CMD [“node”, “server.js”]
多阶段构建的另一个好处是隐藏构建的细节: 比如上游构建的过程中传递的一些敏感信息、隐藏源代码等。
在上面的 Next.js 例子中， 最终构建的是 runner, 它从 builder 中拷贝编译的结果，对最终的镜像使用者来说，是查看不到 builder 的构建细节和内容的。
构建参数
程序在构建时可能会有一些微调变量，比如调整 Webpack PublicPath、编译产物的目标平台、调试开关等等。
在 DockerFile 下可以通过 ARG 指令来声明构建参数 ：
# 声明构建参数，支持默认值
ARG DOCKER_USERNAME=library
# 可以在 DockerFile 中作为 模板变量 使用
FROM ${DOCKER_USERNAME}/alpine
# 打印 library
RUN echo ${DOCKER_USERNAME}
# 打印 包含 DOCKER_USERNAME=library
RUN env
ARG 和 ENV 的效果一样，都是设置「环境变量」。不同的是，ARG 所设置是构建时的环境变量，在将来容器运行时是不会存在这些环境变量的。
注意，尽量不要在 ARG 放置敏感信息，因为 docker history 可以看到构建的过程
通过 docker build –build-arg Key=[Value] 设置构建参数：
$ docker build –build-arg BABEL_ENV=test .
# 或者只指定 KEY, Value 自动获取
$ docker build –build-arg BABEL_ENV .
怎么支持更复杂的构建需求？
Dockerfile 中不建议放置复杂的逻辑，而且它语法支持也很有限。如果有复杂的构建需求，更应该通过 Shell 脚本或者 Node 程序来实现。
集成到 CI/CD 平台
上文，我们探索了使用 Docker 来实现‘跨平台’(CI/CD) 的构建任务。看起来还不错，应该能够满足我们的需求。
通常这些平台对 Docker 镜像构建的支持都是开箱即用的， 如果使用 Dockerfile 方案，我们可以免去一些额外的声明，比如构建依赖的软件包、缓存配置、构建脚本等等。
现在只需要关注 Dockerfile 构建， 下图以 Zadig 为例。在 Zadig 中，我们只需要告诉 Dockerfile 在哪，其余的工作(比如镜像 tag、镜像发布)都不需要操心：
接入其他构建平台也是类似的，「我们只需要学习对应平台如何构建镜像就行」。
标准化部署和运行
上一节， 讲到将 Docker 作为‘跨平台’的任务执行环境。下一步就是发布、部署、运行。注意接下内容可能需要你对 K8S 有基本的了解。
镜像发布就不用展开说了，就和 npm 发布一样简单。本节的重点在于讨论，前端‘应用’在容器环境如何对外服务。
目前比较主流的前端应用可以分为三类：
- 纯静态资源。
- NodeJS 程序。包括 NodeJS 的纯后端服务、还有 NextJS、NuxtJS 这里 SSR 服务
- 微前端。主要指「以基座为核心的中心化的微前端方案」， 比如 qiankun。这类程序需要基座和子应用相互搭配才能对外服务。
纯静态资源
估计 80% 以上的前端应用都是纯静态的。
笔者尝试过多种部署的方式。在我们将前端应用容器化的初期， 有过这样一种中间的演进形态：
在改造之前我们所有的前端静态资源都堆在一个静态资源服务器中(上图左侧)，所有人都有部署权限、所有人都能改 Nginx 配置、目录混乱。部署方式也是各显神通，有 Jenkins 自动部署、有 FTP/rsync 手动上传… 就是一个极其原始的状态。
在容器化改造的初期，运维把静态资源服务器转换成为了 Nginx 容器，而原本 Nginx 的配置通过配置映射（Config Map）来挂载到容器内部。
前端应用也做了非常简单的改造， 就是简单把静态资源 COPY 到镜像中：
FROM busybox:latest
COPY dist /data
运行时，前端应用以 Nginx 容器的 Sidecar 形式存在，在启动时向共享的 PVC (数据卷)拷贝静态资源。
更理想的情况是每个前端应用能够独立对外服务， 对镜像的使用者来说，他应该是开箱即用的、自包含、透明的。
所以我们对部分比较独立的应用进行了重构：
如上图， 前端应用基于 nginx 运行，流量会通过 Ingress 来分发到不同的应用，分发的方式通常有域名、请求路径等等。
这也进一步简化了运维的工作，运维只需要前端后两个镜像就可以将一套系统部署起来。
我们稍微改造一下上文的 Dockerfile 来支持 nginx 部署：
# 阶段 1，安装依赖
FROM node:20-slim as base
RUN corepack enable
WORKDIR /app
ENV PNPM_HOME=”/pnpm”
ENV PATH=”$PNPM_HOME:$PATH”
# 拷贝依赖声明
COPY package.json pnpm-lock.yaml /app/
RUN –mount=type=cache,id=pnpm,target=/pnpm/store pnpm install
# 阶段 2，单元测试
FROM base as test
# 拷贝源代码
COPY . /app
RUN pnpm test
# 阶段 3，构建
FROM test as build
RUN pnpm build
# 阶段 4，运行
FROM nginx:stable-alpine as deploy
COPY –from=build /app/dist/ /usr/nginx/wwwroot
# 如果需要自定义 nginx 配置，可以开启这行
#COPY nginx.conf /etc/nginx/nginx.conf
EXPOSE 80
CMD [“nginx”, “-g”, “daemon off;”]
NodeJS 程序
这个和普通后端服务没什么区别，狭义上不属于前端的范畴，没有太多可以讲的，可以参考上文的 Next.js 示例。
微前端
我在微前端的落地和治理实战 中简单介绍过：
我们公司目前采用的是上图的 Sidecar 模式。每个子应用都是一个 Sidecar，启动时将自己‘注册’到基座中，由基座统一对外服务。
好处：基座可以统一管理所有子应用。比如可以实现‘子应用发现’、动态配置替换之类的工作
坏处：依赖 PVC 共享存储。我们也有遇到部分客户环境不支持共享 PVC 的。
对于不支持共享 PVC 的场景，我们也会进行回退：
让每个子应用独立对外服务，每个子应用都有自己的前缀， Ingress 根据前缀来分发流量。
好处就是子应用可以自己管理自己，升级和流量控制会更加灵活。缺点就是基座无法感知到这些子应用的存在，需要手动配置这些子应用的信息。
如果要更进一步，可以将基座定义为类似后端“注册中心”， 子应用主动向基座注册，有点后端微服务的味道了。如果真需要复杂到这一步，也没有必要自己造轮子，复用后端的技术栈不是更香？
除此之外，还有很多手段，比如基座提供发布服务，子应用调用基座发布服务，将自己的应用信息、静态资源提交给基座。
不是银弹
上面我们介绍了基于 Docker 容器的前端应用部署的各种方式和场景。但这并不是银弹！前端也不一定非得就要容器化。
很多大厂都有自己成熟的发布、部署流程和系统平台，他们需要应付各种复杂的情况, 比如大流量、CDN 同步、熔断降级、灰度发布、蓝绿发布，回滚… 那本文讲到的各种‘朴素’的技巧，就是一种雕虫小技
「那它对我们为什么有用？」
我们主要做 ToB 业务，容器化的方案可以应付私有化交付、私有化部署需求。开发和运维会面对各种千奇百怪的运行环境、公有云、私有云。但大部分甲方都会提供基础的 K8S 环境，容器化对我们来说就是一个最简单且高效的方案。
另外，依托于 K8S 这类强大容器管理平台，大部分问题都有解决方案，何必造轮子呢？
相关文章
萌ICP备20240170号