什么是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 这类强大容器管理平台,大部分问题都有解决方案,何必造轮子呢?