在Docker映像中压缩大文件夹，然后在入口点提取它们，有什么缺点吗？

Question

广义问题

压缩一个Docker映像中的大文件夹，然后在图像的入口点中的容器级别提取它们，有什么坏处吗？

缺点：

• 不像可重用的那样。(但假设它是一次性图像，这不是什么问题)
• 由于提取文件夹的延迟而缓慢启动。

优点：

• 在某些情况下显着地缩小了图像大小！！

示例dockerfile：

FROM some/image:latest
COPY ./venv.tar.gz .
COPY ./some_python_script.py .
SHELL ["/bin/bash", "-c"]
 
  # if directory venv does not exist: extract it to root then remove the tar file
ENTRYPOINT  [ ! -d "venv" ] && tar xzf venv.tar.gz && rm venv.tar.gz || \ 
  # else: it already exists so we don't have to waste time doing it again
  echo 'venv already extracted from tar' && \
  # these always run
  source venv/bin/activate && \
  cd /app && \
  python "some_python_scipt.py"

为什么我要问

我伪造了一个不包括数据的整个PyTorch地理空间培训应用程序。然而，地理空间培训包是巨大的，更不用说PyTorch和Cuda图书馆的规模了。仅我的映像的虚拟环境就有10.9GB，因此总的图像大小为11.5GB。这也是在多级构建中使用conda-pack优化的v-env。预先压缩它们，将图像大小缩小到5.2GB。

运行的容器在运行时显然是原来的11.5GB。然而，缩小的图像大小使它更容易管理，特别是在速度时推和拉从码头枢纽。

演示压缩conda虚拟环境的完整要点：https://gist.github.com/NoahTarr/cdc0af59ebc84fc9d936eece35ebfaf7

Answer 1

我建议这个设置有三个问题：

就本地磁盘空间而言，

1. 需要1.5倍的存储空间才能运行容器的单个实例，然后每个附加实例都需要相当于整个虚拟环境(大)大小的额外空间。也就是说，每个容器需要一个压缩的venv副本，再加上一个未压缩的venv副本。如果未压缩的it在图像中，则只需在所有容器中复制一份。

1. 解压缩一个大型tar文件需要时间，这可能会使您的容器启动速度明显减慢。

1. 我遇到了一些实际问题，docker push和docker pull单独的层比1GB还大。您可以使用一些技巧来使各个层更小，例如，在RUN pip install pytorch之前使用RUN pip install -r requirements.txt。使用此设置，您别无选择，只能拥有一个5GB的tarfile层.

尽管如此，我相信这种方法将从根本上起作用；同样，假设您可以成功地使用docker push和docker pull。我要做的一个改变是将复杂的入口点行分解为一个单独的shell脚本：

#!/bin/sh
# entrypoint.sh

# Unpack the virtual environment if it doesn't already exist
if [ ! -d venv ]; then
  tar xzf venv.tar.gz
else
  echo 'venv already extracted from tar'
fi

# Add the virtual environment into $PATH
. venv/bin/activate

# Run the main container CMD
exec "$@"

# Dockerfile
...
WORKDIR /app
ENTRYPOINT ["./entrypoint.sh"]
CMD ["python", "some_python_script.py"]

这将允许您执行像docker run --rm your-image ls venv/python3.10/site-packages这样的操作，在不实际运行主应用程序的情况下查看已爆炸的树。