我想在应用程序的官方docker基础映像中包含并启用一些自定义插件。
以下是目录结构的样子;
<input type="radio" placeholder="" name="answer['.$idx.']" value = "true" id=""> True
<input type="radio" placeholder="" name="answer['.$idx.']" value = "false" id=""> False
如果我需要包含插件 plugin_1 ， plugin_3 ， plugin_7 和 plugin_8
.
+-- Dockerfile
+-- plugins
| +-- plugin_1
| +-- plugin_2
| +-- plugin_3
| +-- ...
| +-- plugin_n
问题是，是否可以迭代/循环遍历列表以消除上面的样板？
例如，像下面这样的Dockerfile会更干净，更易于维护;
FROM myapp_officialimage
COPY plugins/plugin_1/* /usr/lib/myapp/plugins/
RUN myapp-plugins.sh enable plugin_1
COPY plugins/plugin_3/* /usr/lib/myapp/plugins/
RUN myapp-plugins.sh enable plugin_3
COPY plugins/plugin_7/* /usr/lib/myapp/plugins/
RUN myapp-plugins.sh enable plugin_7
COPY plugins/plugin_8/* /usr/lib/myapp/plugins/
RUN myapp-plugins.sh enable plugin_8
CMD ["myapp-start.sh"]
答案 0 :(得分：0)
在您的情况下，我会准备一个新的插件文件夹以及安装它们的（可能是生成的或手工制作的）脚本。将真正的插件文件夹添加到public void ExportMeshToObj(string filepath)。然后复制新文件夹并运行安装脚本。这也减少了在构建开始之前上载到docker的上下文的大小。无论如何，你都在挑选依赖项，所以事先做好工作（在你.dockerignore之前）应该可以正常工作。
在构建系统中，您应该执行以下操作：
build这两层可能是：
collect_plugins.sh # Creates the new plugin folder and install script
docker build <params>
如果您准备要发送给docker的上下文，它将使COPY plugins_selected/ /usr/lib/myapp/plugins/
RUN /usr/lib/myapp/plugins/install.sh
变得更加简单（一件好事）。我们只是在Dockerfile之前解决问题。
通常使用包管理器通过网络获取依赖关系，或者只是通过http（s）下载它们。像你一样将它们复制到构建上下文中并不一定是错的，但它会变得更加尴尬。
让我们来看看docker如何处理build （稍微简化）。
当你Dockerfile时，docker会将上下文中的所有文件上传到docker引擎（build中提到的路径除外）并开始处理.dockerignore。目的是生成代表最终图像的文件系统层。
当您执行Dockerfile之类的操作时，docker实际上启动一个容器来执行命令，然后将生成的图层添加到图像中。在制作中实际运行的唯一内容是您在RUN和/ CMD末尾ENTRYPOINT中指定的内容。
尽量创建尽可能少的图层。