这是一个创建于 880 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们这边小公司，没有用公有云流水线和仓库。 用的是一个 4 核 8G 的机器跑 gitlab runner ，专门拉代码 做 docker build ，然后把 image push 到私有仓库。感觉时间用的有点长，不同的前端项目 14 分钟～ 30 分钟，后端项目 5 分钟左右。
今天看了一个前端部署流水线，docker build 时的 copy 操作，用了 660s ，没想明白为啥这么慢，代码仓库大小是 23M ，按道理代码仓库和 runner 机器都在一个内网网段，也没有网络瓶颈，ECS 监控看部署的时候，IOPS 才 200 次 /s ，远远没到机器云盘的上限 2400 次 /s 。不知道和 inode 快满了是不是有关系。
前端项目占用了很多 inode ，而且所有项目的 CI 没有做清理 image 的操作，有个 linux 定时任务，1 天清一次，但是同一天部署前端次数太多的话，inode 就满了，就得手动清理，也是很醉🐶
24 条回复
 |
1
wtfedc OP 排版乱了，尴尬
|
 |
2
yurong333333 2022-06-23 17:48:41 +08:00
我哭了，前公司采用的是刀耕火种的方式。
|
 |
3
darksword21 2022-06-23 17:50:34 +08:00 via iPhone
1 分钟，主要是 ci cd 的机器非常快
|
 |
4
colatea 2022-06-23 17:55:45 +08:00
试试 gogs,gitlab 比较耗资源
|
|
5
wtfedc OP @yurong333333 刀耕火种，一秒上线 :) 就是版本回退，麻烦点
|
 |
6
Jooooooooo 2022-06-23 17:56:35 +08:00
后端咋这么快...不一批一批机器分开发的吗?
|
 |
7
duke807 2022-06-23 17:58:00 +08:00 via Android
幾秒鐘吧
裸跑，不用 docker |
|
8
wtfedc OP @Jooooooooo 后端用的基础系统镜像和前端不太一样，是 14M 的 alpine linux ，装上一些依赖，只跑 go 的二进制，分发的 image 大小就 30 多 M ，k8s 集群拉的话也比较快
|
 |
9
sujin190 2022-06-23 18:24:10 +08:00  1
如果是前端如果已经编译完成之后 docker build 镜像慢的话，我们之前发现个问题，就是一般 docker build 会在项目根目录执行，npm 安装后的 node_modules 也会在根目录，docker build 的时候好像会 copy 文件到 docker domen context ，看日志特点就是 docker build 启动花了非常长的时间，启动之后开发 build 很快就完成了，这个问题就是 node_modules 文件太多，所以可以试试把编译出的文件 copy 到一个单独的目录，然后 docker build 就可以快非常多了
如果也是用 docker 编译的话，其实可以把项目目录和 node_modules 映射进去，估计能快不少吧 |
 |
10
hccsoul 2022-06-23 18:27:44 +08:00 1
nohup java -jar 🐶
|
 |
11
estk 2022-06-23 19:23:58 +08:00 via Android
push 到 git ，服务器自动拉取编译发布
|
 |
12
MineDog 2022-06-23 20:01:25 +08:00
9 楼说的有点道理，可以看看每个阶段时间，分析一下耗时集中在哪里
|
 |
13
ScepterZ 2022-06-23 20:14:16 +08:00
前公司的有些项目跑编译耗时要按小时计算，主要是编译机没做缓存，项目依赖实在是太多了，当时公司的源好像性能也不太行
|
 |
15
yhxx 2022-06-23 21:20:17 +08:00
前端半分钟左右，后端半天左右
|
 |
16
linchengzzz 2022-06-23 23:24:27 +08:00
试试加上 --production 来安装依赖，这样 node_modules 体积比较小
|
 |
17
Hstar 2022-06-24 00:03:45 +08:00 1
无论是前后端项目，打包镜像都可以大致分为两步：安装依赖，编译项目代码，第二步的时间开销难以避免，但第一步是可以通过本地缓存、镜像分层等手段来加速的。
至于具体的时间，部署的时间因为集群的原因不太可控，有时 1 分钟有时 5 分钟，但是构筑的时间都很稳定。一般前端 1~3 分钟看项目大小，后端不会超过 1 分钟，像 Python 项目没有编译过程的只用十秒，都是上传下载镜像花的时间。只有项目升级了依赖文件，构筑时间才会到 15 分钟以上。 缺点就是镜像机挂载的 10PB 硬盘过几个月就会满一遍，之前出了一次事故就是这个硬盘满了还没告警，全司的部署都卡死了。 |
 |
18
suyuyu 2022-06-24 00:18:30 +08:00
用啥 docker 问就是不会 doge
|
 |
19
NNNNzs 2022-06-24 09:56:40 +08:00
是不是 build 得时候把 node_modules 这些也 copy 过去了？碎文件确实会很慢
如果是可以尝试先在外面打包成压缩包 再在容器里面解压 还可以把 node_modules/.cache 文件夹删除在压缩 |
|
20
wtfedc OP add 操作下一步才是 npm run build ，进行 webpack 打包，看 CPU 占用不到整体（ 4 个核）的 50%。前端项目流水线部分日志：
#6 [initial 2/6] COPY --chown=node:node package.json package-lock.json /hom... #6 CACHED #7 [initial 3/6] COPY --chown=node:node script/ /home/node/code/script/ #7 CACHED #8 [initial 4/6] RUN cd /home/node/code && npm --registry https://registry-... #8 CACHED #9 [initial 5/6] ADD --chown=node:node . /home/node/code #9 DONE 662.5s ------手动切割线---------------- docker build 用的是下边的命令： DOCKER_BUILDKIT=1 docker build . -f ./deploy/Dockerfile-production --output type=local,dest=$OUTPUT_DIR 确实大多项目都在同一个目录 build ，等会尝试一下 9 楼老兄的方法，换一个目录进行 build ，再给大家反馈 |
 |
21
flighter 2022-06-24 10:17:52 +08:00
安装依赖，编译打包镜像 5 到 10 分钟吧，部署集群 1 到 5 分钟吧
|
|
22
wtfedc OP @NNNNzs node_modules 是在 docker copy 之后，再进行 npm install 生成的，压缩的话莫非在 git pre commit 这一步进行
|
|
23
wtfedc OP 不好意思 20 楼说错， 是在 docker add 命令前进行的 npm install ，node_modules 也用到了 cache
|
|
24
wtfedc OP 自己把自己绕糊涂了，我把整个 dockfile 贴出来：
+ FROM --私有库地址--/public/alpine-streamline-node:14.10.1 as initial USER node COPY --chown=node:node package.json package-lock.json /home/node/code/ COPY --chown=node:node script/ /home/node/code/script/ RUN cd /home/node/code && npm --registry https://--私有库地址--/ install ENV NODE_ENV production ADD --chown=node:node . /home/node/code RUN cd /home/node/code \ && cp consul.config.json.example consul.config.json \ && sed -i "/host/c \"host\": \"confsrv.smartstudy.com\"\," consul.config.json \ && sed -i "/env/c \"env\": \"production\"" consul.config.json \ && npm run gen:config \ && npm run build:pre FROM scratch as server COPY --from=initial /home/node/code/build / |
Select Language