用前端姿势玩docker【四】基于docker快速构建webpack的开发与生产环境

目录

• 用前端姿势玩docker【一】Docker通俗理解常用功能汇总与操作埋坑
• 用前端姿势玩docker【二】dockerfile定制镜像初体验
• 用前端姿势玩docker【三】基于nvm的前端环境构建技巧
• 用前端姿势玩docker【四】基于docker快速构建webpack的开发与生产环境
• 用前端姿势玩docker【五】快速构建中类Unix系统与Windows系统的差异化处理

前言

关于docker构建前端环境，相关的坑点与难点，基本上都在这儿了，很多都是个人尝试总结的经验，都是从小白过来的，希望能帮助大家快速解决一些问题，抛开前端环境来看，差不多点的镜像基本也够用了。反而前端对易用性的要求更高（前端开发人员可不是天天跟linux打交道），还需要考虑类unix系统与windows的差异化问题，这点会在下一篇文章中重点说明。

打赏啥的也不需要，如果可以，很感激能在github上给打个小星星✨: https://github.com/pomelott/webpack4-cli

回顾

之前也说过 docker对于前端而言组重要的两个优势：

1. 工作环境的快速构建
2. 工作环境的统一
   所以利用docker的工程化工作流在想象中应该是这样的：
   例如一个新人从0到1构建前端环境： 安装docker => 拉取镜像 => 根据环境（dev、build）的不同传入不同的环境变量运行相应的容器 至此ok，易用性做到位之后，整一个开发环境基本相当于是在安装软件，这样基本上就很香了。

难点与坑点

以下主要分享一下过程当中出现的比较坑或比较重要的点，在此不做傻瓜式的教程，也希望大家能够多动手操作，遇到问题尝试自我解决并开源分享。

坑点一：docker pull 基础镜像拉取缓慢

首先获取镜像有这么以下三种方式：

1. dockerHub: 镜像最全， 但访问速度慢，很蛋疼
2. 局域网仓库：需要手动搭建，公司内部大批量使用的最佳方案，但不建议个人开发者使用
3. 通过import 引入他人导出的压缩包来获取镜像
   关于使用dockerhub镜像缓慢的问题在第三篇文章中已经介绍过了，配置了DNS、切换了阿里，网易，中科大的国内源之后，很可能仍然很缓慢，之前的方法网上一抓一大把，效果有限，有时候拉取一个源，一下午都拉不下来，只能等晚上才会稍微好点。关于这点，经过这么多次尝试后（至少对于我个人所处的网络拓扑结构下），最稳定，速度最快的是使用阿里云的个人镜像加速：登录阿里云 => 搜索容器镜像服务 => 寻找 镜像加速器 => 按照文档操作即可。 至少使用第一种方法来说，这已经是我尝试过的最快的方法了。

坑点二：alpine安装nvm夭折

• 这里首先要了解alpine是一个非常小巧的linux基础镜像， alpine + busybox 的架构与传统双系linux发行版不同，并且手动安装直接安装的时node最新版本，多版本的node难以同时存在，当然也不是不能安装nvm，只是比较麻烦。在此建议直接跑apk的命令， 个人尝试过切换稳定源后，安装非常迅速，即便是通过反复安装切换node版本也非常迅速。

坑点三：命令找不到，例如 sh: 命令未找到

在linux镜像中若出现not found或者命令未找到的报错信息，多半是因为环境变量未找到，未在相应文件中（~/bashrc, ~/.zshrc, ~/.profile, ~/.bash_profile）导出环境变量, 根据不同的基础镜像与shell类型，与环境变量相关的文件也不尽相同： 例如ubuntu的文件为 ~/.bash_profile。

• 单次生效可直接使用 export， 但需要注意，在dockerfile中，尽量在同一个layer层中使用export，也就是在同一个RUN命令下导出。
• 使用source命令执行相应的配置文件，此处需要注意 ubuntu的 sh命令是基于dash，因此source不能直接使用，需要利用 /bin/bash -c "source ~/.bash_profile"
• 在dockerfille中通过ENV 设置环境变量可能是最方便的做法。

坑点四：build失败 网络问题，build后不是最新的

1. 首先说build失败的网络问题
   此项主要涉及yum、apt-get等update操作或者安装软件包的问题，需要保证两点：
   • docker编译环境 与 宿主机的 网络连接问题，这点可以通过参数 --network解决，注意 build是 --network， 而 run是 --net

     docker build -t <image>:<tag> --network=host .
   

   • 修改相应的镜像源
     例如使用alpine需要修改 /etc/apk/repositories：

     echo "http://mirrors.aliyun.com/alpine/latest-stable/main/" > /etc/apk/repositories \
     && echo "http://mirrors.aliyun.com/alpine/latest-stable/community/" >> /etc/apk/repositories \
   

   使用ubuntu则需要修改 /etc/apt/sources.list
2. 使用 docker build之后，发现build的镜像不是最新的，与dockerfile不符
   如果确定自己run的image和tag都正确，一般出现这种情况大概率是因为缓存，缓存这个东西嘛，你是个前端你还不懂吗？哈哈，清除缓存即可

     docker build -t <image>:<tag> --network=host --no-cache.
   

坑点五: 容器内无法ping通内网其他ip，打开VPN同样如此.

• 具体表现可能有很多中，比如说：timeout、no route、can't access等，且不通的多为内网ip。
  解决方法为修改/etc/docker/daemon.json ，增加bip，与内网分配至不通网段，例如当前使用172.17.x.x,则改为172.16.x.x

{
  "experimental" : false,
  "debug" : true,
  "bip": "172.16.10.1/24"
}

坑点六：npm install 易失败，安装时间长

• 在此有必要说一下npm，cnpm，yarn的锁机制：
  首先需要清除版本号前面^与_的区别，1.2.3匹配的是1.2.3-1.2.x ; ^1.2.3 匹配的是 1.2.3-1.x.x

1. npm： 存在锁机制 ，高版本(具体忘记了) 增加 package-lock.json， 可以再相同的package.json 与 package-lock.json 配合下安装确定版本的npm包。
2. cnpm：不存在锁版本，目的是使用符合严格规范的包(按照 大.中.小 来说， 大版本的数字代表的重大的更新， 中版本的数字代表着功能迭代，但要向下兼容，小版本则代表bug修复)， 默认安装大版本下最新的包。
3. yarn： 存在锁机制，使用yarn.lock（version字段、resolved字段共同起作用）
   install 时安装时间长主要因为源不够稳定快速，nrm是一个解决方案。

• 其次主要涉及一些特殊的包例如： node-sass，这个包在不同的node大版本下，兼容的版本是不同的：
• 其次还要注意可能是npm缓存有影响：

npm uninstall xxx --save
npm cache clean -f
npm install xxx

NodeJS	Minimum node-sass version	Node Module
Node 14	4.14+	83
Node 13	4.13+	79
Node 12	4.12+	72
Node 11	4.10+	67
Node 10	4.9+	64
Node 8	4.5.3+	57

坑点七：-v 挂载卷后，容器内文件被清空

• 我们起初的想法是，通过本机目录挂载容器目录，从而实现修改源码的目的，但实际操作中会出现挂载后容器内 挂载卷内的文件缺失的情况。主要原因如下：
  宿主机 /home/files/src 与 容器 /home/src 相挂载， 是以宿主机目录 /home/files/src/ 为基准，若起初宿主机目录为空，容器对应目录存在文件，则挂载后，容器内文件会被清空。在此有个小技巧： 大部分情况下源码都在版本控制器中，以git为例，容器内文件被清空后，可以通过 git status 查看，是存在操作记录的，所以清空操作与git并不冲突， 使用正则做部分匹配还原即可：

      git checkout -- src/**

• 其次数据的通信、备份、恢复等操作可以通过数据卷容器，可以回看我的第一篇文章。

坑点八：宿主机访问docker容器内webpack-dev-server，端口映射失败

• 这里首先要ping 一下127.0.0.1 保证本地的回环地址是通的，并且TCP/IP功能正常。
• 其次最重要的一点就是 webpack-dev-server的配置中要确保host设置为： 0.0.0.0
devServer: { ... host: '0.0.0.0', port: '9999', }
• 然后使用 docker run 做端口映射即可

      docker run -it -p 9999:9999 <image>:<tag>

坑点九：在宿主机访问后，webpack 热更新失败

当时想达到的效果就是通过容器执行dev操作，开启webpack-dev-server做端口映射，宿主机浏览器直接访问相应网址， 由于挂载卷中的文件与容器相连，修改后可根据热更直接显示在宿主机浏览器上，这样就大功告成了。
但实际操作过程是这样的：

1. 首先开启容器

docker run -it -v /Users/tate/Documents/work/geek/docker/ws/src:/home/webpack4-cli/src -p 9999:9999 ws:1 /bin/bash

2. 在对应目录下执行 npm run dev 启动开发模式
3. 在宿主机浏览器使用 localhost 访问， 成功访问。
4. 修改挂载的数据卷中的文件，检查是够能够热更新。
5. 热更新失败，但是刷新后，修改内容生效。
   解决此问题需要保证以下几点：

• 按照坑八将devServer的host修改为 0.0.0.0
• 将webpack的output配置按照以下修改：

// 此处的publicPath的端口号要与devServer中相同
module.exports = {
      output: {
          publicPath: `//localhost:9999/`,
          hotUpdateChunkFilename: 'js/hot-update-[name].js',
          hotUpdateMainFilename: `hot-update.json`
      }
}
//  在宿主机通过localhost或宿主机IP访问，避免通过0.0.0.0访问

坑点十 npm部分包构建不成功

• 在一些相对小巧的镜像或者镜像的slim版本中，不会默认安装编译构建c++程序的基础包，所以一些node包就会构建失败，例如：

# error
gulp-imagemin: Couldn't load default plugin "gifsicle"
# error 
gifsicle pre-build test failed

安装对应的编译c++的基础包即可， 拿ubuntu来讲,需要在dockerfile中安装以下包：

apt-get install -y  g++ make automake gcc

成型

dockerfile配合shell脚本做差异化处理

• 解决上述问题后，可以再dockerfile中将宿主机的shell脚本copy至镜像中，在默认启动时执行：

COPY init.sh /home/

CMD ["/bin/bash", "-c", "/home/init.sh"]

• init.sh 文件则根据传入的环境变量构建不同的环境 dev or build

# !/bin/bash
source ~/.bash_profile
cd /home/webpack4-cli
git checkout -- src/** page/**
echo "WEBPACK_MODE: $WEBPACK_MODE"
if [ $WEBPACK_MODE = 'dev' ]; then
      echo "running in develop mode"
      npm run dev
else
      echo "running in build mode"
      npm run build
fi

• 测试阶段的dockerfile也做一下展示，详细的可见github：https://github.com/pomelott/webpack4-cli

FROM pomelott/webpack-cli
WORKDIR /home/webpack4-cli
COPY init.sh /home/
COPY cli-config.js /home/webpack4-cli/
COPY output.js /home/webpack4-cli/config/dev/
RUN chmod -R +x /home/init.sh
EXPOSE 9999
CMD ["/bin/bash", "-c", "/home/init.sh"]

实际使用

• dev环境，挂载容器卷，端口映射开启热更
  注: 因不需要手动执行 npm run dev ，所以不需要手动指定/bin/bash

      docker run -it -p 9999:9999 -v /Users/tate/Documents/work/geek/docker/ws/src:/home/webpack4-cli/src --env WEBPACK_MODE=dev pomelott/webpack-cli:latest

• build 环境
  注： 根据个人需要更换挂载目录：/Users/tate/Documents/work/geek/docker/ws/src 、/Users/tate/Documents/work/geek/docker/ws/dist

      docker run -it -v -v /Users/tate/Documents/work/geek/docker/ws/src:/home/webpack4-cli/src \
       -v /Users/tate/Documents/work/geek/docker/ws/dist:/home/webpack4-cli/dist --env WEBPACK_MODE=build pomelott/webpack-cli:latest

这里分享一个本人已构建成型的前端镜像，欢迎使用。如果有帮助请赐我一颗小行星✨：https://github.com/pomelott/webpack4-cli

Dockerhub: docker pull pomelott/webpack-cli