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

时间：2021-10-23 13:58:34

目录

前言

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

打赏啥的也不需要，如果可以，很感激能在github上给个小星星，github入口在 博客最顶部

回顾

之前也说过 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"

坑点四：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.

坑点五：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大版本下，兼容的版本是不同的：

    | 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/webpack-multipage-cli/src -p 9999:9999 ws:1 /bin/bash
  1. 在对应目录下执行 npm run dev 启动开发模式
  2. 在宿主机浏览器使用 localhost 访问， 成功访问。
  3. 修改挂载的数据卷中的文件，检查是够能够热更新。
  4. 热更新失败，但是刷新后，修改内容生效。

    解决此问题需要保证以下几点：
  • 按照坑七将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访问

成型

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/webpack-multipage-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
FROM pomelott/webpack-cli

WORKDIR /home/webpack-multipage-cli

COPY init.sh /home/

COPY cli-config.js /home/webpack-multipage-cli/

COPY output.js /home/webpack-multipage-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/webpack-multipage-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/webpack-multipage-cli/src \

       -v /Users/tate/Documents/work/geek/docker/ws/dist:/home/webpack-multipage-cli/dist --env WEBPACK_MODE=build pomelott/webpack-cli:latest

相关文章