前端运维踩坑实录（diss自己的上篇文章）构建在jenkin触发docker build -t ${IMAGE_NAME

首先上篇文章写了一个最简单版本的发布部署脚本，但是发到环境上跑的时候问题发下了很多

1 我家运维给的机器是1核1G的（哭了），直接导致了构建时间过长，服务器直接报警钉钉

2 之前文章里面发布部署代码耦合在一起，在准备打通jenkins部署的时候发现极大的问题

##!/usr/bin/env bash
CONTAINER_NAME=CONTAINER_NAM
IMAGE_NAME=CONTAINER_NAM

echo "正在重新部署 ${CONTAINER_NAME}"

# #停止正在运行的容器
docker stop ${CONTAINER_NAME}

# #删除旧容器
docker rm -f ${CONTAINER_NAME}

# #删除image，确保下载的是最新镜像
docker rmi ${IMAGE_NAME}

# #重新构建
docker build -t ${IMAGE_NAME} .

#下载最新镜像并启动
docker run -d -p 4900:80 --name ${CONTAINER_NAME} ${IMAGE_NAME}

echo "容器 ${CONTAINER_NAME} 重新部署成功"

光是上面两个问题就已经无法忍受了，所以要实现以下改变

首先构建和部署的分离

大致构思

构建在jenkin触发docker build -t ${IMAGE_NAME} .

构建完成后打包对应镜像 docker save -o ${IMAGE_NAME}.tar ${IMAGE_NAME}

jenkins在构建触发器之后将镜像传输到对应的部署机器然后加载对应镜像包 docker load --input ${IMAGE_NAME}.tar

然后重新启动容器docker run -d -p 80:80 --name ${CONTAINER_NAME} ${IMAGE_NAME}

其次是优化构建部署的速度

首先是构建速度

需要对对应拉取的node镜像执行优化（这里内容比较多，后面准备出一个文章，这里就先带过）

webpack的执行速度，我这里比较暴力，直接使用happypack（happy的原理也很好玩，后期也准备出文章）获取jenkins机器的信息，直接多线程开启，最大化的占用了机器性能（同事每次的构建任务都很慢，他们疑惑的时候，我只能憋住笑容）

其次是部署速度

这里是要对对应文件的筛选传输，过滤不需要的文件，直接获取需要的文件传输，docker run image几乎是秒级，这里最最最重要的还是对文件传输进行优化