coolliyong.github.io

解决80%docker环境问题

背景

部署过程中总是会碰到各种各样的问题，比如在本机能启动，放到docker容器中就无法正常运行，对于这样的问题，既不好调试，也不好定位。 今天记录一个我遇到的问题：一个图片处理库，安装的时候需要下载一些二进制的文件，在jenkins中安装非常慢，几乎装不上，这个问题困扰我了一天

解决方法

于是求助了部门的架构师大佬，他告诉我，如果实在安装不上，可以使用本机打包一个基础镜像的方式来部署。

基础镜像方式指的是通过本机运行良好的环境下，把项目的package.json单独提成一个项目，在项目中进行from node基础镜像操作，npm install操作， 安装完依赖，进行docker build，把本机的镜像推送到 容器云 上面，这就是一个基础镜像。

基础镜像配置

FROM node:latest
LABEL liyonglong "liyong857637472@163.com"

COPY . /usr/src/webapp
WORKDIR /usr/src/webapp

CMD npm install 

然后docker build 在推送到容器云

然后业务项目 from 的镜像是刚刚推上去的基础镜像

业务项目镜像配置

FROM nodeservice-basic:node-12.15.0-v1
LABEL liyonglong "liyong857637472@163.com"

COPY . /usr/src/webapp
WORKDIR /usr/src/webapp

EXPOSE 8082

CMD node .

这样依赖的问题就解决了

其实解决的不仅仅是依赖问题，采用这种方式可以规避80%docker起不来的问题，基本上能保证你的容器是能够被启动的，启动之后产生的问题多半就是代码和宿主机或配置的问题了

优缺点分析

1. 解决大多数的容器不能启动问题
2. 尽可能的保证了开发环境和线上环境一致

缺点

1. 增加了部署步骤：如果安装了新的三方包，或者更改了package.json的三方包版本，需要更新基础镜像
2. 如果是通过本机docker容易产生安全问题：比如我一定需要在本机登录容器云，这样我本机能拉取镜像，也能推送镜像，只是有可能发生，当然也是可以规避的

总的来说，这种方式是一种很好的放好，比起镜像在生产上起不来、依赖不一致、环境不一致 基本上都可以解决了！