还不懂Docker? 一文带你了解清楚!

4个月前发布 SanS三石
21 0 0

什么是Docker?

Docker 容器化技术是当今最重要的基础设施之一,或者说它已经成为服务程序 的标准化运行环境。

先不谈它相比传统的虚拟化技术有多少优势,站在软件工程角度,笔者认为,Docker 有两个重要的意义:

还不懂Docker? 一文带你了解清楚!

一)「提供一致性的运行环境。让我们的程序在一致性的环境中运行:不管是开发环境、测试环境、还是生产环境;不管是开发时、构建时、还是运行时」

比如开发时可以使用 Docker Dev Environments, 可以配合 VsCode Remote 开发,从而实现跳槽时或者换设备,可以快速 Setup 自己的开发环境。有兴趣的可以看看掘友写的 Docker化一个前端基础开发环境:简洁高效的选择

构建时,现在 CI/CD 平台都是基于 Docker 来提供多样化的构建环境需求。

运行时,‘巨轮’ K8S 已经是云时代的重要基础设施。

还不懂Docker? 一文带你了解清楚!

「二)标准化的服务程序封装技术。」

在没有容器之前,使用不同编程语言或框架编写的程序,部署和运行的方式千差万别。比如 Java 会生成 jar 包或者war 包,运行环境需要预装指定版本的 JDK…

而现在,容器镜像成为了标准的服务程序封装技术。镜像中包含了程序以及程序对运行环境的依赖。

还不懂Docker? 一文带你了解清楚!

不管前后端应用都可以使用镜像的形式进行分发和流通。这应该就是 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? 一文带你了解清楚!

接入其他构建平台也是类似的,「我们只需要学习对应平台如何构建镜像就行」

标准化部署和运行

上一节, 讲到将 Docker 作为‘跨平台’的任务执行环境。下一步就是发布、部署、运行。注意接下内容可能需要你对 K8S 有基本的了解。

镜像发布就不用展开说了,就和 npm 发布一样简单。本节的重点在于讨论,前端‘应用’在容器环境如何对外服务。

目前比较主流的前端应用可以分为三类:

  • 纯静态资源。
  • NodeJS 程序。包括 NodeJS 的纯后端服务、还有 NextJS、NuxtJS 这里 SSR 服务
  • 微前端。主要指「以基座为核心的中心化的微前端方案」, 比如 qiankun。这类程序需要基座和子应用相互搭配才能对外服务。

纯静态资源

估计 80% 以上的前端应用都是纯静态的。

笔者尝试过多种部署的方式。在我们将前端应用容器化的初期, 有过这样一种中间的演进形态:

还不懂Docker? 一文带你了解清楚!

在改造之前我们所有的前端静态资源都堆在一个静态资源服务器中(上图左侧),所有人都有部署权限、所有人都能改 Nginx 配置、目录混乱。部署方式也是各显神通,有 Jenkins 自动部署、有 FTP/rsync 手动上传… 就是一个极其原始的状态。

在容器化改造的初期,运维把静态资源服务器转换成为了 Nginx 容器,而原本 Nginx 的配置通过配置映射(Config Map)来挂载到容器内部。

前端应用也做了非常简单的改造, 就是简单把静态资源 COPY 到镜像中:

FROM busybox:latest

COPY dist /data

运行时,前端应用以 Nginx 容器的 Sidecar 形式存在,在启动时向共享的 PVC (数据卷)拷贝静态资源。


更理想的情况是每个前端应用能够独立对外服务, 对镜像的使用者来说,他应该是开箱即用的、自包含、透明的。

所以我们对部分比较独立的应用进行了重构:

还不懂Docker? 一文带你了解清楚!

如上图, 前端应用基于 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 示例。

微前端

我在微前端的落地和治理实战 中简单介绍过:

还不懂Docker? 一文带你了解清楚!

我们公司目前采用的是上图的 Sidecar 模式。每个子应用都是一个 Sidecar,启动时将自己‘注册’到基座中,由基座统一对外服务。

好处:基座可以统一管理所有子应用。比如可以实现‘子应用发现’、动态配置替换之类的工作

坏处:依赖 PVC 共享存储。我们也有遇到部分客户环境不支持共享 PVC 的。

对于不支持共享 PVC 的场景,我们也会进行回退:

还不懂Docker? 一文带你了解清楚!

让每个子应用独立对外服务,每个子应用都有自己的前缀, Ingress 根据前缀来分发流量。

好处就是子应用可以自己管理自己,升级和流量控制会更加灵活。缺点就是基座无法感知到这些子应用的存在,需要手动配置这些子应用的信息。

如果要更进一步,可以将基座定义为类似后端“注册中心”, 子应用主动向基座注册,有点后端微服务的味道了。如果真需要复杂到这一步,也没有必要自己造轮子,复用后端的技术栈不是更香?

除此之外,还有很多手段,比如基座提供发布服务,子应用调用基座发布服务,将自己的应用信息、静态资源提交给基座。

不是银弹

上面我们介绍了基于 Docker 容器的前端应用部署的各种方式和场景。但这并不是银弹!前端也不一定非得就要容器化。

很多大厂都有自己成熟的发布、部署流程和系统平台,他们需要应付各种复杂的情况, 比如大流量、CDN 同步、熔断降级、灰度发布、蓝绿发布,回滚… 那本文讲到的各种‘朴素’的技巧,就是一种雕虫小技

「那它对我们为什么有用?」

我们主要做 ToB 业务,容器化的方案可以应付私有化交付、私有化部署需求。开发和运维会面对各种千奇百怪的运行环境、公有云、私有云。但大部分甲方都会提供基础的 K8S 环境,容器化对我们来说就是一个最简单且高效的方案。

另外,依托于 K8S 这类强大容器管理平台,大部分问题都有解决方案,何必造轮子呢?

© 版权声明

相关文章

暂无评论

您必须登录才能参与评论!
立即登录
暂无评论...