是的，你可以的，你通常要做的是
备选方案A：
创建一个busybox映像并复制您的框架，将该位置公开为一个卷
VOLUME /opt/framework/
FROM alpineCOPY framework /opt/frameworkVOLUME /opt/frameworkCOPY busyscript.sh /usr/local/bin/busyscriptRUN chmod +x /usr/local/bin/busyscriptCMD ["busyscript"]
虽然
busyscript.sh看起来像
#!/bin/sh#set -xpid=0# SIGTERM-handlerterm_handler() { if [ $pid -ne 0 ]; then kill -SIGTERM "$pid" wait "$pid" fi exit 143; # 128 + 15 -- SIGTERM}# setup handlers# on callback, kill the last background process, which is `tail -f /dev/null` and execute the specified handlertrap 'kill ${!}; term_handler' SIGTERMecho "Started pre"# wait foreverwhile truedo tail -f /dev/null & wait ${!}done将该图像作为服务添加到您的docker-compose.yml中，让我们说“ framework”，然后在您希望它们使用的服务上添加
volume_from - framework:ro
优点：
- 您可以编译，构建和部署framworks soley
- 运行此额外的容器几乎没有运行时开销
缺点：
- 图像大小的开销（高山，30mb）
备选方案B 您将服务之一用作“框架基础”，假设服务A，这意味着您在该服务上复制了该框架（使用该服务的两个框架之一），并且再次使用该框架
VOLUME/opt/framework作为卷公开
在服务B中，以相同的方式安装卷
serviceB: volume_from - serviceA:ro
优点：
- 没有额外的容器
缺点：
- 框架需要与服务A一起部署，无论服务A是否需要更新
- 您对A有依赖性，A是否需要更新，由于共享，需要重新创建所有其他容器
