Docker镜像大小是否影响启动速度的试验

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镜像容器优势还是可能会显现出来

# 参考

+ 官网dockerfile最佳实践

+ ‘’‘find . -size +1M’‘’  shell命令可用于在容器中寻找比较大的文件

# 已知故障

- 在Dockerfile中通过RUN命令对大的目录，无差别地变更执行权限，非常不可取！

例如  ‘’‘RUN chmod -R +x .’‘’ 导致镜像size暴增一倍！

更应该通过在docker build image 上下文环境中或版本库中加入文件的执行权限，进行减小镜像大小