1. 遇到的问题 项目介绍: 文件大小 5.6 GB 文件数量 529352 Dockerfile 1 2 3 FROM golang:1.13 COPY ./ /go/src/code 构建命令及输入如下: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 time DOCKER_BUILDKIT=1 docker build --no-cache -t test:v3 -f Dockerfile . --progress=plain #1 [internal] load build definition from Dockerfile #1 sha256:2a154d4ad813d1ef3355d055345ad0e7c5e14923755cea703d980ecc1c576ce7 #1 transferring dockerfile: 37B done #1 DONE 0.1s #2 [internal] load .dockerignore #2 sha256:9598c0ddacf682f2cac2be6caedf6786888ec68f009c197523f8b1c2b5257b34 #2 transferring context: 2B

不同于 CentOS、Ubuntu，我们感受到 mv 比 cp 快；在使用 Dockerfile 构建镜像时，使用 Run cp 会比 Run mv 更快。本篇将给出相关的一些测试、验证的数据结果。 1. 测试准备 机器环境 Ubuntu 20.04.1 LTS 32C 125Gi 由于是生产机器，上面会有些负载，因此测试会有偏差。我会多次测试，等结果稳定

非分阶段构建场景下，使用容器进行构建时，我们可以将容器中的缓存目录挂载到构建主机上，执行构建任务；然后将产物拷贝到运行镜像，制作应用镜像。但是在分阶段构建时，构建镜像和运行镜像在同一个 Dockerfile 中，这给优化第三方依赖的缓存带来了难度。 1. 创建一个 Vue 实

1. SSH 连接方向: Master 主动连接 Agent 要求: Master 能通过 SSH 直连 Agent Agent 上启动了 SSHD 服务 Jenkins 安装 SSH Credentials Plugin、SSH Build Agents 插件 2. JNLP 连接方向: Agent 主动连接 Master 要求: Agent 能访问 Master Agent 需要 JVM 环境运行 Master 需要放开 50000（默认值）端口用于 Agent 通信 50000 端口是 Jenkins Master 的服务端口，不需要再运行

1. 问题背景 在 Jenkins 中添加了很多个构建节点使用同一个 Label 以供流水线使用，但是 Jenkins 却每次都倾向于在同一个节点进行构建。 这导致了并发问题，单个节点的压力过大，而其他节点空闲，负载极其不均衡。 2. 业务流水线的设计 上述问题的产生和业务流水线的设计有一定的关系。