为什么通过 ENTRYPOINT 和 tini 安装依赖项？

如何解决为什么通过 ENTRYPOINT 和 tini 安装依赖项？

我有一个关于在 Dockerfile 上实现 dask-docker 的问题。

FROM continuumio/miniconda3:4.8.2

RUN conda install --yes \
    -c conda-forge \
    python==3.8 \
    [...]
    && rm -rf /opt/conda/pkgs

COPY prepare.sh /usr/bin/prepare.sh

RUN mkdir /opt/app

ENTRYPOINT ["tini","-g","--","/usr/bin/prepare.sh"]

prepare.sh 只是促进通过 conda、pip 和 apt 安装其他软件包。

有两件事我不明白：

1. 为什么不直接放置在Dockerfile这些指令？可能通过复制专用文件（requirements.txt、environment.yaml 等）间接（模块化）
2. 为什么要通过 tini 执行此操作？最后，它执行 exec "$@" 可以启动调度程序或工作程序 - 这更像是我与 tini 相关的内容。

这样每次从构建的镜像运行容器时都必须重复安装过程！？

也许我多虑了，但它看起来很不寻常 - 但也许这是一个有充分理由的 Dockerfile 模式。

---

可选的奖金问题为DASK业内人士：

• 为什么将 prepare.sh 复制到 /usr/bin（而不是 f.x. 到 /tmp）？
• 创建的目录 /opt/app 有何用途？

解决方法

这实际上取决于入口点脚本安装的文件的性质和用途。总的来说，我喜欢把它分成几类：

1. 在主机系统上会频繁更改的本地文件，将被卷入生产版本的最终映像。这适用于诸如正在开发且需要在容器中测试的应用程序的源代码之类的内容。您希望每次重建映像时将这些内容复制到运行时中。在 Dockerfile 中使用 COPY。

2. 来自其他地方的经常更改和/或特定于部署环境的文件。这就像来自 Hashicorp 保险库的机密、网络设置、服务器配置等……它们可能会一直下载到容器中，即使它进入生产环境也是如此。入口点脚本应该下载这些文件，并且应该根据主机注入的环境变量决定哪些文件以及从哪里获取。

3. 库、可执行程序（在 /bin、/usr/local/bin 等下...），以及除了在执行过程中计划升级。通常使用 pip、maven 或其他一些执行依赖项管理的程序安装的任何东西，以及使用 apt-get 或等效物安装的任何东西。这些文件不应该从Dockerfile或从入口点脚本安装。更好的是使用已经安装的所有依赖项构建您的基础映像，然后使用该映像作为进一步开发的 FROM 源。这有许多优点：它确保了一个稳定的、位于中心的起始平台，每个人都可以使用它来进行开发和测试（它在重要的地方强制统一）；它可以防止您攻击托管这些库的服务器（不断从 pypy.org 重新下载所有这些库是非常糟糕的形式……有人必须为该带宽付费）；它使构建速度更快；如果您有一个单独的安全团队，这可能有助于减少他们需要扫描的文件数量。

您可能正在查看 #3，但我将所有三个都包括在内，因为我认为这是对事物进行分类的有用方法。