从单独的Docker图像中组合可执行文件？
假设我需要a.exe和b.exe我的最终 node 按运行时图像。 a.exe和b.exe恰好在Docker Hub上可用，但它们来自单独的图像。 Docker是否有办法以某种方式从我的最终图像中可用的不同图像中制作同时可执行文件？
我认为Docker的多阶段构建并不重要，因为它仅简化了我们希望在下一个图像上可用的 trafacts 。而在我的情况下，我需要以前图像的整个运行时环境。我可以选择 run run shell命令手动安装这些依赖性，但这确实是唯一的方法吗？
Let's say I need A.exe and B.exe installed in my final node image by runtime. Both A.exe and B.exe happen to be available on Docker Hub, but they're from separate images. Does Docker have a way to somehow make both executables from different images available in my final image?
I don't think Docker's multi-stage build is relevant as it only simplifies passing artefacts that we want available on the next image. Whereas in my case, I need the whole runtime environment from previous images to be available. I have the option to RUN shell commands to manually install these dependencies but is this really the only way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以使用多阶段构建，因为您可以声明a。 EXE/B.EXE以及所需的运行时是所需的人工制品。
但是我同意，如果您从软件包中安装运行时，只需复制应用程序即可。
You could use a multistage build, since you could declare a.exe/b.exe together with the required runtime to be the required artefacts.
But I agree it could be easier if you install the runtime from packages and just copy the application.
如果您对所需的需求有所肯定，则可以 export 图像图像a>和图像B作为焦油球。
现在是棘手的部分：合并两个文件系统结构
提取两个档案，使您拥有一个目标文件系统结构，然后将其再次包裹在焦油球中。
因此，获取文件并非不可能 - 但是您需要确切知道自己在做什么。
最后， import tar ball to docker映像。
If you feel sure enough about what you need, you could export image A and image B as tar balls.
Now comes the tricky part: merging the two filesystem structures
Extract both archives such that you have one target filesystem structure and wrap that up into a tar ball again.
So it is not impossible to get the files - but you need to know exactly what you are doing.
Finally import that tar ball into a docker image.
获得组合图像的一种选项不是合并两个图像，而是合并两个Dockerfiles。这可能偶尔需要审查，但甚至可能比图像本身的变化频率少。
One option to get a combined image is not to merge two images but maybe merge two dockerfiles. This may need a review once in a while but might even change less often than the images themselves.