见字如晤。
前段时间,Node.js 官方发布了Node 8.9.3 LTS版本,并且官网首页提示新版本有重要安全更新,“Important security releases, please update now!” ,然后我立即着手公司产品各个模块的Node版本升级。
发布基础镜像
我们所有项目均使用Node.js实现,并采用Docker容器交付和部署,所以要升级所有产品的线上Node.js版本,只需要更新一下Docker镜像打包时的配置文件Dockerfile即可。下方就是一个典型项目的Dockerfile配置文件。
FROM maichong/node:8.9.1
MAINTAINER Maichong Cloud <support@maichong.io>
RUN apt-get update \
&& apt-get install -y --no-install-recommends openssh-client \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/*
COPY package.json /app/
WORKDIR /app
RUN npm install --production \
&& rm -R ~/.npm*
COPY . /app
CMD node index.js
脚本大意:
- 基于 maichong/node:8.9.1 基础镜像构建
- 记录作者信息
- 运行 apt ,为镜像安装 openssh-client 软件
- 拷贝代码 package.js 到目标镜像中
- 设置镜像容器工作目录为 /app
- 在镜像中运行 npm 安装依赖
- 拷贝代码到目标镜像的 /app 目录中
- 设置镜像的启动命令
技巧: 这里先拷贝 package.js 再安装npm依赖,最后拷贝代码,这样的好处是:项目代码经常变动,而项目的npm依赖一般不会变化,这样的顺序安排可以有效利用docker build缓存,在package.js没有变化的情况下跳过漫长的npm依赖安装时间,大大提高打包速度。
从上边的Dockerfile配置文件中看到,我们的项目均依赖于基础镜像 maichong/node
,这是我们自己发布的Node.js镜像,和Node.js官方镜像的主要区别是:我们的镜像使用了阿里云的 debian apt 源镜像,并采用了 registry.npm.taobao.org 做npm加速镜像。
所以,首先要做的是发布一个新版本的Node.js镜像:maichong/node:8.9.3。
发布过程很简单,编写基础镜像的Dockerfile,在本地构建镜像,最后将镜像推送到Docker官方的仓库,Done!
基础镜像的Dockerfile可以在这里找到 https://github.com/liangxingc... 。之所以在本地构建,而没有使用Docker仓库的 automated build,是因为,我们的镜像采用了国内阿里云的 Debian apt 源,再加上某些很奇妙的网络因素,在Docker Hub中自动构建时,apt升级总会失败。
升级项目
maichong/node:8.9.3 基础镜像已经准备就绪,接下来开始升级公司的各个项目。
我们的所有项目都基于脉冲云 maichong.io 进行管理,脉冲云包含了从代码仓库,到自动化构建,再到自动化部署等持续集成流程。
修改项目的Dockerfile,将基础镜像变更为 maichong/node:8.9.3,然后将代码提交到代码仓库,然后起身泡了一杯咖啡,悠然地等待脉冲云自动地在线编译打包Docker镜像,并自动将最新的镜像部署到服务器集群上,完成升级工作。
意外!
当我端者刚刚泡好的咖啡回到工位,意外发现,脉冲云在线编译构建失败!心里一凉,我*,何方BUG在此作祟?!赶快在线查看构建日志,导致失败的关键部分日志如下:
2017-12-12 10:04:05 Step 5/12 : RUN apt-get update && apt-get install -y --no-install-recommends openssh-client && apt-get clean && rm -rf /var/lib/apt/lists/*
2017-12-12 10:04:05 ---> Running in c3fb701ef925
2017-12-12 10:04:06 Ign http://mirrors.aliyun.com jessie InRelease
...
2017-12-12 10:04:07 Fetched 11.1 MB in 1s (6028 kB/s)
2017-12-12 10:04:09 Reading package lists...
2017-12-12 10:04:10 Building dependency tree...
2017-12-12 10:04:10 Reading state information...
2017-12-12 10:04:10 The following extra packages will be installed:
2017-12-12 10:04:10 adduser debconf debianutils dpkg ... (一共40个软件包)
2017-12-12 10:04:10 Suggested packages: ...
2017-12-12 10:04:10 Recommended packages: ...
2017-12-12 10:04:12 0 upgraded, 40 newly installed, 0 to remove and 0 not upgraded.
2017-12-12 10:04:12 Need to get 16.7 MB of archives.
2017-12-12 10:04:12 After this operation, 44.7 MB of additional disk space will be used.
2017-12-12 10:04:12 Get:1 http://mirrors.aliyun.com/debian/ jessie/main sensible-utils all 0.0.9 [11.3 kB]
...
2017-12-12 10:04:22 dpkg: error processing archive /var/cache/apt/archives/libgcc1_1%3a4.9.2-10_amd64.deb (--unpack):
2017-12-12 10:04:22 pre-dependency problem - not installing libgcc1:amd64
为了限制篇幅,上边贴出的构建日志进行了精简,大量的 apt 网络请求和解压缩包日志使用 … 代替,同时apt显示了大量的必须或推荐安装的软件包也以 … 省略。
从日志中得到错误信息是,在docker build打包过程中,运行apt安装openssh-client失败,最直接的错误是因为openssh-client依赖的libgcc1包安装失败。
直接反应是,莫非又是apt软件仓库依赖的问题?!咦,我为什么要说又呢?
apt 是Debian和Ubuntu系统使用的包管理器,类似Node.js世界的npm的作用,用来管理、安装Linux系统中的各种软件包,各种软件包又有不同版本并互相依赖。apt安装软件时,会从网络服务器上获取所需软件包和相关依赖包,这里的“网络服务器”被称为“源”,所以上文中说到的 maichong/node 镜像用到了国内阿里云的“源”,是为了加快apt安装软件时的网络速度,阿里云的“源”服务器是对Debian官方源的加速镜像。
由于apt所管理的软件包数量众多、版本众多、互相依赖、互相依赖指定版本,所以容易造成依赖问题,比如 A依赖于B的1.0版本,C依赖于B的2.0版本,如果安装了A,安装C时就会出错,因为系统中无法共存B的1.0和2.0两个版本。
题外话,npm采用多层node_modules目录嵌套解决了一个包不同版本共存的问题。
仔细观察安装openssh-client时所安装的40个依赖包,发现竟然有dpkg这样非常基础的包,怎么可能?!dpkg是Debian系统最基础的包管理器,apt都是依赖于dpkg,所有能跑起来的Debian系统一定是存在dpkg包的,难道是...
基础镜像是“坏”的?
Docker的镜像一旦构建完成,就一定能够正确执行,我个人从未见过某个镜像自身是“坏”的,可能这次要开眼!
这里之所以说“坏”,是因为镜像中整个apt管理依赖都错乱了,可能是某些原因造成了镜像的“损坏”!
在我本地执行构建命令:
docker build -t test ./
然后竟然构建成功!说明基础镜像没问题,莫非又是环境差异问题?!本地构建日志如下:
Step 5/12 : RUN apt-get update && apt-get install -y --no-install-recommends openssh-client && apt-get clean && rm -rf /var/lib/apt/lists/*
---> Running in 237bec98f4e6
Ign http://mirrors.aliyun.com jessie InRelease
...
Fetched 11.1 MB in 11s (972 kB/s)
Reading package lists...
Building dependency tree...
Reading state information...
The following extra packages will be installed:
libbsd0 libedit2
Suggested packages:
ssh-askpass libpam-ssh keychain monkeysphere
Recommended packages:
xauth
The following NEW packages will be installed:
libbsd0 libedit2 openssh-client
0 upgraded, 3 newly installed, 0 to remove and 8 not upgraded.
从日志中发现,在我本地构建时,apt安装openssh-client只需要安装3个软件包。这怎么可能?!同样的基础镜像,同样都使用阿里云的源,难道是...
阿里云源镜像数据问题?
阿里云的源镜像服务是搭建在CDN上的,CDN的目的是为了让用户就近访问不同地理位置的服务器,以达到不同地区的用户访问速度都能很快,所以虽然使用了同样的源镜像地址,但是在不同位置更新apt时,所请求的阿里云服务器是不一样的。那么就有可能是阿里CDN数据不同或是从国外Debian官方服务器数据同步未完成导致的问题。
登录到远程脉冲云Builder Runner,这是专门用来执行用户自动化集成的服务器,一开始我们的在线构建就是发生在这里的。在Runner上 ping mirrors.aliyun.com 得到的源镜像IP地址和我本地的果然不一样。
然后我将在Runner上得到的IP地址,加到了我本地DNS解析中,这样,我本地再运行apt时,访问的服务器就和在Runner上是一样的了。
然而,在本地再次构建成功。说明并非是阿里云源镜像数据问题。同样的镜像,同样的源服务器,不同的apt运行结果,难道是...
远程主机上的镜像损坏?
会不会是我本地拉到的镜像是好的,但是远程Runner上拉到的镜像却是坏的?
这是不可能的,因为Docker在拉取镜像后,会对镜像进行验证,所以同一个镜像版本,多人拉取完成后可以保证每个人所得是一模一样的。不会存在某人拉取到一个损坏的镜像的情况。
似乎所有可能性都被排除了,问题仍然得不到解决,真是莫名其妙,手上的线索已经全部断掉,案件侦破进入了僵局。
我向团队说明了我遇到的情况,邻桌Mr.Li断言道:“一定是环境差异导致的BUG!”
是呀,一定是环境差异问题,但是所有环境差异都排除过了,同样的网络环境,同样的构建配置,同样的镜像...
我们知道Docker的优势就在于将软件和运行环境打包成一个镜像,一个镜像在不同外部环境下执行,能够保证镜像内的程序所在的镜像内部环境一模一样,因为Docker运行容器时,会将环境完全隔离。不对,并没有“完全”隔离,难道是...
宿主机内核差异问题?
在本地和在Ranner上分别执行uname -a
,果然得到的内核版本是不一样的。
本地:
Linux local 4.4.0-103-generic #126-Ubuntu SMP Mon Dec 4 16:23:28 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Runner:
Linux runner02 4.4.0-98-generic #121-Ubuntu SMP Tue Oct 10 14:24:03 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
本地的Linux内核版本是 4.4.0-103-generic
,远程Runner宿主机内核版本是 4.4.0-98-generic
。尝试升级远程Runner宿主机内核:
apt-get update
apt-get dist-upgrade
将宿主机内核升级到了最新版4.4.0-103-generic
,重启Runner后,在线Docker打包成功!
总结
其实Docker运行容器时,并非将所有环境“完全隔离”,比如宿主机内核就没有隔离。Docker并不像VMware那样,在启动虚拟机时,完全虚拟一个硬件环境,然后从头加载虚拟机操作系统的内核。Docker容器运行时,仍然依赖于宿主机内存里正在运行的内核,虽然不同容器使用不同镜像,但镜像的本质是文件系统的压缩包,是让你的容器运行时有一个自己定义的文件系统和软件群,而执行容器程序时,并没有从头为你启动一个系统内核。所以我们称Docker为轻量级虚拟化技术。
本文所遇到的问题的原因应该是,在构建 maichong/node:8.9.3
镜像时,是在 4.4.0-103-generic
版本内核环境下执行的,apt 安装的一系列软件是适用于 4.4.0-103-generic
版本的,而在Runner上执行构建时,内核又变为了 4.4.0-98-generic
,可能 是apt
将之前基础镜像中的一些软件标识为无效,又要进行重新安装。
这种情况我之前也从未见过,所以撰文记录,可以断定,Docker Hub大部分镜像编译时的内核环境和我们本地的内核是不一样的,怎么单单这次apt会出错?apt在管理软件时,系统内核对apt有怎样的具体影响?待来日机缘成熟再一探究竟。