Docker镜像的大小,我们知道影响传输、分发和启动,但具体而微,对启动的影响有大呢?
那么,首先是建立评判的标准。如果缺少必要的前提条件,也很难讲结论的正确性...
# 前置条件
+ 独立测试环境,缺少其他并发干扰
+ 运行相同输出时间戳的代码,例如,printloop.sh
+ 大size镜像的容器先启动,小size镜像的容器后启动
# 评判标准
- 如果后启动小size镜像的容器在多次试验中,能够后发先至,说明小size镜像的容器启动具有明显的优势
# 测试脚本
# printloop.sh
trap "exit 0" TERM
logfile="$(hostname)".txt
cat /dev/null > $logfile
while true
do
echo "$(hostname) print $(date +'%Y-%m-%d %H-%M-%S-%N')" >> $logfile
sleep 1
done
##########################################################
# test.sh
set -e
sudo docker run --rm -d --name "abc" -h "centos" -v $PWD:/workspace -v /etc/localtime:/etc/localtime:ro -w /workspace centos:centos7.6.1810 /bin/sh printloop.sh &
sudo docker run --rm -d --name "abc1" -h "ubuntu" -v $PWD:/workspace -v /etc/localtime:/etc/localtime:ro -w /workspace ubuntu:20.04 /bin/sh printloop.sh &
echo "wait job exit......."
wait
echo "finish ......."
# 试验结论
+ 小size镜像容器启动,并不能经常后发先至。Docker对启动几百M镜像的容器速度还是非常快的!
# 未来工作
+ 评判标准可能不够准确和精确,以资交流、讨论:)
# 预测
+ 在服务器压力比较大的时间,小size镜像容器优势还是可能会显现出来
# 参考
+ ‘’‘find . -size +1M’‘’ shell命令可用于在容器中寻找比较大的文件
# 已知故障
- 在Dockerfile中通过RUN命令对大的目录,无差别地变更执行权限,非常不可取!
例如 ‘’‘RUN chmod -R +x .’‘’ 导致镜像size暴增一倍!
更应该通过在docker build image 上下文环境中或版本库中加入文件的执行权限,进行减小镜像大小